[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-smp
Subject:    Re: Possible cause of "spurious APIC interrupt"
From:       Gerard Roudier <groudier () club-internet ! fr>
Date:       1998-05-24 12:30:25
[Download RAW message or body]


On Sat, 23 May 1998, Chris Pirih wrote:

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

[prev in list] [next in list] [prev in thread] [next in thread]