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: Thu, 14 Oct 2004 11:00:21 -0700
On Oct 14, 2004, at 6:58 AM, Parav Pandit wrote:
-----Original Message-----
From: David Gatwood [mailto:email@hidden]
Sent: Tuesday, October 12, 2004 1:17 AM
To: Parav Pandit
Cc: email@hidden
Subject: Re: pmap_unnest: Other processor did not see interruption
request
On Oct 9, 2004, at 6:57 AM, Parav Pandit wrote:
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
--------------------------------------------
Here is the problem, if I don't execute my chip reset function, and
completes my start(), there is no panic.
But it is really very strange.
My chip_reset() does it:
Disable interrupts
Do PCI IO regs.
IODelay() to wait to complete reset...
Enable interrupts.
I'd make sure that it calls the IOSimpleLockUnlockEnableInterrupt() to
enable interrupts.
I use the IOSimpleLockLockDisableInterrupt()
IOSimpleLockUnlockEnableInterrupt() for my critical section.
They are needed, if during working after loading my PCI card hangs, I
use
the same reset function.
I can't really understand that what it pmap_unnest between 2 processors
during driver loading phase?
pmap_unnest can be called at any time. It occurs frequently as part of
the normal mapping and unmapping of memory. The pmap_unnest is
probably completely unrelated to your driver. and just happens to occur
at about the same time.
The problem is that, for whatever reason, your driver seems to be
holding interrupts off for several seconds. It is generally unsafe to
disable interrupts for more than a few microseconds, as holding
interrupts for longer can cause anything from a kernel panic to your
computer shutting itself off or rebooting. If a pmap_unnest occurs in
some other part of the OS while interrupts are off for more than a few
seconds, you will get a kernel panic.
If at all possible, you should replace the IOSimpleLock with an IOLock
(mutex). That would still prevent multiple resets happening
concurrently. If you need to ignore device interrupts during a reset,
you should either set a flag in your driver to tell your interrupt
handler to ignore interrupts or you should disable that particular
interrupt event source temporarily.
If the reason you are disabling interrupts is that the reset routine is
timing-critical, you'll have to keep using IOSimpleLocks, but you
should use IOSimpleLockLock instead of
IOSimpleLockLockDisableInterrupt. By doing that, preemption is still
disabled, but interrupts can occur so that the OS doesn't lobotomize
itself.
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