December 2004 - Darwin-kernel

Re: "kextunload: unload kext <HelloIOKit> failed"
by Garth Cummings 06 Dec '04

06 Dec '04

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi Brian, On Dec 3, 2004, at 5:21 PM, Brian Jorgage wrote: When I run kextunload it fails (see subject line). The /var/log/system.log indicates: "localhost kernel: Stopping localhost kernel: Can't unload <driver> due to - localhost kernel: <driver name>:<driver name> has 1 instance(s)" This occurs after I have disconnected the device in question. Also IORegistryExplorer still sees the device and my driver after it's been disconnected. I am guessing this is the problem since Explorer still has a lock on the driver. So how to force IORegistryExplorer to refesh and release it's lock ? Any ideas please respond. Brian Jorgage --gc __________________________________________________________________ Garth Cummings Apple Developer Technical Support gcummings(a)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 <snippage...> No. IORegistryExplorer does not retain any of the objects in the I/O Registry, otherwise running it would change the behavior of a running system. Or is the problem something else ? Yes. Someone else still has a reference to your driver. Often this is because the termination code isn't quite correct--it's easy to get wrong. It's very hard to tell what exactly the problem is in your case. Has this code ever worked for you? A common debugging strategy for reference leaks is to get the code back to a state when it worked, such as the plain vanilla HelloIOKit sample. Then, make one small change at a time and retest until the leak reappears. http://developer.apple.com/technicalsupport smime.p7s

1 0

PPC OEA mode and IOKit drivers
by Parav Pandit 06 Dec '04

06 Dec '04

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Importance: Normal Hi, PowerPC architecture generally defines 3 types of modes or programming environment. 1. UIA (User instruction Architecture) corresponds to user application programming instruction definitions. 2. VEA (Virtual Environment Arch.) mid way to user space and OEA, has support for cache modeling instructions, timing read instructions support. 3. OEA (Operating Env. Arch.) Memory management support. timing write, cache modeling instructions etc. This can use all the instructions of above two modes. 1. I think IOKit driver and the xnu kernel work in the OEA environment mode, Am I correct? or I have misunderstood something? 2. Can somebody give more idea/ links on how to bind this concept of various PPC programming mode to the xnu and IOKit driver? Regards, Parav Pandit _______________________________________________ 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: KP / gdb debug question...
by Shawn Erickson 04 Dec '04

04 Dec '04

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 .stabs ,0000,0000,FFFF100,0000,0000,FFFF0,0000,0000,FFFF">0,Ltext0 .stabs ,0000,0000,FFFF100,0000,0000,FFFF0,0000,0000,FFFF">0,Ltext0 .section __TEXT,__text,regular,pure_instructions .align 2 Ltext0: .stabs ,0000,0000,FFFF60,0000,0000,FFFF0,0000,0000,FFFF0,0000,0000,FFFF">0 .align 2 .globl __ZN20com_ftsw_drv_qlc_hba18handleMissingTimerEv .section __TEXT,__text,regular,pure_instructions .align 2 __ZN20com_ftsw_drv_qlc_hba18handleMissingTimerEv: .stabd ,0000,0000,FFFF0,0000,0000,FFFF">18 mflr r0 stmw r30,-8(r1) mr r31,r3 stw r0,8(r1) stwu r1,-80(r1) .stabd ,0000,0000,FFFF0,0000,0000,FFFF">25 LBB2: jbsr __ZN20com_ftsw_drv_qlc_hba25updateStateOfMissingPortsEv,L3 .stabd ,0000,0000,FFFF0,0000,0000,FFFF">27 lwz r0,256(r31) andis. r2,r0,1024 beq- cr0,L1 .stabd ,0000,0000,FFFF0,0000,0000,FFFF">28 lwz r3,240(r31) li r4,1000 lwz r0,88(r1) addi r1,r1,80 lmw r30,-8(r1) lwz r2,0(r3) mtlr r0 lwz r12,300(r2) mtctr r12 bctr .stabd ,0000,0000,FFFF0,0000,0000,FFFF">29 L1: lwz r0,88(r1) addi r1,r1,80 lmw r30,-8(r1) mtlr r0 blr

1 0

Re: KP / gdb debug question...
by Ronnie Misra 04 Dec '04

04 Dec '04

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Dec 3, 2004, at 6:54 PM, Marek Kozubal wrote: Key parts from the KP: Proceeding back via exception chain: Exception state (sv=0x1C79C280) PC=0x1C808CD8; MSR=0x00009030; DAR=0x00000060; DSISR=0x40000000; LR=0x1C80A5F4; R1=0x0A103BF0; XCP=0x0000000C (0x300 - Data access) Kernel version: Darwin Kernel Version 7.5.0: Thu Aug 5 19:26:16 PDT 2004; root:xnu/xnu-517.7.21.obj~3/RELEASE_PPC You can do this if your binary has debugging symbols. Before the kext crashes, figure out where it loaded on the target: The third number is the load address of the kext. Now after you get your panic, do the following: Ronnie _______________________________________________ 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 is probably documented somewhere, but I've not found the answer to this. I have a KP log from a user, its a simple data access problem (so a NULL pointer deference or something like). However, how do I figure out which line of code its in? I know its 68 bytes into my function, but there's no Disassemble in XCode like there is in CodeWarriror that let me figure such things out. So how do I figure out what line of code is the offender without become awesome at reading PPC asm code (and who knows how the optimiser might have changed orders of things and etc). Backtrace: 0x00093D70 0x1C80A5F4 0x000CE2E0 0x002218C8 0x00221764 0x002452B4 0x00094200 0x40B73B71 Now the function the PC is at starts at 0x1c808c94. So 0x1C808CD8 - 0x1c808c94 = 0x44 = 68 bytes. % kextstat | grep org.samoconnor.driver.NetworkAudioDriver 117 0 0x20781000 0x4000 0x3000 org.samoconnor.driver.NetworkAudioDriver (0.1) <82> % gdb (gdb) add-symbol-file /path/to/NetworkAudioDriver.kext/ts/MacOS/NetworkAudioDriver -s LC_SEGMENT. 0x20782000 <- add 0x1000 here, I'm not sure exactly why though :) (gdb) l *0x20782a7c 0x20782a7c is in org_samoconnor_driver_NetworkAudioEngine::init() (NetworkAudioEngine.cpp:153). 148 149 if (!IOAudioEngine::init(NULL)) { 150 return false; ... Incidentally, how did you figure out that the function starts at 0x1c808c94? This email sent to site_archiver(a)lists.apple.com

1 0

KP / gdb debug question...
by Marek Kozubal 04 Dec '04

04 Dec '04

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Key parts from the KP: Proceeding back via exception chain: Exception state (sv=0x1C79C280) PC=0x1C808CD8; MSR=0x00009030; DAR=0x00000060; DSISR=0x40000000; LR=0x1C80A5F4; R1=0x0A103BF0; XCP=0x0000000C (0x300 - Data access) Backtrace: 0x00093D70 0x1C80A5F4 0x000CE2E0 0x002218C8 0x00221764 0x002452B4 0x00094200 0x40B73B71 Kernel version: Darwin Kernel Version 7.5.0: Thu Aug 5 19:26:16 PDT 2004; root:xnu/xnu-517.7.21.obj~3/RELEASE_PPC Thanks. --- Marek Kozubal marek(a)portents.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 is probably documented somewhere, but I've not found the answer to this. I have a KP log from a user, its a simple data access problem (so a NULL pointer deference or something like). However, how do I figure out which line of code its in? I know its 68 bytes into my function, but there's no Disassemble in XCode like there is in CodeWarriror that let me figure such things out. So how do I figure out what line of code is the offender without become awesome at reading PPC asm code (and who knows how the optimiser might have changed orders of things and etc). Now the function the PC is at starts at 0x1c808c94. So 0x1C808CD8 - 0x1c808c94 = 0x44 = 68 bytes. This email sent to site_archiver(a)lists.apple.com

1 0

"kextunload: unload kext <HelloIOKit> failed"
by Brian Jorgage 04 Dec '04

04 Dec '04

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com I ran through the tutorial and am able to kextload a driver. The driver's plist specifies idVendor/idProduct for a particular device in order to win against AppleUSBComposite. When I view the device in IORegistryExplorer it displays w/my test driver driving it. So far so good. When I run kextunload it fails (see subject line). The /var/log/system.log indicates: "localhost kernel: Stopping localhost kernel: Can't unload <driver> due to - localhost kernel: <driver name>:<driver name> has 1 instance(s)" This occurs after I have disconnected the device in question. Also IORegistryExplorer still sees the device and my driver after it's been disconnected. I am guessing this is the problem since Explorer still has a lock on the driver. So how to force IORegistryExplorer to refesh and release it's lock ? Or is the problem something else ? Any ideas please respond. Brian Jorgage _______________________________________________ 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: Interrupt delays
by Mark Cookson 03 Dec '04

03 Dec '04

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Microsoft-Entourage/10.1.0.2006 So if latency doesn't show anything worse than 200us and yet our time stamp has a delta off by 5+ ms, any ideas? Our PC developers say that this looks like a PCI controller issue that they've seen where the DMA requests from the card don't get honored. The card doesn't reissue the request (no buffer, if it doesn't get the data, it's too late to retry) causing the input and output DMA engines to get out of sync with each other. Since a fundamental assumption of our driver (and many CoreAudio applications) is that the input and output are locked together, we only have one time stamp, driven from the input interrupt. If the DMAs get out of sync, our time stamp will be wrong, and we're up the proverbial estuary without a means of locomotion. I've filed a Radar issue on this, but not gotten any response to it. Thanks, Mark -- Mark Cookson M-Audio, a division of Avid 225 Locust St. Hudson, WI 54016 On 12/3/04 1:14 PM, "Godfrey van der Linden" <gvdl(a)apple.com> wrote: > You could try latency -it, it will tell you if some other process is > blocking interrupts for too long. > > Godfrey > > On Dec 3, , at 9:11, Mark Cookson wrote: > >> I'm trying to track down an issue where it appears that our PCI card's >> primary interrupt is delayed (in some cases more than 9 milliseconds) >> from >> when I would have expected to have seen it. >> >> Since we make audio hardware, our driver needs to give accurate timing >> information to CoreAudio. We do that by calling clock_get_uptime() >> from our >> primary interrupt. More specifically, we check that it was our card >> generating the interrupt, if it was, call clock_get_uptime, then clear >> the >> interrupt, and return "true" so that our secondary interrupt handler >> gets >> called. The secondary interrupt is when we actually post the time >> collected >> by the primary interrupt routine. >> >> We are logging the delta between these time stamps (via HALLab) and >> see them >> coming very regularly, as expected, except that on occasion on the new >> 1.8 >> GHz G5 with PCI slots (as opposed to the original 1.8 GHz G5 that had >> PCI-X >> slots) we see the delta grow by a very large amount, up to 9ms in one >> case. >> >> I believe it is this rogue time stamp that is causing our problems, but >> since the time stamps are directly related to the primary interrupt, it >> seems that something is preventing our primary interrupt from running. >> >> Any ideas about how I could track this down further? _______________________________________________ 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: Interrupt delays
by Godfrey van der Linden 03 Dec '04

03 Dec '04

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Godfrey On Dec 3, , at 9:11, Mark Cookson wrote: I believe it is this rogue time stamp that is causing our problems, but since the time stamps are directly related to the primary interrupt, it seems that something is preventing our primary interrupt from running. _______________________________________________ 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.… You could try latency -it, it will tell you if some other process is blocking interrupts for too long. I'm trying to track down an issue where it appears that our PCI card's primary interrupt is delayed (in some cases more than 9 milliseconds) from when I would have expected to have seen it. Since we make audio hardware, our driver needs to give accurate timing information to CoreAudio. We do that by calling clock_get_uptime() from our primary interrupt. More specifically, we check that it was our card generating the interrupt, if it was, call clock_get_uptime, then clear the interrupt, and return "true" so that our secondary interrupt handler gets called. The secondary interrupt is when we actually post the time collected by the primary interrupt routine. We are logging the delta between these time stamps (via HALLab) and see them coming very regularly, as expected, except that on occasion on the new 1.8 GHz G5 with PCI slots (as opposed to the original 1.8 GHz G5 that had PCI-X slots) we see the delta grow by a very large amount, up to 9ms in one case. Any ideas about how I could track this down further? This email sent to site_archiver(a)lists.apple.com

1 0

Interrupt delays
by Mark Cookson 03 Dec '04

03 Dec '04

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Microsoft-Entourage/10.1.0.2006 I'm trying to track down an issue where it appears that our PCI card's primary interrupt is delayed (in some cases more than 9 milliseconds) from when I would have expected to have seen it. Since we make audio hardware, our driver needs to give accurate timing information to CoreAudio. We do that by calling clock_get_uptime() from our primary interrupt. More specifically, we check that it was our card generating the interrupt, if it was, call clock_get_uptime, then clear the interrupt, and return "true" so that our secondary interrupt handler gets called. The secondary interrupt is when we actually post the time collected by the primary interrupt routine. We are logging the delta between these time stamps (via HALLab) and see them coming very regularly, as expected, except that on occasion on the new 1.8 GHz G5 with PCI slots (as opposed to the original 1.8 GHz G5 that had PCI-X slots) we see the delta grow by a very large amount, up to 9ms in one case. I believe it is this rogue time stamp that is causing our problems, but since the time stamps are directly related to the primary interrupt, it seems that something is preventing our primary interrupt from running. Any ideas about how I could track this down further? Thanks, Mark -- Mark Cookson M-Audio, a division of Avid 225 Locust St. Hudson, WI 54016 _______________________________________________ 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

How can i read from disk device in mach kernel ?
by Plamen Grigorov 02 Dec '04

02 Dec '04

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Importance: Normal Hi! I am new in darwin kernel. Than i ma sory if my question is stupid, but i must know. I have simple problem. I use "SampleFilterScheme". Always is the best, but i don't know how to access real disk device etc. my filter work over "disk1s5" for example but i want read data from "disk1". I think that it is simple but ... i don't know how :-( That is it. If somebody can help me ... i will be so glad. Thank's ! _______________________________________________ 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