strange e1000 interface freeze

strange e1000 interface freeze

[P]

I've been able to reproduce an situation here
where the interface freezes on a platform
where a continuous stream of about 8000 packets
per second are being received. It usually takes
about 2 days to reproduce, but I've a system
in this state now if you have anything you want
me to look at.

I've reproduced the problem in both 100 and 1000 Mb/s mode,
but it seems easier to reproduce in 100 mode?
Also usually one but sometimes both interfaces lock up.
By lock up I mean that the interface records all packets
as fifo errors, and it receives only 1 interrupt every 2 seconds.
Note the other NAPI interface works fine (at about 7.5K interrupts/s).

The system is E7501 based with an 82546EB running kernel 2.4.20
with the 5.2.52 e1000 driver in NAPI mode.
Here are the ethernet settings from one of the dual ports
(the other is identical):

Intel(R) PRO/1000 Network Driver - version 5.2.52
Copyright (c) 1999-2004 Intel Corporation.
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: eth1: e1000_validate_option: Transmit Descriptors set to 4096
e1000: eth1: e1000_validate_option: Receive Descriptors set to 4096
e1000: eth1: e1000_validate_option: Checksum Offload Enabled
e1000: eth1: e1000_validate_option: Flow Control Disabled
e1000: eth1: e1000_validate_option: Transmit Interrupt Delay set to 0
e1000: eth1: e1000_validate_option: Transmit Absolute Interrupt Delay 
set to 0
e1000: eth1: e1000_validate_option: Receive Interrupt Delay set to 0
e1000: eth1: e1000_validate_option: Receive Absolute Interrupt Delay 
set to 0

Here is the lspci output for the locked interface.
NOTE the pci master abort is set!

05:0c.1 Class 0200: 8086:1010 (rev 01)
	Subsystem: 8086:1011
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort+ >SERR- <PERR-
	Latency: 52 (63750ns min), cache line size 08
	Interrupt: pin B routed to IRQ 49
	Region 0: Memory at fc220000 (64-bit, non-prefetchable) [size=128K]
	Region 4: I/O ports at 2040 [size=64]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [e4] PCI-X non-bridge device.
		Command: DPERE- ERO+ RBC=2 OST=0
		Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-, DC=simple, 
DMMRBC=0, DMOST=0, DMCRS=0, RSCEM-	Capabilities: [f0] Message 
Signalled Interrupts: 64bit+ Queue=0/0 Enable-
		Address: 0000000000000000  Data: 0000

There are no e1000 messages in the logs.

cheers,
Pádraig.

strange e1000 interface freeze

[Robert Olsson]

P@draigBrady.com writes:
 > I've been able to reproduce an situation here
 > where the interface freezes on a platform
 > where a continuous stream of about 8000 packets
 > per second are being received. It usually takes

 > By lock up I mean that the interface records all packets
 > as fifo errors, and it receives only 1 interrupt every 2 seconds.
 > Note the other NAPI interface works fine (at about 7.5K interrupts/s).

 Weird. We had a problem with a e1000 in one particular PCI-slot were the 
 NIC was dropping packets no other clues. Decreasing PCI-bus speed from 133 
 to 100 MHz solved this problem. There are two chip revs. Anvik I and II.
 Anvik I had problems in some architectures from what I understood.

 Cheers.
						--ro

Re: strange e1000 interface freeze

[Robert Olsson]

P@draigBrady.com writes:

 > Interesting.
 > We've noticed the problems on 133MHz but not on 100MHz
 > We're double checking 100MHz at the moment.

 I've guess you have seen that the QUAD board which uses
 2 * 82546EB plus a PCI-bridge sets the speed between the 
 onboard bridge and 82546 chips to 120 MHz.

 Cheers.
					--ro