site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Importance: Normal Hi, You suggested some testing to do. Here are the results. 1. I tested my hardware using Apple Protection Plan test CD which I got with G5. And all the tests are passed. BTW we have two G5, and on both the system I get the same result, kernel panic also and hardware test results ok also. 2. from CHUD One processor is disabled, and I tried loading driver for 200 times.( script did that :-) ) And it doesn't get kernel panic in that testing. But When I enabled both the CPUs - same kernel panic happens on 11th load. I looked in the xnu code- pmap.c for pmap_unnest() comments says - removes the shared map. I don't understand that I have nothing like that in my driver, what it actually code/pmap it unnest from other processor. What does kext loader put as shared map during driver load that had to be unnested ? 3. This panic is not fixed on cpu 1 only, it randomly happen on cpu 0 also. 4. [David Gatwood] There's some really, really bizarre bug in the kernel code that triggers the interrupt (and all other interrupts are routed only to CPU 1 for some equally bizarre reason), by "kernel code" do you xnu kernel code or our driver kernel code that we need to debug again? ------------------------------------------------------ Let me give you more idea about my driver during loading phase: It does the following steps in sequence: It first enables the memory mapped io for PCI card's register file.( I have 256 registers) Enables the PCI bus mastering, disables the Option ROM on the card. ( I have to do that) Some memory mapped read/write operation on the PCI card to reset the card and processor on the Card. All memory allocation goes here. I can see IOLog message printed here. (Up to here- all works fine) After this message I get this kernel panic on pmap_unnest. Then after this I set the PCI-X card's cache line to 0x10h. (required by hardware) Then I download the firmware using my PCI card's bus mastering. Even till this point interrupts are not enabled. as there is no address that falls in to my driver's program memory area, I could not figure what cause panic. Regards Parav Pandit -----O riginal Message----- From: David Gatwood [mailto:dgatwood@apple.com] Sent: Thursday, October 07, 2004 1:28 AM To: darwin-kernel@lists.apple.com Cc: parav.pandit@einfochips.com Subject: Re: pmap_unnest: Other processor did not see interruption request On Oct 6, 2004, at 12:05 PM, parav.pandit@einfochips.com wrote: My IOKit driver has provider Class IOPCIDevice. and Driver class is derived from IOSCSIParallelInteraceController. Running my driver on G5 PCI-X dual 1.8GHz system. When I load the driver using kextload -v myDriver.kext Randomly I get kernel panic at this point: ("pmap_unnest: Other processor (%d) did not see interruption request\n", i); . . . panic(cpu 1): pmap_unnest: Other processor (0) did not see interruption request That's a little bizarre. One CPU failed to acknowledge the interrupt from the other CPU (or any other interrupt, for that matter) for over half a second. That really shouldn't be possible. The obvious possibilities are either: 1. CPU 0 hung in an interrupt handler (infinite loop in an I/O Filter—possibly caused by some race condition—not likely to be your driver, though, since I don't think it would be running yet), 2. There's some really, really bizarre bug in the kernel code that triggers the interrupt (and all other interrupts are routed only to CPU 1 for some equally bizarre reason), or 3. You have a defective CPU and/or main logic board. The third one makes the most sense. It would be sporadic because the code sometimes executes on CPU 0, and that CPU may be able to reliably signal CPU 1, but not vice-versa. Other drivers wouldn't see the same behavior because pmap-based hardware address mapping doesn't occur for any peripherals except for PCI/AGP (and a few built-in devices), and those drivers are probably loaded before the second CPU is enabled, which means that it would always be CPU 0 signaling CPU 1, while the panic is the reverse of that. Try running the hardware test CD and see if it turns anything up. Try unloading and loading another PCi driver and see if the same behavior occurs. Finally, try disabling one CPU with CHUD. Let us know what happens. David _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com