On Sun, Jan 30, 2005 at 07:27:26PM +0100, Arjan van de Ven wrote:
> On Sun, 2005-01-30 at 13:27 -0200, Marcelo Tosatti wrote:
> > On Fri, Jan 07, 2005 at 04:38:32AM +0000, Matthew Wilcox wrote:
> > > On Thu, Jan 06, 2005 at 11:53:27PM -0500, Lukasz Kosewski wrote:
> > > > I have an idea of something I might do for 2.6.11, but I doubt anyone
> > > > will actually agree with it. Say we keep a counter of how many times
> > > > interrupt x has been fired off since the last timer interrupt
> > > > (obviously, a timer interrupt resets the counter). Then we can pick an
> > > > arbitrary threshold for masking out this interrupt until another device
> > > > actually pines for it.
> > > >
> > > > Or something. The point is, we need a general solution to the problem,
> > > > not poking about in every single driver trying to tie it down.
> > >
> > > Something like note_interrupt() in kernel/irq/spurious.c?
> >
> > BTW I wonder if its feasible to add an interface on top of
> > kernel/irq/spurious.c for
> > notifying drivers about interrupts storms, so they can take appropriate
> > action
> > (try to reset the device).
>
> the problem is... the driver just denied it was their irq (at least in
> all the common cases)...
Hum, drivers should, at least in theory, be able to return IRQ_NONE if
interrupts
can't be handled.
So is 8390 a special case?
drivers/net/8390.c
irqreturn_t ei_interrupt(int irq, void *dev_id, struct pt_regs * regs)
{
...
}
spin_unlock(&ei_local->page_lock);
return IRQ_RETVAL(nr_serviced > 0);
}
The "workaround" looks like (at the end of ei_interrupt):
if (!nr_serviced)
interrupt_cnt++;
else
interrupt_cnt = 0;
if (interrupt_cnt > 256) {
ei_status.reset_8390(dev);
interrupt_cnt = 0;
}
One could argue that it is a hardware problem...
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
