Re: APIC errors and aic7xxx interrupts w/SMP on 2.3.25

Doug Ledford (dledford@redhat.com)
Wed, 10 Nov 1999 07:12:07 -0500

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/