Re: pmap_unnest: Other processor did not see interruption request
Re: pmap_unnest: Other processor did not see interruption request
- Subject: Re: pmap_unnest: Other processor did not see interruption request
- From: David Gatwood <email@hidden>
- Date: Wed, 6 Oct 2004 12:58:20 -0700
On Oct 6, 2004, at 12:05 PM, email@hidden 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden