> At 04:44 PM 05/23/1998 -0700, Vadim E. Kogan wrote:
> >In my case (same MB, 2 PPro233) I *don't* have USB enabled (at least
> >it's not in /proc/pci) and I *do* get spurious APIC interrupts. (see my
> >message several hours ago). Let's check what other common hardware we
> >have - maybe we'll be able to find the problem.
> >
> >PCI devices found:
> > Host bridge: Intel 82441FX Natoma (rev 2).
> > ISA bridge: Intel 82371SB PIIX3 ISA (rev 1).
> > IDE interface: Intel 82371SB PIIX3 IDE (rev 0).
> > Display controller: Matrox Millennium (rev 1).
> > SCSI storage controller: NCR 53c825 (rev 2).
> > VGA compatible controller: S3 Inc. Trio32/Trio64 (rev 84).
> > Ethernet controller: 3Com 3C905 100bTX (rev 0).
>
> I too get spurious APIC interrupts in 2.1.103. The only hardware
> I have in common with Vadim is the ncr53c825.
It perhaps helps a little to trigger the problem, but I doubt
it is the cause. BTW, I also doubt the apic code be correct.
My reading of the docs let me think that differences between
edge and level interrupts are handled by the APIC hardware and
this should allow to handle them transparently from software.
My opinion is that the current code has been suggested by
people who are confusing real-time and messed-time. ;-)
Things like disable_interrupt(irq) seems suspicious to me.
Imagine that a level interrupt, that have been accepted by
a local APIC but donnot have been yet dispensed to the CPU,
is so blindly masked. In such a situation the CPU may try
to handle an interrupt with no interrupt actually pending.
BTW, the way edge interrupts are disabled by the current apic
code is explicitely stated as 'should not' by intel docs.
Anyway, these spurious interrupts should'nt make problems,
I think, and are just, IMO, the punishment for the way the
apic code is currently implemented.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu