Strange e1000

Strange e1000

[Michael Knigge]

Hi *,

when I load the e1000 module, my NIC is recognized. Then, "pump –i 
eth0" is called (DHCP-Client), the message "e1000: eth0 NIC Link is Up 
1000 Mbps Full Duplex" appears and after some time I get the message 
"operation failed".

When I sleep some time (currently 20 seconds) before doing the "pump", 
everything works as expected.

What the hell is happening here? Ok, I got it working with the 
20-sec-sleep but this is not the way it sould work...

My Board is a Gigabyte GA-7ZXR (1.0) and the Intel NIC is a PRO/1000 
MT (should be the 82540OEM Chip). The NIC is attached to a NetGear 
FSM726S Switch (24x100 + 2x1000). It is currenty the only box attached 
with a gigabit-nic to the switch. All other PC's (including the 
DHCP-Server) are 100 Mbit/s.... I hope I've written all somehow 
important things ;-)

My distribution is Debian Woody 3.0R1 with some updates (i.e. pump). 
I'm running 2.4.18 with the e1000 driver from the Intel site (I've 
tried e1000-4.6.11 and e1000-5.0.43) and pump is 0.8.14. I've also 
tried 2.4.21-pre5-ac3 with the "built-in" e1000 driver. All without 
any success...

Output from dmesg:

Linux version 2.4.18 (root@crash) (gcc version 2.95.4 20011002 (Debian 
prerelease)) #1 SMP Fri Dec 27 09:08:43 CET 2002
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 0000000010000000 (usable)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
On node 0 totalpages: 65536
zone(0): 4096 pages.
zone(1): 61440 pages.
zone(2): 0 pages.
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Kernel command line: auto BOOT_IMAGE=Linux ro root=801
Initializing CPU#0
Detected 902.063 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1795.68 BogoMIPS
Memory: 255388k/262144k available (1186k kernel code, 6368k reserved, 
450k data, 220k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: Before vendor init, caps: 0183fbff c1c7fbff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183fbff c1c7fbff 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0183fbff c1c7fbff 00000000 00000000
CPU:             Common caps: 0183fbff c1c7fbff 00000000 00000000
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
CPU: Before vendor init, caps: 0183fbff c1c7fbff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183fbff c1c7fbff 00000000 00000000
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0183fbff c1c7fbff 00000000 00000000
CPU:             Common caps: 0183fbff c1c7fbff 00000000 00000000
CPU0: AMD Athlon(tm) Processor stepping 02
per-CPU timeslice cutoff: 730.71 usecs.
SMP motherboard not detected.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 902.0570 MHz.
..... host bus clock speed is 200.4569 MHz.
cpu: 0, clocks: 2004569, slice: 1002284
CPU0<T0:2004560,T1:1002272,D:4,S:1002284,C:2004569>
Waiting on wait_init_idle (map = 0x0)
All processors have done init_idle
PCI: PCI BIOS revision 2.10 entry at 0xfdb61, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Disabling VIA memory write queue: [55] 89->09
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
PCI: Disabling Via external APIC routing
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ 
SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
block: 128 slots per queue, batch=32
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with 
idebus=xx
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
SCSI subsystem driver Revision: 1.00
3ware Storage Controller device driver for Linux v1.02.00.016.
PCI: Found IRQ 10 for device 00:0f.0
scsi0 : Found a 3ware Storage Controller at 0xdc00, IRQ: 10, P-chip: 
5.7
scsi0 : 3ware Storage Controller
  Vendor: 3ware     Model: 3w-xxxx           Rev: 1.0
  Type:   Direct-Access                      ANSI SCSI revision: 00
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: 160832256 512-byte hdwr sectors (82346 MB)
Partition check:
 sda: sda1 sda2 sda3 sda4
Linux Kernel Card Services 3.1.22
  options:  [pci] [cardbus]
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
ds: no socket drivers loaded!
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 220k freed
Adding Swap: 996020k swap-space (priority -1)
EXT3 FS 2.4-0.9.17, 10 Jan 2002 on sd(8,1), internal journal
Real Time Clock Driver v1.10e
Intel(R) PRO/1000 Network Driver - version 5.0.43
Copyright (c) 1999-2003 Intel Corporation.
PCI: Found IRQ 9 for device 00:0a.0
eth0: Intel(R) PRO/1000 Network Connection
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.17, 10 Jan 2002 on sd(8,4), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex
e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
spurious 8259A interrupt: IRQ7.


Any ideas? 


Bye & Thanks,
  Michael

Re: Strange e1000

[Paul Rolland]

Hello,

> when I load the e1000 module, my NIC is recognized. Then, "pump -i 
> eth0" is called (DHCP-Client), the message "e1000: eth0 NIC 
> Link is Up 
> 1000 Mbps Full Duplex" appears and after some time I get the message 
> "operation failed".
> 
> When I sleep some time (currently 20 seconds) before doing 
> the "pump", 
> everything works as expected.
> 
> What the hell is happening here? Ok, I got it working with the 
> 20-sec-sleep but this is not the way it sould work...
> 
> My Board is a Gigabyte GA-7ZXR (1.0) and the Intel NIC is a PRO/1000 
> MT (should be the 82540OEM Chip). The NIC is attached to a NetGear 
> FSM726S Switch (24x100 + 2x1000). It is currenty the only box 
> attached 

Could it be possible that the 1000MBps FD on the e1000 side is
a local configuration, and that it needs some time to discuss with
the Netgear switch to negotiate correctly speed and duplex before 
working correctly ? (i.e. 20 sec = negotiation time)

Regards,
Paul

Re: Strange e1000

[Michael Knigge]

Hi,

> Could it be possible that the 1000MBps FD on the e1000 side is
> a local configuration, and that it needs some time to discuss with
> the Netgear switch to negotiate correctly speed and duplex before
> working correctly ? (i.e. 20 sec = negotiation time)

Hmmm, I don't think so but I will try to 

A) force e1000 to negotiate only 1000/FD   and
B) configure the switch to force 1000/FD

Maybee it wil help....


Bye
  Michael

Re: Strange e1000

[Abhishek Agrawal]

On Fri, 2003-04-04 at 19:11, Paul Rolland wrote:

> Could it be possible that the 1000MBps FD on the e1000 side is
> a local configuration, and that it needs some time to discuss with
> the Netgear switch to negotiate correctly speed and duplex before
> working correctly ? (i.e. 20 sec = negotiation time)
Autoneg must be completed within 2 sec, or else it is considered as
failed.

Re: Strange e1000

[Justin Cormack]

On Fri, 2003-04-04 at 14:41, Paul Rolland wrote:
> Hello,
> 
> > when I load the e1000 module, my NIC is recognized. Then, "pump -i 
> > eth0" is called (DHCP-Client), the message "e1000: eth0 NIC 
> > Link is Up 
> > 1000 Mbps Full Duplex" appears and after some time I get the message 
> > "operation failed".
> > 
> > When I sleep some time (currently 20 seconds) before doing 
> > the "pump", 
> > everything works as expected.
> > 
> > What the hell is happening here? Ok, I got it working with the 
> > 20-sec-sleep but this is not the way it sould work...
> > 
> > My Board is a Gigabyte GA-7ZXR (1.0) and the Intel NIC is a PRO/1000 
> > MT (should be the 82540OEM Chip). The NIC is attached to a NetGear 
> > FSM726S Switch (24x100 + 2x1000). It is currenty the only box 
> > attached 
> 
> Could it be possible that the 1000MBps FD on the e1000 side is
> a local configuration, and that it needs some time to discuss with
> the Netgear switch to negotiate correctly speed and duplex before 
> working correctly ? (i.e. 20 sec = negotiation time)

It is probably something like this. For some reason the managed Netgear
switches take a very long time to do anything. Log into the switch and
watch the port status while this happens to confirm. I actually can't
netboot off these switches because if this. Hopefully Netgear will come
up with a fix.

Justin

Re: Strange e1000

[Jeff Garzik]

On Fri, Apr 04, 2003 at 03:45:25PM +0100, Justin Cormack wrote:
> On Fri, 2003-04-04 at 14:41, Paul Rolland wrote:
> > Hello,
> > 
> > > when I load the e1000 module, my NIC is recognized. Then, "pump -i 
> > > eth0" is called (DHCP-Client), the message "e1000: eth0 NIC 
> > > Link is Up 
> > > 1000 Mbps Full Duplex" appears and after some time I get the message 
> > > "operation failed".
> > > 
> > > When I sleep some time (currently 20 seconds) before doing 
> > > the "pump", 
> > > everything works as expected.
> > > 
> > > What the hell is happening here? Ok, I got it working with the 
> > > 20-sec-sleep but this is not the way it sould work...
> > > 
> > > My Board is a Gigabyte GA-7ZXR (1.0) and the Intel NIC is a PRO/1000 
> > > MT (should be the 82540OEM Chip). The NIC is attached to a NetGear 
> > > FSM726S Switch (24x100 + 2x1000). It is currenty the only box 
> > > attached 
> > 
> > Could it be possible that the 1000MBps FD on the e1000 side is
> > a local configuration, and that it needs some time to discuss with
> > the Netgear switch to negotiate correctly speed and duplex before 
> > working correctly ? (i.e. 20 sec = negotiation time)
> 
> It is probably something like this. For some reason the managed Netgear
> switches take a very long time to do anything. Log into the switch and
> watch the port status while this happens to confirm. I actually can't
> netboot off these switches because if this. Hopefully Netgear will come
> up with a fix.

In another thread, Scott Feldman (one of the e1000 team) asked if
spanning trees were enabled on the switch.  That could be a potential
cause.

	Jeff

Re: Strange e1000

[Patrick R. McManus]

[Jeff Garzik: Apr 04 10:48]
> On Fri, Apr 04, 2003 at 03:45:25PM +0100, Justin Cormack wrote:
> > On Fri, 2003-04-04 at 14:41, Paul Rolland wrote:
> > > Hello,
> > > 
> > > > when I load the e1000 module, my NIC is recognized. Then, "pump -i 
> > > > eth0" is called (DHCP-Client), the message "e1000: eth0 NIC 
> > > > Link is Up 
> > > > 1000 Mbps Full Duplex" appears and after some time I get the message 
> > > > "operation failed".
> > > > 
> > > > When I sleep some time (currently 20 seconds) before doing 
> > > > the "pump", 
> > > > everything works as expected.
> > > > 
[..]

> > It is probably something like this. For some reason the managed Netgear
> > switches take a very long time to do anything. Log into the switch and
> > watch the port status while this happens to confirm. I actually can't
> > netboot off these switches because if this. Hopefully Netgear will come
> > up with a fix.
> 
> In another thread, Scott Feldman (one of the e1000 team) asked if
> spanning trees were enabled on the switch.  That could be a potential
> cause.

I can confirm this is isolated to the managed netgear switches.. I
started the other thread jeff mentions and, just this morning, cobbled
together a network without them and had no problems. I'll see if I can
create a setup without spanning tree to test that explicitly.

Re: Strange e1000

[Patrick R. McManus]

> I can confirm this is isolated to the managed netgear switches.. I
> started the other thread jeff mentions and, just this morning, cobbled
> together a network without them and had no problems. I'll see if I can
> create a setup without spanning tree to test that explicitly.

yes - turning off spanning tree on the netgear switches 'fixes' this
issue with the intel 1000 MT.

Re: Strange e1000

[Jeff Garzik]

On Fri, Apr 04, 2003 at 07:49:28PM +0530, Abhishek Agrawal wrote:
> On Fri, 2003-04-04 at 19:11, Paul Rolland wrote:
> 
> > Could it be possible that the 1000MBps FD on the e1000 side is
> > a local configuration, and that it needs some time to discuss with
> > the Netgear switch to negotiate correctly speed and duplex before
> > working correctly ? (i.e. 20 sec = negotiation time)
> Autoneg must be completed within 2 sec, or else it is considered as
> failed.

If we follow this rule, we have lots of Cisco and other network gear
that will not be able to communicate with Linux.

	Jeff

Re: Strange e1000

[Henning P. Schmiedehausen]

Jeff Garzik <jgarzik@pobox.com> writes:

>On Fri, Apr 04, 2003 at 07:49:28PM +0530, Abhishek Agrawal wrote:
>> On Fri, 2003-04-04 at 19:11, Paul Rolland wrote:
>> 
>> > Could it be possible that the 1000MBps FD on the e1000 side is
>> > a local configuration, and that it needs some time to discuss with
>> > the Netgear switch to negotiate correctly speed and duplex before
>> > working correctly ? (i.e. 20 sec = negotiation time)
>> Autoneg must be completed within 2 sec, or else it is considered as
>> failed.

>If we follow this rule, we have lots of Cisco and other network gear
>that will not be able to communicate with Linux.

2 seconds sound like "spanning-tree portfast" in Cisco-speak. 20
seconds sounds like normal configuration. Both are legal and work with
normal FE gear. It might be possible that you must deactivate
spanning-tree if you don't connect a switch.

I personally found the 20 second break always annoying so I routinely
disable it on my catalysts. :-)

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

Re: Strange e1000 - SOLVED

[Michael Knigge]

Hi all,

> yes - turning off spanning tree on the netgear switches 'fixes' this
> issue with the intel 1000 MT.

I can confirm this, too.... now it works like a charm for me.

Thank you all for your help....


Bye
  Michael - hey, great monday this week ;-)

RE: Strange e1000

[Mroczek, Joseph T]

On Fri, 2003-04-04 at 19:11, Paul Rolland wrote:

> Could it be possible that the 1000MBps FD on the e1000 side is
> a local configuration, and that it needs some time to discuss with
> the Netgear switch to negotiate correctly speed and duplex before
> working correctly ? (i.e. 20 sec = negotiation time)
Autoneg must be completed within 2 sec, or else it is considered as
failed.

It should be pointed out that there is a difference between completing
autonegotation and being able to pass traffic to other devices in the
network. The spanning tree and port fast settings have nothing to do with
autonegotiation. With port fast disabled on these switches, autonegotation
usually completes in the required 2s, but the switch does not pass frames to
the rest of the network until spanning tree assures loop free topology. The
NIC and switch port are actively passing traffic, but the switch is not
forwarding that traffic.

Hope this helps clarify.

~joe