September 2007 - Darwin-kernel

Re: Bootable Kernel CD
by mm w 11 Sep '07

11 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=fbbYgwZZI8U7Lt5qTDjmLWJsYZ7N2WBS3dL39+0Y19A=; b=sFPz6AAzFGdiYxF4qiwKWnumXDgv8riYlp8/pyrG24E1ksfULDzb44chpGqnf4EUgThIXWXDYhVMqrlbEQt1nhAS1XY2uLaeWlHzwmZ8hzxu4CmPL2kO3G8YbkbO4i1w/aqS2Hw1FK128qXpSjE5rvCL4dpsqLyyIsfdC0uX23c= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DvP4XPOBnvIa2oMGE8twN+2fYYp43G38K9uTOqotX8vxvsT9MKEQg9Q9aO9F6ucLrPKwjs3JL5PGC6Mz/83we1vPAwYjDAFE/EHV2oV5wSrh6lQBu/uF2sNzkJAcJTzVryBXYzJRW+CgMHp72eLL2TaViOyNJAQxCXlC9GOVU0c= http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/hdi… -mmw On 9/11/07, Jeffrey Portman <chromox(a)gmail.com> wrote: > I am in the process of creating a bootloader + kernel and I figured > the easiest way to test this kernel would be to wrap it up into a > bootable cd, but I have yet to find any tools that will allow me to > do this on a mac. Does anyone have any suggestions or tools I should > look at? > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-kernel/openspecies%40gmail.com > > This email sent to openspecies(a)gmail.com > -- http://openspecies.googlepages.com/gpgkey.txt _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Bootable Kernel CD
by Jeffrey Portman 11 Sep '07

11 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer; bh=uYbkX8SP84wlOmQo+zLrmK8SzDcg7Xo9aS5Sr4QjkF4=; b=HT6LHLvf2IJBhefzWdO67uyw2ph4sBd+UCsrX0TFuh1HOiA7k/shNoR9DC06txqWV2SmYEH8c9ma2dyIeYHEd5se4EKFXfc1JgEA2CaV/Y8euW0sa+RDZ91tiq1K9zkaUyPVsqxJ8YFYYS3nCaMMZ2FwdguvtpJj5rKlbe0out4= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer; b=B7MGxhIP7gMn2uFxQJQG9cCaB0jBtPXlTLkEkBoew60Y3sKj4V9a5SVxQYVZmapKLMHbmF2oTbSnt7bjFoSrMni/YrZlKUhjTygHNe2QBZJLjoU13lNTO7yJlKO0qHRs2qt/OtU4wb/DIcLVBzBDuyiffKq8PqSr0zUx4ECJNjw= I am in the process of creating a bootloader + kernel and I figured the easiest way to test this kernel would be to wrap it up into a bootable cd, but I have yet to find any tools that will allow me to do this on a mac. Does anyone have any suggestions or tools I should look at? _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Bug: hanging stat()/open() on ttys in 8.10.1 ?
by Quinn 11 Sep '07

11 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Alas, not on 10.4.x and earlier. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… At 13:32 +0200 11/9/07, Phil Regnauld wrote: Ok -- no way to break into the debugger locally ? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Yielding the processor in a kext?
by Anton Altaparmakov 11 Sep '07

11 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com You're right, it is. You should, instead, either: Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On 11 Sep 2007, at 10:28, Postmaster wrote: On 7 Sep 2007, at 22:14, Anton Altaparmakov wrote: a) Fail the operation with a resource shortage error. Can't do that without leaving the FS in severe state of corruption. Keeping state and rolling back is too much effort (resources wise it would slow down things a lot) to be worth it for such an uncommon case. So fix your FS design; don't cite it as an excuse for writing bad code... This discussion is becoming pointless, sorry. It has nothing to do with my FS design. I think he means the design of the code that implements your file system, not the file system design itself. Your code should be designed in such a way that a memory allocation error caused by a memory shortage should not corrupt it. That is pretty impossible without allocating tons of memory "just in case" before every operation which would slow things down and be generally a silly thing to do. And really it is impossible to do because the allocations may be happening elsewhere in the kernel as indirect consequences of what my code is doing. Also the code operates directly on the metadata so if a memory allocation fails deeply enough in the code the previous state has been long lost so it cannot be restored and even worse often I modify some metadata, then have to release the VM page holding the metadata to avoid potential deadlocks whilst doing something else and then have to re-get the VM page to finish up the operation. If a get an ENOMEM at this point (the VM perhaps page out the page holding my metadata and now has to page it back in) I cannot get back at the metadata and thus can neither complete nor roll back the operation even if I knew the previous state. This would not be too bad in itself because I always leave metadata records in self-consistent state. The problem is that the FS has metadata records all over the place in different system files / directory indexes, other indexes, etc that all need to be consistent with each other. And here comes the problem. I update one piece of metadata and it succeeds, then I try to do the second one and that fails with ENOMEM. I then try and roll back the first change and get another ENOMEM. And now the metadata is screwed because you have records out of sync with each other and nothing you can do about it other than tell the user they have a corrupt file system and they need to unmount and check their disk or in some cases you can keep retrying the memory allocation in the hope that you can proceed (either forward or back it does not matter as long you are not left in the middle!) You try and put a relational database in the kernel as file system and put in lots of metadata duplication and cross references all over the place and then try and keep it both fast in the 99.9999% and 100% correct in the 0.0001% where a memory shortage occurs without journalling, COW, and other modern approaches to fs consistency and then you will be in my boat and see how retrying memory allocations suddenly seems like a great idea... (-; Of course the other problem is that the ENOMEM is only one of many failure modes. It could be as you say the user pulled the plug or a power outage happened or a bad sector developed or the computer's memory got corrupted, etc. And you end up leaving a corrupt FS in all those situations too. And those other cases happen a LOT more often than the odd case where the system runs out of memory so it is silly to optimize for the least common failure mode when there are so many other failure modes that are far more lethal and you have no control over at all... In 25 years of using computers I have never seen a kernel task fail with ENOMEM whilst I have lost count of how many times one of my children has pressed the off button on my external drive (which nutcase decided to make the button light up when it is on so children are attracted to pressing the light like mosquitoes?!?) or has pressed the nice and shiny round button on my MacBook Pro (and as I use it for development that is an NMI thus the machine dies immediately and I can only get it back if I plug in a second machine, enter gdb and continue!) so if my driver causes corruption less than once in 25 years of daily use I really don't mind putting up with having to run a filesystem check afterward as it fades into insignificance compared to the number of times I have had to run filesystem checks for other reasons. And your proposed solution, which is to make the thread hang around until some memory becomes available, is not really a solution at all. Your file system is in a corrupt state all the time while the thread is waiting and the wait might not end in a successful memory allocation, but in sudden termination when the bored user switches off the computer which is probably highly unresponsive if there is no kernel memory available. If they do that then they will get corruption no matter what. We do not implement journalling so pulling the plug whilst the file system is mounted guarantees that you have to run a check of the volume. I mark the FS dirty at mount time and only on clean unmount is it marked clean again so if such an event does not happen because the user rebooted by force / power failed, etc on next mount the user will be warned that the volume is dirty and that they should check the disk... And one day hopefully trying to mount will automatically run a check of the disk if the volume is dirty but that is still a long way off as we don't have a file system checker yet... This email sent to site_archiver(a)lists.apple.com

1 0

Re: Bug: hanging stat()/open() on ttys in 8.10.1 ?
by Phil Regnauld 11 Sep '07

11 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Mutt/1.5.15 (2007-04-06) Quinn (eskimo1) writes: > > casing the problem. And the best way do that, at least on currently > released systems, is to fire up the kernel debugger and get a > "showallstacks" log. This will let you figure out which locks the various > threads in question are blocked waiting for. Ok -- no way to break into the debugger locally ? I do need two machines ? (I do, it's just that I'm rarely around the second machine when this happens). > Also, if you have access to Leopard seeds, you should try to reproduce the > problem on Leopard. Nope, no Leopard for the moment. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Bug: hanging stat()/open() on ttys in 8.10.1 ?
by Quinn 11 Sep '07

11 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com <http://developer.apple.com/documentation/DeviceDrivers/Conceptual/WritingDe…> S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… At 22:27 +0200 10/9/07, Phil Regnauld wrote: Any idea on how to debug this ? My guess is that you've run into some sort of kernel bug that's causing it to leave a dangling mutex. To debug this, you need to know what mutex is casing the problem. And the best way do that, at least on currently released systems, is to fire up the kernel debugger and get a "showallstacks" log. This will let you figure out which locks the various threads in question are blocked waiting for. Also, if you have access to Leopard seeds, you should try to reproduce the problem on Leopard. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Yielding the processor in a kext?
by Quinn 11 Sep '07

11 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com We manage a bunch of (userland) threads that do some heavy computation (very similar to finite element analysis). For some reason that I'm not going to detail here, this management happens in a kext. Our goal is to make sure that none of these threads computes much faster than the others. That is, the more consistent the rate of progress across all these threads, the better the accuracy of the result of the computation. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… At 9:46 -0700 7/9/07, Régis Duchesne wrote: Are all of these threads in the same task (in the Mach sense of that word)? If so, you could use thread_policy_set (which is exported as a supported KPI) with the THREAD_PRECEDENCE_POLICY flavour to alter their priority relative to one another. Seems like that would get the job done in a fashion that's more likely to remain binary compatible in the long term. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Yielding the processor in a kext?
by Régis Duchesne 10 Sep '07

10 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Icedove 1.5.0.9 (X11/20061220) Folks, Terry wrote: > Your only input, other than using an FSA (which I see you say you can't > use because you are using a "black box thread") is to control your > thread priority. > thread priority is PTHREAD_SCOPE_SYSTEM, rather than PTHREAD_SCOPE_PROCESS Yes, given my constraints, that seems the best thing to do. I just hope it won't be too costly to do it often (at a granularity shorter than a timeslice). Benchmarking will tell :) Thanks for your input, -- hpreg _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Bug: hanging stat()/open() on ttys in 8.10.1 ?
by Phil Regnauld 10 Sep '07

10 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Mutt/1.5.15 (2007-04-06) Hi, I'm having the following problem on a stock 8.10.1 Darwin Kernel (OS X 10.4.10): Darwin macbook 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 i386 i386 ... in short, for the past few months I've been experiencing the situation where suddenly, allocation of new ttys will hang. Opening a new Terminal.app window will hang the entire application. Trying to open an xterm or any other application which allocates a tty hangs. The funny thing is, only a _particular_ tty will cause the problem, not all ttys. For example, I have ttys allocated up to ttyr2, then I try to open a new terminal, which hangs. Access to ttyr3 will hang whichever application attempts to access it - stat, open, ... will fail, but opening the next tty ttyr4 will succeed. This happens randomly, sometimes with days in between, sometimes weeks. Today it happened twice. I've tried to correllate this to some installed piece of software or kext, to no avail. Output from ktrace on "ls -l /dev": 17427 ls RET getuid 0 17427 ls CALL lstat(0x3002b0,0x3002bc) 17427 ls NAMI "/dev/ttyr2" (hangs here) Output from ktrace on "ps ax": 17191 ps NAMI "/dev/ptyr1" 17191 ps RET lstat 0 17191 ps CALL lstat(0xbffff2fb,0xbffff400) 17191 ps NAMI "/dev/ttyr2" (hangs here) Attempt to open new xterm: 17174 xterm RET close 0 17174 xterm CALL read(0x9,0xbfffef84,0x418) 17174 xterm RET read RESTART 17174 xterm PSIG SIGTERM SIG_DFL (hangs here) ... I can do "echo /dev/*", and get the list -- but any attempt to view any info about the file hangs that process. Hard reboot required (reboot -q at least). Any idea on how to debug this ? Thanks, Phil Index Refs Address Size Wired Name (Version) <Linked Against> 1 1 0x0 0x0 0x0 com.apple.kernel (8.10.1) 2 34 0x0 0x0 0x0 com.apple.kpi.bsd (8.10.1) 3 52 0x0 0x0 0x0 com.apple.kpi.iokit (8.10.1) 4 56 0x0 0x0 0x0 com.apple.kpi.libkern (8.10.1) 5 49 0x0 0x0 0x0 com.apple.kpi.mach (8.10.1) 6 25 0x0 0x0 0x0 com.apple.kpi.unsupported (8.10.1) 7 1 0x0 0x0 0x0 com.apple.iokit.IONVRAMFamily (8.10.1) 8 1 0x0 0x0 0x0 com.apple.driver.AppleNMI (8.10.1) 9 1 0x0 0x0 0x0 com.apple.iokit.IOSystemManagementFamily (8.10.1) 10 1 0x0 0x0 0x0 com.apple.iokit.ApplePlatformFamily (8.10.1) 11 47 0x0 0x0 0x0 com.apple.kernel.6.0 (7.9.9) 12 1 0x0 0x0 0x0 com.apple.kernel.bsd (7.9.9) 13 1 0x0 0x0 0x0 com.apple.kernel.iokit (7.9.9) 14 1 0x0 0x0 0x0 com.apple.kernel.libkern (7.9.9) 15 1 0x0 0x0 0x0 com.apple.kernel.mach (7.9.9) 16 16 0x584000 0x10000 0xf000 com.apple.iokit.IOPCIFamily (2.2) <11> 17 10 0x67c000 0x4000 0x3000 com.apple.iokit.IOACPIFamily (1.2.0) <11> 18 3 0x680000 0x3e000 0x3d000 com.apple.driver.AppleACPIPlatform (1.0.10) <17 16 11 6 3> 19 7 0x53a000 0x33000 0x32000 com.apple.iokit.IOHIDFamily (1.4.11) <6 5 4 3 2> 20 0 0x786000 0x5000 0x4000 com.apple.BootCache (27) <6 5 4 3 2> 21 0 0x984000 0x4000 0x3000 com.apple.driver.AppleIntelCPUPowerManagement (1.0.2) <11 6 4 3 2> 22 0 0x725000 0x3000 0x2000 com.apple.driver.AppleAPIC (1.2.0) <11> 23 2 0x82c000 0x3000 0x2000 com.apple.iokit.IOSMBusFamily (1.0.1) <5 4 3> 24 0 0x8f9000 0x5000 0x4000 com.apple.driver.AppleACPIEC (1.0.10) <23 18 17 11> 25 0 0x8f5000 0x4000 0x3000 com.apple.driver.AppleSMBIOS (1.0.12) <11> 26 0 0x8f1000 0x4000 0x3000 com.apple.driver.AppleACPIButtons (1.0.10) <19 18 17 6 5 4 3 2> 28 0 0x981000 0x3000 0x2000 com.apple.driver.AppleHPET (1.0.0d1) <17 6 5 4 3> 29 0 0x872000 0x5000 0x4000 com.apple.driver.AppleRTC (1.0.3) <17 5 4 3 2> 30 1 0x988000 0x3000 0x2000 com.apple.driver.AppleEFIRuntime (1.0.1) <17 6 5 4 3> 31 0 0x842000 0x3000 0x2000 com.apple.driver.AppleACPIPCI (1.0.10) <18 17 16 11> 32 0 0x82f000 0x6000 0x5000 com.apple.driver.AppleSmartBatteryManager (111.8.0) <23 5 4 3 2> 33 0 0x9b0000 0x6000 0x5000 com.apple.driver.AppleEFINVRAM (1.0.2) <30 11 5 4 3> 34 4 0x70d000 0x16000 0x15000 com.apple.iokit.IONetworkingFamily (1.5.1) <6 5 4 3 2> 35 6 0x609000 0x16000 0x15000 com.apple.iokit.IOStorageFamily (1.5.1) <6 5 4 3 2> 37 0 0x9b6000 0x3f000 0x3e000 com.apple.iokit.AppleYukon (1.0.11b2) <34 17 16 5 4 3 2> 38 14 0x519000 0x21000 0x20000 com.apple.iokit.IOUSBFamily (2.7.5) <6 5 4 3> 39 0 0x91e000 0xe000 0xd000 com.apple.driver.AppleUSBUHCI (2.7.5) <38 16 5 4 3> 40 0 0x98b000 0x12000 0x11000 com.apple.driver.AppleUSBEHCI (2.7.5) <38 16 5 4 3> 41 5 0x636000 0x32000 0x31000 com.apple.iokit.IOFireWireFamily (2.5.7) <5 4 3> 42 0 0x8c5000 0x19000 0x18000 com.apple.driver.AppleFWOHCI (2.9.6) <41 16 6 5 4 3> 43 0 0x582000 0x2000 0x1000 com.apple.iokit.IOUSBUserClient (2.7.6) <38 11> 44 0 0x96c000 0x9000 0x8000 com.apple.driver.AppleUSBHub (2.7.5) <38 11> 45 2 0x61f000 0xd000 0xc000 com.apple.iokit.IOATAFamily (1.7.1f4) <5 4 3 2> 46 0 0x90c000 0x8000 0x7000 com.apple.driver.AppleIntelPIIXATA (1.16) <45 16 11> 47 2 0x835000 0x6000 0x5000 com.apple.iokit.IOAHCIFamily (1.0.3) <5 4 3 2> 48 0 0x83b000 0x7000 0x6000 com.apple.driver.AppleAHCIPort (1.0.7) <47 16 5 4 3 2> 49 0 0x8e2000 0xf000 0xe000 com.apple.iokit.IOAHCIBlockStorage (1.0.6) <47 35 11> 50 4 0x6c1000 0x17000 0x16000 com.apple.iokit.IOSCSIArchitectureModelFamily (1.5.4) <11> 51 0 0x6d8000 0x4000 0x3000 com.apple.iokit.IOATAPIProtocolTransport (1.5.1) <50 45 11> 53 0 0x906000 0x6000 0x5000 com.apple.iokit.SCSITaskUserClient (1.5.4) <50 35 11> 54 2 0x92c000 0x8000 0x7000 com.apple.iokit.IOCDStorageFamily (1.4) <35 5 4 3> 55 1 0x934000 0x5000 0x4000 com.apple.iokit.IODVDStorageFamily (1.4) <54 35 5 4 3> 56 1 0x939000 0x16000 0x15000 com.apple.iokit.IOSCSIBlockCommandsDevice (1.5.4) <50 35 11> 57 0 0x94f000 0x12000 0x11000 com.apple.iokit.IOSCSIMultimediaCommandsDevice (1.5.4) <56 55 54 50 35 11> 58 0 0x845000 0x3000 0x2000 com.apple.driver.AppleUSBComposite (2.7.5) <38 11> 59 0 0x979000 0x2000 0x1000 com.apple.driver.AppleUSBMergeNub (2.7.5) <38 11> 60 2 0x56d000 0x5000 0x4000 com.apple.iokit.IOUSBHIDDriver (2.7.5) <38 19 11> 61 0 0x572000 0x3000 0x2000 com.apple.driver.AppleUSBTCKeyboard (1.5.2b1) <60 38 19 11> 63 0 0x9ae000 0x2000 0x1000 com.apple.driver.AppleUSBTCKeyEventDriver (1.5.2b1) <19 11> 64 0 0x728000 0x18000 0x17000 com.apple.driver.AppleUSBTrackpad (1.5.2b1) <38 19 11> 65 3 0x740000 0x34000 0x33000 com.apple.iokit.IOBluetoothFamily (1.9f8) <11> 66 1 0x774000 0x5000 0x4000 com.apple.driver.AppleUSBBluetoothHCIController (1.9f8) <65 38 11> 67 0 0x78b000 0x3000 0x2000 com.apple.driver.CSRUSBBluetoothHCIController (1.9f8) <66 65 11> 68 4 0x594000 0x1b000 0x1a000 com.apple.iokit.IOGraphicsFamily (1.4.7) <16 6 5 4 3> 69 3 0x5af000 0xf000 0xe000 com.apple.iokit.IONDRVSupport (1.4.7) <68 16 6 5 4 3> 70 0 0x914000 0x4000 0x3000 com.parallels.kext.ConnectUSB (3.0.0) <38 11 6 5 4 3> 71 0 0x975000 0x4000 0x3000 com.apple.driver.AppleBacklight (1.4.2) <69 68 16 11 5 4 3> 72 0 0x9f5000 0x3000 0x2000 com.apple.driver.AppleLPC (1.2.1) <16 5 4 3> 73 1 0x6ee000 0xe000 0xd000 com.apple.driver.IOPlatformPluginFamily (2.7.1d6) <11> 74 4 0x6fc000 0x8000 0x7000 com.apple.driver.AppleSMC (1.1.1d2) <17 6 5 4 3> 75 0 0x704000 0x9000 0x8000 com.apple.driver.ACPI_SMC_PlatformPlugin (2.7.1d6) <74 73 17 16 11 5 4 3> 76 2 0x668000 0xf000 0xe000 com.apple.iokit.IOFireWireAVC (1.9.7) <41 11> 77 1 0x78e000 0x2000 0x1000 com.apple.kext.OSvKernDSPLib (1.0) <5 4> 78 4 0x790000 0x17000 0x16000 com.apple.iokit.IOAudioFamily (1.6.0b7) <77 38 11> 79 1 0x877000 0x4b000 0x4a000 com.apple.driver.AppleFWAudio (2.1.0fc9) <78 76 41 11> 80 0 0x8c2000 0x3000 0x2000 com.apple.driver.AppleMLANAudio (2.1.0fc9) <79 76 41 11> 81 0 0x99d000 0x5000 0x4000 com.apple.kext.AppleSMCLMU (1.3.5d6) <74 5 4 3> 82 0 0x8de000 0x4000 0x3000 com.apple.driver.AudioIPCDriver (1.0.0) <78 5 4 3 2> 83 0 0x97b000 0x6000 0x5000 com.apple.driver.SMCMotionSensor (2.0.2d1) <74 5 4 3> 84 2 0x6e1000 0x6000 0x5000 com.apple.iokit.IOHDAFamily (1.3.3a1) <5 4 3 2> 85 0 0x6e7000 0x7000 0x6000 com.apple.driver.AppleHDAController (1.3.3a1) <84 16 5 4 3 2> 86 1 0x851000 0x1f000 0x1e000 com.apple.iokit.IO80211Family (162.1) <34 6 5 4 3 2> 87 0 0x9f8000 0x89000 0x88000 com.apple.driver.AirPort.Atheros (235.9.3) <86 34 16 6 5 4 3 2> 88 0 0x5be000 0x4b000 0x4a000 com.apple.ATIRadeonX1000 (4.5.6) <69 68 16 11 6 5 4 3 2> 90 0 0x964000 0x8000 0x7000 com.apple.iokit.IOFireWireIP (1.5.4) <41 34 6 5 4 3 2> 91 0 0x779000 0x4000 0x3000 com.apple.driver.AppleIRController (74) <60 38 19 11> 92 0 0x961000 0x3000 0x2000 com.apple.Dont_Steal_Mac_OS_X (6.0.1) <74 6 4 3 2> 93 0 0x918000 0x6000 0x5000 com.parallels.kext.Pvsnet (3.0) <5 4 3 2> 94 0 0x7a7000 0x4d000 0x4c000 com.apple.driver.AppleHDA (1.3.3a1) <84 78 5 4 3 2> 95 0 0x7f4000 0x38000 0x37000 com.apple.kext.ATY_Wormy (4.5.6) <69 68 5 4 3 2> 96 0 0x6dc000 0x5000 0x4000 com.apple.driver.AppleHWSensor (1.5.5d2) <11> 98 0 0x4b394000 0x63000 0x62000 com.vmware.kext.vmmon (1.0) <11 5 4 3 2> 99 0 0x4b417000 0xa000 0x9000 com.vmware.kext.vmci (1.0) <5 4 3 2> 100 1 0x575000 0x9000 0x8000 com.apple.iokit.IOSerialFamily (9.0.0d30) <6 5 4 3 2> 101 0 0x77d000 0x9000 0x8000 com.apple.iokit.IOBluetoothSerialManager (1.9f8) <100 11> 102 0 0x8fe000 0x8000 0x7000 com.apple.filesystems.ntfs (1.2.1) <4 2> 103 0 0x4b572000 0x5000 0x4000 com.vmware.kext.vmioplug (1.0) <38 19 5 4 3> 104 0 0x4b57b000 0x8000 0x7000 com.vmware.kext.vmnet (1.0) <11 5 4 3 2> 106 0 0x9a2000 0xc000 0xb000 com.apple.driver.IOBluetoothSCOAudioDriver (1.9f8) <78 65 11> 107 0 0x4bde8000 0x6f000 0x6e000 com.cisco.nke.ipsec (2.0.1) <4 2> 108 0 0x4bd51000 0x6000 0x5000 foo.tun (1.0) <11 6 4 2> 109 0 0x4bd27000 0x2000 0x1000 com.increw.kext.speedit (0.32) <11 4 3 2> 110 0 0x4bcef000 0x6000 0x5000 foo.tap (1.0) <11 6 4 2> 111 0 0x4be5f000 0xf000 0xe000 org.virtualbox.kext.VBoxDrv (1.4.1) <11 6 5 4 3 2> _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: panic routine?
by Garth Cummings 10 Sep '07

10 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0