lkml.org 
[lkml]   [2005]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: SCSI aic7xxx driver: Initialization Failure over a kdump reboot
    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-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:10    [W:0.021 / U:12.276 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site