Problem with Linux 2.4.7 and builtin eepro on Intel's EEA2 motherboard.

Problem with Linux 2.4.7 and builtin eepro on Intel's EEA2 motherboard.

[Ben Greear]

The driver seems to lock up for a while and then recover...

Aug  7 11:55:19 lanf1 last message repeated 5 times
Aug  7 11:56:04 lanf1 last message repeated 21 times
Aug  7 11:56:07 lanf1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug  7 11:56:07 lanf1 kernel: eth0: Transmit timed out: status 0050  0cf0 at 900/928 command 000c0000.
Aug  7 11:58:53 lanf1 kernel: eepro100: wait_for_cmd_done timeout!
Aug  7 11:59:34 lanf1 last message repeated 10 times
Aug  7 12:00:02 lanf1 last message repeated 16 times
Aug  7 12:00:05 lanf1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug  7 12:00:05 lanf1 kernel: eth0: Transmit timed out: status 0050  0cf0 at 1151/1179 command 000c0000.
Aug  7 12:02:24 lanf1 kernel: eepro100: wait_for_cmd_done timeout!
Aug  7 12:02:47 lanf1 last message repeated 14 times
Aug  7 12:03:09 lanf1 su(pam_unix)[5778]: session opened for user root by lanforge(uid=500)
Aug  7 12:03:24 lanf1 kernel: eepro100: wait_for_cmd_done timeout!
Aug  7 12:03:33 lanf1 last message repeated 10 times
Aug  7 12:03:37 lanf1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug  7 12:03:37 lanf1 kernel: eth0: Transmit timed out: status 0050  0c80 at 1954/1982 command 000c0000.



[root@lanf1 bin]# eepro100-diag eth0 -aa -ee -mm -f
eepro100-diag.c:v2.02 7/19/2000 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Index #1: Found a Intel i82562 EEPro100 adapter at 0xdf00.
i82557 chip registers at 0xdf00:
  0c000090 0f1123e0 00000000 00080002 18250021 00000600
  No interrupt sources are pending.
   The transmit unit state is 'Active'.
   The receive unit state is 'Ready'.
  This status is unusual for an activated interface.
 The Command register has an unprocessed command 0c00(?!).
EEPROM contents, size 64x16:
    00: 0300 9f47 c4df 1a03 0000 0201 4701 0000
  0x08: 0000 0000 49b2 3013 8086 007f ffff ffff
  0x10: ffff ffff ffff ffff ffff ffff ffff ffff
  0x18: ffff ffff ffff ffff ffff ffff ffff ffff
  0x20: ffff ffff ffff ffff ffff ffff ffff ffff
  0x28: ffff ffff ffff ffff ffff ffff ffff ffff
  0x30: 0000 ffff ffff ffff ffff ffff ffff ffff
  0x38: ffff ffff ffff 0000 ffff ffff ffff f5f4
 The EEPROM checksum is correct.
Intel EtherExpress Pro 10/100 EEPROM contents:
  Station address 00:03:47:9F:DF:C4.
  Board assembly 000000-000, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
 MII PHY #1 transceiver registers:
  3100 782d 02a8 0330 05e1 0021 0000 0000
  0000 0000 0000 0000 0000 0000 0000 0000
  2404 0000 0000 0000 0000 0000 0000 0000
  0000 0000 0000 0000 0010 0000 0000 0000.
  Baseline value of MII status register is 782d.

NOTE:  The eepro100-diag program hangs here, and will not
continue after at least 2 minutes.  Ctrl-c does stop it
though...

Interestingly enough, a minute after I did this, the whole
machine locked up hard :(



Here is an lspci I did before the lockup.

(The 82557 below is not a problem, it is the other Intel NIC.)
[root@lanf1 /root]# lspci -vvvv
00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 02)
	Subsystem: Intel Corporation: Unknown device 4532
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 0
	Capabilities: [88] #09 [f104]

00:02.0 VGA compatible controller: Intel Corporation 82815 CGC [Chipset Graphics Controller]  (rev 02) (prog-if 00 [VGA])
	Subsystem: Intel Corporation: Unknown device 4532
	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: 0
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
	Region 1: Memory at ffa80000 (32-bit, non-prefetchable) [size=512K]
	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=0 PME-

00:1e.0 PCI bridge: Intel Corporation 82820 820 (Camino 2) Chipset PCI (rev 02) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
	I/O behind bridge: 0000d000-0000dfff
	Memory behind bridge: ff400000-ff8fffff
	Prefetchable memory behind bridge: f6a00000-f6afffff
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-

00:1f.0 ISA bridge: Intel Corporation 82820 820 (Camino 2) Chipset ISA Bridge (ICH2) (rev 02)
	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: 0

00:1f.1 IDE interface: Intel Corporation 82820 820 (Camino 2) Chipset IDE U100 (rev 02) (prog-if 80 [Master])
	Subsystem: Intel Corporation: Unknown device 4532
	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: 0
	Region 4: I/O ports at ffa0 [size=16]

00:1f.2 USB Controller: Intel Corporation 82820 820 (Camino 2) Chipset USB (Hub A) (rev 02) (prog-if 00 [UHCI])
	Subsystem: Intel Corporation: Unknown device 4532
	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: 0
	Interrupt: pin D routed to IRQ 11
	Region 4: I/O ports at ef40 [size=32]

00:1f.3 SMBus: Intel Corporation 82820 820 (Camino 2) Chipset SMBus (rev 02)
	Subsystem: Intel Corporation: Unknown device 4532
	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-
	Interrupt: pin B routed to IRQ 9
	Region 4: I/O ports at efa0 [size=16]

00:1f.4 USB Controller: Intel Corporation 82820 820 (Camino 2) Chipset USB (Hub B) (rev 02) (prog-if 00 [UHCI])
	Subsystem: Intel Corporation: Unknown device 4532
	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: 0
	Interrupt: pin C routed to IRQ 10
	Region 4: I/O ports at ef80 [size=32]

00:1f.5 Multimedia audio controller: Intel Corporation: Unknown device 2445 (rev 02)
	Subsystem: Intel Corporation: Unknown device 4656
	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: 0
	Interrupt: pin B routed to IRQ 9
	Region 0: I/O ports at e800 [size=256]
	Region 1: I/O ports at ef00 [size=64]

01:08.0 Ethernet controller: Intel Corporation 82820 820 (Camino 2) Chipset Ethernet (rev 01)
	Subsystem: Intel Corporation: Unknown device 3013
	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: 32 (2000ns min, 14000ns max), cache line size 08
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at ff6ff000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at df00 [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=2 PME-

01:0b.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 01)
	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: 32 (2000ns min, 14000ns max)
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at f6aff000 (32-bit, prefetchable) [size=4K]
	Region 1: I/O ports at df80 [size=32]
	Region 2: Memory at ff800000 (32-bit, non-prefetchable) [size=1M]
	Expansion ROM at ff700000 [disabled] [size=1M]

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: [eepro100] Problem with Linux 2.4.7 and builtin eepro on Intel's EEA2 motherboard.

[Donald Becker]

On Tue, 7 Aug 2001, Ben Greear wrote:

> Subject: [eepro100] Problem with Linux 2.4.7 and builtin eepro on Intel's
    EEA2 motherboard.
> 
> The driver seems to lock up for a while and then recover...

Presumably this is the driver in the 2.4.7 kernel, not the Scyld driver.

> Aug  7 11:56:07 lanf1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Aug  7 11:56:07 lanf1 kernel: eth0: Transmit timed out: status 0050  0cf0 at 900/928 command 000c0000.
> Aug  7 11:58:53 lanf1 kernel: eepro100: wait_for_cmd_done timeout!

Hmmm, the chip didn't reset.


> [root@lanf1 bin]# eepro100-diag eth0 -aa -ee -mm -f
> eepro100-diag.c:v2.02 7/19/2000 Donald Becker (becker@scyld.com)
>  http://www.scyld.com/diag/index.html
> Index #1: Found a Intel i82562 EEPro100 adapter at 0xdf00.
> i82557 chip registers at 0xdf00:
>   0c000090 0f1123e0 00000000 00080002 18250021 00000600
>   No interrupt sources are pending.
>    The transmit unit state is 'Active'.

..and the transmit unit is still trying to do something (transmit?).

>    The receive unit state is 'Ready'.
>   This status is unusual for an activated interface.
>  The Command register has an unprocessed command 0c00(?!).

This is a little misleading.  The driver you are using is trying to mask
the early receive interrupt, but the proper approach is to configure the
chip to not generate the event, rather than mask the interrupt.

...
>  MII PHY #1 transceiver registers:
>   3100 782d 02a8 0330 05e1 0021 0000 0000
>   0000 0000 0000 0000 0000 0000 0000 0000
>   2404 0000 0000 0000 0000 0000 0000 0000
>   0000 0000 0000 0000 0010 0000 0000 0000.
>   Baseline value of MII status register is 782d.
> 
> NOTE:  The eepro100-diag program hangs here, and will not
> continue after at least 2 minutes.  Ctrl-c does stop it
> though...

It hasn't hung.  It's doing what it's documented to do -- polling the
MII register for state transititions.  Pull the network cable and you'll
see timestamped events as the link is lost and autonegotiation occurs.

> Interestingly enough, a minute after I did this, the whole
> machine locked up hard :(

That shouldn't happen -- polling the MII register should be safe.  This
might be due to the underlying problem that cause the eepro100 driver to
stop working.


Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993

Re: [eepro100] Problem with Linux 2.4.7 and builtin eepro on Intel's EEA2 motherboard.

[Christian Robottom Reis]

Had the same board, and the same sort of problems with both drivers. Had
to roll back to 2.2 and intel's e100. :(

On Tue, 7 Aug 2001, Ben Greear wrote:

> The driver seems to lock up for a while and then recover...
>
> Aug  7 11:55:19 lanf1 last message repeated 5 times
> Aug  7 11:56:04 lanf1 last message repeated 21 times
> Aug  7 11:56:07 lanf1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Aug  7 11:56:07 lanf1 kernel: eth0: Transmit timed out: status 0050  0cf0 at 900/928 command 000c0000.
> Aug  7 11:58:53 lanf1 kernel: eepro100: wait_for_cmd_done timeout!
> Aug  7 11:59:34 lanf1 last message repeated 10 times
> Aug  7 12:00:02 lanf1 last message repeated 16 times
> Aug  7 12:00:05 lanf1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Aug  7 12:00:05 lanf1 kernel: eth0: Transmit timed out: status 0050  0cf0 at 1151/1179 command 000c0000.
> Aug  7 12:02:24 lanf1 kernel: eepro100: wait_for_cmd_done timeout!
> Aug  7 12:02:47 lanf1 last message repeated 14 times
> Aug  7 12:03:09 lanf1 su(pam_unix)[5778]: session opened for user root by lanforge(uid=500)
> Aug  7 12:03:24 lanf1 kernel: eepro100: wait_for_cmd_done timeout!
> Aug  7 12:03:33 lanf1 last message repeated 10 times
> Aug  7 12:03:37 lanf1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Aug  7 12:03:37 lanf1 kernel: eth0: Transmit timed out: status 0050  0c80 at 1954/1982 command 000c0000.
>
>
>
> [root@lanf1 bin]# eepro100-diag eth0 -aa -ee -mm -f
> eepro100-diag.c:v2.02 7/19/2000 Donald Becker (becker@scyld.com)
>  http://www.scyld.com/diag/index.html
> Index #1: Found a Intel i82562 EEPro100 adapter at 0xdf00.
> i82557 chip registers at 0xdf00:
>   0c000090 0f1123e0 00000000 00080002 18250021 00000600
>   No interrupt sources are pending.
>    The transmit unit state is 'Active'.
>    The receive unit state is 'Ready'.
>   This status is unusual for an activated interface.
>  The Command register has an unprocessed command 0c00(?!).
> EEPROM contents, size 64x16:
>     00: 0300 9f47 c4df 1a03 0000 0201 4701 0000
>   0x08: 0000 0000 49b2 3013 8086 007f ffff ffff
>   0x10: ffff ffff ffff ffff ffff ffff ffff ffff
>   0x18: ffff ffff ffff ffff ffff ffff ffff ffff
>   0x20: ffff ffff ffff ffff ffff ffff ffff ffff
>   0x28: ffff ffff ffff ffff ffff ffff ffff ffff
>   0x30: 0000 ffff ffff ffff ffff ffff ffff ffff
>   0x38: ffff ffff ffff 0000 ffff ffff ffff f5f4
>  The EEPROM checksum is correct.
> Intel EtherExpress Pro 10/100 EEPROM contents:
>   Station address 00:03:47:9F:DF:C4.
>   Board assembly 000000-000, Physical connectors present: RJ45
>   Primary interface chip i82555 PHY #1.
>  MII PHY #1 transceiver registers:
>   3100 782d 02a8 0330 05e1 0021 0000 0000
>   0000 0000 0000 0000 0000 0000 0000 0000
>   2404 0000 0000 0000 0000 0000 0000 0000
>   0000 0000 0000 0000 0010 0000 0000 0000.
>   Baseline value of MII status register is 782d.
>
> NOTE:  The eepro100-diag program hangs here, and will not
> continue after at least 2 minutes.  Ctrl-c does stop it
> though...
>
> Interestingly enough, a minute after I did this, the whole
> machine locked up hard :(
>
>
>
> Here is an lspci I did before the lockup.
>
> (The 82557 below is not a problem, it is the other Intel NIC.)
> [root@lanf1 /root]# lspci -vvvv
> 00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 02)
> 	Subsystem: Intel Corporation: Unknown device 4532
> 	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
> 	Latency: 0
> 	Capabilities: [88] #09 [f104]
>
> 00:02.0 VGA compatible controller: Intel Corporation 82815 CGC [Chipset Graphics Controller]  (rev 02) (prog-if 00 [VGA])
> 	Subsystem: Intel Corporation: Unknown device 4532
> 	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: 0
> 	Interrupt: pin A routed to IRQ 11
> 	Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
> 	Region 1: Memory at ffa80000 (32-bit, non-prefetchable) [size=512K]
> 	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=0 PME-
>
> 00:1e.0 PCI bridge: Intel Corporation 82820 820 (Camino 2) Chipset PCI (rev 02) (prog-if 00 [Normal decode])
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
> 	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0
> 	Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
> 	I/O behind bridge: 0000d000-0000dfff
> 	Memory behind bridge: ff400000-ff8fffff
> 	Prefetchable memory behind bridge: f6a00000-f6afffff
> 	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
>
> 00:1f.0 ISA bridge: Intel Corporation 82820 820 (Camino 2) Chipset ISA Bridge (ICH2) (rev 02)
> 	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: 0
>
> 00:1f.1 IDE interface: Intel Corporation 82820 820 (Camino 2) Chipset IDE U100 (rev 02) (prog-if 80 [Master])
> 	Subsystem: Intel Corporation: Unknown device 4532
> 	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: 0
> 	Region 4: I/O ports at ffa0 [size=16]
>
> 00:1f.2 USB Controller: Intel Corporation 82820 820 (Camino 2) Chipset USB (Hub A) (rev 02) (prog-if 00 [UHCI])
> 	Subsystem: Intel Corporation: Unknown device 4532
> 	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: 0
> 	Interrupt: pin D routed to IRQ 11
> 	Region 4: I/O ports at ef40 [size=32]
>
> 00:1f.3 SMBus: Intel Corporation 82820 820 (Camino 2) Chipset SMBus (rev 02)
> 	Subsystem: Intel Corporation: Unknown device 4532
> 	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-
> 	Interrupt: pin B routed to IRQ 9
> 	Region 4: I/O ports at efa0 [size=16]
>
> 00:1f.4 USB Controller: Intel Corporation 82820 820 (Camino 2) Chipset USB (Hub B) (rev 02) (prog-if 00 [UHCI])
> 	Subsystem: Intel Corporation: Unknown device 4532
> 	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: 0
> 	Interrupt: pin C routed to IRQ 10
> 	Region 4: I/O ports at ef80 [size=32]
>
> 00:1f.5 Multimedia audio controller: Intel Corporation: Unknown device 2445 (rev 02)
> 	Subsystem: Intel Corporation: Unknown device 4656
> 	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: 0
> 	Interrupt: pin B routed to IRQ 9
> 	Region 0: I/O ports at e800 [size=256]
> 	Region 1: I/O ports at ef00 [size=64]
>
> 01:08.0 Ethernet controller: Intel Corporation 82820 820 (Camino 2) Chipset Ethernet (rev 01)
> 	Subsystem: Intel Corporation: Unknown device 3013
> 	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: 32 (2000ns min, 14000ns max), cache line size 08
> 	Interrupt: pin A routed to IRQ 11
> 	Region 0: Memory at ff6ff000 (32-bit, non-prefetchable) [size=4K]
> 	Region 1: I/O ports at df00 [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=2 PME-
>
> 01:0b.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 01)
> 	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: 32 (2000ns min, 14000ns max)
> 	Interrupt: pin A routed to IRQ 10
> 	Region 0: Memory at f6aff000 (32-bit, prefetchable) [size=4K]
> 	Region 1: I/O ports at df80 [size=32]
> 	Region 2: Memory at ff800000 (32-bit, non-prefetchable) [size=1M]
> 	Expansion ROM at ff700000 [disabled] [size=1M]
>
> Thanks,
> Ben
>
>


Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL

Re: [eepro100] Problem with Linux 2.4.7 and builtin eepro on Intel'sEEA2 motherboard.

[Ben Greear]

Donald Becker wrote:
> 
> On Tue, 7 Aug 2001, Ben Greear wrote:
> 
> > Subject: [eepro100] Problem with Linux 2.4.7 and builtin eepro on Intel's
>     EEA2 motherboard.
> >
> > The driver seems to lock up for a while and then recover...
> 
> Presumably this is the driver in the 2.4.7 kernel, not the Scyld driver.

Yes, I'm under the impression that the Scyld driver for 2.4.7 is not prime-time
yet.  I wouldn't mind being wrong!

Intel's driver only supports up to 2.4.4 according to their page.  So, that leaves
me with the kernel eepro100 driver (which due to the convienience of not having
to patch any files, is what I would prefer to work!)...

> 
> > Aug  7 11:56:07 lanf1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
> > Aug  7 11:56:07 lanf1 kernel: eth0: Transmit timed out: status 0050  0cf0 at 900/928 command 000c0000.
> > Aug  7 11:58:53 lanf1 kernel: eepro100: wait_for_cmd_done timeout!
> 
> Hmmm, the chip didn't reset.
> 
> > [root@lanf1 bin]# eepro100-diag eth0 -aa -ee -mm -f
> > eepro100-diag.c:v2.02 7/19/2000 Donald Becker (becker@scyld.com)
> >  http://www.scyld.com/diag/index.html
> > Index #1: Found a Intel i82562 EEPro100 adapter at 0xdf00.
> > i82557 chip registers at 0xdf00:
> >   0c000090 0f1123e0 00000000 00080002 18250021 00000600
> >   No interrupt sources are pending.
> >    The transmit unit state is 'Active'.
> 
> ..and the transmit unit is still trying to do something (transmit?).
> 
> >    The receive unit state is 'Ready'.
> >   This status is unusual for an activated interface.
> >  The Command register has an unprocessed command 0c00(?!).
> 
> This is a little misleading.  The driver you are using is trying to mask
> the early receive interrupt, but the proper approach is to configure the
> chip to not generate the event, rather than mask the interrupt.
> 
> ...
> >  MII PHY #1 transceiver registers:
> >   3100 782d 02a8 0330 05e1 0021 0000 0000
> >   0000 0000 0000 0000 0000 0000 0000 0000
> >   2404 0000 0000 0000 0000 0000 0000 0000
> >   0000 0000 0000 0000 0010 0000 0000 0000.
> >   Baseline value of MII status register is 782d.
> >
> > NOTE:  The eepro100-diag program hangs here, and will not
> > continue after at least 2 minutes.  Ctrl-c does stop it
> > though...
> 
> It hasn't hung.  It's doing what it's documented to do -- polling the
> MII register for state transititions.  Pull the network cable and you'll
> see timestamped events as the link is lost and autonegotiation occurs.

Oh, I don't remember seeing this result before...  It does indeed do
that on the working Intel NIC too, though, so I guess you're right..

> 
> > Interestingly enough, a minute after I did this, the whole
> > machine locked up hard :(
> 
> That shouldn't happen -- polling the MII register should be safe.  This
> might be due to the underlying problem that cause the eepro100 driver to
> stop working.

I've seen other related posts about locking up their machine, so I assume that
I hit that same bug..maybe I aggravated it by using the eepro100-diag program,
or maybe it was a coincidence...


By the way, the NICs were attached to a 10bt netgear 4-port hub.

THanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: [eepro100] Problem with Linux 2.4.7 and builtin eepro on Intel'sEEA2 motherboard.

[Ben Greear]

Christian Robottom Reis wrote:
> 
> Had the same board, and the same sort of problems with both drivers. Had
> to roll back to 2.2 and intel's e100. :(

Intel's e100 works with kernels up to 2.4.4, according to their page
(which I can't seem to access from a 2.4.7 machine, interestingly
enough!)

I didn't try that kernel because in that kernel the tulip driver is
busted for my NIC, so I'm caught between a rock and a huge amount of risky
patching/hacking that I don't have time for!

Ben

-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: [eepro100] Problem with Linux 2.4.7 and builtin eepro on Intel'sEEA2 motherboard.

[Christian Robottom Reis]

On Tue, 7 Aug 2001, Ben Greear wrote:

> By the way, the NICs were attached to a 10bt netgear 4-port hub.

I forgot to say: my hang with the EEA2 also happens exclusively on a
10BaseT hub.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL

Re: [eepro100] Problem with Linux 2.4.7 and builtin eepro on Intel'sEEA2 motherboard.

[Justin Guyett]

On Tue, 7 Aug 2001, Ben Greear wrote:

> Intel's e100 works with kernels up to 2.4.4, according to their page
> (which I can't seem to access from a 2.4.7 machine, interestingly
> enough!)

At least some of intel's servers are suffering from denial of ecn-enabled
traffic.  notably, I noticed it with the acpi pages.


justin

Re: [eepro100] Problem with Linux 2.4.7 and builtin eepro on Intel'sEEA2 motherboard.

[Donald Becker]

On Tue, 7 Aug 2001, Ben Greear wrote:
> Donald Becker wrote:
> > On Tue, 7 Aug 2001, Ben Greear wrote:
> > 
> > > Subject: [eepro100] Problem with Linux 2.4.7 and builtin eepro on Intel's
> >     EEA2 motherboard.
> > >
> > > The driver seems to lock up for a while and then recover...
> > 
> > Presumably this is the driver in the 2.4.7 kernel, not the Scyld driver.
> 
> Yes, I'm under the impression that the Scyld driver for 2.4.7 is not
> prime-time yet.  I wouldn't mind being wrong!

We don't validate on the 2.4 kernels, but the drivers should all
nominally work with 2.4.  It will at least provide a useful reference
point.

The current public version of eepro100.c is v1.17.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993

Re: [eepro100] Problem with Linux 2.4.7 and builtin eepro onIntel'sEEA2 motherboard. (Solved, kinda)

[Ben Greear]

A kind Intel employee told me that the e100 would indeed work
on 2.4.7 kernels, so I downloaded the driver and gave it a shot.

So far, it seems to be working flawlessly.  Does anyone know how
to get mii-diag like information out of the e100?  (For instance,
I'd like to be able to query the card to see what it's current link
speed is, and force it to various speeds and advertise flags...)

Enjoy,
Ben

-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: Problem with Linux 2.4.7 and builtin eepro on Intel's EEA2 motherboard.

[Florin Andrei]

On 07 Aug 2001 13:12:46 -0700, Ben Greear wrote:
> The driver seems to lock up for a while and then recover...
> 
> Aug  7 11:55:19 lanf1 last message repeated 5 times
> Aug  7 11:56:04 lanf1 last message repeated 21 times
> Aug  7 11:56:07 lanf1 kernel: NETDEV WATCHDOG: eth0: transmit timed out

Same hardware, same problem, only worse: for me, it locks up forever!

Had this problem with several 2.4.x versions, then switched to Intel's
driver. I'm using the Intel driver now, with 2.4.7, and i have no
problem.

-- 
Florin Andrei

Re: [eepro100] Re: Problem with Linux 2.4.7 and builtin eepro on Intel's EEA2 motherboard.

[Luc Lalonde]

Hello Fiorin,

What is your uptime on this machine.  I've come to the same conclusion and
I'm up to 13 days with the Intel e100 driver.

Cheers.


On 8 Aug 2001, Florin Andrei wrote:

> On 07 Aug 2001 13:12:46 -0700, Ben Greear wrote:
> > The driver seems to lock up for a while and then recover...
> >
> > Aug  7 11:55:19 lanf1 last message repeated 5 times
> > Aug  7 11:56:04 lanf1 last message repeated 21 times
> > Aug  7 11:56:07 lanf1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
>
> Same hardware, same problem, only worse: for me, it locks up forever!
>
> Had this problem with several 2.4.x versions, then switched to Intel's
> driver. I'm using the Intel driver now, with 2.4.7, and i have no
> problem.
>
> --
> Florin Andrei
>
>
> _______________________________________________
> eepro100 mailing list
> eepro100@scyld.com
> http://www.scyld.com/mailman/listinfo/eepro100
>

Re: [eepro100] Re: Problem with Linux 2.4.7 and builtin eepro on Intel's EEA2 motherboard.

[Florin Andrei]

On 08 Aug 2001 21:58:39 -0400, Luc Lalonde wrote:
> Hello Fiorin,
> 
> What is your uptime on this machine.  I've come to the same conclusion and
> I'm up to 13 days with the Intel e100 driver.

With kernel's driver, the interface was frozen in 30 minutes. I had to
ifdown / ifup the interface.
With Intel's driver, it works for days with no problem. But i never had
an uptime bigger than one week on that system.

-- 
Florin Andrei