From ThomasScholten@schmuecker.de Thu Nov 1 03:32:00 2001 From: ThomasScholten@schmuecker.de (Scholten, Thomas) Date: Thu Nov 1 03:32:00 2001 Subject: [eepro100] RE: single ping prob (sorry if i sended this one twice) Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C162AF.A448D540 Content-Type: text/plain; charset="iso-8859-1" Hello All, at first a big sorry in case i sended this one twice (i'm currently fighting this outlook thingy and it seems he won once or twice) i'm currently experience an unusal error by using two Intel 82557 NIC's. When i ping a random, reachable site i only get 1 ping/pong through than it seems to hang: ping www.heise.de PING www.heise.de (193.99.144.71): 56 data bytes 64 bytes from 193.99.144.71: icmp_seq=0 ttl=249 time=3.725 ms using ctrl-c... --- www.heise.de ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 3.725/3.725/3.725 ms ...tells everything is ok. Further symptoms are slow connection in telnet sessions. All my investigations ended up with no result. The NIC's are driven by the eepro100.o module under a 2.2.19 kernel (SuSE dist). less /proc/pci brings up the following informatiion: Bus 0, device 2, function 0: Ethernet controller: Intel 82557 (rev 8). Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=64. Min Gnt=8.Max Lat=56. Non-prefetchable 32 bit memory at 0xc4fff000 [0xc4fff000]. I/O at 0x2400 [0x2401]. Non-prefetchable 32 bit memory at 0xc4e00000 [0xc4e00000]. us 0, device 5, function 0: Ethernet controller: Intel 82557 (rev 8). Medium devsel. Fast back-to-back capable. IRQ 5. Master Capable. Latency=64. Min Gnt=8.Max Lat=56. Non-prefetchable 32 bit memory at 0xc4dfd000 [0xc4dfd000]. I/O at 0x2c00 [0x2c01]. Non-prefetchable 32 bit memory at 0xc4c00000 [0xc4c00000]. Can anyone gimme a hand tracking down this problem ?? greetings from germany Tom Scholten ------_=_NextPart_001_01C162AF.A448D540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: single ping prob (sorry if i sended this one twice)

Hello All,

at first a big sorry in case i sended this one twice = (i'm currently fighting this outlook thingy and it seems he won once or = twice)

i'm currently experience an unusal error by using two = Intel 82557 NIC's. When i ping a random, reachable site i only get 1 = ping/pong through than it seems to hang:

ping www.heise.de
PING www.heise.de (193.99.144.71): 56 data = bytes
64 bytes from 193.99.144.71: icmp_seq=3D0 ttl=3D249 = time=3D3.725 ms

using ctrl-c...

--- www.heise.de ping statistics ---
1 packets transmitted, 1 packets received, 0% packet = loss
round-trip min/avg/max =3D 3.725/3.725/3.725 = ms

...tells everything is ok.

Further symptoms are slow connection in telnet = sessions. All my investigations ended up with no result. The NIC's are = driven by the eepro100.o module under a 2.2.19 kernel (SuSE = dist).

less /proc/pci brings up the following = informatiion:

Bus  0, device   2, function  = 0:
    Ethernet controller: Intel 82557 = (rev 8).
      Medium devsel.  = Fast back-to-back capable.  IRQ 11.  Master Capable.  = Latency=3D64.  Min Gnt=3D8.Max Lat=3D56.
      Non-prefetchable 32 = bit memory at 0xc4fff000 [0xc4fff000].
      I/O at 0x2400 = [0x2401].
      Non-prefetchable 32 = bit memory at 0xc4e00000 [0xc4e00000].
us  0, device   5, function  = 0:
    Ethernet controller: Intel 82557 = (rev 8).
      Medium devsel.  = Fast back-to-back capable.  IRQ 5.  Master Capable.  = Latency=3D64.  Min Gnt=3D8.Max Lat=3D56.
      Non-prefetchable 32 = bit memory at 0xc4dfd000 [0xc4dfd000].
      I/O at 0x2c00 = [0x2c01].
      Non-prefetchable 32 = bit memory at 0xc4c00000 [0xc4c00000].

Can anyone gimme a hand tracking down this problem = ??

greetings from germany

Tom Scholten

------_=_NextPart_001_01C162AF.A448D540-- From rsweet@atos-group.nl Mon Nov 5 07:15:01 2001 From: rsweet@atos-group.nl (Ryan Sweet) Date: Mon Nov 5 07:15:01 2001 Subject: [eepro100] scyld driver for 2.4? Message-ID: I'm having difficulty locating the eepro100 driver from Scyld for Linux 2.4.x. The web page for the network drivers states that it is only for 2.2, but recently on lkml there has been mention of a Scyld driver for 2.4.x, but I can't find a link to it anywhere... any pointers? thanks, -Ryan -- Ryan Sweet Atos Origin Engineering Services http://www.aoes.nl From Francois.Isabelle@ca.kontron.com Mon Nov 5 09:22:01 2001 From: Francois.Isabelle@ca.kontron.com (Isabelle, Francois) Date: Mon Nov 5 09:22:01 2001 Subject: [eepro100] 82559ER Message-ID: <5009AD9521A8D41198EE00805F85F18F017CE0AB@SEMBO111> Hi, you might as well have some difficulties finding a PXE (Boot from lan) bios extension for the 82559ER, since there is no support from Intel to implement it. > -----Original Message----- > From: Christoph Plattner [SMTP:christoph.plattner@alcatel.at] > Sent: 20 septembre, 2001 02:49 > To: ml_ravi@usa.net > Cc: eepro100@scyld.com > Subject: Re: [eepro100] 82559ER > > Hello, > > yes I think, I can help you. > The 82559ER is a subset of the 82559. The feature the > 82559ER misses in comparison to 82559 > - No CardBus and modem support, as the 82559 has a internel > PCMCIA/CardBus controller > - Some restriction in WOL > - New Device ID 1209 for 82559ER, I think 82559 has Device ID 1229 > > For a "normal" user, there is NO relevant differece between the > two chip derivates. The only point is, that chip ID of 1209 > instead of the 1229, which often older drivers do not recognize. > For this I often patch the chip ID (for test purpose) or I add > the new ID to be tested from the driver. > > With friendly regards > Christoph > > > ravi modgekar wrote: > > > > hi, > > Does anybody can help me out in finding out the > > main difference between 82559ER and 82559. > > > > thanks > > --- eepro100-admin@scyld.com wrote: > > > > > > Send eepro100 mailing list submissions to > > > eepro100@scyld.com > > > > > > To subscribe or unsubscribe via the web, visit > > > http://www.scyld.com/mailman/listinfo/eepro100 > > > or, via email, send a message with subject or body > > > 'help' to > > > eepro100-request@scyld.com > > > You can reach the person managing the list at > > > eepro100-admin@scyld.com > > > > > > When replying, please edit your Subject line so it > > > is more specific than > > > "Re: Contents of eepro100 digest..." > > > > > > > > > Today's Topics: > > > > > > 1. eepro100 driver (2.4 kernel) fails with S2080 > > > Tomcat i815t motherboard. (Ben Greear) > > > 2. e100 driver fails to work correctly with Tyan > > > S2080 Tomcat i185t > > > motherboard. (Ben Greear) > > > 3. Re: eepro100 driver (2.4 kernel) fails with > > > S2080 Tomcat > > > i815t motherboard. (Donald Becker) > > > 4. Re: eepro100 driver (2.4 kernel) fails with > > > S2080 Tomcati815t > > > motherboard. (Ben Greear) > > > 5. BSD driver (Alexander Gdalevich) > > > > > > --__--__-- > > > > > > Message: 1 > > > Date: Tue, 18 Sep 2001 19:20:13 -0700 > > > From: Ben Greear > > > Organization: Candela Technologies > > > To: eepro list , > > > linux-kernel > > > Subject: [eepro100] eepro100 driver (2.4 kernel) > > > fails with S2080 Tomcat i815t motherboard. > > > > > > I have a Tyan motherboard (S2080 Tomcat i815t) with > > > 2 built-in NICs. > > > > > > The manual claims this: > > > > > > "One Intel 82559 LAN controller > > > One ICH2 LAN controller" > > > > > > Seems that the eepro driver tries to bring up both > > > of > > > them, and fails to read the eeprom on the second one > > > it > > > scans. One visible result is that the MAC is all > > > FF's. > > > > > > I have two other EEPRO NICs in the system, and they > > > seem to be > > > detected first. > > > > > > The kernel is 2.4.10-pre11: > > > [root@lanf2 /root]# dmesg | more > > > Linux version 2.4.10-pre11 (root@lanf2) (gcc version > > > 2.96 20000731 (Red Hat Linux 7.1 2.96-85)) #3 Tue > > > Sep 18 > > > 10:07:01 MST 2001 > > > The same problem is appearant with RH's 7.1 kernels > > > (the upgrade 2.4.3* too). > > > > > > > > > Here is a pertinent part of the dmesg. > > > eepro100-diag messages > > > follow below, along with an 'ifconfig -a'. > > > > > > The kernel is 2.4.10-pre11: > > > [root@lanf2 /root]# dmesg | more > > > Linux version 2.4.10-pre11 (root@lanf2) (gcc version > > > 2.96 20000731 (Red Hat Linux 7.1 2.96-85)) #3 Tue > > > Sep 18 > > > 10:07:01 MST 2001 > > > > > > > > > > > > eepro100.c:v1.09j-t 9/29/99 Donald Becker > > > > > http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html > > > eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by > > > Andrey V. Savochkin and others > > > PCI: Found IRQ 10 for device 01:0b.0 > > > eth0: Intel Corporation 82557 [Ethernet Pro 100] > > > (#3), 00:E0:81:03:B9:7B, IRQ 10. > > > Board assembly 567812-052, Physical connectors > > > present: RJ45 > > > Primary interface chip i82555 PHY #1. > > > General self-test: passed. > > > Serial sub-system self-test: passed. > > > Internal registers self-test: passed. > > > ROM checksum self-test: passed (0x04f4518b). > > > PCI: Found IRQ 3 for device 01:09.0 > > > eth1: Intel Corporation 82557 [Ethernet Pro 100] > > > (#2), 00:90:27:65:39:1B, IRQ 3. > > > Board assembly 721383-006, Physical connectors > > > present: RJ45 > > > Primary interface chip i82555 PHY #1. > > > General self-test: passed. > > > Serial sub-system self-test: passed. > > > Internal registers self-test: passed. > > > ROM checksum self-test: passed (0x04f4518b). > > > PCI: Found IRQ 9 for device 01:04.0 > > > PCI: Sharing IRQ 9 with 00:1f.3 > > > eth2: Intel Corporation 82557 [Ethernet Pro 100], > > > 00:90:27:65:37:8A, IRQ 9. > > > Board assembly 721383-006, Physical connectors > > > present: RJ45 > > > Primary interface chip i82555 PHY #1. > > > General self-test: passed. > > > Serial sub-system self-test: passed. > > > Internal registers self-test: passed. > > > ROM checksum self-test: passed (0x04f4518b). > > > PCI: Found IRQ 11 for device 01:08.0 > > > eth3: Invalid EEPROM checksum 0xff00, check settings > > > before activating this device! > > > eth3: OEM i82557/i82558 10/100 Ethernet, > > > FF:FF:FF:FF:FF:FF, IRQ 11. > > > Board assembly ffffff-255, Physical connectors > > > present: RJ45 BNC AUI MII > > > Primary interface chip unknown-15 PHY #31. > > > Secondary interface chip i82555. > > > General self-test: passed. > > > Serial sub-system self-test: passed. > > > Internal registers self-test: passed. > > > ROM checksum self-test: passed (0x04f4518b). > > > > > > > > > > > > > > > > > > [root@lanf2 /root]# eepro100-diag > > > 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 i82557 (or i82558) > > > EtherExpressPro100B adapter at 0xdf00. > > > A potential i82557 chip has been found, but it > > > appears to be active. > > > Either shutdown the network, or use the '-f' flag. > > > Index #2: Found a Intel i82557 (or i82558) > > > EtherExpressPro100B adapter at 0xde80. > > > Index #3: Found a Intel i82557 (or i82558) > > > EtherExpressPro100B adapter at 0xdd00. > > > Index #4: Found a Intel i82562 EEPro100 adapter at > > > 0xdd80. > > > Use '-a' or '-aa' to show device registers, > > > '-e' to show EEPROM contents, -ee for parsed > > > contents, > > > or '-m' or '-mm' to show MII management registers. > > > > > > > > > [root@lanf2 /root]# eepro100-diag -aaeemmf eth3 > > > 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 i82557 (or i82558) > > > EtherExpressPro100B adapter at 0xdf00. > > > i82557 chip registers at 0xdf00: > > > 0c000090 0f22c000 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: e000 0381 7bb9 0403 0000 0201 4701 0000 > > > 0x08: 5678 1234 4082 100c 8086 0000 0000 0000 > > > ... > > > 0x30: 0128 0000 0000 0000 0000 0000 0000 0000 > > > 0x38: 0000 0000 0000 0000 0000 0000 0000 d393 > > > The EEPROM checksum is correct. > > > Intel EtherExpress Pro 10/100 EEPROM contents: > > > Station address 00:E0:81:03:B9:7B. > > > Board assembly 567812-052, Physical connectors > > > present: RJ45 > > > Primary interface chip i82555 PHY #1. > > > MII PHY #1 transceiver registers: > > > 3000 782d 02a8 0154 05e1 0021 0000 0000 > > > 0000 0000 0000 0000 0000 0000 0000 0000 > > > 0400 0000 0001 0000 0000 0000 0000 0000 > > > 0000 0000 0000 0000 0000 0000 0000 0000. > > > Baseline value of MII status register is 782d. > > > > > > > > > > > > [root@lanf2 /root]# eepro100-diag -aaeemmf eth2 > > > 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 i82557 (or i82558) > > > EtherExpressPro100B adapter at 0xdf00. > > > i82557 chip registers at 0xdf00: > > > 0c000090 0f22c000 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: e000 0381 7bb9 0403 0000 0201 4701 0000 > > > 0x08: 5678 1234 4082 100c 8086 0000 0000 0000 > > > ... > > > 0x30: 0128 0000 0000 0000 0000 0000 0000 0000 > > > 0x38: 0000 0000 0000 0000 0000 0000 0000 d393 > > > The EEPROM checksum is correct. > > > Intel EtherExpress Pro 10/100 EEPROM contents: > > > Station address 00:E0:81:03:B9:7B. > > > Board assembly 567812-052, Physical connectors > > > present: RJ45 > > > Primary interface chip i82555 PHY #1. > > > MII PHY #1 transceiver registers: > > > 3000 782d 02a8 0154 05e1 0021 0000 0000 > > > 0000 0000 0000 0000 0000 0000 0000 0000 > > > 0400 0000 0001 0000 0000 0000 0000 0000 > > > 0000 0000 0000 0000 0000 0000 0000 0000. > > > Baseline value of MII status register is 782d. > > > > > > [root@lanf2 /root]# eepro100-diag -aaeemmf eth1 > > > 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 i82557 (or i82558) > > > EtherExpressPro100B adapter at 0xdf00. > > > i82557 chip registers at 0xdf00: > > > 0c000090 0f22c000 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: e000 0381 7bb9 0403 0000 0201 4701 0000 > > > 0x08: 5678 1234 4082 100c 8086 0000 0000 0000 > > > ... > > > 0x30: 0128 0000 0000 0000 0000 0000 0000 0000 > > > 0x38: 0000 0000 0000 0000 0000 0000 0000 d393 > > > The EEPROM checksum is correct. > > > Intel EtherExpress Pro 10/100 EEPROM contents: > > > Station address 00:E0:81:03:B9:7B. > > > Board assembly 567812-052, Physical connectors > > > present: RJ45 > > > Primary interface chip i82555 PHY #1. > > > MII PHY #1 transceiver registers: > > > 3000 782d 02a8 0154 05e1 0021 0000 0000 > > > 0000 0000 0000 0000 0000 0000 0000 0000 > > > 0400 0000 0001 0000 0000 0000 0000 0000 > > > 0000 0000 0000 0000 0000 0000 0000 0000. > > > Baseline value of MII status register is 782d. > > > > > > [root@lanf2 /root]# eepro100-diag -aaeemmf eth0 > > > 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 i82557 (or i82558) > > > EtherExpressPro100B adapter at 0xdf00. > > > i82557 chip registers at 0xdf00: > > > 0c000090 0f22c000 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: e000 0381 7bb9 0403 0000 0201 4701 0000 > > > 0x08: 5678 1234 4082 100c 8086 0000 0000 0000 > > > ... > > > 0x30: 0128 0000 0000 0000 0000 0000 0000 0000 > > > 0x38: 0000 0000 0000 0000 0000 0000 0000 d393 > > > The EEPROM checksum is correct. > > > Intel EtherExpress Pro 10/100 EEPROM contents: > > > Station address 00:E0:81:03:B9:7B. > > > Board assembly 567812-052, Physical connectors > > > present: RJ45 > > > Primary interface chip i82555 PHY #1. > > > MII PHY #1 transceiver registers: > > > 3000 782d 02a8 0154 05e1 0021 0000 0000 > > > 0000 0000 0000 0000 0000 0000 0000 0000 > > > 0400 0000 0001 0000 0000 0000 0000 0000 > > > 0000 0000 0000 0000 0000 0000 0000 0000. > > > Baseline value of MII status register is 782d. > > > > > > [root@lanf2 /root]# ifconfig -a > > > eth0 Link encap:Ethernet HWaddr > > > 00:E0:81:03:B9:7B > > > inet addr:192.168.1.56 > > > Bcast:192.168.1.255 Mask:255.255.255.0 > > > UP BROADCAST RUNNING MULTICAST MTU:1500 > > > Metric:1 > > > RX packets:412 errors:0 dropped:0 > > > overruns:0 frame:0 > > > TX packets:278 errors:0 dropped:0 > > > overruns:0 carrier:0 > > > collisions:0 txqueuelen:100 > > > Interrupt:10 Base address:0xe000 > > > > > > eth1 Link encap:Ethernet HWaddr > > > 00:90:27:65:39:1B > > > BROADCAST MULTICAST MTU:1500 Metric:1 > > > RX packets:0 errors:0 dropped:0 overruns:0 > > > frame:0 > > > TX packets:0 errors:0 dropped:0 overruns:0 > > > carrier:0 > > > collisions:0 txqueuelen:100 > > > Interrupt:3 > > > > > > eth2 Link encap:Ethernet HWaddr > > > 00:90:27:65:37:8A > > > BROADCAST MULTICAST MTU:1500 Metric:1 > > > RX packets:0 errors:0 dropped:0 overruns:0 > > > frame:0 > > > TX packets:0 errors:0 dropped:0 overruns:0 > > > carrier:0 > > > collisions:0 txqueuelen:100 > > > Interrupt:9 Base address:0x2000 > > > > > > eth3 Link encap:Ethernet HWaddr > > > FF:FF:FF:FF:FF:FF > > > BROADCAST MULTICAST MTU:1500 Metric:1 > > > RX packets:0 errors:0 dropped:0 overruns:0 > > > frame:0 > > > TX packets:0 errors:0 dropped:0 overruns:0 > > > carrier:0 > > > collisions:0 txqueuelen:100 > > > Interrupt:11 Base address:0x4000 > > > > > > lo Link encap:Local Loopback > > > inet addr:127.0.0.1 Mask:255.0.0.0 > > > UP LOOPBACK RUNNING MTU:16436 Metric:1 > > > RX packets:18 errors:0 dropped:0 > > > overruns:0 frame:0 > > > TX packets:18 errors:0 dropped:0 > > > overruns:0 carrier:0 > > > collisions:0 txqueuelen:0 > > > > > > > > > > > > > > > > > > -- > > > Ben Greear > > > > > > President of Candela Technologies Inc > > > http://www.candelatech.com > > > ScryMUD: http://scry.wanfear.com > > > http://scry.wanfear.com/~greear > > > > > > --__--__-- > > > > > > Message: 2 > > > Date: Tue, 18 Sep 2001 19:41:23 -0700 > > > From: Ben Greear > > > Organization: Candela Technologies > > > To: linux.nics@intel.com > > > CC: eepro list > > > Subject: [eepro100] e100 driver fails to work > > > correctly with Tyan S2080 Tomcat i185t > > > motherboard. > > > > > > It seems to assign the second NIC's MAC to all FF's. > > > The eepro100 > > > driver for Linux also fails: It reports a bad > > > checksum on the eeprom. > > > I already sent a bug report to the linux kernel > > > developers about that one, > > > and it has the gory details if you want to see > > > them... > > > > > > Note that eth3 seems to be some generic (unknown??) > > > 8255* chipset, > > > where the other one is more specifically > > > identified... > > > > > > > > > Here are the e100 driver loading messages: > > > > > > Sep 18 19:39:17 lanf2 kernel: Intel(R) PRO/100 Fast > > > Ethernet Adapter - Loadable driver, ver 1.6.13 > > > Sep 18 19:39:17 lanf2 kernel: Copyright (c) 2001 > > > Intel Corporation > > > Sep 18 19:39:17 lanf2 kernel: PCI: Found IRQ 10 for > > > device 01:0b.0 > > > Sep 18 19:39:17 lanf2 kernel: > > > Sep 18 19:39:17 lanf2 kernel: eth0: Intel(R) > > > PRO/100+ Server Adapter (PILA8470B) > > > Sep 18 19:39:17 lanf2 kernel: Mem:0xfe9ff000 > > > IRQ:10 Speed:10 Mbps Dx:Half > > > Sep 18 19:39:17 lanf2 kernel: Hardware receive > > > checksums enabled > > > Sep 18 19:39:17 lanf2 kernel: ucode was not loaded > > > Sep 18 19:39:21 lanf2 kernel: PCI: Found IRQ 3 for > > > device 01:09.0 > > > Sep 18 19:39:21 lanf2 kernel: > > > Sep 18 19:39:21 lanf2 kernel: eth1: Intel(R) > > > PRO/100+ Management Adapter > > > Sep 18 19:39:21 lanf2 kernel: Mem:0xfe9fe000 > > > IRQ:3 Speed:0 Mbps Dx:N/A > > > Sep 18 19:39:21 lanf2 kernel: Failed to detect > > > cable link. > > > Sep 18 19:39:21 lanf2 kernel: Speed and duplex > > > will be determined at time of connection. > > > Sep 18 19:39:21 lanf2 kernel: Hardware receive > > > checksums enabled > > > Sep 18 19:39:21 lanf2 kernel: ucode was not loaded > > > Sep 18 19:39:24 lanf2 kernel: PCI: Found IRQ 9 for > > > device 01:04.0 > > > Sep 18 19:39:24 lanf2 kernel: PCI: Sharing IRQ 9 > > > with 00:1f.3 > > > Sep 18 19:39:24 lanf2 kernel: > > > Sep 18 19:39:24 lanf2 kernel: eth2: Intel(R) > > > PRO/100+ Management Adapter > > > Sep 18 19:39:24 lanf2 kernel: Mem:0xfe9fc000 > > > IRQ:9 Speed:0 Mbps Dx:N/A > > > Sep 18 19:39:24 lanf2 kernel: Failed to detect > > > cable link. > > > Sep 18 19:39:24 lanf2 kernel: Speed and duplex > > > will be determined at time of connection. > > > Sep 18 19:39:24 lanf2 kernel: Hardware receive > > > checksums enabled > > > Sep 18 19:39:24 lanf2 kernel: ucode was not loaded > > > Sep 18 19:39:27 lanf2 kernel: PCI: Found IRQ 11 for > > > device 01:08.0 > > > Sep 18 19:39:27 lanf2 kernel: > > > Sep 18 19:39:27 lanf2 kernel: eth3: Intel(R) > > > 8255x-based Ethernet Adapter > > > Sep 18 19:39:27 lanf2 kernel: Mem:0xfe9fd000 > > > IRQ:11 Speed:0 Mbps Dx:N/A > > > Sep 18 19:39:27 lanf2 kernel: Failed to detect > > > cable link. > > > Sep 18 19:39:27 lanf2 kernel: Speed and duplex > > > will be determined at time of connection. > > > Sep 18 19:39:27 lanf2 kernel: Hardware receive > > > checksums disabled > > > Sep 18 19:39:27 lanf2 kernel: ucode was not loaded > > > > > > > > > > > > [root@lanf2 /root]# ifconfig -a > > > eth0 Link encap:Ethernet HWaddr > > > 00:E0:81:03:B9:7B > > > inet addr:192.168.1.56 > > > Bcast:192.168.1.255 Mask:255.255.255.0 > > > UP BROADCAST RUNNING MULTICAST MTU:1500 > > > Metric:1 > > > RX packets:17 errors:0 dropped:0 > > > overruns:0 frame:0 > > > TX packets:9 errors:0 dropped:0 overruns:0 > > > carrier:0 > > > collisions:0 > > > > > > eth1 Link encap:Ethernet HWaddr > > > 00:90:27:65:39:1B > > > UP BROADCAST RUNNING MULTICAST MTU:1500 > > > Metric:1 > > > RX packets:0 errors:0 dropped:0 overruns:0 > > > frame:0 > > > TX packets:0 errors:0 dropped:0 overruns:0 > > > carrier:0 > > > collisions:0 > > > > > > eth2 Link encap:Ethernet HWaddr > > > 00:90:27:65:37:8A > > > UP BROADCAST RUNNING MULTICAST MTU:1500 > > > Metric:1 > > > RX packets:0 errors:0 dropped:0 overruns:0 > > > frame:0 > > > TX packets:0 errors:0 dropped:0 overruns:0 > > > carrier:0 > > > collisions:0 > > > > > > eth3 Link encap:Ethernet HWaddr > > > FF:FF:FF:FF:FF:FF > > > UP BROADCAST RUNNING MULTICAST MTU:1500 > > > Metric:1 > > > RX packets:0 errors:0 dropped:0 overruns:0 > > > frame:0 > > > TX packets:0 errors:0 dropped:0 overruns:0 > > > carrier:0 > > > collisions:0 > > > > > > lo Link encap:Local Loopback > > > inet addr:127.0.0.1 Mask:255.0.0.0 > > > UP LOOPBACK RUNNING MTU:16436 Metric:1 > > > RX packets:18 errors:0 dropped:0 > > > overruns:0 frame:0 > > > TX packets:18 errors:0 dropped:0 > > > overruns:0 carrier:0 > > > collisions:0 > > > > > > [root@lanf2 /root]# > > > > > > Any ideas?? > > > > > > THanks, > > > Ben > > > > > > -- > > > Ben Greear > > > > > > President of Candela Technologies Inc > > > http://www.candelatech.com > > > ScryMUD: http://scry.wanfear.com > > > http://scry.wanfear.com/~greear > > > > > > --__--__-- > > > > > > Message: 3 > > > Date: Wed, 19 Sep 2001 00:21:38 -0400 (EDT) > > > From: Donald Becker > > > To: Ben Greear > > > cc: eepro list , > > > linux-kernel > > > Subject: Re: [eepro100] eepro100 driver (2.4 kernel) > > > fails with S2080 Tomcat > > > i815t motherboard. > > > > > > On Tue, 18 Sep 2001, Ben Greear wrote: > > > > > > > I have a Tyan motherboard (S2080 Tomcat i815t) > > > with 2 built-in NICs. > > > > > > > > The manual claims this: > > > > > > > > "One Intel 82559 LAN controller > > > > One ICH2 LAN controller" > > > > > > > > Seems that the eepro driver tries to bring up both > > > of > > > > them, and fails to read the eeprom on the second > > > one it > > > > scans. One visible result is that the MAC is all > > > FF's. > > > > > > Does the diagnostic program correctly read the > > > EEPROM on both cards? > > > If so, my driver release should work with the cards. > > > > > > > eth0: Intel Corporation 82557 [Ethernet Pro 100] > > > (#3), 00:E0:81:03:B9:7B, IRQ 10. > > > > eth1: Intel Corporation 82557 [Ethernet Pro 100] > > > (#2), 00:90:27:65:39:1B, IRQ 3. > > > > eth2: Intel Corporation 82557 [Ethernet Pro 100], > > > 00:90:27:65:37:8A, IRQ 9. > > > > eth3: Invalid EEPROM checksum 0xff00, check > > > settings before activating this device! > > > > eth3: OEM i82557/i82558 10/100 Ethernet, > > > FF:FF:FF:FF:FF:FF, IRQ 11. > > > > > > > [root@lanf2 /root]# eepro100-diag -aaeemmf eth3 > > > > > > The diagnostic does not (and cannot) know which card > > > is "eth3". > > > (Consider the case where no driver is loaded.) > > > > > > You must specify the interface to examine with e.g. > > > "-#3" > > > > > > 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 > > > > > > > > > --__--__-- > > > > > > Message: 4 > > > Date: Tue, 18 Sep 2001 22:04:55 -0700 > > > From: Ben Greear > > > Organization: Candela Technologies > > > To: Donald Becker > > > CC: eepro list , > > > linux-kernel > > > Subject: Re: [eepro100] eepro100 driver (2.4 kernel) > > > fails with S2080 Tomcati815t > > > motherboard. > > > > > > Interestingly enough, when I manually set a MAC it > > > seems to pass traffic, > > > at least at low speeds. I'm about to crank it up a > > > bit to see what > > > falls out :) > > > > > > (Working fine at 10Mbps (about 4200 > > > packets-per-second..) > > > > > > > > > Donald Becker wrote: > > > > > > > > On Tue, 18 Sep 2001, Ben Greear wrote: > > > > > > > > > I have a Tyan motherboard (S2080 Tomcat i815t) > > > with 2 built-in NICs. > > > > > > > > > > The manual claims this: > > > > > > > > > > "One Intel 82559 LAN controller > > > > > One ICH2 LAN controller" > > > > > > > > > > Seems that the eepro driver tries to bring up > > > both of > > > > > them, and fails to read the eeprom on the second > > > one it > > > > > scans. One visible result is that the MAC is > > > all FF's. > > > > > > > > Does the diagnostic program correctly read the > > > EEPROM on both cards? > > > > If so, my driver release should work with the > > > cards. > > > > > > > > > > It doesn't seem to... > > > > > > > > > [root@lanf1 /root]# eepro100-diag -aaeemmf -#1 > > > 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 > > > 0xdd80. > > > i82557 chip registers at 0xdd80: > > > 0c000050 0f162000 00000000 00080002 1be7ffff > > > 00000600 > > > No interrupt sources are pending. > > > The transmit unit state is 'Suspended'. > > > The receive unit state is 'Ready'. > > > This status is normal for an activated but idle > > > interface. > > > The Command register has an unprocessed command > > > 0c00(?!). > > > EEPROM contents, size 256x16: > > > 00: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0x08: ffff ffff ffff ffff ffff ffff 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: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0x38: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0x40: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0x48: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0x50: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0x58: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0x60: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0x68: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0x70: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0x78: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0x80: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0x88: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0x90: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0x98: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0xa0: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0xa8: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0xb0: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0xb8: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0xc0: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0xc8: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0xd0: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0xd8: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0xe0: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0xe8: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0xf0: ffff ffff ffff ffff ffff ffff ffff ffff > > > 0xf8: ffff ffff ffff ffff ffff ffff ffff ffff > > > ***** The EEPROM checksum is INCORRECT! ***** > > > The checksum is 0xFF00, it should be 0xBABA! > > > Intel EtherExpress Pro 10/100 EEPROM contents: > > > Station address FF:FF:FF:FF:FF:FF. > > > Board assembly ffffff-255, Physical connectors > > > present: RJ45 BNC AUI MII > > > Primary interface chip i82555 PHY #-1. > > > Secondary interface chip i82555, PHY -1. > > > Baseline value of MII status register is 0000. > > > > > > [root@lanf1 /root]# > > > > > > > > eth0: Intel Corporation 82557 [Ethernet Pro 100] > > > (#3), 00:E0:81:03:B9:7B, IRQ 10. > > > > > eth1: Intel Corporation 82557 [Ethernet Pro 100] > > > (#2), 00:90:27:65:39:1B, IRQ 3. > > > > > eth2: Intel Corporation 82557 [Ethernet Pro > > > 100], 00:90:27:65:37:8A, IRQ 9. > > > > > eth3: Invalid EEPROM checksum 0xff00, check > > > settings before activating this device! > > > > > eth3: OEM i82557/i82558 10/100 Ethernet, > > > FF:FF:FF:FF:FF:FF, IRQ 11. > > > > > > > > > [root@lanf2 /root]# eepro100-diag -aaeemmf eth3 > > > > > > > > The diagnostic does not (and cannot) know which > > > card is "eth3". > > > > (Consider the case where no driver is loaded.) > > > > > > I wish it would have complained about me sending it > > > eth3 then, so > > > I would have known! > > > > > > > > > > > You must specify the interface to examine with > > > e.g. "-#3" > > > > > > Thanks, > > > Ben > > > > > > > > > > > > > > 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 > > > > > > > > _______________________________________________ > > > > eepro100 mailing list > > > > eepro100@scyld.com > > > > http://www.scyld.com/mailman/listinfo/eepro100 > > > > > > -- > > > Ben Greear > > > > > > President of Candela Technologies Inc > > > http://www.candelatech.com > > > ScryMUD: http://scry.wanfear.com > > > http://scry.wanfear.com/~greear > > > > > > --__--__-- > > > > > > Message: 5 > > > From: "Alexander Gdalevich" > > > To: eepro100@scyld.com > > > Date: Wed, 19 Sep 2001 11:53:02 -0400 > > > Subject: [eepro100] BSD driver > > > > > > People, hello! > > > > > > Is there an eepro100 driver for BSD? > > > > > > Thanks. > > > > > > > > > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > > > http://explorer.msn.com/intl.asp > > > > > > > > > > > > > > > --__--__-- > > > > > > _______________________________________________ > > > eepro100 mailing list > > > eepro100@scyld.com > > > http://www.scyld.com/mailman/listinfo/eepro100 > > > > > > > > > End of eepro100 Digest > > > > __________________________________________________ > > Terrorist Attacks on U.S. - How can you help? > > Donate cash, emergency relief information > > http://dailynews.yahoo.com/fc/US/Emergency_Information/ > > > > _______________________________________________ > > eepro100 mailing list > > eepro100@scyld.com > > http://www.scyld.com/mailman/listinfo/eepro100 > > -- > +--------V--------+ Christoph.Plattner@alcatel.at > | A L C A T E L | ----------------------------- > +-----------------+ Phone: +43 1 27722 3706 > T A S Fax: +43 1 27722 3955 > > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 From OReinert@janichklass.com Mon Nov 5 10:38:01 2001 From: OReinert@janichklass.com (Oliver Reinert) Date: Mon Nov 5 10:38:01 2001 Subject: [eepro100] [eepro100]Serial eeprom description Message-ID: <000a01c1660f$8198c560$1a00a8c0@workgroup> Hello, I'm looking for detailed register-description of the serial eeprom for intel's 82559ER. Any hint would be appreciated. Regards Oliver Reinert From robbie@microbus.com Mon Nov 5 11:52:00 2001 From: robbie@microbus.com (Robbie Dinn) Date: Mon Nov 5 11:52:00 2001 Subject: [eepro100] [eepro100]Serial eeprom description Message-ID: <200111051651.fA5Gpk020718@blueraja.scyld.com> Hi Oliver Reinert wrote >> >> I'm looking for detailed register-description of the serial eeprom >> for intel's 82559ER. I think this document from Intel contains a description of the contents eeprom. Is that what you are after? http://developer.intel.com/design/network/applnots/74894501.pdf ---------- robbie@microbus.co.uk From becker@scyld.com Mon Nov 5 12:24:00 2001 From: becker@scyld.com (Donald Becker) Date: Mon Nov 5 12:24:00 2001 Subject: [eepro100] scyld driver for 2.4? In-Reply-To: Message-ID: On Mon, 5 Nov 2001, Ryan Sweet wrote: > I'm having difficulty locating the eepro100 driver from Scyld for > Linux 2.4.x. The web page for the network drivers states that it is only > for 2.2, but recently on lkml there has been mention of a Scyld driver for > 2.4.x, but I can't find a link to it anywhere... any pointers? The driver now works with 2.4, but is not tested. Note: "2.4" is not specific enough -- there have been driver interface changes in the 2.4 kernel series. ftp://ftp.scyld.com/pub/network/netdrivers-3.0-1.src.rpm 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 From OReinert@janichklass.com Mon Nov 5 12:38:01 2001 From: OReinert@janichklass.com (Oliver Reinert) Date: Mon Nov 5 12:38:01 2001 Subject: AW: [eepro100] [eepro100]Serial eeprom description Message-ID: <000501c16620$c48f5940$1a00a8c0@workgroup> Thanks Robbie, I have read this document several times. but it is not what I expected. My question is: Are the others 16Bit-Values in this eeprom not used by intel's 82559ER? I have read back the contents from another Ethernet-Card and found some undocumented entries. For example: Offset 0x3, 0x5, 0x6, 0x7,...... Something like this: e000 0381 7bb9 0403 0000 0201 4701 0000 5678 1234 4082 100c 8086 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0128 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 d393 Regards Oliver -----Ursprüngliche Nachricht----- Von: Robbie Dinn [mailto:robbie@microbus.com] Gesendet: Montag, 5. November 2001 16:42 An: eepro100@scyld.com; Oliver Reinert Betreff: RE: [eepro100] [eepro100]Serial eeprom description Hi Oliver Reinert wrote >> >> I'm looking for detailed register-description of the serial eeprom >> for intel's 82559ER. I think this document from Intel contains a description of the contents eeprom. Is that what you are after? http://developer.intel.com/design/network/applnots/74894501.pdf ---------- robbie@microbus.co.uk From wouter.coppens@dct-mail.com Tue Nov 6 07:35:00 2001 From: wouter.coppens@dct-mail.com (Wouter Coppens) Date: Tue Nov 6 07:35:00 2001 Subject: [eepro100] Problem with kernel 2.4.13 Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C166BF.60AFAF9C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey, =20 We have a lot of performance problems with the stock eepro100 driver of kernel 2.4.13. =20 So we would like to use the driver from scyld or the e100 driver from Intel. But we didn't succeed to compile one of them. =20 The machines are booted over NFS, so the driver has to be included in the kernel and not as module. =20 I copied eepro.c, pci-scan.c , pci-scan.h and kern_compat.h to drivers/net. I modified the Makefile to include: export-objs :=3D 8390.o arlan.o aironet4500_core.o aironet4500_card.o \ ppp_async.o ppp_generic.o slhc.o pppox.o auto_irq.o \ net_init.o pci-scan.o =20 But it won't compile. =20 This is the error I get: =20 ld -m elf_i386 -T /usr/src/linux-2.4.13/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/net/fc/fc.o drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/pci/driver.o drivers/net/pcmcia/pcmcia_net.o drivers/video/video.o drivers/md/mddev.o \ net/network.o \ /usr/src/linux-2.4.13/arch/i386/lib/lib.a /usr/src/linux-2.4.13/lib/lib.a /usr/src/linux-2.4.13/arch/i386/lib/lib.a \ --end-group \ -o vmlinux drivers/pci/driver.o: In function `pci_find_capability': drivers/pci/driver.o(.text+0xfc): multiple definition of `pci_find_capability' drivers/net/net.o(.text+0xf7a0): first defined here ld: Warning: size of symbol `pci_find_capability' changed from 123 to 186 in drivers/pci/driver.o make: *** [vmlinux] Error 1 =20 Has anybody an idea what I'm doing wrong? =20 Thnx, =20 Wouter =20 ------_=_NextPart_001_01C166BF.60AFAF9C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey,

 

We have a lot of = performance problems with the stock eepro100 driver of kernel = 2.4.13.

 

So we would like to = use the driver from scyld or the e100 driver from = Intel.

But we didn’t = succeed to compile one of them.

 

The machines are = booted over NFS, so the driver has to be included in the kernel and not as = module.

 

I copied eepro.c, pci-scan.c , pci-scan.h and kern_compat.h to drivers/net.

I modified the Makefile to include:

            = export-objs     :=3D      8390.o = arlan.o aironet4500_core.o aironet4500_card.o = \

       &nbs= p;            = ;    ppp_async.o ppp_generic.o slhc.o pppox.o = auto_irq.o \

       &nbs= p;            = ;    net_init.o pci-scan.o

 

But it won’t = compile.

 

This is the error I = get:

 

 ld -m elf_i386 -T /usr/src/linux-2.4.13/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o = arch/i386/kernel/init_task.o init/main.o init/version.o \

        --start-group \

        arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o = ipc/ipc.o \

       &nbs= p; drivers/char/char.o = drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/net/fc/fc.o drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/pci/driver.o drivers/net/pcmcia/pcmcia_net.o = drivers/video/video.o drivers/md/mddev.o \

        = net/network.o = \

        /usr/src/linux-2.4.13/arch/i386/lib/lib.a /usr/src/linux-2.4.13/lib/lib.a = /usr/src/linux-2.4.13/arch/i386/lib/lib.a \

        --end-group \

        = -o vmlinux

drivers/pci/driver.o: In function `pci_find_capability':

drivers/pci/driver.o(.text+0xfc): multiple definition of `pci_find_capability'

drivers/net/net.o(.text+0xf7a0): first defined here

ld: Warning: size of symbol `pci_find_capability' changed from 123 to 186 in drivers/pci/driver.o

make= : *** [vmlinux] = Error 1

 

Has anybody an idea = what I’m doing wrong?

 

Thnx= ,

 

Wouter

 

=00 ------_=_NextPart_001_01C166BF.60AFAF9C-- From bill@jeffuswilliams.com Thu Nov 8 00:48:01 2001 From: bill@jeffuswilliams.com (Runs With Scissors ) Date: Thu Nov 8 00:48:01 2001 Subject: [eepro100] errors with eepro100 nic In-Reply-To: Message-ID: On Thu, 4 Oct 2001, Donald Becker wrote: > On Thu, 4 Oct 2001, Runs With Scissors wrote: > > > I have a Sony Viao FX220 with a built-in NIC that is giving me problems. > > The NIC is an eepro100, and it has very erratic behavior when the laptop > > is running Linux, but does seem fast and reliable under WinME. > > Have you tried the driver from > http://www.scyld.com/network/eepro100.html > or the e100 driver from Intel? > > The directions are at > http://www.scyld.com/network/updates.html > > > There were several messages that read > > eepro100: wait_for_cmd_done timeout! > > which repeated some number of times, then were followed by > > eth0: Transmit timed out: status 0050 0c80 at 4720/4748 command 200c0000 > > 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 > Sorry to take so long to get back to you on this, but I just recently got the driver installed and have been able to see the performance. This driver is a lot better than the one I had previously, but still does lose its connection while in service. What I get now is good enough that file transfers do happen, which is dramatically better than the other one gave me. During some sessions, I am still getting slow performance, though, and during those periods, I popped open a new xterm and tried to ping some machine. What I'll see is 9 packets sent, and 4 returned, or something along those lines. Then it'll start getting 100% again, and my performance looks normal. Then it may drop out for a while again, and come back again. The symptoms are very similar to the ones from the other driver, but _much_ less severe. I don't know if that helps in debugging at all, but I did want to be sure to give whatever feedback I can provide. Thank you. -BA -- ________ Bill Arnold bill@jeffuswilliams.com /_------_\ Jeffus & Williams Company / $$ \ 907 Capitol Avenue, Juneau, Alaska 99801 |______| 907-586-3700 or fax 586-3703 From WeitzerA@portlanddev.org Fri Nov 9 17:39:01 2001 From: WeitzerA@portlanddev.org (Weitzer, Alex) Date: Fri Nov 9 17:39:01 2001 Subject: [eepro100] port aggregation using 802.3ad Message-ID: I am wondering about the possibility of adding a network card to my Linux server and aggregating the ports in the manner of ieee 802.3ad. I do this with my windows machines, but cannot find any reference to this ability under Linux (It's possible I'm searching for the wrong thing.) Any Ideas? If this is not implemented yet, how about failover from one network card to the next using the same IP? Thanks a lot in advance, Alex Weitzer Portland Development Commission From mike@oddjob.utias.utoronto.ca Tue Nov 13 22:45:01 2001 From: mike@oddjob.utias.utoronto.ca (Mike Sullivan) Date: Tue Nov 13 22:45:01 2001 Subject: [eepro100] eeproo 100 does not work with SMP Message-ID: <3BF1E8B2.78FE4CCA@oddjob.utias.utoronto.ca> I upgraded my Dual P-Pro, 440 FX based system from RH 7.1 to RH 7.2 and now the eepro NIC will not work with the SMP kernels. I have tried a few including 2.4.13+ac5. Under uniprocessor it works fine but with an SMP enabled kernel. I get transmit timeouts. The card initialises fine and I can ping the card and there are link lights active on both the card and the hub, but all packets get dropped. Does anyone have any ideas why and SMP kernel would do this. Mike Sullivan From subscriptions@graphon.com Wed Nov 14 00:49:01 2001 From: subscriptions@graphon.com (Nate Amsden) Date: Wed Nov 14 00:49:01 2001 Subject: [eepro100] eeproo 100 does not work with SMP In-Reply-To: <3BF1E8B2.78FE4CCA@oddjob.utias.utoronto.ca> References: <3BF1E8B2.78FE4CCA@oddjob.utias.utoronto.ca> Message-ID: <3752.192.168.30.2.1005716928.squirrel@webmail-wa.graphon.com> >Does anyone have any ideas why and SMP kernel would > do this. my personal opinion is 2.4 is not ready for use in any kind of production enviornment. im glad redhat uses it though. more bugs get fixed by the time i start using it sometime in late 2002. nate (happily running a couple dozen eepro100 systems on 2.2.19 both SMP and UP, if i could find backports to security fixes i'd still be on 2.2.10) -- Nate Amsden System Administrator GraphOn (Sent using Squirrelmail! 1.2.0rc2) From sgcarr@civeng.adelaide.edu.au Wed Nov 14 01:09:00 2001 From: sgcarr@civeng.adelaide.edu.au (Stephen Carr) Date: Wed Nov 14 01:09:00 2001 Subject: [eepro100] eeproo 100 does not work with SMP In-Reply-To: <3752.192.168.30.2.1005716928.squirrel@webmail-wa.graphon.com> References: <3752.192.168.30.2.1005716928.squirrel@webmail-wa.graphon.com> Message-ID: <4365.129.127.16.31.1005718019.squirrel@brooks.civeng.adelaide.edu.au> Dear users It amazes me that people have problems wit the eepro 100 on SMP systems with the 2.4.x kernels - Using Slackware 7.1 or Slackware 8 I encounted no problems at all. Admittedly I manually build a kernel to match our needs. By the way the systems a very stable under varying network load. Regards Stephen Carr >>Does anyone have any ideas why and SMP kernel would >> do this. > > my personal opinion is 2.4 is not ready for use in any > kind of production enviornment. im glad redhat uses > it though. more bugs get fixed by the time i start > using it sometime in late 2002. > > nate > (happily running a couple dozen eepro100 systems on > 2.2.19 both SMP and UP, if i could find backports to > security fixes i'd still be on 2.2.10) > > -- > Nate Amsden > System Administrator > GraphOn > (Sent using Squirrelmail! 1.2.0rc2) > > > > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 -- Stephen Carr Computing Officer Department of Civil and Environmental Engineering Adelaide University Tel +618-8303-4313 Fax +618-8303-4359 From jmadden@ivy.tec.in.us Wed Nov 14 09:09:01 2001 From: jmadden@ivy.tec.in.us (John Madden) Date: Wed Nov 14 09:09:01 2001 Subject: [eepro100] eeproo 100 does not work with SMP In-Reply-To: <4365.129.127.16.31.1005718019.squirrel@brooks.civeng.adelaide.edu.au> References: <4365.129.127.16.31.1005718019.squirrel@brooks.civeng.adelaide.edu.au> Message-ID: <2476.168.91.2.45.1005746515.squirrel@mail.ivy.tec.in.us> > Dear users > > It amazes me that people have problems wit the eepro 100 on SMP systems > with the 2.4.x kernels - Using Slackware 7.1 or Slackware 8 I encounted > no problems at all. Admittedly I manually build a kernel to match our > needs. I agree -- I've only had one issue with the kernel driver, and replacing the dual-port nic with two singles fixed it. Running a combination of 2.2 and 2.4, all under slack 7.1 or 8. John -- John Madden UNIX Systems Engineer Ivy Tech State College jmadden@ivy.tec.in.us From mike@oddjob.utias.utoronto.ca Wed Nov 14 12:18:01 2001 From: mike@oddjob.utias.utoronto.ca (Mike Sullivan) Date: Wed Nov 14 12:18:01 2001 Subject: [eepro100] Re: eepro100 digest References: <200111141704.fAEH44029976@blueraja.scyld.com> Message-ID: <3BF2A6B0.BFDB4DF2@oddjob.utias.utoronto.ca> > Thanks for the responses. It seems to be an issue with something redhat has done, I have gotten nowhere on related forums. I was hoping that someone who knows a great deal more than I do about the flow of data through the various software layers might be able to suggest a possible fix. Some more points. A kernel from RH 7.1 that workd under 7.1 does not work under 7.2. I have tried compiling several kernels by hand. Differing only in the selection of SMP enabled. The SMP ones do not work the uni versions do. Enabling SMP for my machine breaks one of the software layers. I had assumed it was the transciever as the card seems to setup ok and the driver reports no probs. I ran the mii-diag tool and the eepro100-diag tool from scyld and no problems were reported and link beats were detected. I stuck in a tulip based card and get the exact same behaviour so it does not appear to be a problem with the driver, at least not a prob unique to this one. I do not want to use other distros as I am part of a large group that also has Alpha machines so I want to be fairly uniform in the software setup. I will try to get a 2.2.x kernel to work and will post the result. Regards All Mike Sullivan > > Dear users > > > > It amazes me that people have problems wit the eepro 100 on SMP systems > > with the 2.4.x kernels - Using Slackware 7.1 or Slackware 8 I encounted > > no problems at all. Admittedly I manually build a kernel to match our > > needs. > > I agree -- I've only had one issue with the kernel driver, and replacing the > dual-port nic with two singles fixed it. Running a combination of 2.2 and > 2.4, all under slack 7.1 or 8. > > John From doering@ucube.de Wed Nov 14 18:46:01 2001 From: doering@ucube.de (=?iso-8859-1?Q?Marcel_D=F6ring?=) Date: Wed Nov 14 18:46:01 2001 Subject: [eepro100] Increasing Buffers ? Message-ID: <003f01c16d66$5a8b60a0$bb2c53d5@nbm> Hi ! We have serveral gameservers running on one 1,4GHz Athlon and 1,5GB RAM using an Intel EtherExpress Pro 10/100 with the stock Red Hat 7.1 driver under 2.2.19 and 2.4.13, while the CPU and RAM usage stays quite calm and down the NIC seems to get to its limits when running about 4 x 16 Playerslots UT (Unreal Tournament) or Half Life Servers. I've read a lot about the "many small packets" Problem, and that even some big Cisco Routers have trouble with them when they get too much, so my question is now, is there *any* kind of possibility how I can increase buffers for the NIC or at least can determine *IF* the NIC is on its limits and causing the "ping hops" to the players on the gameservers. The players encounter "ping hops" which means that the "ping" raises from 30 (which is very good) to 200 (which is very bad) from one to the other second, then, again from one to the other seconds, it drops again to 30... the strange thing is that the CPU seems to have nothing to do and RAM is also quite free, so there must be something with the NIC, but I just cant figure out how to get some way to work around this. I would appreciate a lot if anyone could give me tips of *any* kind, I'm picking around in the dark all the time.. getting more and more confused... Help ! :) Bye Marcel From m@rcel.to Wed Nov 14 18:54:01 2001 From: m@rcel.to (m@rcel.to) Date: Wed Nov 14 18:54:01 2001 Subject: [eepro100] Buffers ? Small Packets ? Message-ID: <004001c16d67$77e092f0$bb2c53d5@nbm> Hi ! We have serveral gameservers running on one 1,4GHz Athlon and 1,5GB RAM using an Intel EtherExpress Pro 10/100 with the stock Red Hat 7.1 driver under 2.2.19 and 2.4.13, while the CPU and RAM usage stays quite calm and down the NIC seems to get to its limits when running about 4 x 16 Playerslots UT (Unreal Tournament) or Half Life Servers. I've read a lot about the "many small packets" Problem, and that even some big Cisco Routers have trouble with them when they get too much, so my question is now, is there *any* kind of possibility how I can increase buffers for the NIC or at least can determine *IF* the NIC is on its limits and causing the "ping hops" to the players on the gameservers. The players encounter "ping hops" which means that the "ping" raises from 30 (which is very good) to 200 (which is very bad) from one to the other second, then, again from one to the other seconds, it drops again to 30... the strange thing is that the CPU seems to have nothing to do and RAM is also quite free, so there must be something with the NIC, but I just cant figure out how to get some way to work around this. I would appreciate a lot if anyone could give me tips of *any* kind, I'm picking around in the dark all the time.. getting more and more confused... Help ! :) Bye Marcel From subscriptions@graphon.com Wed Nov 14 20:08:01 2001 From: subscriptions@graphon.com (Nate Amsden) Date: Wed Nov 14 20:08:01 2001 Subject: [eepro100] Buffers ? Small Packets ? References: <004001c16d67$77e092f0$bb2c53d5@nbm> Message-ID: <3BF314F5.BBB52602@graphon.com> m@rcel.to wrote: > > Hi ! > > We have serveral gameservers running on one 1,4GHz Athlon and 1,5GB RAM > using an Intel EtherExpress Pro 10/100 with the stock Red Hat 7.1 driver > under 2.2.19 and 2.4.13, while the CPU and RAM usage stays quite calm > and down the NIC seems to get to its limits when running about 4 x 16 > Playerslots UT (Unreal Tournament) or Half Life Servers. while i can't speak for half life, i know UT has a known bug with large numbers of players. the longer they play the more lagged everyone gets. its been a bug for a long time a year or more. it can occur on win2000 systems and linux. i used to participate in the UT newsgroup from loki and it was a very common problem. there was never any really good solution. there was some workarounds(i think the README file may mention 1 or 2). if your experiencing that problem it not related to the NIC itself but the TCP stack of the OS or the game. not sure about halflife since theres no linux native client ive never played it. i havent experienced it myself but theres rarely more then 2 or 3 people on my UT servers(my servers are not advertised on the masters) dig through the newsgroup archives for that newsgroup(if there are any) you may find some possible fixes. sounds to me thats the problem your having. ive seen those symtoms reported quite a bit ..dont think its the NIC .. good luck .. nate -- Nate Amsden System Administrator GraphOn http://www.graphon.com From christoph.plattner@alcatel.at Thu Nov 15 08:15:00 2001 From: christoph.plattner@alcatel.at (Christoph Plattner) Date: Thu Nov 15 08:15:00 2001 Subject: [eepro100] Re: eepro100 digest References: <200111141704.fAEH44029976@blueraja.scyld.com> <3BF2A6B0.BFDB4DF2@oddjob.utias.utoronto.ca> Message-ID: <3BF3BFBD.B556C174@alcatel.at> You seem to be right that it is not a problem of THIS driver. But the tulip driver and the eepro100 driver are written by the same person (or group), have a similar structure and handling. But this should not say (!) that the driver is causing the problem any way. It only want to point out, that the argument of driver independence is in this case weak ! With friendly regards Christoph P. Mike Sullivan wrote: > > > > > Thanks for the responses. It seems to be an issue with something redhat has > done, I have gotten nowhere on related forums. I was hoping that someone > who knows a great deal more than I do about the flow of data through the > various software layers might be able to suggest a possible fix. Some > more points. > > A kernel from RH 7.1 that workd under 7.1 does not work under 7.2. > > I have tried compiling several kernels by hand. Differing only in the selection > of SMP enabled. The SMP ones do not work the uni versions do. Enabling SMP > for my machine breaks one of the software layers. > > I had assumed it was the transciever as the card seems to setup ok and the driver > reports no probs. I ran the mii-diag tool and the eepro100-diag tool from scyld > and no problems were reported and link beats were detected. > > I stuck in a tulip based card and get the exact same behaviour so it does not > appear to be a problem with the driver, at least not a prob unique to this one. > > I do not want to use other distros as I am part of a large group that also has > Alpha machines so I want to be fairly uniform in the software setup. > > I will try to get a 2.2.x kernel to work and will post the result. > > Regards All > Mike Sullivan > > > > Dear users > > > > > > It amazes me that people have problems wit the eepro 100 on SMP systems > > > with the 2.4.x kernels - Using Slackware 7.1 or Slackware 8 I encounted > > > no problems at all. Admittedly I manually build a kernel to match our > > > needs. > > > > I agree -- I've only had one issue with the kernel driver, and replacing the > > dual-port nic with two singles fixed it. Running a combination of 2.2 and > > 2.4, all under slack 7.1 or 8. > > > > John > > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 ------------------------------------------------------------------ private: christoph.plattner@gmx.at company: christoph.plattner@alcatel.at From m@rcel.to Thu Nov 15 10:10:01 2001 From: m@rcel.to (m@rcel.to) Date: Thu Nov 15 10:10:01 2001 Subject: [eepro100] Buffers ? Small Packets ? Message-ID: <001501c16de7$67713570$bb2c53d5@nbm> Hi Nate ! Hmm, I've also heard from this bug but couldn't get that specific problem on my systems. For example: I've got one machine, running ONE public UT Server with 16 Playerslots, all are full, the pings are 'roundabout 30-40 for most of the players, this runs good, everything ok so far. I install another 16Player public UT Server on the same machine, still everything is fine, the pings are around 30-40, no problems, I then install the third 16 Player public Server on the same machine, and now all pings rise to about 50-60ms, though the cpu and ram utilitzation is still very (!) low, about 10% CPU and about 30% used RAM, so nothing to worry about. I install another Server on the machine, all the pings rise again to about 80-100ms and now these "ping jumps" happen, but only if all the servers are full, means there a many players connected. Keeping in mind that the cpu is about 35% now and RAM is about 70% everything SHOULD run fine, since there's no peak which hits any border or so, so there's no reason for any kind of jump or rise in the ping.. Strange things there.. these "jumps" are most confusing, the pings jumps from 40 to 200, and 3 seconds later again back to 40... then it works awhile, 5 min later again some quick jumps.. and gone again.. seems that the more players are connected, the more problems I've got. At first I thought that must be something with the CPU or the RAM, but there is definately no problem. And the other strange thing is, that it happens with all kind of *game*server, the more players are connected, the more small udp packets are transmitted and received, the more problems i've get.. Maybe Donald, who has much more knowledge about all of this stuff has an idea.. I though about lowering the MTU or so, or increasing the buffers for the card.. just need to know where to start... Bye Marcel -----Ursprüngliche Nachricht----- Von: eepro100-admin@scyld.com [mailto:eepro100-admin@scyld.com] Im Auftrag von Nate Amsden Gesendet: Donnerstag, 15. November 2001 02:06 An: eepro100@scyld.com Betreff: Re: [eepro100] Buffers ? Small Packets ? m@rcel.to wrote: > > Hi ! > > We have serveral gameservers running on one 1,4GHz Athlon and 1,5GB > RAM using an Intel EtherExpress Pro 10/100 with the stock Red Hat 7.1 > driver under 2.2.19 and 2.4.13, while the CPU and RAM usage stays > quite calm and down the NIC seems to get to its limits when running > about 4 x 16 Playerslots UT (Unreal Tournament) or Half Life Servers. while i can't speak for half life, i know UT has a known bug with large numbers of players. the longer they play the more lagged everyone gets. its been a bug for a long time a year or more. it can occur on win2000 systems and linux. i used to participate in the UT newsgroup from loki and it was a very common problem. there was never any really good solution. there was some workarounds(i think the README file may mention 1 or 2). if your experiencing that problem it not related to the NIC itself but the TCP stack of the OS or the game. not sure about halflife since theres no linux native client ive never played it. i havent experienced it myself but theres rarely more then 2 or 3 people on my UT servers(my servers are not advertised on the masters) dig through the newsgroup archives for that newsgroup(if there are any) you may find some possible fixes. sounds to me thats the problem your having. ive seen those symtoms reported quite a bit ..dont think its the NIC .. good luck .. nate -- Nate Amsden System Administrator GraphOn http://www.graphon.com _______________________________________________ eepro100 mailing list eepro100@scyld.com http://www.scyld.com/mailman/listinfo/eepro100 From aaime@libero.it Fri Nov 16 09:04:00 2001 From: aaime@libero.it (Andrea Aime) Date: Fri Nov 16 09:04:00 2001 Subject: [eepro100] eepro100: wait_for_cmd timout Message-ID: <003401c16ea7$13bef500$bc02090a@comnet.comune.modena.it> Hi everybody, I have a problems with my Intel PRO/100 VE integrated ethernet card on my Acer Travelmate notebook... I've tried to find a solution without bothering you, but with no luck. Here is the problem: my card get recognized and the module eepro10 is loaded by the network start script, and it may even work for a while, but... as soon as a long data transfer occurs (how long? well, 1 Meg is enough), the driver hangs with a "eepro100: wait_for_cmd timeout" message, and the network becomes unreachable and it stays as such unless I reload the driver (I have compiled it as a module). This is the only message I get from the driver. Now I'm using linux kernel 2.4.15pre4, but the same problem occurs with kernel 2.4.10 vanilla (Linus one) and 2.4.8 (mandrake stock kernel). I didn't tried ac kernels (sorry... should I do that?). I also tried to download the source RPM from scyld site, but they don't compile (do they support 2.2 series only?) I also downloaded and compiled Intel drivers, which claims to support Intel PRO/100 VE, but with no luck (insmod e100 says the device isn't there) I also downloaded mii-diag programs, and they work... but how can I use them to solve my problems? I saw in a previous posting that the problem may be related to power management, and tried to recompile the kernel without power management support... no luck, either... I also tried to increase the counter in wait_for_cmd from 1000 to 2.000.000, well, now I can transfer 10 Mbyte before it hangs... Any help would be much appreciated :-) Thanks in advance Best regards Andrea Aime PS: please cc me, I'm not on the list (otherwise I'll see your answer the next day, in the archives...) From rsweet@atos-group.nl Fri Nov 16 12:22:01 2001 From: rsweet@atos-group.nl (Ryan Sweet) Date: Fri Nov 16 12:22:01 2001 Subject: [eepro100] Re: eepro100 digest, Vol 1 #315 - 1 msg In-Reply-To: <200111161701.fAGH1i030458@blueraja.scyld.com> Message-ID: On Fri, 16 Nov 2001 eepro100-request@scyld.com wrote: > I also downloaded and compiled Intel drivers, which claims to support > Intel PRO/100 VE, but with no luck (insmod e100 says the device isn't there) That is the message you will get if the eepro100 driver is already loaded. Are you sure that you removed the eepro100 driver from your kernel? -- Ryan Sweet Atos Origin Engineering Services http://www.aoes.nl From unxgroup@optonline.net Fri Nov 16 21:54:00 2001 From: unxgroup@optonline.net (UNX Group) Date: Fri Nov 16 21:54:00 2001 Subject: [eepro100] eepro100 Prob w/RH 7.2 (2.4.9-13smp) Message-ID: <003101c16f12$d994d9f0$1400000a@matilda> This is a multi-part message in MIME format. --Boundary_(ID_rk/Vw3rvWbXGWaLdQZ6vHA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Installed RH7.2 (2.4.9-13smp) on a box that was successfully running RH7.0 (2.2.16-22smp) with a single, dual-port Intel Ethernet Pro 100 (82557). Using the vanilla eepro100 delivered with 2.4.9-13 and cannot run card at 100MB, full-duplex and getting tons of collisions. Performance, needless to say, is unacceptable. Checked all the NOV threads to date, but do not see a clear answer, if there is one, other than roll-back off of 2.4.x. Thank you in advance. Don Schulze The UNX Group, Inc. --Boundary_(ID_rk/Vw3rvWbXGWaLdQZ6vHA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Installed RH7.2 (2.4.9-13smp) on a box that was successfully
running RH7.0 (2.2.16-22smp) with a single, dual-port Intel
Ethernet Pro 100 (82557).  Using the vanilla eepro100
delivered with 2.4.9-13 and cannot run card at 100MB,
full-duplex and getting tons of collisions.  Performance,
needless to say, is unacceptable.  Checked all the NOV
threads to date, but do not see a clear answer, if there
is one, other than roll-back off of 2.4.x.
 
Thank you in advance.
Don Schulze
The UNX Group, Inc.
 
--Boundary_(ID_rk/Vw3rvWbXGWaLdQZ6vHA)-- From bernd@cs.ucsb.edu Mon Nov 19 13:19:01 2001 From: bernd@cs.ucsb.edu (Bernd Oliver Christiansen) Date: Mon Nov 19 13:19:01 2001 Subject: [eepro100] PRO/100+ PCI 721383-011 Message-ID: Hello: I just installed Redhat 4.2 because I need a libc 5-based system. Unfortunately, it doesn't recognize my 721383-011 Intel PRO/100+ PCI Management Adapter (TP) (82559, full duplex, 2 led's) NIC out-of-the-box. It does have /lib/modules/2.0.30/net/eepro.o and eepro100.o from 1997, but I don't see pci-scan.o. I guess the plus version didn't even exist back then... Q: Does the current eepro100.c driver support the above NIC? I tried to compile it on RedHat 4.2 (which is libc 5 based in case it matters), but it fails with kern_compat.h:148: linux/init.h: No such file of directory (I did -I/usr/src/linux/include) Q: Any ideas? Also, trying to install the RPM on Redhat 4.2 gives me a Data type 9 not support error. Any help would be highly appreciated! Thanks, -Bernd From M@pi.sk Tue Nov 20 06:51:01 2001 From: M@pi.sk (Michal Medvecky) Date: Tue Nov 20 06:51:01 2001 Subject: [eepro100] eth0: card reports no resources. Message-ID: <20011120125028.X24048@pi.sk> Hi all, I'm experiencing %subj% problem on my large academic proxy-server. I have daily tens of these messages in dmesg. Machine does not hang up, but stops responding for a while (<10sec) and slows down explicitly. I have read about similar problems in the archive of this mailinglist, tried newest Becker's driver, increased RX_RING_SIZE, and it still happens. Do you have any idea how to solve this problem, except changing the network card? I'm using debian woody, Linux cache 2.4.14-grsec-1.8.8 #3 Mon Nov 19 23:15:57 CET 2001 i686 unknown on model name : AMD Athlon(tm) processor stepping : 4 cpu MHz : 1401.734 cache size : 256 KB total used free shared buffers cached Mem: 1030092 1024368 5724 0 215532 293904 -/+ buffers/cache: 514932 515160 Swap: 530136 101608 428528 eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin and others eth0: Intel Corp. 82557 [Ethernet Pro 100], 00:02:B3:2E:9A:FB, IRQ 11. Board assembly 751767-003, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Secondary interface chip i82555. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x3258698e). Thank you for any help. Michal From charles.schmidt@timberline.com Tue Nov 20 18:08:01 2001 From: charles.schmidt@timberline.com (Charles Schmidt) Date: Tue Nov 20 18:08:01 2001 Subject: [eepro100] Speed and duplex settings Message-ID: How do you force the speed and duplex settings on this driver? Thanks Charles.schmidt@timberline.com From becker@scyld.com Tue Nov 20 23:46:01 2001 From: becker@scyld.com (Donald Becker) Date: Tue Nov 20 23:46:01 2001 Subject: [eepro100] PRO/100+ PCI 721383-011 In-Reply-To: Message-ID: On Mon, 19 Nov 2001, Bernd Oliver Christiansen wrote: > I just installed Redhat 4.2 because I need a libc 5-based system. > Unfortunately, it doesn't recognize my > > 721383-011 Intel PRO/100+ PCI Management Adapter (TP) > (82559, full duplex, 2 led's) > > NIC out-of-the-box. It does have /lib/modules/2.0.30/net/eepro.o and > eepro100.o from 1997, but I don't see pci-scan.o. I guess the plus version > didn't even exist back then... > > Q: Does the current eepro100.c driver support the above NIC? Yes. > I tried to compile it on RedHat 4.2 (which is libc 5 based in case it > matters), but it fails with > > kern_compat.h:148: linux/init.h: No such file of directory Verify that LINUX_VERSION_CODE is set. Line 148 is #if LINUX_VERSION_CODE > 0x20153 #include #else 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 From becker@scyld.com Tue Nov 20 23:51:00 2001 From: becker@scyld.com (Donald Becker) Date: Tue Nov 20 23:51:00 2001 Subject: [eepro100] Speed and duplex settings In-Reply-To: Message-ID: On Tue, 20 Nov 2001, Charles Schmidt wrote: > How do you force the speed and duplex settings on this driver? Using 'mii-diag' http://www.scyld.com/diag/index.html mii-diag -F 100baseTx-FDX or when loading the driver using the instructions at http://www.scyld.com/network/eepro100.html Forcing the duplex and speed is usually a mistake. There have been reports that the driver packaged with recent 2.4 kernel versions does not force the duplex correctly. 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 From jbeisert@eurodsn.de Fri Nov 23 05:46:00 2001 From: jbeisert@eurodsn.de (Juergen Beisert) Date: Fri Nov 23 05:46:00 2001 Subject: [eepro100] Mysterious 82559ER problems Message-ID: <3.0.6.32.20011123114613.007b7500@pop3.eurodsn.de> Hi! I have developed a card with a i82559ER chip on it. I am using the regular eepro100.c driver of the 2.2.19 Linux kernel. Driver and chip comes up, I can ping my card and I can boot NFS as a root device in my test system. But I can't do anything else. I have started a http and a database server on my test system but I can't connect from a second machine to this servers. nmap tells me that every "port is filtered". Another card with the i82558 added to my test system works. The driver finds both chips, traffic with the i82558 is ok (NFS,Telnet,ping,X,http), but no usable traffic with my i82559ER (except NFS and ping, a customer told me, UDP works, too). I am using the same software configuration in both cases. Without the add-in card, the i82559ER is eth0, with the added card, the i82558 is eth0. With tcpdump and in the case of telnet I see a packet sended to the test system, and an answer from the test system, but nothing more. For example: telnet 80 -> the httpd respons telnet 79 -> immediately error message telnet 80 -> no response (time out) telnet 79 -> ro response (time out) Could be anything wrong in the EEPROM? I see the drivers examines more bits in the EEPROM as the Intel docs support (in the Intel doc the most bits are zero). I have chaged the 2.2.19 eepro100 drivers to the ones from the Scyld-web pages. But the same result: i82558 works, i82559ER not. Has anyone an idea? I have not so much experience in networking with linux. Is there a tool available that can help me more than nmap or tcpdump what happens (or not happens)? Thanks in advance. Juergen Beisert -- ********************************* Fa. EuroDesign embedded technologies GmbH Waldstr. 4a 85414 Kirchdorf a.d. Amper/Germany Tel: +49/8166/99495-77 Fax: +49/8166/99495-81 EMAIL: jbeisert@eurodsn.de Web: http://www.eurodsn.de ********************************* From mfr@kt.e-technik.uni-dortmund.de Mon Nov 26 10:54:00 2001 From: mfr@kt.e-technik.uni-dortmund.de (Markus Fraedrich) Date: Mon Nov 26 10:54:00 2001 Subject: [eepro100] Intel HPQ and MAC Setting question Message-ID: <00c001c17692$74876e60$73b6d981@licht> This is a multi-part message in MIME format. ------=_NextPart_000_00BD_01C1769A.D6303810 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Due to a project im studying for the Timing of Fast Ethernet NICs to = generate a QoS. Unfortunately I didn=B4t get the User Manual for the 82557. Does anyone know if its possible to change/increase the IFS setting of = the NIC, and knows the Register Adress. Second question, does annyone know if its possible to implement a HPQ=20 under Linux. thanks Markus Fraedrich ------=_NextPart_000_00BD_01C1769A.D6303810 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
Due to a project im studying for the = Timing of Fast=20 Ethernet NICs to generate a QoS.
Unfortunately I didn=B4t get the User = Manual for the=20 82557.
Does anyone know if its possible to = change/increase=20 the IFS setting of the
NIC, and knows the Register = Adress.
Second question, does annyone know = if its=20 possible to implement a HPQ
under Linux.
 
thanks
Markus = Fraedrich
------=_NextPart_000_00BD_01C1769A.D6303810-- From toshiya@ieg.com.br Mon Nov 26 11:40:00 2001 From: toshiya@ieg.com.br (Edson Toshiya) Date: Mon Nov 26 11:40:00 2001 Subject: [eepro100] problems with rh6.2 and intel eepro100 Message-ID: <01b101c176a1$38861c90$1e64a8c0@toshi> Hi, I have a Linux RedHat 6.2 (2.4.15) running over an Intel L440GX+, which uses an Intel Etherxpress 10/100 card. ifconfig shows the following: eth0 Link encap:10Mbps Ethernet HWaddr 00:D0:B7:89:1A:FF inet addr:- Bcast:- Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:919622753 errors:31360022 dropped:0 overruns:0 TX packets:0 errors:0 dropped:0 overruns:2147483647 Interrupt:21 Base address:0x2000 It's quite strange because, is connected to a Cisco Catalyst 2900XL with the ports forced to work 100 Mbps. Also, the errors is raising up. Any idea of what is happening ? Thanks, Edson T. From edsont2@ieg.com.br Mon Nov 26 11:49:01 2001 From: edsont2@ieg.com.br (Edson Toshiya) Date: Mon Nov 26 11:49:01 2001 Subject: [eepro100] problems with rh6.2 and intel eepro100 Message-ID: <01d201c176a2$8badfea0$1e64a8c0@toshi> Hi, I have a Linux RedHat 6.2 (2.4.15) running over an Intel L440GX+, which uses an Intel Etherxpress 10/100 card. ifconfig shows the following: eth0 Link encap:10Mbps Ethernet HWaddr 00:D0:B7:89:1A:FF inet addr:- Bcast:- Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:919622753 errors:31360022 dropped:0 overruns:0 TX packets:0 errors:0 dropped:0 overruns:2147483647 Interrupt:21 Base address:0x2000 It's quite strange because, is connected to a Cisco Catalyst 2900XL with the ports forced to work 100 Mbps. Also, the errors is raising up. Any idea of what is happening ? Thanks, Edson T. From becker@scyld.com Mon Nov 26 14:44:01 2001 From: becker@scyld.com (Donald Becker) Date: Mon Nov 26 14:44:01 2001 Subject: [eepro100] Intel HPQ and MAC Setting question In-Reply-To: <00c001c17692$74876e60$73b6d981@licht> Message-ID: On Mon, 26 Nov 2001, Markus Fraedrich wrote: > Due to a project im studying for the Timing of Fast Ethernet NICs to > generate a QoS. > Unfortunately I didn´t get the User Manual for the 82557. That's usual -- Intel rarely provides complete programming information. I haven't gotten an update from Intel for years. > Does anyone know if its possible to change/increase the IFS setting of the > NIC, and knows the Register Adress. Yes, it's at offset 2 in the configuration block. The extended IFS is tied to the PCI bus speed, with the IFS never being less than the standard Ethernet IFS. If you are running a 33Mhz PCI bus, a setting of '4' correesponds to the 960ns minimum IFS. A setting of '5' results in an IFS of 5*8*30ns = 1200ns. Changing the IFS on the 8255* chips requires sending a configure command. This overhead makes it impractical to change the IFS frequently. Note that changing the IFS is not a good solution to QoS. You will change the fairness of the contention-based network, but the change is very difficult to predict. If you have a switch-based network and want to experiment with QoS you should really be looking at real-time packet scheduling and rate limiting. 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 From mfr@kt.e-technik.uni-dortmund.de Tue Nov 27 04:31:01 2001 From: mfr@kt.e-technik.uni-dortmund.de (Markus Fraedrich) Date: Tue Nov 27 04:31:01 2001 Subject: [eepro100] Intel HPQ and MAC Setting question References: Message-ID: <005e01c17726$31278260$73b6d981@licht> I did some tests with Realtek,3Com and SUN NICS and it seems that setting a higher IFG (more than a slottime) could give one client a deterministic bus request. For QoS Streams I set the higher IFS with an IOCTL Command. This QoS is for a small home network with about max. 5PC and a connection with a normal hub, the Qos is for realizing a DVB stream over Ethernet. Know i want to implement a high priotization queue for video stream.Therefor I try to understand the building and controlling of the buffers. Markus Fraedrich >Note that changing the IFS is not a good solution to QoS. You will >change the fairness of the contention-based network, but the change is >very difficult to predict. If you have a switch-based network and want >to experiment with QoS you should really be looking at real-time packet >scheduling and rate limiting. >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 From becker@scyld.com Tue Nov 27 13:52:01 2001 From: becker@scyld.com (Donald Becker) Date: Tue Nov 27 13:52:01 2001 Subject: [eepro100] Intel HPQ and MAC Setting question In-Reply-To: <005e01c17726$31278260$73b6d981@licht> Message-ID: On Tue, 27 Nov 2001, Markus Fraedrich wrote: > I did some tests with Realtek,3Com and SUN NICS and it seems that setting a > higher IFG (more than a slottime) > could give one client a deterministic bus request. Nope. You have only changed the definition of "fair" in "fair access". You must understand Ethernet, which is surprisingly complex and robust for such a simple protocol. Image a new transmit request being generated at a point that causes a collision with the (single!) high priority station . Your high priority station will back off, and then effectively have a larger IFG than low priority stations. So while the network will accept more average traffic from the normal IFG machine, you still won't have deterministic access. [[ In years past someone would have responded with "use Token Ring". The correct response is that token ring doesn't have deterministic access time either. When the token is lost, as frequently occurs, the access time can be really bad. The probabilistic access time graph is just different, in a way that is worse for most application. ]] > This QoS is for a small home network with about max. 5PC and a connection > with a normal hub, the Qos > is for realizing a DVB stream over Ethernet. > Know i want to implement a high priotization queue for video stream.Therefor > I try to understand the building > and controlling of the buffers. To do this reliably you will essentially reproduce the complexity of an ATM switch controller. ATM was supposed to be a simpler system than Ethernet, but it's now accepted as a much more complex due mostly to the _required_ QoS handling. You can optionally achieve the same effect with Ethernet by using switches, packet scheduling, and per-link bandwidth allocation. The cost/value relationship of precise QoS, vs. "throw more cheap bandwidth at the problem" is demonstrated by how many QoS Ethernet systems you find in the market. The preferred solution is link flow-control, which is now silently implemented even on the least expensive NICs and switches. 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 From aarondowning@home.com Wed Nov 28 11:52:01 2001 From: aarondowning@home.com (Aaron Downing) Date: Wed Nov 28 11:52:01 2001 Subject: [eepro100] Intel 82559 Message-ID: <000101c1782c$c136c210$9fe9fe18@cx2072410a> This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C177FA.769C5210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Is there a precompiled module for the eepro100 for 2.0.x kernel versions that I could download. I am running a floppy based kernel and lack compilers and all that. -Thanks Aaron ------=_NextPart_000_0002_01C177FA.769C5210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Is there a precompiled module for the eepro100 for = 2.0.x kernel versions that I could download. I am running a floppy based = kernel and lack compilers and all that.

 

-Thanks

 

Aaron

------=_NextPart_000_0002_01C177FA.769C5210-- From becker@scyld.com Wed Nov 28 13:25:01 2001 From: becker@scyld.com (Donald Becker) Date: Wed Nov 28 13:25:01 2001 Subject: [eepro100] Intel 82559 In-Reply-To: <000101c1782c$c136c210$9fe9fe18@cx2072410a> Message-ID: On Wed, 28 Nov 2001, Aaron Downing wrote: > Is there a precompiled module for the eepro100 for 2.0.x kernel versions > that I could download. I am running a floppy based kernel and lack > compilers and all that. The driver must be compiled for your specific kernel version and options. There is no universal binary module that will work for you. 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 From unxgroup@optonline.net Wed Nov 28 20:23:01 2001 From: unxgroup@optonline.net (UNX Group) Date: Wed Nov 28 20:23:01 2001 Subject: [eepro100] Speed and Duplexing, Once Again Message-ID: <016001c17874$3ff2c9e0$1400000a@matilda> This is a multi-part message in MIME format. --Boundary_(ID_DvrHHD7D01Z5K3ktvpFxUA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Donald, I have read now several times in your responses: "Forcing the duplex and speed is usually a mistake" Could you please expand on this for a newcomer to Linux but experienced with Unix, although certainly not to your level of expertise with networking and these drivers. I recently inherited sa responsibility for a large number of RedHat Linux 7.0 systems. All machines have a variation of Intel NIC, all utilizing e100 or eepro100. All systems are being "forced", via modules.conf, to 100Mbs, full-duplex. I notice, via dmesg, that we recv the message: On "eepro100" systems, recv dmesg: "Forcing 100Mbs half-duplex operation." modules.conf specifies: options eth0 options=0x20 full_duplex=1 On "e100" systems, recv dmesg: "e100 - Intel 8255x-based Ethernet" "eth0: Mem: IRQ: 16 Speed: 100 Dx:Full" modules.conf specifies: options eth0 e100_speed_duplex=4 We are transmitting voice and video and the developers tell me immediately when they believe the boards are running at 10Mbs. They are insistent that the "forcing" be done but I am concerned, from your comments, that something else is wrong. I appreciate your comments very much. Thank you in advance. Don Schulze --Boundary_(ID_DvrHHD7D01Z5K3ktvpFxUA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Donald,
 
I have read now several times in your responses:
 
"Forcing the duplex and speed is usually a mistake"
 
Could you please expand on this for a newcomer to
Linux but experienced with Unix, although certainly
not to your level of expertise with networking and these
drivers.
 
I recently inherited sa responsibility for a large number
of RedHat Linux 7.0 systems.  All machines have a variation
of Intel NIC, all utilizing e100 or eepro100.  All systems are
being "forced", via modules.conf, to 100Mbs, full-duplex.
I notice, via dmesg, that we recv the message:
 
On "eepro100" systems, recv dmesg:
"Forcing 100Mbs half-duplex operation."
 
modules.conf specifies:
options eth0 options=0x20 full_duplex=1
 
 
On "e100" systems, recv dmesg:
"e100 - Intel 8255x-based Ethernet"
"eth0: Mem: <xxxx>  IRQ: 16  Speed: 100  Dx:Full"
 
modules.conf specifies:
options eth0 e100_speed_duplex=4
 
 
We are transmitting voice and video and the developers
tell me immediately when they believe the boards are running
at 10Mbs.  They are insistent that the "forcing" be done but
I am concerned, from your comments, that something else
is wrong.  I appreciate your comments very much.  Thank you
in advance.
 
Don Schulze
 
--Boundary_(ID_DvrHHD7D01Z5K3ktvpFxUA)-- From becker@scyld.com Thu Nov 29 07:59:00 2001 From: becker@scyld.com (Donald Becker) Date: Thu Nov 29 07:59:00 2001 Subject: [eepro100] Speed and Duplexing, Once Again In-Reply-To: <016001c17874$3ff2c9e0$1400000a@matilda> Message-ID: On Wed, 28 Nov 2001, UNX Group wrote: > I have read now several times in your responses: > > "Forcing the duplex and speed is usually a mistake" > > Could you please expand on this for a newcomer to > Linux but experienced with Unix, although certainly > not to your level of expertise with networking and these > drivers. Read http://scyld.com/expert/NWay.html for background. Autonegotiation is disabled when the speed and duplex is forced. Here's an obvious scenario of why disabling autonegotiation is wrong: Plug an unconfigured or non-configurable device into your network. Does it work correctly? Does it work at a near-optimal setting? Forcing the switch speed to 100Mbps will allow the device to work correctly, but performance features such as full duplex and flow control cannot be correctly enabled. (Remember that the twisted pair Ethernet standard is half duplex. Full duplex was only added to the standard with autonegotiation. Forced full duplex is a common but non-standard extension. ) Forcing the switch to full duplex mean that every new device must be configured by hand, and the configuration reversed when you move the device to standard networking equipment. Forgetting either case results in difficult to track down performance problems. I consider forced-full-duplex to be an serious issue somewhere between "..and these cars have the brake pedal on the right" and "we decided to put the drinking water in the brown jugs, and the 'other' water in blue". You won't necessarily die right away, but it isn't healthy. > I recently inherited sa responsibility for a large number > of RedHat Linux 7.0 systems. All machines have a variation > of Intel NIC, all utilizing e100 or eepro100. All systems are > being "forced", via modules.conf, to 100Mbs, full-duplex. > I notice, via dmesg, that we recv the message: > > modules.conf specifies: > options eth0 options=0x20 full_duplex=1 What driver version? > On "eepro100" systems, recv dmesg: > "Forcing 100Mbs half-duplex operation." Hmmm, this _is_ misleading. I'll change it. In the meantime try options=0x200 Other valid options are 0x100, 0x20, and 0x10. I hope the mapping of speed and duplex is obvious. 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 From unxgroup@optonline.net Thu Nov 29 09:40:02 2001 From: unxgroup@optonline.net (UNX Group) Date: Thu Nov 29 09:40:02 2001 Subject: [eepro100] Speed and Duplexing, Once Again References: Message-ID: <01b701c178e3$a5dd7d30$1400000a@matilda> Donald, In response to the driver version question in your response: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/driv ers/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin and others eth0: OEM i82557/i82558 10/100 Ethernet, 00:06:5B:04:34:11, IRQ 16. Forcing 100Mbs half-duplex operation. This specific system is running RH 7.1 (2.4.9-12smp i686 optimized) Thanks very much for your help! Don ----- Original Message ----- From: "Donald Becker" To: "UNX Group" Cc: Sent: Thursday, November 29, 2001 8:04 AM Subject: Re: [eepro100] Speed and Duplexing, Once Again > On Wed, 28 Nov 2001, UNX Group wrote: > > > I have read now several times in your responses: > > > > "Forcing the duplex and speed is usually a mistake" > > > > Could you please expand on this for a newcomer to > > Linux but experienced with Unix, although certainly > > not to your level of expertise with networking and these > > drivers. > > Read > http://scyld.com/expert/NWay.html > for background. > > Autonegotiation is disabled when the speed and duplex is forced. > > Here's an obvious scenario of why disabling autonegotiation is wrong: > Plug an unconfigured or non-configurable device into your network. > Does it work correctly? > Does it work at a near-optimal setting? > > Forcing the switch speed to 100Mbps will allow the device to work > correctly, but performance features such as full duplex and flow control > cannot be correctly enabled. (Remember that the twisted pair Ethernet > standard is half duplex. Full duplex was only added to the standard > with autonegotiation. Forced full duplex is a common but non-standard > extension. ) > > Forcing the switch to full duplex mean that every new device must be > configured by hand, and the configuration reversed when you move the > device to standard networking equipment. Forgetting either case results > in difficult to track down performance problems. > > I consider forced-full-duplex to be an serious issue somewhere between > "..and these cars have the brake pedal on the right" and "we decided to > put the drinking water in the brown jugs, and the 'other' water in blue". > You won't necessarily die right away, but it isn't healthy. > > > I recently inherited sa responsibility for a large number > > of RedHat Linux 7.0 systems. All machines have a variation > > of Intel NIC, all utilizing e100 or eepro100. All systems are > > being "forced", via modules.conf, to 100Mbs, full-duplex. > > I notice, via dmesg, that we recv the message: > > > > modules.conf specifies: > > options eth0 options=0x20 full_duplex=1 > > What driver version? > > > On "eepro100" systems, recv dmesg: > > "Forcing 100Mbs half-duplex operation." > > Hmmm, this _is_ misleading. I'll change it. In the meantime try > options=0x200 > > Other valid options are 0x100, 0x20, and 0x10. > I hope the mapping of speed and duplex is obvious. > > > 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 >