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

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

kumon@flab.fujitsu.co.jp wrote:
>
> kumon@flab.fujitsu.co.jp writes:
> > Thanks Doug,
> > Your information suggests me to investigate USB devices.
> >
> > Doug Ledford writes:
> > > 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.
>
> My guess is not true.
>
> The result of /proc/interrupts and lspci are attached at the tail.
>
> IRQ19 is shared by aic7xxx and Vortex Aureal sound chip.
> Even if the sound card is removed, massive interrupts exist.

It's also shared by the uhci device (part of the USB stuff I think).

> My BOIS was set to use MPS-1.4. But if I changed it to use MPS-1.1,
> the interrupts disappeared.
>
> As Harold suggested that:
> > There is a known problem with USB on the BP6 if you have the bios
> >set to MPS v1.4. I would make sure that you have the bios set to MPS v1.1.
>
> It may be the case.
>
> In this experiment, I used the latest bios 'BP6 LP BIOS+HPT366 beta
> BIOS v1.21', released several day ago.
>
> Even if I use MPS-1.4 setting, Linux booting messages said "MPS 1.1",
> what's curious.
>
> I added /proc/interrupts and slightly edited 'lspci -v' output for
> (un)informative data.
>
> ----------
> using MPS 1.4
> ----------
> /proc/interrupts:
> CPU0 CPU1

> 5: 0 0 IO-APIC-edge uhci
> 18: 20 25 IO-APIC-level aic7xxx
> 19: 48385152 48385308 IO-APIC-level aic7xxx

> ----------
> MPS 1.1
> ----------
> /proc/interrupts:
> CPU0 CPU1
> 5: 46 43 IO-APIC-level uhci, aic7xxx
> 11: 23 22 IO-APIC-level aic7xxx

This could be an MPS-1.4 table parsing bug, but regardless, the situation is
clear. The uhci device and the aic7xxx device are sharing the same interrupt
pin even though linux doesn't think so and as a result we are seeing infinite
interrupts on INT19 as the hardware is trying to get the uhci driver to handle
some condition (and likely the uhci driver is waiting on those interrupts as
well and is likewise frustrated about not getting them).

-- 
  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/