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: "Parav Pandit" <email@hidden>
- Date: Sat, 9 Oct 2004 19:27:58 +0530
- 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:email@hidden]
Sent: Thursday, October 07, 2004 1:28 AM
To: email@hidden
Cc: email@hidden
Subject: Re: pmap_unnest: Other processor did not see interruption request
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