Spurious interrupts on eepro100 1.06/2.2.1/SMP

[Andi Kleen]

On Sat, Feb 20, 1999 at 06:01:22PM +0100, Donald Becker wrote:
> On Sat, 20 Feb 1999, Andi Kleen wrote:
> 
> > I'm using the eepro100.c 1.06 driver as shipped in 2.2.1 on a SMP
> > machine. I noticed that the interrupt count in /proc/interrupts
> > increases by one about every 2-3 seconds, even though there
> > is no traffic on the network and no packets send out (RX/TX counters zero,
> > only active node on the net). The interrupt is a IO-APIC interrupt and
> > is not shared.
> 
> Hey, you are lucky -- share some of those extras with other APIC users!
> (The usual bug with the APIC is that it won't pass interrupts.  For a while
> the broken PCI slots on my machines changed with each kernel release.)

:)

> 
> > eth1: Intel EtherExpress Pro 10/100 at 0xe800, 00:A0:C9:30:39:BC, IRQ 19.
> ...
> >   Receiver lock-up workaround activated.
> 
> The real story: some EEPro100 boards had a bug where the receiver would
> silently lock up in rare and obscure circumstance.  So at every timer tick
> (2 seconds) we check for recent Rx packets.  If we haven't received any we
> do a set-multicast-list command to bring the receiver back to life.
> 
> in speedo_timer()
>    if (sp->rx_mode < 0  ||
>       (sp->rx_bug  && jiffies - sp->last_rx_time > 2*HZ)) {
> 	   /* We haven't received a packet in a Long Time.  We might
> 	   have been bitten by the receiver hang bug.  This can be
> 	   cleared by sending a set multicast list command. */
> 	set_rx_mode(dev);
>     }
> 
> This bug probably only happens at 10mbps with older chips.  The real impact
> has been the multicast-list bugs in the driver caused by supporting the
> work-around.

Thank you for the explanation (and for the great driver). The card works
fine, I was just curious what was causing the counter increases.


-Andi

-- 
This is like TV. I don't like TV.