Messages in this thread | | | Subject | Re: linux interrupt handling problem | Date | Tue, 9 Nov 1999 21:43:32 +0000 (GMT) | From | Alan Cox <> |
| |
> There are times when a driver really needs to stop ALL interrupts on the > current CPU. This is where I've been using sti() and cli().
Certainly - and that is one reason we don't want to do something like this generally. On x86 we do this for broken IDE controllers for example
> spin_lock_irqsave(...) > Sit around > spin_unlock_irqrestore(...) > > The problem with this is that when you make the spin lock, you never > indicate what IRQ level the lock has to protect against. If you initialized > the spin lock with it's interrupt number, the M68K and SPARC code could do > the IRQ save based on that. Everything would run better on these systems.
I put that to Linus once. It turns out you get some amazingly complex dependancy issues. Suppose it is a shared IRQ. Suppose the core code doesnt know which IRQ is involved - for example networking isnt too clued up on every IRQ allocated to a networking device.
In the few cases it really matters we do it using disable_irq, but even then you have to be careful. Disabling at the irq source isnt enough, you have to mask the IRQ on the PIC/APIC. If you don't then eventually the PC IRQ propogation delay gets you. You disable the irq on the chip and do a normal spinlock and an irq arrives between the disable being done and the IRQ coming in over the apic bus.
It happens. It took a lot of work to figure quite why 8390.o was deadlocking
> decide if it should be spin_lock() or spin_lock_irqsave(). We could get rid > of the spin_lock_irqsave() and spin_unlock_irqrestore() routines by making > spin_lock() and spin_unlock() look at if the mutex can be called from > interrupt or not.
How do you handle nested locks in such a case ?
Alan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |