Re: Scanning problems - machine lockups

[David Woodhouse <dwmw2@infradead.org>]

bfrey@turbolinux.com.cn said:
> For Linux I think the right way to handle this is to have each
> (SA_SHIRQ) sharing capable interrupt handler return a TRUE or FALSE
> value indicating whether the interrupt belongs to the driver. In
> kernel/irq.c:handle_IRQ_event() check the return value. If after one
> pass through all of the interrupt (action) handlers no one has claimed
> the inerrupt then log a warning message (spurious interrupt) and clear
> the interrupt.

There exists hardware on which it's impossible to know for sure whether an 
interrupt was generated or not. Upon receiving what might have been a 
'status change' IRQ you check the status register. If it's reading the same 
as when you last looked at it, you have know way to be sure that it hasn't 
actually changed twice.

So you'd have to have a YES/NO/MAYBE return code, which means you'd still 
want to deal with the case of an IRQ storm with the only handler returning 
MAYBE. And in reality, your first pass through all the drivers would simply 
be to change the prototype and make them return MAYBE. And many 
of them would stay that way for a _loooong_ time. 

Also, you don't necessarily need to mask the IRQ just because you got a 
single spurious trigger. It's only really necessary if you're getting 
inundated with so many IRQs that the system is falling over.

So your heuristic might be something like...

 Each jiffy, reset the 'spurious IRQ' count for each IRQ.


 Each time an IRQ is triggered, note the 'maximum' return code from the
	handlers called (where NO < MAYBE < YES).

 If YES, goto out:

 If MAYBE, increase the spurious IRQ count for this IRQ by 1

 If NO, increase the spurious IRQ count for this IRQ by 100

 If the spurious IRQ count for this IRQ has reached <a suitable number>,
	then disable the IRQ.

out:
 Return from irq.


Perhaps you don't want to touch the whole list of IRQ counts every jiffy. 
Perhaps you could reset it to zero on each YES response. Or something.

And if you start randomly disabling IRQs because they're triggering too 
often, then you'll probably need a way for a device driver to force you to 
turn them back on again, like kick_irq().

--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/