lkml.org 
[lkml]   [1999]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: APIC errors and aic7xxx interrupts w/SMP on 2.3.25
    Rogier Wolff wrote:
    >
    > Doug Ledford wrote:
    > > On Tue, 9 Nov 1999 kumon@flab.fujitsu.co.jp wrote:
    > >
    > > > Another problem is on aic7xxx.
    > > >
    > > > /proc/interrupts saids the SCSI driver produces massive interrupts,
    > > > about 17000 interrupts per second for each CPU even if no SCSI
    > > > devices are attached.
    > > >
    > > > The SCSI I/F(2940UWD) is a dual channel SCSI adaptor, only one of the
    > > > channel produces interupts.
    > > >
    > > > This happens on 2.3.25 but not on 2.3.18.
    > > >
    > > > Does anybody tell me a clue?
    > >
    > > This most likely means something besides the aic7xxx is making that
    > > interrupt but as sson as the aic7xxx is loaded and that interrupt is
    > > enabled then the other device (whatever it may be, check the output of
    > > lspci to see if anything else is sharing that interrupt) is likely making
    > > all those interrupts and that's what needs fixed.
    >
    > - The machine doesn't hang, so if it's a level triggered interrupt,
    > something must be disabeling the interrupt.

    Not true. This is an SMP machine, and you can have a level triggered
    interrupt go permanently active and not make the machine hang. It gives you a
    good idea how many empty interrupts per second your machine can handle (you
    end up loosing one processor more or less BTW).

    > - It would've been pretty obvious to someone looking in
    > /proc/interrupts that the interrupt is shared.

    No, it's not. It's obvious that there aren't any other drivers attached to
    the process, it isn't obvious at all that the wiring on the motherboard is
    only linking that one device to that interrupt though.

    > - Could some device be holding hte interrupt line "active" for say 10%
    > of the time (without feedback from its driver!), and thus triggering
    > "short" interrupt storms?

    The only thing that strobes an interrupt in all the time I've been dealing
    with hardware devices is a clock interrupt or some serial interrupt
    controllers that have timer based interrupts. But even then, they all require
    that a driver turn them off, so the answer to your question about without
    feedback from a driver is no.

    > If the interrupt indeed isn't shared, I would recommend enabelign
    > debugging on the AIC7xxx driver. This should tell you what the chip
    > thinks needs to be addressed. (I'm not familiar with the AIC driver,
    > so I don't know how much debugging it will spew at you from the
    > interrupt routine.)

    It won't do any good. There aren't any interrupt sources on the aic7xxx cards
    that my driver doesn't handle. Besides, in a later email on the list you see
    that when the machine is switched to MPS-1.1 mode, then the aic7xxx and uhci
    share the same interrupt and things work great, when in MPS-1.4 mode, then the
    aic7xxx and uhci have different interrupts, but I suspect that the uhci is
    still using the same interrupt as the aic7xxx (they are likely tied to the
    same pin) and as a result, the aic7xxx is seeing an interrupt storm and the
    uhci is seeing no interrupts and it's clear to me anyway that the source of
    the interrupt storm is the uhci hardware that is waiting for an interrupt
    handler to take care of it. I would write this one off as a buggy bios with a
    bad MPS-1.4 table.

    --
    Doug Ledford <dledford@redhat.com>
    Opinions expressed are my own, but
    they should be everybody's.

    -
    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:2.056 / U:0.420 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site