Untitled Document

From cpdgnade@yahoo.com Sat Mar 2 07:48:01 2002 From: cpdgnade@yahoo.com (yxwnade) Date: Sat Mar 2 07:48:01 2002 Subject: [eepro100] Just want to share it with you! medw Message-ID: <200203021247.g22Cl8R09699@blueraja.scyld.com> Untitled Document

If you thought sex was all over for you, take heart and read on! There's every chance that very, very soon you'll actually be watching your penis stand up and salute with all the vigor, zest, and lusty appetite of a fresh, young recruit! The secret of success will be all yours - she need ever know - and this is how it works...

For more information please send an email to revolutionary_pills@yahoo.com with "MORE INFO" being the only two words on the subject line. To remove, place "REMOVE" being the only word on the subject line.

hhsorpxoqoxmbxwaf From greearb@candelatech.com Sat Mar 2 18:36:00 2002 From: greearb@candelatech.com (Ben Greear) Date: Sat Mar 2 18:36:00 2002 Subject: [eepro100] wait_for_cmd_done timeout in 2.4.19-re2-ac2 Message-ID: <3C8161D3.4080507@candelatech.com> This is a multi-part message in MIME format. --------------020307050106070107020400 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit My EEA2 motherboard with eepro100 driver screwed up again today. This seems to be the same old issue with the eepro100 being connected to a 10bt hub. I believe this kernel has all of the patches from the Sun engineer (sparker), but maybe it doesn't?? The error is: wait_for_cmd_done timeout! The one good thing is that at least the machine didn't lock up hard like it used to. Looks like it's back to e100 time, unfortunately. eepro100-diag output is attached in case that is useful.l Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear --------------020307050106070107020400 Content-Type: text/plain; name="foo.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="foo.txt" eepro100-diag.c:v2.02 7/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Intel i82562 EEPro100 adapter at 0xdf00. i82557 chip registers at 0xdf00: 0c000050 0efbb1a0 00000000 00080002 18250021 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 64x16: 00: 0300 c247 d2a6 1a03 0000 0201 4701 0000 0x08: 0000 0000 49b2 3013 8086 007f ffff ffff 0x10: ffff ffff ffff ffff ffff ffff ffff ffff 0x18: ffff ffff ffff ffff ffff ffff ffff ffff 0x20: ffff ffff ffff ffff ffff ffff ffff ffff 0x28: ffff ffff ffff ffff ffff ffff ffff ffff 0x30: 0120 4000 4011 ffff ffff ffff ffff ffff 0x38: ffff ffff ffff 0000 ffff ffff ffff 43fa The EEPROM checksum is correct. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:03:47:C2:A6:D2. Board assembly 000000-000, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. MII PHY #1 transceiver registers: 3100 782d 02a8 0330 05e1 0021 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 2404 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0010 0000 0000 0000. 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. --------------020307050106070107020400-- From greearb@candelatech.com Sat Mar 2 18:51:01 2002 From: greearb@candelatech.com (Ben Greear) Date: Sat Mar 2 18:51:01 2002 Subject: [eepro100] Re: wait_for_cmd_done timeout in 2.4.19-re2-ac2 References: <3C8161D3.4080507@candelatech.com> <3C81629C.D56936E1@mandrakesoft.com> Message-ID: <3C81653D.6090308@candelatech.com> Jeff Garzik wrote: > Ben Greear wrote: > >>My EEA2 motherboard with eepro100 driver screwed up again today. >>This seems to be the same old issue with the eepro100 being >>connected to a 10bt hub. I believe this kernel has all of the >>patches from the Sun engineer (sparker), but maybe it doesn't?? >> >>The error is: wait_for_cmd_done timeout! >> > > What driver and kernel version? 2.4.19-pre2-ac2 > What does 'dmesg' show upon hardware init eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin and others PCI: Found IRQ 11 for device 01:08.0 eth0: Intel Corp. 82820 (ICH2) Chipset Ethernet Controller, 00:03:47:C8:3E:D2, IRQ 11. Board assembly 000000-000, 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). > > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From alan@lxorguk.ukuu.org.uk Sat Mar 2 18:54:01 2002 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Sat Mar 2 18:54:01 2002 Subject: [eepro100] Re: wait_for_cmd_done timeout in 2.4.19-re2-ac2 In-Reply-To: <3C81653D.6090308@candelatech.com> from "Ben Greear" at Mar 02, 2002 04:50:21 PM Message-ID: > 2.4.19-pre2-ac2 Ok thats probably my fault. I think I see the problem From jgarzik@mandrakesoft.com Sun Mar 3 20:40:01 2002 From: jgarzik@mandrakesoft.com (Jeff Garzik) Date: Sun Mar 3 20:40:01 2002 Subject: [eepro100] Re: wait_for_cmd_done timeout in 2.4.19-re2-ac2 References: <3C8161D3.4080507@candelatech.com> Message-ID: <3C81629C.D56936E1@mandrakesoft.com> Ben Greear wrote: > > My EEA2 motherboard with eepro100 driver screwed up again today. > This seems to be the same old issue with the eepro100 being > connected to a 10bt hub. I believe this kernel has all of the > patches from the Sun engineer (sparker), but maybe it doesn't?? > > The error is: wait_for_cmd_done timeout! What driver and kernel version? What does 'dmesg' show upon hardware init? -- Jeff Garzik | Building 1024 | MandrakeSoft | Choose life. From marco.difolco@coresecure.com Mon Mar 4 05:06:00 2002 From: marco.difolco@coresecure.com (Marco Di Folco) Date: Mon Mar 4 05:06:00 2002 Subject: [eepro100] collision problem Message-ID: <002601c1c364$0032ce00$2100a8c0@fox> This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C1C36C.602E5CE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, I am having ethernet connection issues with a Dell PowerEdge 2450 server, it has two Intel NICs. The system is running Red Hat Linux 6.2 with all updates applied. The kernel version is 2.2.19 from Red Hat. The eepro100 driver version is $Revision: 1.20.2.10 $ 2000/05/31. Both NICs are connected to a 10/100 mbps Cisco switch. Here are my problems: - the NICs seem to be running at 10 mbps, half-duplex. - ifconfig reports a huge number of collisions for both NICs. I have lately upgraded the kernel from 2.2.14 to 2.2.19. I think I was having the same problems before the kernel upgrade, I just didn't notice them... Also, close to this server, there is a Dell PowerEdge 1550 box, it also has two Intel NICs connected to the same Cisco switch, and they are running just fine at 100 mbps full-duplex with no collisions at all! Though this other server is running Red Hat Linux 7.2 and kernel 2.4.9 from Red Hat. I attached a text file with the output of ifconfig, dmesg, mii-diag, eepro-diag, pci-config in order to help diagnose my connection problems with the 2450 server. How can I force the NICs to run at 100 mbps full-duplex? How can I get rid of the collisions? Thanks in advance, Marco. ------=_NextPart_000_0023_01C1C36C.602E5CE0 Content-Type: text/plain; name="dell_2450_connection_problems.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dell_2450_connection_problems.txt" ifconfig output (I replaced the Internet IP with XXX...): eth0 Link encap:Ethernet HWaddr 00:02:B3:0A:06:7E =20 inet addr:XXX.XXX.XXX.XXX Bcast:XXX.XXX.XXX.XXX = Mask:255.255.255.240 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:30929056 errors:0 dropped:0 overruns:0 frame:0 TX packets:35314266 errors:0 dropped:0 overruns:0 carrier:0 collisions:1916335 txqueuelen:100=20 Interrupt:22 Base address:0xecc0=20 eth1 Link encap:Ethernet HWaddr 00:B0:D0:68:54:D2 =20 inet addr:10.2.1.12 Bcast:10.2.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:35432594 errors:0 dropped:0 overruns:0 frame:0 TX packets:55868203 errors:0 dropped:0 overruns:0 carrier:0 collisions:32751600 txqueuelen:100=20 Interrupt:16 Base address:0xccc0=20 dmesg ouput: eepro100.c:v1.09j-t 9/29/99 Donald Becker = http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. = Savochkin and others eepro100.c: VA Linux custom, Dragan Stancevic = 2000/11/15 eth0: OEM i82557/i82558 10/100 Ethernet, 00:02:B3:0A:06:7E, I/O at = 0xecc0, IRQ 22. Board assembly a08922-002, 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). eth1: Intel PCI EtherExpress Pro100 82557, 00:B0:D0:68:54:D2, I/O at = 0xccc0, IRQ 16. Receiver lock-up bug exists -- enabling work-around. Board assembly 07195d-000, 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). Receiver lock-up workaround activated. cat uses obsolete /proc/pci interface mmi-diag output: # mii-diag eth0 Basic registers of MII PHY #1: 0000 780d 02a8 0154 05e1 0000 0000 0000. Basic mode control register 0x0000: Auto-negotiation disabled, with Speed fixed at 10 mbps, half-duplex. You have link beat, and everything is working OK. Link partner information is not exchanged when in fixed speed mode. End of basic transceiver information. # mii-diag eth1 Basic registers of MII PHY #1: 0000 780d 02a8 0154 05e1 41e1 0001 0000. The autonegotiated capability is 01e0. The autonegotiated media type is 100baseTx-FD. Basic mode control register 0x0000: Auto-negotiation disabled, with Speed fixed at 10 mbps, half-duplex. You have link beat, and everything is working OK. Your link partner advertised 41e1: 100baseTx-FD 100baseTx 10baseT-FD = 10baseT. End of basic transceiver information. eepro-diag output: # eepro100-diag -f -aa eepro100-diag.c:v2.05 6/13/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Intel i82557/8/9 EtherExpressPro100 adapter at 0xecc0. i82557 chip registers at 0xecc0: 0c000050 1f7ba0e4 00000000 00080002 18250000 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(?!). Index #2: Found a Intel i82557/8/9 EtherExpressPro100 adapter at 0xccc0. i82557 chip registers at 0xccc0: 0c000050 1f7320e4 00000000 00080002 182541e1 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(?!). # eepro100-diag -f -ee eepro100-diag.c:v2.05 6/13/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Intel i82557/8/9 EtherExpressPro100 adapter at 0xecc0. EEPROM contents, size 64x16: 00: 0200 0ab3 7e06 0503 0000 0201 4701 0000 0x08: a089 2202 4882 100c 8086 0000 0000 0000 ... 0x30: 002c 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 4631 The EEPROM checksum is correct. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:02:B3:0A:06:7E. Board assembly a08922-002, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Sleep mode is enabled. This is not recommended. Under high load the card may not respond to PCI requests, and thus cause a master abort. Index #2: Found a Intel i82557/8/9 EtherExpressPro100 adapter at 0xccc0. EEPROM contents, size 64x16: 00: b000 68d0 d254 0400 0000 0201 4701 0000 0x08: 0719 5d00 48a2 009b 1028 0000 0000 0000 ... 0x30: 0020 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 c4f6 The EEPROM checksum is correct. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:B0:D0:68:54:D2. Receiver lock-up bug exists. (The driver work-around *is* = implemented.) Board assembly 07195d-000, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. Sleep mode is enabled. This is not recommended. Under high load the card may not respond to PCI requests, and thus cause a master abort. # eepro100-diag -f -m eepro100-diag.c:v2.05 6/13/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Intel i82557/8/9 EtherExpressPro100 adapter at 0xecc0. Index #2: Found a Intel i82557/8/9 EtherExpressPro100 adapter at 0xccc0. pci-config output: # pci-config=20 pci-config.c:v2.02 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Device #1 at bus 0 device/function 0/0, 00091166. Device #2 at bus 0 device/function 0/1, 00091166. Device #3 at bus 0 device/function 8/0, 12298086. Device #4 at bus 0 device/function 14/0, 47591002. Device #5 at bus 0 device/function 15/0, 02001166. Device #6 at bus 0 device/function 15/1, 02111166. Device #7 at bus 0 device/function 15/2, 02201166. ------=_NextPart_000_0023_01C1C36C.602E5CE0-- From ewdjohn@pumkinpatch.com Mon Mar 4 08:48:00 2002 From: ewdjohn@pumkinpatch.com (ajetjohn) Date: Mon Mar 4 08:48:00 2002 Subject: [eepro100] Please read as it is important eyx Message-ID: <200203041346.g24DkvR25825@blueraja.scyld.com> Untitled Document

1. How do you rate your confidence that you could get and keep an erection?

2. When you had erections with sexual stimulation, how often were your erections hard enough for penetration (entering your partner)?

3. During sexual intercourse, how often were you able to maintain your erection after you had penetrated (entered) your partner?

4. During sexual intercourse, how difficult was it to maintain your erection to completion of intercourse?

5. When you attempted sexual intercourse, how often was it satisfactory for you?

If your answers to any of these questions like “Almost never or never”, “Difficult”, or “Low”, etc.. Worry not. We have solutions. Safe and affordable. Results occur immediately!

For more information please send an email to new_me@yahoo.com with "MORE INFO" being the only two words on the subject line. To remove, place "REMOVE" being the only word on the subject line.

ljfmjblprxhofhptvayaixeepgdmcbek From becker@scyld.com Mon Mar 4 20:59:00 2002 From: becker@scyld.com (Donald Becker) Date: Mon Mar 4 20:59:00 2002 Subject: [eepro100] collision problem In-Reply-To: <002601c1c364$0032ce00$2100a8c0@fox> Message-ID: On Mon, 4 Mar 2002, Marco Di Folco wrote: > I am having ethernet connection issues with a Dell PowerEdge 2450 server, it > has two Intel NICs. > The system is running Red Hat Linux 6.2 with all updates applied. > The kernel version is 2.2.19 from Red Hat. > The eepro100 driver version is $Revision: 1.20.2.10 $ 2000/05/31. > Both NICs are connected to a 10/100 mbps Cisco switch. > > Here are my problems: > - the NICs seem to be running at 10 mbps, half-duplex. The mii-diag output indicated that eth0 was forced to 10baseT. Is that what you intended? > - ifconfig reports a huge number of collisions for both NICs. That's expected when you force 10baseT on a busy network. > Also, close to this server, there is a Dell PowerEdge 1550 box, it also has > two Intel NICs connected to the same Cisco switch, and they are running just > fine at 100 mbps full-duplex with no collisions at all! ... > How can I force the NICs to run at 100 mbps full-duplex? > How can I get rid of the collisions? You should really let the link autonegotiate. This is the default setting -- verify that you are not unintentionally passing an option to the driver (/etc/modules.conf or /etc/conf.modules) If your Cisco switch is set to forced-full-duplex, which disables autonegotiation, you can force the driver speed with an option as described at http://www.scyld.com/network/eepro100.html or do mii-diag -F 100baseTx-FDX 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 japc@co.sapo.pt Tue Mar 5 11:33:00 2002 From: japc@co.sapo.pt (Jose Celestino) Date: Tue Mar 5 11:33:00 2002 Subject: [eepro100] eepro100 driver state Message-ID: <20020305162729.C3215@co.sapo.pt> I, how is the eepro100 driver in stability terms. The question comes after I had a problem with our local gw. After a few days of uptime we got without connectivity, dmesg displayed several: NETDEV WATCHDOG: eth2: transmit timed out eth2: Transmit timed out: status f088 0c00 at 7187202/7187232 command 0001a000. eth2: Tx ring dump, Tx queue 7187232 / 7187202: eth2: = 0 0003a000. eth2: 1 4003a000. eth2: * 2 0001a000. eth2: 3 0002a000. eth2: 4 0003a000. eth2: 5 000ca000. eth2: 6 000ca000. eth2: 7 000ca000. eth2: 8 200ca000. eth2: 9 0003a000. eth2: 10 000ca000. eth2: 11 000ca000. eth2: 12 0003a000. eth2: 13 000ca000. eth2: 14 000ca000. eth2: 15 0003a000. eth2: 16 200ca000. eth2: 17 000ca000. eth2: 18 0003a000. eth2: 19 000ca000. eth2: 20 000ca000. eth2: 21 0003a000. eth2: 22 000ca000. eth2: 23 000ca000. eth2: 24 0003a000. eth2: 25 000ca000. eth2: 26 000ca000. eth2: 27 0003a000. eth2: 28 000ca000. eth2: 29 000ca000. eth2: 30 0003a000. eth2: 31 4003a000. And the interface didn't manage to recover with a simple ifconfig eth2 down; ifconfig eth2 up, I had to reboot. What may be causing this? Solutions? Kernel-2.4.18 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html 00:0c.0: 3Com PCI 3cSOHO100-TX Hurricane at 0x1080. Vers LK1.1.16 eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin and others eth1: Intel Corp. 82557 [Ethernet Pro 100], 00:90:27:CB:B1:61, IRQ 11. Board assembly 721383-007, 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). eth2: Intel Corp. 82557 [Ethernet Pro 100] (#2), 00:90:27:73:78:C2, IRQ 11. Receiver lock-up bug exists -- enabling work-around. Board assembly 677173-001, 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 (0x24c9f043). Receiver lock-up workaround activated. TIA. -- Jose Celestino SysAdmin::SAPO.pt http://www.sapo.pt --------------------------------------------------------------------- main(){printf("%xu%xk%x!\n",15,12,237);} From japc@co.sapo.pt Tue Mar 5 11:52:01 2002 From: japc@co.sapo.pt (Jose Celestino) Date: Tue Mar 5 11:52:01 2002 Subject: [eepro100] Driver problems Message-ID: <20020305164620.A3312@co.sapo.pt> I, how is the eepro100 driver in stability terms. The question comes after I had a problem with our local gw. After a few days of uptime we got without connectivity, dmesg displayed several: NETDEV WATCHDOG: eth2: transmit timed out eth2: Transmit timed out: status f088 0c00 at 7187202/7187232 command 0001a000. eth2: Tx ring dump, Tx queue 7187232 / 7187202: eth2: = 0 0003a000. eth2: 1 4003a000. eth2: * 2 0001a000. eth2: 3 0002a000. eth2: 4 0003a000. eth2: 5 000ca000. eth2: 6 000ca000. eth2: 7 000ca000. eth2: 8 200ca000. eth2: 9 0003a000. eth2: 10 000ca000. eth2: 11 000ca000. eth2: 12 0003a000. eth2: 13 000ca000. eth2: 14 000ca000. eth2: 15 0003a000. eth2: 16 200ca000. eth2: 17 000ca000. eth2: 18 0003a000. eth2: 19 000ca000. eth2: 20 000ca000. eth2: 21 0003a000. eth2: 22 000ca000. eth2: 23 000ca000. eth2: 24 0003a000. eth2: 25 000ca000. eth2: 26 000ca000. eth2: 27 0003a000. eth2: 28 000ca000. eth2: 29 000ca000. eth2: 30 0003a000. eth2: 31 4003a000. And the interface didn't manage to recover with a simple ifconfig eth2 down; ifconfig eth2 up, I had to reboot. What may be causing this? Solutions? Kernel-2.4.18 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html 00:0c.0: 3Com PCI 3cSOHO100-TX Hurricane at 0x1080. Vers LK1.1.16 eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin and others eth1: Intel Corp. 82557 [Ethernet Pro 100], 00:90:27:CB:B1:61, IRQ 11. Board assembly 721383-007, 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). eth2: Intel Corp. 82557 [Ethernet Pro 100] (#2), 00:90:27:73:78:C2, IRQ 11. Receiver lock-up bug exists -- enabling work-around. Board assembly 677173-001, 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 (0x24c9f043). Receiver lock-up workaround activated. TIA. -- Jose Celestino SysAdmin::SAPO.pt http://www.sapo.pt --------------------------------------------------------------------- main(){printf("%xu%xk%x!\n",15,12,237);} From John.Wilson@savvis.net Tue Mar 5 14:11:01 2002 From: John.Wilson@savvis.net (Wilson, John) Date: Tue Mar 5 14:11:01 2002 Subject: [eepro100] wait_for_cmd_done timeout Message-ID: eepro100 group: I am seeing a problem with wait_for_cmd_done that is very similar to timeout issue that I found on GeoCrawler. I hope my findings will help resolve this problem. Basically what I have found is that I run into a simular time out problem when running Samba. If Samba is not enabled then I don't see this error and the ATM and eepro100 are fine. Below is some fairly detailed output... thought this might help track down the problem. In summary: It appears to me that the network is being flooded with ICMP traffic (and possibly other traffic) and that the eepro100 may not be handling the errors/traffic. (I'm new to Linux device drivers, so please bear with me here). The period of the ICMP error messages may, in itself, not be much traffic... so I assume there may be more to this problem, for example the two device drivers may be sharing the same tx buffer and/or memory. Regardless if Samba is running, (which is probably raising the amount of traffic causing the eepro100 problem to surface), I would like to fix the eepro100 driver if there is a patch available for it. I'm running: RH 7.2 Kernel 2.4.9-13 modified to support the ATM device drivers (eni and FORE (Marconi)) ATM on Linux support software: linux-atm-2.4.0 Samba The system runs for some period, usually less than 24 hours, then eventually the interfaces die with this error (from /var/log/messages) Mar 5 08:36:46 sla2 kernel: 10.12.136.1 sent an invalid ICMP error to a broadcast. Mar 5 08:39:51 sla2 kernel: 10.12.136.1 sent an invalid ICMP error to a broadcast. Mar 5 08:41:46 sla2 kernel: 10.12.136.1 sent an invalid ICMP error to a broadcast. Mar 5 08:46:46 sla2 kernel: 10.12.136.1 sent an invalid ICMP error to a broadcast. Mar 5 08:51:47 sla2 kernel: 10.12.136.1 sent an invalid ICMP error to a broadcast. Mar 5 08:56:46 sla2 last message repeated 2 times Mar 5 09:01:46 sla2 kernel: 10.12.136.1 sent an invalid ICMP error to a broadcast. Mar 5 09:03:51 sla2 kernel: 10.12.136.1 sent an invalid ICMP error to a broadcast. Mar 5 09:05:14 sla2 kernel: eepro100: wait_for_cmd_done timeout! Mar 5 09:05:46 sla2 last message repeated 24 times Mar 5 09:05:48 sla2 last message repeated 3 times Mar 5 09:05:49 sla2 kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 5 09:05:49 sla2 kernel: eth0: Transmit timed out: status 0050 0c80 at 48699/48728 command 00030000. Mar 5 09:05:49 sla2 kernel: eepro100: wait_for_cmd_done timeout! Mar 5 09:06:21 sla2 last message repeated 22 times Mar 5 09:06:22 sla2 kernel: eni(itf 0): TX DMA full Mar 5 09:06:23 sla2 last message repeated 7 times Mar 5 09:06:23 sla2 kernel: eepro100: wait_for_cmd_done timeout! Mar 5 09:06:24 sla2 kernel: eni(itf 0): TX DMA full At this point both the eth0 interface and atm0 interface stop working. Note that the eepro100 times out first and then the eni driver also dies with TX DMA full error. ifconfig shows: [root@sla2 root]# more ifconfig.txt atm0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.6.160.254 Mask:255.255.255.252 UP RUNNING MTU:1500 Metric:1 RX packets:4860 errors:0 dropped:0 overruns:0 frame:0 TX packets:4860 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:408240 (398.6 Kb) TX bytes:447120 (436.6 Kb) eth0 Link encap:Ethernet HWaddr 00:50:8B:D3:92:7C inet addr:216.90.89.xx Bcast:216.90.89.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:504622 errors:0 dropped:0 overruns:0 frame:0 TX packets:47444 errors:289 dropped:0 overruns:0 carrier:0 collisions:1416 txqueuelen:100 RX bytes:50644863 (48.2 Mb) TX bytes:10479503 (9.9 Mb) Interrupt:10 Base address:0x2000 Note the collisions are on eth0. I know that the ICMP error above is caused by our network configuration (Samba broadcasts a NBNS message on 216.90.89.255 and the 10.12.136.1 is replying with the above error. Ethereal shows the error as Type 3 (Destination Unreachable) and Code 3 (Port Unreachable)). For whatever reason this message is being sent (I've not been able to determine how to stop Nortel Shasta from doing this yet). I wanted to point out that the eepro100 is timing out and is effecting the ATM device driver too. The eepro100 version is: "eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html\n" "eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin and others\n"; I know there is a lot of info here, but after reading the thread on the wait_for_cmd_done, I thought this might shed some light on the problem and that it may not be confined to the newer/experimental kernels. Any help would be much appreciated. regards, jd wilson Software Engineer Savvis Communications From becker@scyld.com Tue Mar 5 14:58:01 2002 From: becker@scyld.com (Donald Becker) Date: Tue Mar 5 14:58:01 2002 Subject: [eepro100] wait_for_cmd_done timeout In-Reply-To: Message-ID: On Tue, 5 Mar 2002, Wilson, John wrote: > I am seeing a problem with wait_for_cmd_done that is very similar to timeout > issue that I found on GeoCrawler. ... > In summary: It appears to me that the network is being flooded with ICMP > traffic (and possibly other traffic) and that the eepro100 may not be > handling the errors/traffic. (I'm new to Linux device drivers, so please > bear with me here). There are a bunch of errors reported here. The device driver does not cause the errors -- it only reports them. > I'm running: > RH 7.2 > Kernel 2.4.9-13 modified to support the ATM device drivers (eni and > FORE (Marconi)) > ATM on Linux support software: linux-atm-2.4.0 > Samba ... > Mar 5 09:05:14 sla2 kernel: eepro100: wait_for_cmd_done timeout! > Mar 5 09:05:46 sla2 last message repeated 24 times > Mar 5 09:05:48 sla2 last message repeated 3 times > Mar 5 09:05:49 sla2 kernel: NETDEV WATCHDOG: eth0: transmit timed out > Mar 5 09:05:49 sla2 kernel: eth0: Transmit timed out: status 0050 0c80 at > 48699/48728 command 00030000. You should run eepro100-diag to see more chip status information. Nothing is obviously wrong from this report. > Mar 5 09:06:22 sla2 kernel: eni(itf 0): TX DMA full > Mar 5 09:06:23 sla2 last message repeated 7 times > Mar 5 09:06:24 sla2 kernel: eni(itf 0): TX DMA full > > At this point both the eth0 interface and atm0 interface stop working. Note > that the eepro100 times out first and then the eni driver also dies with TX > DMA full error. Yup. That indicates that there is a system problem that affects both devices. > ifconfig shows: > eth0 Link encap:Ethernet HWaddr 00:50:8B:D3:92:7C > RX packets:504622 errors:0 dropped:0 overruns:0 frame:0 > TX packets:47444 errors:289 dropped:0 overruns:0 carrier:0 > collisions:1416 txqueuelen:100 > RX bytes:50644863 (48.2 Mb) TX bytes:10479503 (9.9 Mb) > Note the collisions are on eth0. What type of link partner? What does 'mii-diag' or 'eepro100-diag -m' report? > I wanted to point out that the eepro100 is timing out and is effecting the > ATM device driver too. That's not likely what is happening. While the eepro100 driver is encountering a problem that causes a timeout, the system workload is reduced. Even so, the ATM device driver is reporting a problem. It seems more likely that both problems are caused by a third source. > The eepro100 version is: > "eepro100.c:v1.09j-t 9/29/99 Donald Becker > http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html\n" Grrr, they still refuse to update the URL. > "eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin > and others\n"; > > I know there is a lot of info here, but after reading the thread on the > wait_for_cmd_done, I thought this might shed some light on the problem and > that it may not be confined to the newer/experimental kernels. > > Any help would be much appreciated. Have you tried the driver from http://www.scyld.com/network/eepro100.html ftp://www.scyld.com/pub/network/eepro100.c It might not solve the system problem, but it is more likely to report useful diagnostic information. 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 John.Wilson@savvis.net Wed Mar 6 15:02:00 2002 From: John.Wilson@savvis.net (Wilson, John) Date: Wed Mar 6 15:02:00 2002 Subject: [eepro100] wait_for_cmd_done timeout Message-ID: Donald, Thanks for the reply. Agreed, the driver is reporting the problem and appearently the ATM driver is seeing this same problem and reporting it in a different way. I've built the eepro100-diag and mii-diag programs. Thanks for the simple compile instructions - that helps! I built the utilities against the libmii.o lib. I've restarted the server in question running smbd and nmbd (Samba) as this is how I can re-create the error. As I mentioned before I'm new to learning about this device driver but am somewhat familar with programming at this level with other OSes. Do you have any recommendations on whether this driver is better off running as a module vs added directly to the kernel... which is currenlty how I have it configured -- mostly due to the previous owners configuration. thanks john __________________________________________ The output from mii-diag and eepro100-diag: [root@sla2 bin]# mii-diag Using the default interface 'eth0'. Basic registers of MII PHY #1: 3000 782d 02a8 0154 05e1 0021 0000 0000. Basic mode control register 0x3000: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner is generating 10baseT link beat (no autonegotiation). End of basic transceiver information. [root@sla2 bin]# eepro100-diag -mm -f eepro100-diag.c:v2.07 12/28/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Intel i82557/8/9 EtherExpressPro100 adapter at 0x4000. 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. 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. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x782d ... 782d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Vendor ID is 00:aa:00:--:--:--, model 21 rev. 4. No specific information is known about this transceiver type. I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0021: 10baseT. Negotiation did not complete. Monitoring the MII transceiver status. 13:28:23.414 Baseline value of MII BMSR (basic mode status register) is 782d. I'm assuming that the above status register might change when the error occurs. I'll let you know if I find out any more info -----Original Message----- From: Donald Becker [...] Sent: Tuesday, March 05, 2002 14:01 To: Wilson, John Cc: 'eepro100@scyld.com' Subject: Re: [eepro100] wait_for_cmd_done timeout On Tue, 5 Mar 2002, Wilson, John wrote: > I am seeing a problem with wait_for_cmd_done that is very similar to timeout > issue that I found on GeoCrawler. ... > In summary: It appears to me that the network is being flooded with ICMP > traffic (and possibly other traffic) and that the eepro100 may not be > handling the errors/traffic. (I'm new to Linux device drivers, so please > bear with me here). There are a bunch of errors reported here. The device driver does not cause the errors -- it only reports them. > I'm running: > RH 7.2 > Kernel 2.4.9-13 modified to support the ATM device drivers (eni and > FORE (Marconi)) > ATM on Linux support software: linux-atm-2.4.0 > Samba ... > Mar 5 09:05:14 sla2 kernel: eepro100: wait_for_cmd_done timeout! > Mar 5 09:05:46 sla2 last message repeated 24 times > Mar 5 09:05:48 sla2 last message repeated 3 times > Mar 5 09:05:49 sla2 kernel: NETDEV WATCHDOG: eth0: transmit timed out > Mar 5 09:05:49 sla2 kernel: eth0: Transmit timed out: status 0050 0c80 at > 48699/48728 command 00030000. You should run eepro100-diag to see more chip status information. Nothing is obviously wrong from this report. > Mar 5 09:06:22 sla2 kernel: eni(itf 0): TX DMA full > Mar 5 09:06:23 sla2 last message repeated 7 times > Mar 5 09:06:24 sla2 kernel: eni(itf 0): TX DMA full > > At this point both the eth0 interface and atm0 interface stop working. Note > that the eepro100 times out first and then the eni driver also dies with TX > DMA full error. Yup. That indicates that there is a system problem that affects both devices. > ifconfig shows: > eth0 Link encap:Ethernet HWaddr 00:50:8B:D3:92:7C > RX packets:504622 errors:0 dropped:0 overruns:0 frame:0 > TX packets:47444 errors:289 dropped:0 overruns:0 carrier:0 > collisions:1416 txqueuelen:100 > RX bytes:50644863 (48.2 Mb) TX bytes:10479503 (9.9 Mb) > Note the collisions are on eth0. What type of link partner? What does 'mii-diag' or 'eepro100-diag -m' report? > I wanted to point out that the eepro100 is timing out and is effecting the > ATM device driver too. That's not likely what is happening. While the eepro100 driver is encountering a problem that causes a timeout, the system workload is reduced. Even so, the ATM device driver is reporting a problem. It seems more likely that both problems are caused by a third source. > The eepro100 version is: > "eepro100.c:v1.09j-t 9/29/99 Donald Becker > http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html\n" Grrr, they still refuse to update the URL. > "eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin > and others\n"; > > I know there is a lot of info here, but after reading the thread on the > wait_for_cmd_done, I thought this might shed some light on the problem and > that it may not be confined to the newer/experimental kernels. > > Any help would be much appreciated. Have you tried the driver from http://www.scyld.com/network/eepro100.html ftp://www.scyld.com/pub/network/eepro100.c It might not solve the system problem, but it is more likely to report useful diagnostic information. 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 Wed Mar 6 16:50:01 2002 From: becker@scyld.com (Donald Becker) Date: Wed Mar 6 16:50:01 2002 Subject: [eepro100] wait_for_cmd_done timeout In-Reply-To: Message-ID: On Wed, 6 Mar 2002, Wilson, John wrote: > Thanks for the reply. Agreed, the driver is reporting the problem and > appearently the ATM driver is seeing this same problem and reporting it in a > different way. > > I've built the eepro100-diag and mii-diag programs. Thanks for the simple ... > Do you have any recommendations on whether this driver is better off running > as a module vs added directly to the kernel... which is currenlty how I have > it configured -- mostly due to the previous owners configuration. Using the driver as a module is preferred. It allow you to easily change drivers, as well as allowing you to change the following module parameters: MODULE_PARM(txfifo, "i"); MODULE_PARM(rxfifo, "i"); MODULE_PARM(txdmacount, "i"); MODULE_PARM(rxdmacount, "i"); It's rare that you need to change from the default settings, but with a compiled-in driver it's much more difficult. > [root@sla2 bin]# mii-diag > Basic registers of MII PHY #1: 3000 782d 02a8 0154 05e1 0021 0000 0000. > Your link partner is generating 10baseT link beat (no autonegotiation). 10baseT hub? Is that correct? > [root@sla2 bin]# eepro100-diag -mm -f > eepro100-diag.c:v2.07 12/28/2001 Donald Becker (becker@scyld.com) Doing 'eepro100-diag -mm' is pretty much the same as doing mii-diag --watch To see the NIC state, run eepro100-diag -a -f just after the interface stops working. > Monitoring the MII transceiver status. > 13:28:23.414 Baseline value of MII BMSR (basic mode status register) is > 782d. > I'm assuming that the above status register might change when the error > occurs. 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 cdjim@enlarger.com Thu Mar 7 06:17:02 2002 From: cdjim@enlarger.com (oavwjack) Date: Thu Mar 7 06:17:02 2002 Subject: [eepro100] Check this out. mwu Message-ID: <200203071116.g27BGLR24072@blueraja.scyld.com> Untitled Document

Use the MAGNA-RX+ Penis Enlargement Formula daily for three to five weeks(one pill per day with water) at home, without weights or surgery, and:

YOU'LL INCREASE YOUR PENIS SIZE FROM 2 TO 5 INCHES
YOUR PENIS WILL BE THICKER AND FULLER
ACHIEVE ROCKHARD ERECTIONS ANYTIME YOU WANT
LAST AS LONG AS YOU WISH
YOUR SENSE OF CONFIDENCE AND SELF-ESTEEM WILL SOAR
YOU'LL SATISFY YOUR LOVER AS NEVER BEFORE

Get the confidence you've always wanted. It's time to do it! Start the rest of your life today.

For more information please send an E-Mail with two words "MORE INFO" on the subject line. To remove, put the word "REMOVE" on the subject line.

wpaptciqbrnoumwnrursqebhqswggoivrfaqmbn From djamil@serveur-express.com Thu Mar 7 07:16:00 2002 From: djamil@serveur-express.com (djamil essaissi) Date: Thu Mar 7 07:16:00 2002 Subject: [eepro100] Check this out. mwu In-Reply-To: <200203071116.g27BGLR24072@blueraja.scyld.com> References: <200203071116.g27BGLR24072@blueraja.scyld.com> Message-ID: <1015503402.2997.11.camel@jul> sorry i cant keep this for my self; it seems these imbeciles dont know that if ur smart enought to mess around with "drivers" ur for sure very happy in every angle of "life" besides of politics of course ... :) grrrr cheers :) On Thu, 2002-03-07 at 12:12, oavwjack wrote: Use the MAGNA-RX+ Penis Enlargement Formula daily for three to five weeks(one pill per day with water) at home, without weights or surgery, and: * YOU'LL INCREASE YOUR PENIS SIZE FROM 2 TO 5 INCHES * YOUR PENIS WILL BE THICKER AND FULLER * ACHIEVE ROCKHARD ERECTIONS ANYTIME YOU WANT * LAST AS LONG AS YOU WISH * YOUR SENSE OF CONFIDENCE AND SELF-ESTEEM WILL SOAR * YOU'LL SATISFY YOUR LOVER AS NEVER BEFORE Get the confidence you've always wanted. It's time to do it! Start the rest of your life today. For more information please send an E-Mail with two words "MORE INFO" on the subject line. To remove, put the word "REMOVE" on the subject line. -- From stahlbock@basysprint.de Thu Mar 7 10:05:00 2002 From: stahlbock@basysprint.de (Bernd Stahlbock) Date: Thu Mar 7 10:05:00 2002 Subject: AW: [eepro100] 82559ER In-Reply-To: <5009AD9521A8D41198EE00805F85F18F017CE0AB@SEMBO111> Message-ID: Hello all, I'm just looking for an BootOnLan solution for a embedded PC Board with a 559er on it. Does anybody has a solution already? Can I use the normal PXE files and just patch the chip ID? Would this work? best regards Bernd Stahlbock > -----Ursprüngliche Nachricht----- > Von: eepro100-admin@scyld.com [mailto:eepro100-admin@scyld.com]Im > Auftrag von Isabelle, Francois > Gesendet: Montag, 5. November 2001 15:21 > An: eepro100@scyld.com > Betreff: RE: [eepro100] 82559ER > > > 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 > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 > From Francois.Isabelle@ca.kontron.com Thu Mar 7 11:13:00 2002 From: Francois.Isabelle@ca.kontron.com (Isabelle, Francois) Date: Thu Mar 7 11:13:00 2002 Subject: [eepro100] 82559ER Message-ID: <5009AD9521A8D41198EE00805F85F18F219909@sembo111.teknor.com> I don't know, ( it might not be the place for this but Kontron SBC using the 82559er implements this ). The best would be to contact the embedded PC manufacturer because it CAN work. -----Original Message----- From: Bernd Stahlbock [mailto:stahlbock@basysprint.de] Sent: 7 mars, 2002 10:05 To: Isabelle, Francois; eepro100@scyld.com Subject: AW: [eepro100] 82559ER Hello all, I'm just looking for an BootOnLan solution for a embedded PC Board with a 559er on it. Does anybody has a solution already? Can I use the normal PXE files and just patch the chip ID? Would this work? best regards Bernd Stahlbock > -----Ursprüngliche Nachricht----- > Von: eepro100-admin@scyld.com [mailto:eepro100-admin@scyld.com]Im > Auftrag von Isabelle, Francois > Gesendet: Montag, 5. November 2001 15:21 > An: eepro100@scyld.com > Betreff: RE: [eepro100] 82559ER > > > 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 > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 > From christoph.plattner@alcatel.at Fri Mar 8 02:30:01 2002 From: christoph.plattner@alcatel.at (Christoph Plattner) Date: Fri Mar 8 02:30:01 2002 Subject: AW: [eepro100] 82559ER References: Message-ID: <3C886822.3C2BAED5@alcatel.at> IMO, you have two possibilities: (1) Stay on the PXE: Use GNU GRUB, which deliveres a PXE diskless version of the GNU GRUB. This bootloader GRUB is one of the best I have ever seen and used. After GRUB is bootsrapped, GRUB can load quite nearly all OSes locally or from net. Also the menu|config file can be loaded from net an organized centrally. (2) You use `etherboot' (replace net-boot ROM contents) and you can boot the desired OS directly or (my prefered solution) you use the GRUB (nbgrub) image to load via `etherboot', and then see GRUB in (1). GRUB: www.gnu.org Etherboot: etherboot.sourceforge.net With friendly regards Christoph Plattner Bernd Stahlbock wrote: > > Hello all, > > I'm just looking for an BootOnLan solution for a embedded PC Board with a > 559er on it. Does anybody has a solution already? > > Can I use the normal PXE files and just patch the chip ID? Would this work? > > best regards > Bernd Stahlbock > From ameader@corp.lcom.net Sat Mar 9 11:06:01 2002 From: ameader@corp.lcom.net (Andrew J. Meader) Date: Sat Mar 9 11:06:01 2002 Subject: [eepro100] I need help... Message-ID: <3C8A31DF.4020705@corp.lcom.net> Hello, I am using onboard dual port eepro100 in a couple penguin relion 225 servers. The eepro100 drivers are compiled directly into kernel 2.4.17. I am experiencing *absolute* weirdness. When I nmap my physical interfaces I see the expected open ports. When I netstat all looks well. When I nmap my virtual interfaces I do not see any open ports. Iptables is stopped. Please help. I need to put these boxes into production on 031202. Andy Meader From ranjit_linux@yahoo.com Sun Mar 17 01:41:01 2002 From: ranjit_linux@yahoo.com (Ranjit S) Date: Sun Mar 17 01:41:01 2002 Subject: [eepro100] delaying eth0 initialization!! Message-ID: <20020317064049.47795.qmail@web20201.mail.yahoo.com> HI, I have been trying to get my linux red hat 6.1 installation to detect my network card but i have been unsuccessful. The card i have is Linksys LNE100TX Fast Ethernet Adapter(LNE100TX v4). 1st i tried compling the code given in the linksys installation floppy....but it did not work. Then i went to scyld.com and downloaded the necessary files ....tulip.c,pci-scan.c,pci-scan.h and kern_compat.h. I followed the instructions and complied the code and installed the drivers as per the given install command. The code compiled successfully and so did the commands: install -m 644 pci-scan.o /lib/modules/`uname -r`/net/ install -m 644 tulip.o /lib/modules/`uname -r`/net/ I was really pleased thinking that NOW the network card would work but when i rebooted the machine i got the message during startup as : Delaying eth0 initialization [failed] I am unable to find any direct solution to this on the internet. I really hope someone can please help me find a solution to this. Ranjit __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ From wyb@ccert.com.cn Mon Mar 18 01:07:00 2002 From: wyb@ccert.com.cn (wyb) Date: Mon Mar 18 01:07:00 2002 Subject: [eepro100] How to make eepro100 to receive pkt > 1514 ? Message-ID: <001401c1ce42$88e29a80$a8010101@talent.com> I'm working on a firewall project, this firewall is designed to support switch trunk, such as 802.1q or CISCO isl. So it must be able to receive packet size > 1514. I changed PKT_BUF_SZ from 1536 to 1572, but it didn't work. Can any give suggesstion ? Mail answer to me for I dit not subscribe to this list. Thanks From christoph.plattner@alcatel.at Mon Mar 18 02:56:00 2002 From: christoph.plattner@alcatel.at (Christoph Plattner) Date: Mon Mar 18 02:56:00 2002 Subject: [eepro100] How to make eepro100 to receive pkt > 1514 ? References: <001401c1ce42$88e29a80$a8010101@talent.com> Message-ID: <3C959D77.DF614099@alcatel.at> As far I know, 1514 is the maximum of that can be transfered by the chip. This represents the highler level MTU from 1500 bytes plus the 14 bytes ethernet specific haeder for the Source and Destination MAC address (2 x 6 bytes) and the protocol type header (2 bytes), which are 14 bytes. The 1500 resepctive 1514 is AFAIK defined in the ethernet standard, and some chips may support non standard frames. I hope, I tell you not wrong things, but this is from my experience with this chip and with other NIC stuff. With friendly regards Christoph Plattner wyb wrote: > > I'm working on a firewall project, this firewall is designed to support switch trunk, > such as 802.1q or CISCO isl. So it must be able to receive packet size > 1514. > I changed PKT_BUF_SZ from 1536 to 1572, but it didn't work. Can any give suggesstion ? > Mail answer to me for I dit not subscribe to this list. > > Thanks > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 ------------------------------------------------------------------ private: christoph.plattner@gmx.at company: christoph.plattner@alcatel.at From ofer@shunra.co.il Mon Mar 18 03:48:01 2002 From: ofer@shunra.co.il (Ofer Fryman) Date: Mon Mar 18 03:48:01 2002 Subject: [eepro100] How to make eepro100 to receive pkt > 1514 ? Message-ID: As far as I know this chip does not support Jumbo frames (pkt > 1514), you can use Intel's e1000 cooper chip it runs as a 10/100/1000 and can deal with Jumbo frames. -----Original Message----- From: wyb [mailto:wyb@ccert.com.cn] Sent: Monday, March 18, 2002 8:03 AM To: eepro100@scyld.com Subject: [eepro100] How to make eepro100 to receive pkt > 1514 ? I'm working on a firewall project, this firewall is designed to support switch trunk, such as 802.1q or CISCO isl. So it must be able to receive packet size > 1514. I changed PKT_BUF_SZ from 1536 to 1572, but it didn't work. Can any give suggesstion ? Mail answer to me for I dit not subscribe to this list. Thanks _______________________________________________ eepro100 mailing list eepro100@scyld.com http://www.scyld.com/mailman/listinfo/eepro100 From mike@nbase.co.il Mon Mar 18 04:42:01 2002 From: mike@nbase.co.il (Michael Rozhavsky) Date: Mon Mar 18 04:42:01 2002 Subject: [eepro100] How to make eepro100 to receive pkt > 1514 ? In-Reply-To: <001401c1ce42$88e29a80$a8010101@talent.com> References: <001401c1ce42$88e29a80$a8010101@talent.com> Message-ID: <20020318094122.GR29400@opticalaccess.com> --AkbCVLjbJ9qUtAXD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Attached patch is for 2.4.9 but should work with later kernels also. On Mon, Mar 18, 2002 at 02:02:34PM +0800, wyb wrote: > I'm working on a firewall project, this firewall is designed to support switch trunk, > such as 802.1q or CISCO isl. So it must be able to receive packet size > 1514. > I changed PKT_BUF_SZ from 1536 to 1572, but it didn't work. Can any give suggesstion ? > Mail answer to me for I dit not subscribe to this list. > > Thanks > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 -- Best regards. Michael Rozhavsky Tel: +972-4-9936248 mrozhavsky@opticalaccess.com Fax: +972-4-9890564 Optical Access Senior Software Engineer www.opticalaccess.com --AkbCVLjbJ9qUtAXD Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="linux-eepro100-big-frames.patch" --- eepro100.c Wed Jul 4 16:21:02 2001 +++ eepro100.c.new Sun Sep 2 16:57:41 2001 @@ -499,12 +499,12 @@ static const char i82557_config_cmd[CONFIG_DATA_SIZE] = { 22, 0x08, 0, 0, 0, 0, 0x32, 0x03, 1, /* 1=Use MII 0=Use AUI */ 0, 0x2E, 0, 0x60, 0, - 0xf2, 0x48, 0, 0x40, 0xf2, 0x80, /* 0x40=Force full-duplex */ + 0xf2, 0x48, 0, 0x40, 0xfa, 0x80, /* 0x40=Force full-duplex */ 0x3f, 0x05, }; static const char i82558_config_cmd[CONFIG_DATA_SIZE] = { 22, 0x08, 0, 1, 0, 0, 0x22, 0x03, 1, /* 1=Use MII 0=Use AUI */ 0, 0x2E, 0, 0x60, 0x08, 0x88, - 0x68, 0, 0x40, 0xf2, 0x84, /* Disable FC */ + 0x68, 0, 0x40, 0xfa, 0x84, /* Disable FC */ 0x31, 0x05, }; /* PHY media interface chips. */ --AkbCVLjbJ9qUtAXD-- From bz@riz.pl Mon Mar 18 05:04:01 2002 From: bz@riz.pl (Bartlomiej Zarzecki) Date: Mon Mar 18 05:04:01 2002 Subject: [eepro100] How to make eepro100 to receive pkt > 1514 ? In-Reply-To: <001401c1ce42$88e29a80$a8010101@talent.com> Message-ID: On Mon, 18 Mar 2002, wyb wrote: > I'm working on a firewall project, this firewall is designed to support switch trunk, > such as 802.1q or CISCO isl. So it must be able to receive packet size > 1514. > I changed PKT_BUF_SZ from 1536 to 1572, but it didn't work. Can any give suggesstion ? > Mail answer to me for I dit not subscribe to this list. You have to do this: go to eepro100.c find : const char i82557_config_cmd[22] = change: 0xf2, 0x48, 0, 0x40, 0xf2, 0x80, to: 0xf2, 0x48, 0, 0x40, 0xfa, 0x80, find: const char i82558_config_cmd[22] = { change 0x68, 0, 0x40, 0xf2, 0xBD, to 0x68, 0, 0x40, 0xfa, 0xBD, generally if I am right this is the "init" of the card. changing 0xf2 to 0xfa enables receiving long frames. -- Pozdrawiam, Bartlomiej Zarzecki bz@riz.pl Public PGP Key http://bz.riz.pl/bz.asc From aogden@unocal.com Mon Mar 18 09:13:02 2002 From: aogden@unocal.com (Ogden, Aaron A.) Date: Mon Mar 18 09:13:02 2002 Subject: [eepro100] RE: eepro100 digest, Vol 1 #400 - 1 msg Message-ID: <41C61615CE88D211AA3500805F9FFECE043C115F@renegade.sugarland.unocal.com> Hello Ranjit, You don't need any special drivers for this card, the drivers are already in the kernel... just select DEC Tulip (210x0). I have five of these cards and they work great in every OS I have tried. As far as I know they are some of the fastest 100base-T cards. Best regards, Aaron > -----Original Message----- > From: eepro100-request@scyld.com [SMTP:eepro100-request@scyld.com] > Sent: Sunday, March 17, 2002 11:03 AM > To: eepro100@scyld.com > Subject: eepro100 digest, Vol 1 #400 - 1 msg > > Send eepro100 mailing list submissions to > eepro100@scyld.com > > To subscribe or unsubscribe via the World Wide 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. delaying eth0 initialization!! (Ranjit S) > > --__--__-- > > Message: 1 > Date: Sat, 16 Mar 2002 22:40:49 -0800 (PST) > From: Ranjit S > To: eepro100@scyld.com > Subject: [eepro100] delaying eth0 initialization!! > > HI, > > I have been trying to get my linux red hat 6.1 > installation to detect my network card but i have been > unsuccessful. > The card i have is Linksys LNE100TX Fast Ethernet > Adapter(LNE100TX v4). > > 1st i tried compling the code given in the linksys > installation floppy....but it did not work. > > Then i went to scyld.com and downloaded the necessary > files ....tulip.c,pci-scan.c,pci-scan.h and > kern_compat.h. > > I followed the instructions and complied the code and > installed the drivers as per the given install > command. The code compiled successfully and so did the > commands: > install -m 644 pci-scan.o /lib/modules/`uname -r`/net/ > install -m 644 tulip.o /lib/modules/`uname -r`/net/ > > I was really pleased thinking that NOW the network > card would work but when i rebooted the machine i got > the message during startup as : > > Delaying eth0 initialization [failed] > > I am unable to find any direct solution to this on the > internet. I really hope someone can please help me > find a solution to this. > > Ranjit > > __________________________________________________ > Do You Yahoo!? > Yahoo! Sports - live college hoops coverage > http://sports.yahoo.com/ > > > --__--__-- > > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 > > > End of eepro100 Digest From joseph.t.mroczek@intel.com Mon Mar 18 14:29:01 2002 From: joseph.t.mroczek@intel.com (Mroczek, Joseph T) Date: Mon Mar 18 14:29:01 2002 Subject: [eepro100] How to make eepro100 to receive pkt > 1514 ? Message-ID: <10C8636AE359D4119118009027AE998709BE55A8@FMSMSX34> This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C1CE70.0BB0F510 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit A word of warning. This will fail if you are using an i82557 controller. i82557 does not support the larger 1522 MTU. It will only work on 82558/559/550 and possibly 562/563 controllers. ~joe -----Original Message----- From: Bartlomiej Zarzecki [mailto:bz@riz.pl] Sent: Monday, March 18, 2002 2:04 AM To: wyb Cc: eepro100@scyld.com Subject: Re: [eepro100] How to make eepro100 to receive pkt > 1514 ? On Mon, 18 Mar 2002, wyb wrote: > I'm working on a firewall project, this firewall is designed to support switch trunk, > such as 802.1q or CISCO isl. So it must be able to receive packet size > 1514. > I changed PKT_BUF_SZ from 1536 to 1572, but it didn't work. Can any give suggesstion ? > Mail answer to me for I dit not subscribe to this list. You have to do this: go to eepro100.c find : const char i82557_config_cmd[22] = change: 0xf2, 0x48, 0, 0x40, 0xf2, 0x80, to: 0xf2, 0x48, 0, 0x40, 0xfa, 0x80, find: const char i82558_config_cmd[22] = { change 0x68, 0, 0x40, 0xf2, 0xBD, to 0x68, 0, 0x40, 0xfa, 0xBD, generally if I am right this is the "init" of the card. changing 0xf2 to 0xfa enables receiving long frames. -- Pozdrawiam, Bartlomiej Zarzecki bz@riz.pl Public PGP Key http://bz.riz.pl/bz.asc _______________________________________________ eepro100 mailing list eepro100@scyld.com http://www.scyld.com/mailman/listinfo/eepro100 ------=_NextPart_000_0000_01C1CE70.0BB0F510 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFvzCCAo4w ggH3oAMCAQICAwTI2DANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDUxMDIzMDM0M1oXDTAyMDUxMDIzMDM0M1owTDEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEpMCcGCSqGSIb3DQEJARYaam9zZXBoLnQubXJvY3pla0BpbnRlbC5j b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALGbKjcIssEC6xteQxlAOfiRpWNYP0QNnX2s xk7AyLOVTMWCVp2Aa4xXB8ira+9F0l3jtiwiV5O2ucGR7aQCQfROKhSS45mIknXgtTir9e8FHwZl vuVYsbeppXUTZGlqLBcXyACwmM8E/sHNX3NwqKecabpFzTswQaQXoeG272+jAgMBAAGjNzA1MCUG A1UdEQQeMByBGmpvc2VwaC50Lm1yb2N6ZWtAaW50ZWwuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZI hvcNAQEEBQADgYEASG8nl40VCz5rEf72knoMmY+Sabz12R3MdBYVjzVRvjjUjxSnQIVW9D9UAnG6 610+JMbOr5qW0o/WF3zJFYHtgzRVm85KeNsbqiUZpIfEaSoOO6bq5O0YyUGnCM92TL5hXyzQI36s XNe3vjPkNr5CBGOwJi+EW77B5zVvzckoy7MwggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUA MIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNl cnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAw WhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz6 3K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzp q+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNV HQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQf uIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX 7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gxggKaMIIClgIBATCBmjCB kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMEyNgwCQYFKw4DAhoFAKCCAVUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwMzE4MTkyODM3WjAjBgkq hkiG9w0BCQQxFgQUm5fJFyMbqw+vUraR8cnqdWJ1dZYwSAYJKoZIhvcNAQkPMTswOTAKBggqhkiG 9w0DBzAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqwYJKwYB BAGCNxAEMYGdMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2Vy dmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwTI2DANBgkq hkiG9w0BAQEFAASBgEfcaxLCKh6OHA3YgKoryf14RMG+VOZWinO9szroJIlXdnfJ6/xpRsgUYEsu VZTEYKjoD01I5agdKORgkmmzIjz7AS/FFnee4hOVjJ9+daZzJxwUM0zg1YvHnGd1Z21Ijeajap7O yNmDu7FylroJ6rP4mdgww6p1uXjSi+E30CWbAAAAAAAA ------=_NextPart_000_0000_01C1CE70.0BB0F510-- From bz@riz.pl Mon Mar 18 14:38:01 2002 From: bz@riz.pl (Bartlomiej Zarzecki) Date: Mon Mar 18 14:38:01 2002 Subject: [eepro100] How to make eepro100 to receive pkt > 1514 ? In-Reply-To: <10C8636AE359D4119118009027AE998709BE55A8@FMSMSX34> Message-ID: On Mon, 18 Mar 2002, Mroczek, Joseph T wrote: > A word of warning. This will fail if you are using an i82557 controller. > i82557 does not support the larger 1522 MTU. It will only work on > 82558/559/550 and possibly 562/563 controllers. I know. i82557_config_cmd doesnt mean it is exactly a 82557. If I am right chips newer than 82557 are detected as for example Intel rev 8 of 556 under linux. -- Pozdrawiam, Bartlomiej Zarzecki bz@riz.pl Public PGP Key http://bz.riz.pl/bz.asc From Shanan.Levin@comverse.com Tue Mar 19 16:13:02 2002 From: Shanan.Levin@comverse.com (Levin, Shanan) Date: Tue Mar 19 16:13:02 2002 Subject: [eepro100] mii-diag compile question Message-ID: <6B1DF6EEBA51D31182F2009027404368048E188E@mail-in.comverse.com> Hello, I'm not quite sure where to turn with this question. I'm trying to simply compile mii-diag.c (from Donald Becker) on a SCO UnixWare 7.1.1 box and after doing some minor changes to get it to work with the SCO C libs this is where I'm stuck: I had to copy the getopts.h file from GNU C libs (from a Red Hat linux box) because it doesn't seem to exist in SCO C libs. My main concern is getopt_long, I can't find it defined anywhere and it has stopped me in my tracks. If someone could please tell me where getopt_long is actually defined, that would at least be a starting point toward my compilation of mii-diag on a SCO UnixWare box. any leads would be helpful. Thanks in advance! Shanan Levin $ uname -a UnixWare uw711-serv 5 7.1.1 i386 x86at SCO UNIX_SVR5 $ /usr/local/bin/gcc -Wall -Wstrict-prototypes -O mii-diag.c -DLIBMII libmii.c -o mii-diag mii-diag.c: In function `parse_advertise': mii-diag.c:313: warning: implicit declaration of function `strcasecmp' Undefined first referenced symbol in file getopt_long /var/tmp/cca003SW1.o UX:ld: ERROR: Symbol referencing errors. No output written to mii-diag From becker@scyld.com Thu Mar 21 11:36:02 2002 From: becker@scyld.com (Donald Becker) Date: Thu Mar 21 11:36:02 2002 Subject: [eepro100] RE: eepro100 digest, Vol 1 #400 - 1 msg In-Reply-To: <41C61615CE88D211AA3500805F9FFECE043C115F@renegade.sugarland.unocal.com> Message-ID: On Mon, 18 Mar 2002, Ogden, Aaron A. wrote: > > The card i have is Linksys LNE100TX Fast Ethernet > > Adapter(LNE100TX v4). > You don't need any special drivers for this card, the drivers are already in > the kernel... just select DEC Tulip (210x0). I have five of these cards and > they work great in every OS I have tried. As far as I know they are some of > the fastest 100base-T cards. Incorrect. This is an ADMtek Comet card. Most older tulip drivers (and the one in the kernel is based on an old version) won't support this chip. -- 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 Thu Mar 21 11:39:01 2002 From: becker@scyld.com (Donald Becker) Date: Thu Mar 21 11:39:01 2002 Subject: [eepro100] How to make eepro100 to receive pkt > 1514 ? In-Reply-To: <20020318094122.GR29400@opticalaccess.com> Message-ID: On Mon, 18 Mar 2002, Michael Rozhavsky wrote: > Subject: Re: [eepro100] How to make eepro100 to receive pkt > 1514 ? > > Attached patch is for 2.4.9 but should work with later kernels also. Please don't put this patch into a general purpose kernel. It disables all Rx length checking. -- 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 aogden@unocal.com Thu Mar 21 11:58:01 2002 From: aogden@unocal.com (Ogden, Aaron A.) Date: Thu Mar 21 11:58:01 2002 Subject: [eepro100] RE: eepro100 digest, Vol 1 #400 - 1 msg Message-ID: <41C61615CE88D211AA3500805F9FFECE043C1171@renegade.sugarland.unocal.com> Vanilla 2.4.x seems to support these using the Tulip driver... mine show up as ADMtek Comet cards, the tulip driver is running them just fine. I had an older LNE100TX (v3?) that worked fine with the Tulip driver as well. I know this is off-topic, I was just trying to help. --aaron > -----Original Message----- > From: Donald Becker [SMTP:becker@scyld.com] > Sent: Monday, March 18, 2002 11:43 AM > To: Ogden, Aaron A. > Cc: 'eepro100@scyld.com' > Subject: Re: [eepro100] RE: eepro100 digest, Vol 1 #400 - 1 msg > > On Mon, 18 Mar 2002, Ogden, Aaron A. wrote: > > > > The card i have is Linksys LNE100TX Fast Ethernet > > > Adapter(LNE100TX v4). > > > You don't need any special drivers for this card, the drivers are > already in > > the kernel... just select DEC Tulip (210x0). I have five of these cards > and > > they work great in every OS I have tried. As far as I know they are > some of > > the fastest 100base-T cards. > > Incorrect. This is an ADMtek Comet card. Most older tulip drivers (and > the one in the kernel is based on an old version) won't support this chip. > > > -- > 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 asingh@exscape.net Thu Mar 21 16:49:02 2002 From: asingh@exscape.net (Amrik Singh) Date: Thu Mar 21 16:49:02 2002 Subject: [eepro100] eth0: Transmit timed out: status f048 0000 at 1614128871/1614128899 command 000ca000. Message-ID: <084201c1d13b$6fa22ee0$02f8a53f@xcess> This is a multi-part message in MIME format. ------=_NextPart_000_083F_01C1D0F8.61512820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We're hosting this dual 1ghz.. w/1gb of ram with smp kernel. 2.4.7-10smp #1 SMP Thu Sep 6 17:09:31 EDT 2001 i686 unknown Every week, it crashes.. as it can pull/push upto 50mbits/s and then we = have to reboot to fix the issue. Please help me. This thing also did with other 3com 10/100 nic we put = in. Thing to be noted is.. all of them on auto select as far as = speed... so i'm wondering perhaps that Nway messes it up and it needs to = be set manually to 100mbits full duplex ? here is other useful info. Mar 21 12:23:10 server kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 21 12:23:10 server kernel: eth0: Transmit timed out: status f048 = 0000 at 1614128871/1614128899 command 000ca000. Mar 21 12:23:14 server kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 21 12:23:14 server kernel: eth0: Transmit timed out: status f048 = 0000 at 1614128899/1614128929 command 0001a000. Mar 21 12:23:18 server kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 21 12:23:18 server kernel: eth0: Transmit timed out: status f048 = 0000 at 1614128929/1614128959 command 0001a000. Mar 21 12:23:22 server kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 21 12:23:22 server kernel: eth0: Transmit timed out: status f048 = 0000 at 1614128959/1614128989 command 0001a000. lsmod Module Size Used by autofs 12068 0 (autoclean) (unused) eepro100 18128 1 ext3 67728 2 jbd 44480 2 [ext3] [root@server progs-corey]# ./pci-config pci-config.c:v2.02 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Device #1 at bus 0 device/function 0/0, 06911106. Device #2 at bus 0 device/function 1/0, 85981106. Device #3 at bus 0 device/function 7/0, 06861106. Device #4 at bus 0 device/function 7/1, 05711106. Device #5 at bus 0 device/function 7/4, 30571106. Device #6 at bus 0 device/function 9/0, 8a015333. Device #7 at bus 0 device/function 11/0, 12298086. Thanks Amrik Singh eXscape Communications Inc. ------=_NextPart_000_083F_01C1D0F8.61512820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We're hosting this dual 1ghz.. w/1gb of = ram with=20 smp kernel.

2.4.7-10smp #1 SMP Thu Sep 6 17:09:31 = EDT 2001 i686=20 unknown

Every week, it crashes.. as it can = pull/push upto=20 50mbits/s and then we have to reboot to fix the issue.

Please help me. This thing also = did with=20 other 3com 10/100 nic we put in. Thing to be noted is.. all of = them on=20 auto select as far as speed... so i'm wondering perhaps that Nway messes = it up=20 and it needs to be set manually to 100mbits full duplex ?

here is other useful info.

Mar 21 12:23:10 server kernel: NETDEV = WATCHDOG:=20 eth0: transmit timed out
Mar 21 12:23:10 server kernel: eth0: = Transmit timed=20 out: status f048 0000 at 1614128871/1614128899 command = 000ca000.
Mar 21=20 12:23:14 server kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar = 21=20 12:23:14 server kernel: eth0: Transmit timed out: status f048 0000 = at=20 1614128899/1614128929 command 0001a000.
Mar 21 12:23:18 server = kernel: NETDEV=20 WATCHDOG: eth0: transmit timed out
Mar 21 12:23:18 server kernel: = eth0:=20 Transmit timed out: status f048 0000 at 1614128929/1614128959 = command=20 0001a000.
Mar 21 12:23:22 server kernel: NETDEV WATCHDOG: eth0: = transmit=20 timed out
Mar 21 12:23:22 server kernel: eth0: Transmit timed out: = status=20 f048 0000 at 1614128959/1614128989 command = 0001a000.

lsmod

Module         &nbs= p;       =20 Size Used=20 by
autofs          &= nbsp;     =20 12068   0 (autoclean)=20 (unused)
eepro100         = ;     =20 18128  =20 1
ext3          &nbs= p;       =20 67728  =20 2
jbd           = ;        =20 44480   2 [ext3]

[root@server progs-corey]#=20 ./pci-config
pci-config.c:v2.02 1/8/2001 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/i= ndex.html
Device=20 #1 at bus 0 device/function 0/0, 06911106.
Device #2 at bus 0 = device/function=20 1/0, 85981106.
Device #3 at bus 0 device/function 7/0, = 06861106.
Device #4=20 at bus 0 device/function 7/1, 05711106.
Device=20 #5 at bus 0 device/function 7/4, 30571106.
Device #6 at bus 0 = device/function=20 9/0, 8a015333.
Device #7 at bus 0 device/function 11/0,=20 12298086.

Thanks

Amrik Singh

eXscape Communications = Inc.

------=_NextPart_000_083F_01C1D0F8.61512820-- From John.Wilson@savvis.net Thu Mar 21 17:33:00 2002 From: John.Wilson@savvis.net (Wilson, John) Date: Thu Mar 21 17:33:00 2002 Subject: [eepro100] eth0: Transmit timed out: status f048 0000 at 161 4128871/1614128899 command 000ca000. 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_01C1D127.C64530BC Content-Type: text/plain; charset="iso-8859-1" Amrik, I had a similar problem... not sure if it was really the driver or the network traffic. I was running Samba and a VPRN router (Nortel Shasta) was responding with a ICMP broadcast error about every 3-5 min. Still not sure what the problem was, as I just shutdown smb. This is not the ideal solution I was looking for, as I use samba quite a bit. But I do see these timeout messages similar to what you have here. I'm certain there is something on the network related to the problem, but I've not had time to track it down yet. Hope this helps. j d wilson -----Original Message----- From: Amrik Singh [mailto:asingh@exscape.net] Sent: Thursday, March 21, 2002 18:50 To: eepro100@scyld.com Subject: [eepro100] eth0: Transmit timed out: status f048 0000 at 1614128871/1614128899 command 000ca000. We're hosting this dual 1ghz.. w/1gb of ram with smp kernel. 2.4.7-10smp #1 SMP Thu Sep 6 17:09:31 EDT 2001 i686 unknown Every week, it crashes.. as it can pull/push upto 50mbits/s and then we have to reboot to fix the issue. Please help me. This thing also did with other 3com 10/100 nic we put in. Thing to be noted is.. all of them on auto select as far as speed... so i'm wondering perhaps that Nway messes it up and it needs to be set manually to 100mbits full duplex ? here is other useful info. Mar 21 12:23:10 server kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 21 12:23:10 server kernel: eth0: Transmit timed out: status f048 0000 at 1614128871/1614128899 command 000ca000. Mar 21 12:23:14 server kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 21 12:23:14 server kernel: eth0: Transmit timed out: status f048 0000 at 1614128899/1614128929 command 0001a000. Mar 21 12:23:18 server kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 21 12:23:18 server kernel: eth0: Transmit timed out: status f048 0000 at 1614128929/1614128959 command 0001a000. Mar 21 12:23:22 server kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 21 12:23:22 server kernel: eth0: Transmit timed out: status f048 0000 at 1614128959/1614128989 command 0001a000. lsmod Module Size Used by autofs 12068 0 (autoclean) (unused) eepro100 18128 1 ext3 67728 2 jbd 44480 2 [ext3] [root@server progs-corey]# ./pci-config pci-config.c:v2.02 1/8/2001 Donald Becker ( becker@scyld.com ) http://www.scyld.com/diag/index.html Device #1 at bus 0 device/function 0/0, 06911106. Device #2 at bus 0 device/function 1/0, 85981106. Device #3 at bus 0 device/function 7/0, 06861106. Device #4 at bus 0 device/function 7/1, 05711106. Device #5 at bus 0 device/function 7/4, 30571106. Device #6 at bus 0 device/function 9/0, 8a015333. Device #7 at bus 0 device/function 11/0, 12298086. Thanks Amrik Singh eXscape Communications Inc. ------_=_NextPart_001_01C1D127.C64530BC Content-Type: text/html; charset="iso-8859-1"

Amrik,

I had a similar problem... not sure if it was really the driver or the network traffic. I was running Samba and a VPRN router (Nortel Shasta) was responding with a ICMP broadcast error about every 3-5 min. Still not sure what the problem was, as I just shutdown smb. This is not the ideal solution I was looking for, as I use samba quite a bit. But I do see these timeout messages similar to what you have here. I'm certain there is something on the network related to the problem, but I've not had time to track it down yet. Hope this helps.

j d wilson

-----Original Message-----
From: Amrik Singh [mailto:asingh@exscape.net]
Sent: Thursday, March 21, 2002 18:50
To: eepro100@scyld.com
Subject: [eepro100] eth0: Transmit timed out: status f048 0000 at 1614128871/1614128899 command 000ca000.

We're hosting this dual 1ghz.. w/1gb of ram with smp kernel.

2.4.7-10smp #1 SMP Thu Sep 6 17:09:31 EDT 2001 i686 unknown

Every week, it crashes.. as it can pull/push upto 50mbits/s and then we have to reboot to fix the issue.

Please help me. This thing also did with other 3com 10/100 nic we put in. Thing to be noted is.. all of them on auto select as far as speed... so i'm wondering perhaps that Nway messes it up and it needs to be set manually to 100mbits full duplex ?

here is other useful info.

Mar 21 12:23:10 server kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 21 12:23:10 server kernel: eth0: Transmit timed out: status f048 0000 at 1614128871/1614128899 command 000ca000.
Mar 21 12:23:14 server kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 21 12:23:14 server kernel: eth0: Transmit timed out: status f048 0000 at 1614128899/1614128929 command 0001a000.
Mar 21 12:23:18 server kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 21 12:23:18 server kernel: eth0: Transmit timed out: status f048 0000 at 1614128929/1614128959 command 0001a000.
Mar 21 12:23:22 server kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 21 12:23:22 server kernel: eth0: Transmit timed out: status f048 0000 at 1614128959/1614128989 command 0001a000.

lsmod

Module                  Size Used by
autofs                 12068   0 (autoclean) (unused)
eepro100               18128   1
ext3                   67728   2
jbd                    44480   2 [ext3]

[root@server progs-corey]# ./pci-config
pci-config.c:v2.02 1/8/2001 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Device #1 at bus 0 device/function 0/0, 06911106.
Device #2 at bus 0 device/function 1/0, 85981106.
Device #3 at bus 0 device/function 7/0, 06861106.
Device #4 at bus 0 device/function 7/1, 05711106.
Device #5 at bus 0 device/function 7/4, 30571106.
Device #6 at bus 0 device/function 9/0, 8a015333.
Device #7 at bus 0 device/function 11/0, 12298086.

Thanks

Amrik Singh

eXscape Communications Inc.

------_=_NextPart_001_01C1D127.C64530BC-- From asingh@exscape.net Thu Mar 21 19:55:00 2002 From: asingh@exscape.net (Amrik Singh) Date: Thu Mar 21 19:55:00 2002 Subject: [eepro100] eth0: Transmit timed out: status f048 0000 at 1614128871/1614128899 command 000ca000. References: Message-ID: <08fb01c1d155$b87b2cb0$02f8a53f@xcess> This is a multi-part message in MIME format. ------=_NextPart_000_08F8_01C1D112.AA103550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the reply. I'm begining to think if I should force it to stay at 100mbits full = duplex via option=3D0x30 i believe. We have changed to all the = different intel 10/100s we had.. we still see this problem. Point to be noted though. These cards were also used in our fbsd = machines.. where they passed close to 100mbits to peaks and for very = long time. I don't know what could be causing it to mess up in linux. = When I tried the 3com 10/100, same thing as well (i think it was 905B.. = ). They only worked for 3 days and then the system timed out with = them.. intel cards seem to last longer before they timeout. Various = 3com cards were put in as part of trouble shooting method.. including = various things from module driver to statically linked.. including = changing the switches.. to cat5 cabling.. and we're still having that. = However, another point to be noted. Switches are on Nway.. so they = negotiate to 100mbits full duplex with the card. Could it be this ? (we = haven't tested this yet and is the only thing we haven't tested) My thinking on this is.. they crap out and eth0 is not able to negotiate = 100mbits after passing large amount of data. I think my solution may be = to force 100mbits in full duplex mode. However, I would like to know = what your input on this... because we can not test this in a live server = environment. Amrik Amrik, I had a similar problem... not sure if it was really the driver or the = network traffic. I was running Samba and a VPRN router (Nortel Shasta) = was responding with a ICMP broadcast error about every 3-5 min. Still = not sure what the problem was, as I just shutdown smb. This is not the = ideal solution I was looking for, as I use samba quite a bit. But I do = see these timeout messages similar to what you have here. I'm certain = there is something on the network related to the problem, but I've not = had time to track it down yet. Hope this helps. j d wilson -----Original Message----- From: Amrik Singh [mailto:asingh@exscape.net] Sent: Thursday, March 21, 2002 18:50 To: eepro100@scyld.com Subject: [eepro100] eth0: Transmit timed out: status f048 0000 at = 1614128871/1614128899 command 000ca000. We're hosting this dual 1ghz.. w/1gb of ram with smp kernel. 2.4.7-10smp #1 SMP Thu Sep 6 17:09:31 EDT 2001 i686 unknown Every week, it crashes.. as it can pull/push upto 50mbits/s and then = we have to reboot to fix the issue. Please help me. This thing also did with other 3com 10/100 nic we = put in. Thing to be noted is.. all of them on auto select as far as = speed... so i'm wondering perhaps that Nway messes it up and it needs to = be set manually to 100mbits full duplex ? here is other useful info. Mar 21 12:23:10 server kernel: NETDEV WATCHDOG: eth0: transmit timed = out Mar 21 12:23:10 server kernel: eth0: Transmit timed out: status f048 = 0000 at 1614128871/1614128899 command 000ca000. Mar 21 12:23:14 server kernel: NETDEV WATCHDOG: eth0: transmit timed = out Mar 21 12:23:14 server kernel: eth0: Transmit timed out: status f048 = 0000 at 1614128899/1614128929 command 0001a000. Mar 21 12:23:18 server kernel: NETDEV WATCHDOG: eth0: transmit timed = out Mar 21 12:23:18 server kernel: eth0: Transmit timed out: status f048 = 0000 at 1614128929/1614128959 command 0001a000. Mar 21 12:23:22 server kernel: NETDEV WATCHDOG: eth0: transmit timed = out Mar 21 12:23:22 server kernel: eth0: Transmit timed out: status f048 = 0000 at 1614128959/1614128989 command 0001a000. lsmod Module Size Used by autofs 12068 0 (autoclean) (unused) eepro100 18128 1 ext3 67728 2 jbd 44480 2 [ext3] [root@server progs-corey]# ./pci-config pci-config.c:v2.02 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Device #1 at bus 0 device/function 0/0, 06911106. Device #2 at bus 0 device/function 1/0, 85981106. Device #3 at bus 0 device/function 7/0, 06861106. Device #4 at bus 0 device/function 7/1, 05711106. Device #5 at bus 0 device/function 7/4, 30571106. Device #6 at bus 0 device/function 9/0, 8a015333. Device #7 at bus 0 device/function 11/0, 12298086. Thanks Amrik Singh eXscape Communications Inc. ------=_NextPart_000_08F8_01C1D112.AA103550 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks for the reply.

I'm begining to think if I should force = it to stay=20 at 100mbits full duplex via option=3D0x30 i believe. We have = changed to all=20 the different intel 10/100s we had.. we still see this = problem.

Point to be noted though. These = cards were=20 also used in our fbsd machines.. where they passed close to 100mbits to = peaks=20 and for very long time. I don't know what could be causing it to = mess up=20 in linux. When I tried the 3com 10/100, same thing as well (i = think=20 it was 905B.. ). They only worked for 3 days and then the system = timed out=20 with them.. intel cards seem to last longer before they = timeout. =20 Various 3com cards were put in as part of trouble shooting method.. = including=20 various things from module driver to statically linked.. including = changing the=20 switches.. to cat5 cabling.. and we're still having that. However, = another=20 point to be noted. Switches are on Nway.. so they negotiate to = 100mbits=20 full duplex with the card. Could it be this ? (we haven't tested = this yet=20 and is the only thing we haven't tested)

My thinking on this is.. they crap out = and eth0 is=20 not able to negotiate 100mbits after passing large amount of data. = I think=20 my solution may be to force 100mbits in full duplex mode. However, = I would=20 like to know what your input on this... because we can not test this in = a live=20 server environment.

Amrik

Amrik,

I=20 had a similar problem... not sure if it was really the driver or the = network=20 traffic. I was running Samba and a VPRN router (Nortel Shasta) = was=20 responding with a ICMP broadcast error about every 3-5 min. = Still not=20 sure what the problem was, as I just shutdown smb. This is not = the ideal=20 solution I was looking for, as I use samba quite a bit. But I do = see=20 these timeout messages similar to what you have here. I'm = certain there=20 is something on the network related to the problem, but I've not had = time to=20 track it down yet. Hope this helps.

j=20 d wilson

-----Original Message-----
From: Amrik Singh=20 [mailto:asingh@exscape.net]
Sent: Thursday, March 21, 2002 = 18:50
To: eepro100@scyld.com
Subject: [eepro100] = eth0:=20 Transmit timed out: status f048 0000 at 1614128871/1614128899 = command=20 000ca000.

We're hosting this dual 1ghz.. = w/1gb of ram=20 with smp kernel.

2.4.7-10smp #1 SMP Thu Sep 6 = 17:09:31 EDT 2001=20 i686 unknown

Every week, it crashes.. as it can = pull/push=20 upto 50mbits/s and then we have to reboot to fix the = issue.

Please help me. This thing = also did with=20 other 3com 10/100 nic we put in. Thing to be noted is.. all of = them on=20 auto select as far as speed... so i'm wondering perhaps that Nway = messes it=20 up and it needs to be set manually to 100mbits full duplex = ?

here is other useful = info.

Mar 21 12:23:10 server kernel: = NETDEV WATCHDOG:=20 eth0: transmit timed out
Mar 21 12:23:10 server kernel: eth0: = Transmit=20 timed out: status f048 0000 at 1614128871/1614128899 command=20 000ca000.
Mar 21 12:23:14 server kernel: NETDEV WATCHDOG: eth0: = transmit=20 timed out
Mar 21 12:23:14 server kernel: eth0: Transmit timed = out: status=20 f048 0000 at 1614128899/1614128929 command 0001a000.
Mar 21 = 12:23:18 server kernel: NETDEV WATCHDOG: eth0: transmit timed = out
Mar 21=20 12:23:18 server kernel: eth0: Transmit timed out: status f048 = 0000 at=20 1614128929/1614128959 command 0001a000.
Mar 21 12:23:22 server = kernel:=20 NETDEV WATCHDOG: eth0: transmit timed out
Mar 21 12:23:22 server = kernel:=20 eth0: Transmit timed out: status f048 0000 at = 1614128959/1614128989=20 command 0001a000.

lsmod

Module         &nbs= p;       =20 Size Used=20 = by
autofs          &= nbsp;     =20 12068   0 (autoclean)=20 = (unused)
eepro100         = ;     =20 18128  =20 = 1
ext3          &nbs= p;       =20 67728  =20 = 2
jbd           = ;        =20 44480   2 [ext3]

[root@server progs-corey]#=20 ./pci-config
pci-config.c:v2.02 1/8/2001 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/i= ndex.html
Device=20 #1 at bus 0 device/function 0/0, 06911106.
Device #2 at bus 0=20 device/function 1/0, 85981106.
Device #3 at bus 0 device/function = 7/0,=20 06861106.
Device #4 at bus 0 device/function 7/1, = 05711106.
Device #5 at bus 0 device/function 7/4,=20 30571106.
Device #6 at bus 0 device/function 9/0, = 8a015333.
Device #7=20 at bus 0 device/function 11/0, 12298086.

Thanks

Amrik Singh

eXscape Communications = Inc.

------=_NextPart_000_08F8_01C1D112.AA103550-- From flygong@yahoo.com Thu Mar 21 23:57:02 2002 From: flygong@yahoo.com (Bergs) Date: Thu Mar 21 23:57:02 2002 Subject: [eepro100] eepro100 Performance Message-ID: <20020322045600.58377.qmail@web14507.mail.yahoo.com> Hello Sir: Sorry for I abort your work. I find what you say in following text. Now the same problem puzzle me.I want to improve the IP throughput of linux firewall that run a 2.2.14 kernel. I use 3 intel 82559 ethernet chip in my linux box.I have tested performance of this linux box by device IXIA.But get a very bad result. To me supprise,when the ip packet size is about 512B,I get the best test result. The bigger or smaller than 512B,the low throughput I get. I think maybe I can do something on ethernet driver. I donn't know which driver I should select between e100 of intel and eepro100. May you give some advice ? Thanks a lot . Bergs ====================================== Well try connecting more then one card(NIC), I connected 4 NIC's and got 400Mbps throughput (in and out), that means that the pci-bus and the driver handled 800Mbps, 400Mbps receive and 400Mbps transmit, off course I used 66/64 pci-bus. If you do not know what is ixia try looking at their site. Any more silly questions any one?. __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ From flygong@yahoo.com Thu Mar 21 23:59:20 2002 From: flygong@yahoo.com (Bergs) Date: Thu Mar 21 23:59:20 2002 Subject: [eepro100] eepro100 Performance Message-ID: <20020322045608.35747.qmail@web14508.mail.yahoo.com> Hello Sir: Sorry for I abort your work. I find what you say in following text. Now the same problem puzzle me.I want to improve the IP throughput of linux firewall that run a 2.2.14 kernel. I use 3 intel 82559 ethernet chip in my linux box.I have tested performance of this linux box by device IXIA.But get a very bad result. To me supprise,when the ip packet size is about 512B,I get the best test result. The bigger or smaller than 512B,the low throughput I get. I think maybe I can do something on ethernet driver. I donn't know which driver I should select between e100 of intel and eepro100. May you give some advice ? Thanks a lot . Bergs ====================================== Well try connecting more then one card(NIC), I connected 4 NIC's and got 400Mbps throughput (in and out), that means that the pci-bus and the driver handled 800Mbps, 400Mbps receive and 400Mbps transmit, off course I used 66/64 pci-bus. If you do not know what is ixia try looking at their site. Any more silly questions any one?. __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ From John.Wilson@savvis.net Mon Mar 25 15:04:01 2002 From: John.Wilson@savvis.net (Wilson, John) Date: Mon Mar 25 15:04:01 2002 Subject: [eepro100] error building netdrivers-3.1 Message-ID: eepro100 group, I'm having some trouble building the netdrivers from the src.rpm file. At one point this worked just fine, but I'm not sure what I'm doing wrong this time. I've re-booted the host and running: Linux sla1.dev.savvis.net 2.4.9-31 #1 Tue Feb 26 06:53:37 EST 2002 i686 unknown Following the directions, I installed (rpm -i) the netdrivers-3.1-1.src.rpm file and then tried to run: # cd /usr/src/redhat # rpm -bb SPECS/netdrivers.spec I'm getting this error: [...] Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.76042 + umask 022 + cd /usr/src/redhat/BUILD + cd netdrivers-3.1 + make all gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -I/lib/modules/2.4.9-31/build/include -pipe -fno-strength-reduce -DMODVERSIONS -c -o pci-skeleton.o pci-skeleton.c In file included from pci-skeleton.c:93: /lib/modules/2.4.9-31/build/include/linux/modversions.h:8:39: linux/modules/Divas_mod.ver: No such file or directory In file included from pci-skeleton.c:93: /lib/modules/2.4.9-31/build/include/linux/modversions.h:17:40: linux/modules/af_netlink.ver: No such file or directory /lib/modules/2.4.9-31/build/include/linux/modversions.h:18:36: linux/modules/af_spx.ver: No such file or directory These .ver files are not in the /usr/src/linux-2.4.9-31/include/linux/modules directory. I have another file system in which these files exist, but some of them are of zero (0) size. I'm not sure how they are created or why I don't have them. I'm assuming there is some step that I missed when I installed the 2.4.9-31 kernel. If anyone can help, it would be much appreciated... I've not been able to determine why I don't have these missing .ver files. thanks in advanced, j d wilson From becker@scyld.com Mon Mar 25 15:48:02 2002 From: becker@scyld.com (Donald Becker) Date: Mon Mar 25 15:48:02 2002 Subject: [eepro100] error building netdrivers-3.1 In-Reply-To: Message-ID: On Mon, 25 Mar 2002, Wilson, John wrote: > eepro100 group, > I'm having some trouble building the netdrivers from the src.rpm file. > At one point this worked just fine, but I'm not sure what I'm doing wrong > this time. I've re-booted the host and running: > > Linux sla1.dev.savvis.net 2.4.9-31 #1 Tue Feb 26 06:53:37 EST 2002 > i686 unknown > > Following the directions, I installed (rpm -i) the netdrivers-3.1-1.src.rpm > file and then tried to run: > > # cd /usr/src/redhat > # rpm -bb SPECS/netdrivers.spec > > In file included from pci-skeleton.c:93: > /lib/modules/2.4.9-31/build/include/linux/modversions.h:8:39: > linux/modules/Divas_mod.ver: No such file or directory This is the module version file from an obscure driver... > In file included from pci-skeleton.c:93: > /lib/modules/2.4.9-31/build/include/linux/modversions.h:17:40: > linux/modules/af_netlink.ver: No such file or directory This is from "Address Family netlink", the Linux "netlink" module. > These .ver files are not in the > /usr/src/linux-2.4.9-31/include/linux/modules directory. I have another > file system in which these files exist, but some of them are of zero (0) > size. I'm not sure how they are created or why I don't have them. I'm > assuming there is some step that I missed when I installed the 2.4.9-31 > kernel. The "*.ver" files are created when you build a kernel with module versioning enabled. If you are missing them they were either accidentally deleted, or you are mixing the header files from different kernel builds. For some distributions (e.g. Red Hat 7.2) you must install the kernel-source package. Confusingly the "kernel-headers" package does not have the headers for your kernel, only the Linux-specific headers headers needed for glibc. -- 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 lbell@essex.ac.uk Tue Mar 26 04:23:00 2002 From: lbell@essex.ac.uk (Bell, Leslie) Date: Tue Mar 26 04:23:00 2002 Subject: [eepro100] eth0: can't fill rx buffer (force 0)! and (force 1) as sertion failed Message-ID: <773A7B88FE13D6119C7B009027D3A56A3B5404@sernt13.essex.ac.uk> Hello: I am new to this mailing list and hope that my mail will get noticed. I had a machine crash twice yesterday. It was like this: Mar 24 07:22:52 serlinux02 kernel: Linux version 2.4.17-PENTIUMII-SMP-2 (root@serlinux04.ess ex.ac.uk) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #63 SMP Thu Feb 14 12:50:00 GMT 2002 Mar 24 07:23:00 serlinux02 kernel: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.g sfc.nasa.gov/linux/drivers/eepro100.html Mar 24 07:23:00 serlinux02 kernel: eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andr ey V. Savochkin and others Mar 25 12:42:07 serlinux02 kernel: eth0: can't fill rx buffer (force 0)! Mar 25 12:42:08 serlinux02 kernel: eth0: can't fill rx buffer (force 0)! Mar 25 12:42:08 serlinux02 kernel: eth0: can't fill rx buffer (force 1)! Mar 25 12:42:08 serlinux02 last message repeated 5 times Mar 25 12:42:08 serlinux02 kernel: eth0: can't fill rx buffer (force 0)! Mar 25 12:42:09 serlinux02 kernel: KERNEL: assertion (flags&MSG_PEEK) failed at tcp.c(1463):tcp_recvmsg Mar 25 12:42:09 serlinux02 kernel: recvmsg bug: copied 54AB7A89 seq 54AB8031 Mar 25 12:42:09 serlinux02 kernel: KERNEL: assertion (flags&MSG_PEEK) failed at tcp.c(1463):tcp_recvmsg Mar 25 12:48:05 serlinux02 squid[714]: TCP connection to wwwcache1.essex.ac.uk/8 080 failed ( this message appears in a number of places) Mar 25 12:48:25 serlinux02 ntpd[560]: synchronisation lost Mar 25 12:59:35 serlinux02 kernel: eth0: card reports no resources. Mar 25 12:59:40 serlinux02 last message repeated 64 times some messages like the above reported last message repeated over 3000 times. Is this a memory problem? We doubled the memory in this computer to 771232 K a few days before the crash. Following a newsgroup message, I thought of tweaking /proc/sys/vm/freepages but the file does not exist. The computer has scsi disks. Leslie Bell, Systems Programmer, Web Support Unit University of Essex, Colchester CO4 3SQ U.K. E-mail: mailto:lbell@essex.ac.uk. Tel:+44 (0)1206 873628. web authors url: http://www2.essex.ac.uk/wag web support unit url: http://www2.essex.ac.uk/wag/wsu From lbell@essex.ac.uk Tue Mar 26 04:37:01 2002 From: lbell@essex.ac.uk (Bell, Leslie) Date: Tue Mar 26 04:37:01 2002 Subject: [eepro100] eth0: can't fill rx buffer (force 0)! and (force 1) as sertion failed Message-ID: <773A7B88FE13D6119C7B009027D3A56A3B5406@sernt13.essex.ac.uk> Hello: I am new to this mailing list and hope that my mail will get noticed. I had a machine crash twice yesterday. It was like this: Mar 24 07:22:52 serlinux02 kernel: Linux version 2.4.17-PENTIUMII-SMP-2 (root@serlinux04.ess ex.ac.uk) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #63 SMP Thu Feb 14 12:50:00 GMT 2002 Mar 24 07:23:00 serlinux02 kernel: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.g sfc.nasa.gov/linux/drivers/eepro100.html Mar 24 07:23:00 serlinux02 kernel: eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andr ey V. Savochkin and others Mar 25 12:42:07 serlinux02 kernel: eth0: can't fill rx buffer (force 0)! Mar 25 12:42:08 serlinux02 kernel: eth0: can't fill rx buffer (force 0)! Mar 25 12:42:08 serlinux02 kernel: eth0: can't fill rx buffer (force 1)! Mar 25 12:42:08 serlinux02 last message repeated 5 times Mar 25 12:42:08 serlinux02 kernel: eth0: can't fill rx buffer (force 0)! Mar 25 12:42:09 serlinux02 kernel: KERNEL: assertion (flags&MSG_PEEK) failed at tcp.c(1463):tcp_recvmsg Mar 25 12:42:09 serlinux02 kernel: recvmsg bug: copied 54AB7A89 seq 54AB8031 Mar 25 12:42:09 serlinux02 kernel: KERNEL: assertion (flags&MSG_PEEK) failed at tcp.c(1463):tcp_recvmsg Mar 25 12:48:05 serlinux02 squid[714]: TCP connection to wwwcache1.essex.ac.uk/8 080 failed ( this message appears in a number of places) Mar 25 12:48:25 serlinux02 ntpd[560]: synchronisation lost Mar 25 12:59:35 serlinux02 kernel: eth0: card reports no resources. Mar 25 12:59:40 serlinux02 last message repeated 64 times some messages like the above reported last message repeated over 3000 times. Is this a memory problem? We doubled the memory in this computer to 771232 K a few days before the crash. Following a newsgroup message, I thought of tweaking /proc/sys/vm/freepages but the file does not exist. The computer has scsi disks. Leslie Bell, Systems Programmer, Web Support Unit University of Essex, Colchester CO4 3SQ U.K. E-mail: mailto:lbell@essex.ac.uk. Tel:+44 (0)1206 873628. web authors url: http://www2.essex.ac.uk/wag web support unit url: http://www2.essex.ac.uk/wag/wsu From kallol@efi.com Tue Mar 26 15:10:01 2002 From: kallol@efi.com (Kallol Biswas) Date: Tue Mar 26 15:10:01 2002 Subject: [eepro100] eepro100 speed setting problem 10 to 100 References: <773A7B88FE13D6119C7B009027D3A56A3B5404@sernt13.essex.ac.uk> Message-ID: <3CA0C528.F03AD718@efi.com> Due to a microcode bug the 82555's speed can't be set from 10 to 100Mbps. Consider the situation: insmod eepro100 option for 10 mbps rmmod insmod eepro100 option for 100 mbps mii-tool reports no link. A fix for the problem is to issue a PHY reset in speedo_found1(). From kallol@efi.com Tue Mar 26 16:03:00 2002 From: kallol@efi.com (Kallol Biswas) Date: Tue Mar 26 16:03:00 2002 Subject: [eepro100] eepro100 speed setting problem 10 to 100 References: <773A7B88FE13D6119C7B009027D3A56A3B5404@sernt13.essex.ac.uk> <3CA0C528.F03AD718@efi.com> Message-ID: <3CA0DFBE.BA495A65@efi.com> I take my word back, only PHY reset does not fix the problem. Kallol Biswas wrote: > Due to a microcode bug the 82555's speed can't be set from > 10 to 100Mbps. > > Consider the situation: > > insmod eepro100 option for 10 mbps > rmmod > insmod eepro100 option for 100 mbps > mii-tool reports no link. > > A fix for the problem is to issue a PHY reset in speedo_found1(). > > _______________________________________________ > eepro100 mailing list > eepro100@scyld.com > http://www.scyld.com/mailman/listinfo/eepro100 From shigang@ict.ac.cn Thu Mar 28 03:28:01 2002 From: shigang@ict.ac.cn (shigang) Date: Thu Mar 28 03:28:01 2002 Subject: [eepro100] How to test DMA start-up latency in eepro100 Message-ID: <001601c1d632$0fd10530$4c00a8c0@shigang> This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C1D675.1DC238B0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8sDQogICAgSSB3YW50IHRvIHRlc3QgdGhlIERNQSBzdGFydC11cCBvdmVyaGVhZCBpbiBl ZXBybzEwMCwgYnV0IEkgY291bGRuJ3QgZmluZCBtb3JlIGluZm9ybWF0aW9uIGFib3V0IERNQSBv cGVyYXRpb24gaW4gZWVwcm8xMDAncyBsaW51eCBkcml2ZXIuIENvdWxkIHlvdSBnaXZlIG1lIHNv bWUgYW5zd2VyPw0KDQpiZXN0IHJlZ2FyZHMuDQoNCkdhbmcgU2hpDQplLW1haWw6IHNoaWdhbmdA aWN0LmFjLmNuDQpEaXZpc2lvbiBvZiBDb21wdXRlciBBcmNoaXRlY3R1cmUNCkluc3RpdHV0ZSBv ZiBDb21wdXRpbmcgVGVjaG5vbG9neQ0KQ2hpbmVzZSBBY2FkZW15IG9mIFNjaWVuY2VzDQpQLk8u Qm94ICA6IDI3MDQtMjUgQmVpamluZywgQ2hpbmENClBvc3QgQ29kZTogMTAwMDgwDQo= ------=_NextPart_000_0013_01C1D675.1DC238B0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4zMzE1LjI4NzAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5IZWxsbyw8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgSSB3YW50IHRvIHRlc3Qg dGhlJm5ic3A7RE1BIA0Kc3RhcnQtdXAmbmJzcDtvdmVyaGVhZCBpbiBlZXBybzEwMCwgYnV0IEkg Y291bGRuJ3QmbmJzcDtmaW5kIG1vcmUgaW5mb3JtYXRpb24gDQphYm91dCBETUEgb3BlcmF0aW9u IGluIGVlcHJvMTAwJ3MgbGludXggZHJpdmVyLiBDb3VsZCB5b3UgZ2l2ZSBtZSBzb21lIA0KYW5z d2VyPzwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5i ZXN0IHJlZ2FyZHMuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPkdhbmcgU2hpPEJSPmUtbWFpbDogPEEgDQpocmVmPSJtYWlsdG86c2hpZ2FuZ0BpY3Qu YWMuY24iPnNoaWdhbmdAaWN0LmFjLmNuPC9BPjxCUj5EaXZpc2lvbiBvZiBDb21wdXRlciANCkFy Y2hpdGVjdHVyZTxCUj5JbnN0aXR1dGUgb2YgQ29tcHV0aW5nIFRlY2hub2xvZ3k8QlI+Q2hpbmVz ZSBBY2FkZW15IG9mIA0KU2NpZW5jZXM8QlI+UC5PLkJveCZuYnNwOyA6IDI3MDQtMjUgQmVpamlu ZywgQ2hpbmE8QlI+UG9zdCBDb2RlOiANCjEwMDA4MDwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1M Pg0K ------=_NextPart_000_0013_01C1D675.1DC238B0-- From aranyin@yahoo.com Thu Mar 28 08:48:01 2002 From: aranyin@yahoo.com (Alex Jurado) Date: Thu Mar 28 08:48:01 2002 Subject: [eepro100] (no subject) Message-ID: <20020328134700.11670.qmail@web11306.mail.yahoo.com> confirm 620303 __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ From becker@scyld.com Thu Mar 28 11:02:01 2002 From: becker@scyld.com (Donald Becker) Date: Thu Mar 28 11:02:01 2002 Subject: [eepro100] How to test DMA start-up latency in eepro100 In-Reply-To: <001601c1d632$0fd10530$4c00a8c0@shigang> Message-ID: On Thu, 28 Mar 2002, shigang wrote: > I want to test the DMA start-up overhead in eepro100, but I couldn't > find more information about DMA operation in eepro100's linux > driver. Could you give me some answer? Please clarify: what are you looking to test? It sounds as if what you really want is the trace from a PCI bus analyzer, which will directly tell you how long it takes between issuing a command and the bus master transfer starts. -- 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 alan@metadigm.co.uk Fri Mar 29 10:02:01 2002 From: alan@metadigm.co.uk (Alan McRae) Date: Fri Mar 29 10:02:01 2002 Subject: [eepro100] eepro100: wait_for_cmd_done timeout Message-ID: <3CA481C6.F3E35B44@metadigm.co.uk> Appears to be a well known error. I have tried various things with no success. System works fine but I get the wait_for_cmd_done timeout under heavy load (e.g. 100Mbps NFS copies). I have tried compiling the drivers according to the instructions in "Network Driver Updates for Linux kernels 1.20 through 2.4" but the insmod fails with missing symbols. Any suggestions. Does anyone have a solid build script for RedHat 7.2. Does the current eepro100.c driver fix this problem if I can get it to install? Intel Hudson Server, 2 x onboard ports Linux RedHat 7.2 2.4.9-21smp 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: OEM i82557/i82558 10/100 Ethernet, 00:02:B3:4F:E4:D0, IRQ 18. Board assembly 000000-000, 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 (0xb874c1d3). eth1: OEM i82557/i82558 10/100 Ethernet, 00:02:B3:4F:E4:D1, IRQ 19. Board assembly 000000-000, 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 (0xb874c1d3). Installing knfsd (copyright (C) 1996 okir@monad.swb.de). host# insmod pci-scan.o pci-scan.o: unresolved symbol pci_write_config_byte pci-scan.o: unresolved symbol kmalloc pci-scan.o: unresolved symbol pci_find_class pci-scan.o: unresolved symbol __check_region pci-scan.o: unresolved symbol pci_read_config_byte pci-scan.o: unresolved symbol pci_read_config_dword pci-scan.o: unresolved symbol __ioremap pci-scan.o: unresolved symbol pci_read_config_word pci-scan.o: unresolved symbol kfree pci-scan.o: unresolved symbol pci_set_master pci-scan.o: unresolved symbol pci_write_config_dword pci-scan.o: unresolved symbol pci_write_config_word pci-scan.o: unresolved symbol printk pci-scan.o: unresolved symbol ioport_resource pci-scan.o: Note: modules without a GPL compatible license cannot use GPLONLY_ symbols Thanks Alan