site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Oct 14, 2004, at 6:58 AM, Parav Pandit wrote: -----Original Message----- From: David Gatwood [mailto:dgatwood@apple.com] Sent: Tuesday, October 12, 2004 1:17 AM To: Parav Pandit Cc: darwin-kernel@lists.apple.com 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 can't really understand that what it pmap_unnest between 2 processors during driver loading phase? 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... 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. 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. This email sent to site_archiver@lists.apple.com