Messages in this thread | | | Date | Wed, 10 Nov 1999 07:19:19 -0500 | From | Doug Ledford <> | Subject | Re: APIC errors and aic7xxx interrupts w/SMP on 2.3.25 |
| |
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/
| |