lkml.org 
[lkml]   [1999]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: linux interrupt handling problem
Date
From
> 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.120 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site