From nick@soundmouse.com Mon Jul 1 09:49:00 2002 From: nick@soundmouse.com (Nick Pay) Date: Mon Jul 1 08:49:00 2002 Subject: [vortex] using 3Com 3c905c on RedHat 7.2 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_01C220FD.944CC8B0 Content-Type: text/plain; charset="iso-8859-1" I'm trying to enable my 3c905c card to run on RedHat 7.2 On boot, eth0 fails to install (possibly as the driver being used is 3c59x). I've downloaded the linux driver (3c90x) for my 3COM card but am unable to compile it. It looks for a header file netdivert.h which does not exist. 1. Am I correct in using the 3c90x driver for my 3c905c card? (or will 3c59x do) 2. If so, am I able to download the .o (compiled) file from anywhere? 3. If not downloadable, any ideas on how to get 3c90x.c to compile? Many thanks Nick Pay ------_=_NextPart_001_01C220FD.944CC8B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable using 3Com 3c905c on RedHat 7.2

I'm trying to enable my 3c905c card to = run on RedHat 7.2 On boot, eth0 fails to install (possibly as the = driver being used is 3c59x). I've downloaded the linux driver (3c90x) = for my 3COM card but am unable to compile it. It looks for a header = file netdivert.h which does not exist.

1. Am I correct in using the 3c90x = driver for my 3c905c card? (or will 3c59x do)
2. If so, am I able to download the = .o (compiled) file from anywhere?
3. If not downloadable, any ideas on = how to get 3c90x.c to compile?

Many thanks
Nick Pay

------_=_NextPart_001_01C220FD.944CC8B0-- From phishy@cox-internet.com Tue Jul 2 06:11:01 2002 From: phishy@cox-internet.com (Will Bending) Date: Tue Jul 2 05:11:01 2002 Subject: [vortex] 3com 3c905-tx NIC fails to run full-duplex Message-ID: <200207020404.31638.phishy@cox-internet.com> Hi all.. I have a couple of 3com "boomerang" NICs that I can't get running in full-duplex. I've been scouring the archives and it seems that these NICs are troublesome to say the least. I have them set to force full_duplex=1,1 in /etc/modules.conf and am using the 3c59x driver. OS is Red Hat 7.3 kernel is 2.4.18-3. Both NICs show full-duplex for the MAC address when diagnosing with vortex-diag, but vortex-diag shows them as "3c592 EISA 10Mps Demon/Vortex" and not "boomerangs". This is strange since they were initially recognized by this tool as boomerangs earlier in the day. I have been changing /etc/modules.conf alot, so maybe that has something to do with the incorrect naming. mii-diag reports that my link partner (Toshiba PCX1100U cable modem) is not autonegotiable and is generating 10baseT link beat. I have tried options 0x200 to force; and options 20..16..8.. When I force full-duplex, it is reported as such by vortex-diag, but bandwidth testing shows downloads never peak over 155 Kb/s. These run at 1.2Mb/s on the NT machines. I appreciate any help greatly! Thanks, Will Bending ucs_whb@shsu.edu phishy@cox-internet.com From becker@scyld.com Tue Jul 2 10:56:01 2002 From: becker@scyld.com (Donald Becker) Date: Tue Jul 2 09:56:01 2002 Subject: [vortex] 3com 3c905-tx NIC fails to run full-duplex In-Reply-To: <200207020404.31638.phishy@cox-internet.com> Message-ID: On Tue, 2 Jul 2002, Will Bending wrote: > Subject: [vortex] 3com 3c905-tx NIC fails to run full-duplex > > I have a couple of 3com "boomerang" NICs that I can't get running in > full-duplex. I've been scouring the archives and it seems that these NICs > are troublesome to say the least. That's pretty harsh. Remember that you are reading the bug report list of one the longest-lasting PCI NICs series. The driver covers four generations with dozens of board varients. > I have them set to force full_duplex=1,1 in /etc/modules.conf and am using the > 3c59x driver. What driver version? What is the detection message? > full-duplex for the MAC address when diagnosing with vortex-diag, but > vortex-diag shows them as "3c592 EISA 10Mps Demon/Vortex" and not > "boomerangs". What does the diagnostic actually report? Is the PCI ID correct? > This is strange since they were initially recognized by this > tool as boomerangs earlier in the day. That hints at a hardware or timing issue. > mii-diag reports that my link partner (Toshiba PCX1100U cable modem) is not > autonegotiable and is generating 10baseT link beat. That probably means that it's not full duplex. Forcing full duplex will cause low performance and packet errors. -- 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 splusplus2000@yahoo.com Tue Jul 2 15:01:01 2002 From: splusplus2000@yahoo.com (S. K.) Date: Tue Jul 2 14:01:01 2002 Subject: [vortex] problems with a 3Com NIC using RH Message-ID: <20020702180016.29948.qmail@web11305.mail.yahoo.com> Hi, I was pointed to this e-mail address for questions about a 3com NIC in linux. I'm using Linux version 2.4.7-10smp (bhcompile@stripples.devel.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)) #1 SMP Thu Sep 6 17:09:31 EDT 2001 with a 3Com NIC card using module 3c59x. for some reason after running for a couple of hours through heavy traffic I get the error: Jun 29 01:35:33 teeth kernel: NETDEV WATCHDOG: eth2: transmit timed out Jun 29 01:35:33 teeth kernel: eth2: transmit timed out, tx_status 00 status e601. Jun 29 01:35:33 teeth kernel: diagnostics: net 0cd8 media 8880 dma 0000003a. Jun 29 01:35:33 teeth kernel: eth2: Interrupt posted but not delivered -- IRQ blocked by another device? Jun 29 01:35:33 teeth kernel: Flags; bus-master 1, dirty 10856077(13) current 10856077(13) Jun 29 01:35:33 teeth kernel: Transmit list 00000000 vs. deaf9540. Jun 29 01:35:33 teeth kernel: 0: @deaf9200 length 800000d5 status 000100d5 Jun 29 01:35:33 teeth kernel: 1: @deaf9240 length 800000d5 status 000100d5 Jun 29 01:35:33 teeth kernel: 2: @deaf9280 length 800000d5 status 000100d5 Jun 29 01:35:33 teeth kernel: 3: @deaf92c0 length 800000d5 status 000100d5 Jun 29 01:35:33 teeth kernel: 4: @deaf9300 length 800000d5 status 000100d5 Jun 29 01:35:33 teeth kernel: 5: @deaf9340 length 800000d5 status 000100d5 Jun 29 01:35:33 teeth kernel: 6: @deaf9380 length 800000d5 status 000100d5 Jun 29 01:35:33 teeth kernel: 7: @deaf93c0 length 800000d5 status 000100d5 Jun 29 01:35:33 teeth kernel: 8: @deaf9400 length 800000d5 status 000100d5 Jun 29 01:35:33 teeth kernel: 9: @deaf9440 length 800000d5 status 000100d5 Jun 29 01:35:33 teeth kernel: 10: @deaf9480 length 800000d5 status 000100d5 Jun 29 01:35:33 teeth kernel: 11: @deaf94c0 length 800000d5 status 800100d5 Jun 29 01:35:33 teeth kernel: 12: @deaf9500 length 800000d5 status 800100d5 Jun 29 01:35:33 teeth kernel: 13: @deaf9540 length 800000d5 status 000100d5 Jun 29 01:35:33 teeth kernel: 14: @deaf9580 length 800000d5 status 000100d5 Jun 29 01:35:33 teeth kernel: 15: @deaf95c0 length 800000d5 status 000100d5 in the kernel message logs. these lines of error appear every 10 seconds from then on. The system becomes unrecheable remotly. (i.e. unseccessfull ping or telnet). However, from the terminal the system seem to be running fine but I cannot reach any computer in the network. Also at this point the other computers on the network have as a MAC address value for the system in question. I checked if any other device was using the same IRQ, however that is not the case. Do you know why this happening? and how it can be fixed? or even were I can read up more info on this? thanks for you time --Sam __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From becker@scyld.com Tue Jul 2 15:24:00 2002 From: becker@scyld.com (Donald Becker) Date: Tue Jul 2 14:24:00 2002 Subject: [vortex] problems with a 3Com NIC using RH In-Reply-To: <20020702180016.29948.qmail@web11305.mail.yahoo.com> Message-ID: On Tue, 2 Jul 2002, S. K. wrote: > Hi, I was pointed to this e-mail address for questions > about a 3com NIC in linux. > > I'm using Linux version 2.4.7-10smp SMP... that means you are using the APIC. > for some reason after running for a couple of hours > through heavy traffic I get the error: > > Jun 29 01:35:33 teeth kernel: NETDEV WATCHDOG: eth2: > transmit timed out > Jun 29 01:35:33 teeth kernel: eth2: transmit timed > out, tx_status 00 status e601. The card is trying to raise an interrupt. > Jun 29 01:35:33 teeth kernel: eth2: Interrupt posted > but not delivered -- IRQ blocked by another device? The driver detects that there is a problem with the interrupt request from the device not raising an interrupt, and accurately reports it. Try running your kernel with the boot option "noapic". > these lines of error appear every 10 seconds from then > on. The system becomes unrecheable remotly. (i.e. > unseccessfull ping or telnet). However, from the > terminal the system seem to be running fine but I > cannot reach any computer in the network. Also at > this point the other computers on the network have > as a MAC address value for the system in > question. I checked if any other device was using the > same IRQ, however that is not the case. The message is only suggesting a possible source of the problem. In this case the problem is likely the APIC bug. -- 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 gluft@clayton.com Tue Jul 2 16:15:02 2002 From: gluft@clayton.com (George Luft) Date: Tue Jul 2 15:15:02 2002 Subject: [vortex] problems installing netdrivers-3.1-1.src.rpm Message-ID: I've compiled the 3c59x driver and pci-scan with no errors, but I still get unresolved symbols when I try to insmod them. So I gave up. I am now trying to install and build the netdrivers-3.1-1.src.rpm per the instructions on http://www.scyld.com/network/updates.html. When I run `rpm -bb SPECS/netdriver*.spec' from /usr/src/redhat, 3c59x.c errors with the following: `NETIF_MSG_MISC' undeclared Any ideas??? George From gluft@clayton.com Tue Jul 2 16:50:01 2002 From: gluft@clayton.com (George Luft) Date: Tue Jul 2 15:50:01 2002 Subject: [vortex] problems installing netdrivers-3.1-1.src.rpm Message-ID: More info: I'm running RedHet 7.2 with 2.4.18 kernel. It appears that NETIF_MSG_MISG is (conditionally) defined in kern_compat.h, but that is also in the usr/src/redhat/SOURCES/netdrivers.tgz archive. What am I doing wrong here? > -----Original Message----- > From: George Luft [mailto:gluft@clayton.com] > Sent: Tuesday, July 02, 2002 3:14 PM > To: vortex@scyld.com > Subject: [vortex] problems installing netdrivers-3.1-1.src.rpm > > > I've compiled the 3c59x driver and pci-scan with no errors, > but I still get > unresolved symbols when I try to insmod them. So I gave up. > > I am now trying to install and build the > netdrivers-3.1-1.src.rpm per the > instructions on http://www.scyld.com/network/updates.html. > > When I run `rpm -bb SPECS/netdriver*.spec' from > /usr/src/redhat, 3c59x.c > errors with the following: > > `NETIF_MSG_MISC' undeclared > > Any ideas??? From turnef@earthlink.net Thu Jul 4 09:01:01 2002 From: turnef@earthlink.net (Scott Turner) Date: Thu Jul 4 08:01:01 2002 Subject: [vortex] 3c905c and 3c900 difficulties Message-ID: Hello, I have a Linux box (running with RedHat 7.3 (kernel 2.4.18-5)) with a 3c900 (eth0) and a 3c905c (eth1) acting as external and internal interfaces in an ipmasquerading setup. I noticed a few days ago that transfer rates off the internal interface were rather asymmetric (11Mbytes/sec moving data off the Linux box with ftp, and only 90KBytes/sec moving data to the Linux box from the same computer with ftp). First thing I tried was obtaining the latest (0.99X) 3c59x.c, compiling it and replacing the much older version of the driver RedHat provided. After doing this dmesg reports: 3c59x.c:v0.99X 6/21/2002 Donald Becker, becker@scyld.com http://www.scyld.com/network/vortex.html eth0: 3Com 3c900 Boomerang 10Mbps Combo at 0xe800, 00:a0:24:d5:b1:ea, IRQ 11 8K buffer 3:5 Rx:Tx split, autoselect/10baseT interface. ***WARNING*** No MII transceivers found! Using bus-master transmits and whole-frame receives. eth1: 3Com 3c905C Tornado at 0xec00, 00:01:03:26:92:0f, IRQ 15 8K buffer 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 786d. Using bus-master transmits and whole-frame receives. The ***WARNING*** message was initially a concern, but after doing some reading I realized this is probably to be expected since the 3c900 is not a 10/100 NIC. I wanted to make sure that everything was ok with eth1, so I tried 'mii-diag -av eth1' which resulted in: mii-diag.c:v2.04 5/9/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Using the new SIOCGMIIPHY value on PHY 24 (BMCR 0x0000). No MII transceiver present!. Use '--force' to view the information anyway. MII PHY #24 transceiver registers: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000. Basic mode control register 0x0000: Auto-negotiation disabled! Speed fixed at 10 mbps, half-duplex. Basic mode status register 0x0000 ... 0000. Link status: not established. Capable of . Unable to perform Auto-negotiation, negotiation not complete. This transceiver has no vendor identification. I'm advertising 0000: Advertising no additional info pages. Using an unknown (non 802.3) encapsulation. Link partner capability is 0000:. Negotiation did not complete. At this point I became confused, as I did not expect to see: "No MII transceiver present!." So I tried 'mii-diag -av eth0': mii-diag.c:v2.04 5/9/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Using the new SIOCGMIIPHY value on PHY 24 (BMCR 0x0000). The autonegotiated capability is 0000. No common media type was autonegotiated! This is extremely unusual and typically indicates a configuration error. Perhaps the advertised capability set was intentionally limited. Basic mode control register 0x0000: Auto-negotiation disabled, with Speed fixed at 10 mbps, half-duplex. Basic mode status register 0xffff ... ffff. Link status: established. This transceiver is capable of 100baseT4 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Remote fault detected! *** Link Jabber! *** Your link partner advertised ffff: Flow-control 100baseT4 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control. End of basic transceiver information. MII PHY #24 transceiver registers: 0000 ffff 0000 ffff 0000 ffff 0000 ffff 0000 ffff 0000 ffff 0000 ffff 0000 ffff 0000 ffff 0000 ffff 0000 ffff 0000 ffff 0000 ffff 0000 ffff 0000 ffff 0000 ffff. Basic mode control register 0x0000: Auto-negotiation disabled! Speed fixed at 10 mbps, half-duplex. Basic mode status register 0xffff ... ffff. Link status: established. Capable of 100baseT4 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Remote fault detected! *** Link Jabber! *** Vendor ID is 00:00:3f:--:--:--, model 63 rev. 15. No specific information is known about this transceiver type. I'm advertising 0000: Advertising no additional info pages. Using an unknown (non 802.3) encapsulation. Link partner capability is ffff: Flow-control 100baseT4 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Negotiation completed. I was sufficiently confused at this point, that I did not know what step to take next. I tried removing the 3c900 from the box, to see if that cleared up the missing "MII transceiver" output from mii-diag, but it did not. Any suggestions as to how to proceed next would be greatly appreciated. For reference I have included the output from "vortex-diag -aev" below: vortex-diag.c:v2.06 4/18/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a 3c900 Boomerang 10Mbps Combo adapter at 0xe800. The Vortex chip may be active, so FIFO registers will not be read. To see all register values use the '-f' flag. Initial window 4, registers values by window: Window 0: 0000 0000 0000 0000 0000 00bf ffff 0000. Window 1: FIFO FIFO 0000 2000 8000 00ff 13fc 2000. Window 2: a000 d524 eab1 0000 0000 0000 06c6 4000. Window 3: 02d8 0103 0000 0000 e138 0bff 13ff 6000. Window 4: 0000 00d0 0000 0cc0 0001 88c0 0000 8000. Window 5: 1ffc fffc 06c6 0600 0007 06de 06c6 a000. Window 6: 0000 0000 0000 0000 0000 0000 0000 c000. Window 7: d178 06d0 0000 0000 8000 00ff 500c e000. Vortex chip registers at 0xe800 0xE810: **FIFO** 00000000 00008000 *STATUS* 0xE820: 00000021 00000000 049c6012 060005d2 0xE830: 00000000 0000621b 06d0d180 00000000 Indication enable is 06c6, interrupt enable is 06de. No interrupt sources are pending. Transceiver/media interfaces available: 10baseT 10base2 AUI. Transceiver type in use: 10baseT. MAC settings: half-duplex. Maximum packet size is 0. Station address set to 00:a0:24:d5:b1:ea. Configuration options 06c6. Saved EEPROM settings of a 3Com Vortex/Boomerang: 3Com Node Address 00:A0:24:D5:B1:EA (used as a unique ID only). OEM Station address 00:A0:24:D5:B1:EA (used as the ethernet address). Device ID 9001, Manufacturer ID 6d50. Manufacture date (MM/DD/YYYY) 7/30/1996, division 6, product FP. No BIOS ROM is present. Options: negotiated duplex, link beat required. Vortex format checksum is correct (00c2 vs. 00c2). Cyclone format checksum is incorrect (00 vs. 0xff). Hurricane format checksum is incorrect (00 vs. 0xff). ***WARNING***: No MII transceivers found! Index #2: Found a 3c905C Tornado 100baseTx adapter at 0xec00. The Vortex chip may be active, so FIFO registers will not be read. To see all register values use the '-f' flag. Initial window 4, registers values by window: Window 0: 0000 0000 0000 0000 0000 00bf ffff 0000. Window 1: FIFO FIFO 0700 0000 0000 007e 0000 2000. Window 2: 0100 2603 0f92 0000 0000 0000 0042 4000. Window 3: 0000 0380 05ea 0000 000a 0800 0800 6000. Window 4: 0000 0000 0000 0cd8 0001 8880 0000 8000. Window 5: 1ffc 0000 0000 0600 0807 06de 06c6 a000. Window 6: 0000 0000 0000 0000 0000 0000 0000 c000. Window 7: 0000 0000 0000 0000 0000 0000 0000 e000. Vortex chip registers at 0xec00 0xEC10: **FIFO** 00000000 00000006 *STATUS* 0xEC20: 00000020 06d0da60 00080000 00001404 0xEC30: 00000000 50b9af47 06d0d9e0 00080004 Indication enable is 06c6, interrupt enable is 06de. No interrupt sources are pending. Transceiver/media interfaces available: 100baseTx 10baseT. Transceiver type in use: Autonegotiate. MAC settings: half-duplex. Station address set to 00:01:03:26:92:0f. Configuration options 0042. Saved EEPROM settings of a 3Com Vortex/Boomerang: 3Com Node Address 00:01:03:26:92:0F (used as a unique ID only). OEM Station address 00:01:03:26:92:0F (used as the ethernet address). Device ID 9200, Manufacturer ID 6d50. Manufacture date (MM/DD/YYYY) 10/7/2000, division H, product JE. No BIOS ROM is present. Options: negotiated duplex, link beat required. Vortex format checksum is incorrect (002a vs. 10b7). Cyclone format checksum is correct (0xb2 vs. 0xb2). Hurricane format checksum is incorrect (0x9b vs. 0xb2). MII PHY found at address 24, status 786d. MII PHY 0 at #24 transceiver registers: 3000 786d 0180 7750 05e1 41e1 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0238 0087 0000 0000 0000 0000 c4c8 0300 0100 0438 2010 2000 0000 0000 0000 0000. Thanks in advance for any help or suggestions. Scott Turner turnef@earthlink.net From bz@riz.pl Thu Jul 4 18:06:01 2002 From: bz@riz.pl (Bartlomiej Zarzecki) Date: Thu Jul 4 17:06:01 2002 Subject: [vortex] 3c905cx-txm Message-ID: Hi ! I've just bought few days ago 2 3c905cx-txm. I had no success to make these cards work under linux. kernel 2.2.19, 2.2.21-rc1, 2.4.19-rc1 I used driver from these kernels and I tried to compile from the ftp://ftp.scyld.com/pub/network/netdrivers.tgz My questions is the 3c905cx-tx-* supported with the current driver ? When I've put a 3c905cx-tx-m it was detected as a Tornado if I remember. Evrything was looking good - but the card do not wanted to work. I was only able to ping computers attached to it - ifconfig was reporting that the macaddress is ff:ff:ff:ff...... - like a broadcast one. and some other strange messages that there is no link, no MII transciver etc. There is a possibility that I had no luck and both of these cards I bought are just broken - When I put them into a asus TUSL2-C motherboard it do not want to power on normally. -- Pozdrawiam, Bartlomiej Zarzecki bz@riz.pl Public PGP Key http://bz.riz.pl/bz.asc From M.Arndt@science-computing.de Sat Jul 6 06:22:00 2002 From: M.Arndt@science-computing.de (Michael Arndt) Date: Sat Jul 6 05:22:00 2002 Subject: [vortex] 3c59.x,Too much work at interrupt, status=0x4090 Message-ID: <20020706112721.A31736@det.science-computing.de> Hello * a big Linux Cluster is reporting the following error on eth0 eth0: Too much work at interrupt, status=0x4090 Can anybody give exact Information what the error message status=0x4090 tells exactly ? We assume that this problem ist due to one of two reasons: -to much broadcast (we still have to monitor, but its a private subnet) -autonegotitation (We now set Speed fixed) please answer to me directly, beacause i am not on the list. Your hel is appreciated it is an important Linux Cluster reference project. More technical info see below. thx Micha M.Arndt@science-computing.de here additional info: repateted error message in dmesg: eth0: Too much work at interrupt, status=0x4090. eth0: Too much work at interrupt, status=0x4090. mii-tool eth0: eth0: 100 Mbit, full duplex, link ok product info: Intel 82555 rev 4 basic mode: 100 Mbit, full duplex basic status: link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control Our module Options in modules.conf: options 3c59x options=0x204 Used Module: lsmod eth0: 3c59x 26984 0 ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:30:48:21:A5:D8 inet addr:10.123.345.678 Bcast:10.123.345.255 Mask:255.255.255.128 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1195999819 errors:0 dropped:0 overruns:0 frame:0 TX packets:1009313493 errors:0 dropped:0 overruns:22 carrier:0 collisions:0 txqueuelen:100 RX bytes:2620685266 (2499.2 Mb) TX bytes:1943696975 (1853.6 Mb) Interrupt:16 Base address:0xc000 From becker@scyld.com Sun Jul 7 14:13:00 2002 From: becker@scyld.com (Donald Becker) Date: Sun Jul 7 13:13:00 2002 Subject: [vortex] 3c59.x,Too much work at interrupt, status=0x4090 In-Reply-To: <20020706112721.A31736@det.science-computing.de> Message-ID: On Sat, 6 Jul 2002, Michael Arndt wrote: > Subject: [vortex] 3c59.x,Too much work at interrupt, status=0x4090 > > a big Linux Cluster is reporting the following error on eth0 > > eth0: Too much work at interrupt, status=0x4090 > > Can anybody give exact Information what the > error message status=0x4090 tells exactly ? Are you certain that you are using the 3c59x driver for this device? It appears that you are using a eepro100 driver, and it's likely not a recent one. For the eepro100 driver, this status means that you are receiving more packets than the interrupt handler can process. You should check what other device is raising interrupts, or keeping interrupt blocked. A typical culprit is a SCSI driver. > -to much broadcast (we still have to monitor, but its > a private subnet) Perhaps... > -autonegotitation (We now set Speed fixed) Definitely not. You should leave autonegotiation on, and never force full duplex. > Your hel is appreciated it is an important Linux Cluster > reference project. More technical info see below. Hmmmm, you should get your OS from a vendor that supports clusters. > mii-tool eth0: > eth0: 100 Mbit, full duplex, link ok > product info: Intel 82555 rev 4 > Our module Options in modules.conf: > options 3c59x options=0x204 Please don't force full duplex. That leads to problems. > Used Module: lsmod eth0: > 3c59x 26984 0 This is a misleading caused by an invalid modules.conf setup. -- 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 gawain@camlann.de Sun Jul 7 15:56:01 2002 From: gawain@camlann.de (Christian Welzel) Date: Sun Jul 7 14:56:01 2002 Subject: [vortex] 3c905cx-txm In-Reply-To: References: Message-ID: <200207072055.35920.gawain@wh9.tu-dresden.de> Am Donnerstag, 4. Juli 2002 23:05 schrieb Bartlomiej Zarzecki: > I've just bought few days ago 2 3c905cx-txm. I had no success to make > these cards work under linux. I had the same cards and they also did not work... so i brought them back to the dealer and he did some diagnostics on them... so he found out, that my cards did work fine if they were not screwed to the chassis... after some work he noticed that there is a circuit path on the board very close to the slot plate which ends in a solder point. if the card is now screwed to the chassis the slot plate is bent and gets contact to this solder point... put an insulating washer between the board and this slot plate screwpoint. my dealer says, that it works now, but i had no time to test it... i make a report as soon as i tested my cards... try it yourself, perhaps it helps... if nobody understood this, i can repost it in german and somebody can translate it into better english :) -- MfG, Christian Welzel (Sektionsvorsitzender und Admin AG DSN Gerokstrasse) GPG-Key: http://www.wh9.tu-dresden.de/~gawain/key.asc Fingerprint: 4F50 19BF 3346 36A6 CFA9 DBDC C268 6D24 70A1 AD15 From edward.tsang@tradelink.com.hk Wed Jul 10 04:19:01 2002 From: edward.tsang@tradelink.com.hk (Edward Tsang) Date: Wed Jul 10 03:19:01 2002 Subject: [vortex] 3C905B Suddenly timeout after 3-4 hours usage (Linux kernel 2.4.18) Message-ID: <000201c227e1$f4a40530$2682c8c8@EDWARD> Hi there, I am running following hardware configuration on linux kernel 2.4.18 Intel Pentium II 350Mhz 3ware 6410 Hardware RAID Controller 1 x 3Com 3C905B Network Adapter 1 x 8139 Realteak network adapter. Recently, we can't access the system suddenly. When we go to the console, the system is up. However, both network cards did not respond anymore. We need to reboot the machine and the network card works again. However, after 3 -4 hours usage, the problem appear again. Originally, the system is based on AMD Athlon XP. We think that the system board or CPU is faulty so that we replace it with old Pentium II. But the problem also did not get solved. I tried to replace the 3Com card with another healthy card (Same Model). But the problem also cannot be solved. I also try to recompile the kernel but the problem still persists. Anyone can give me some hints to solve this mysterous problem. I will try to run the vortdex-diag and realteak-diag tonight and post the result later. Regards, Edward. From becker@scyld.com Wed Jul 10 10:58:01 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jul 10 09:58:01 2002 Subject: [vortex] 3C905B Suddenly timeout after 3-4 hours usage (Linux kernel 2.4.18) In-Reply-To: <000201c227e1$f4a40530$2682c8c8@EDWARD> Message-ID: On Wed, 10 Jul 2002, Edward Tsang wrote: > I am running following hardware configuration on linux kernel 2.4.18 > Intel Pentium II 350Mhz > 3ware 6410 Hardware RAID Controller > 1 x 3Com 3C905B Network Adapter > 1 x 8139 Realteak network adapter. What driver versions? > Recently, we can't access the system suddenly. When we go to the console, > the system is up. However, both network cards did not respond anymore. ... > I will try to run the vortdex-diag and realteak-diag tonight and post the > result later. They will provide important information. Run them after the network interface stops. -- 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 raymondj@us.ibm.com Wed Jul 10 16:19:01 2002 From: raymondj@us.ibm.com (Raymond Jennings) Date: Wed Jul 10 15:19:01 2002 Subject: [vortex] Question about linux 3com driver Message-ID: Hello, I have a question about your driver for 3Com for 905c & 905cx cards. I have been using these cards because the driver supports the NETIF_F_SG option as well as checksum offloading. I found through testing that this card/driver does not support zero-copy for highmem pages. I saw a comment in the code that said "Make NETIF_F_SG dependent upon nr_free_highpages( ), not on CONFIG_HIGHMEM. I'm curious about this comment. Isn't it the case that zero-copy could still work with CONFIG_HIGHMEM? The only catch would be for skbuff's that contain highmem pages the skbuff would have to be "linearized" which the network stack does automatically (at least as of 2.4.16 possibly earlier.) Do you disable NETIF_F_SG support if highmem pages exist? Thanks. Raymond B. Jennings III IBM Thomas J. Watson Research Center raymondj@us.ibm.com (914)784-5475 (TL 863) From becker@scyld.com Wed Jul 10 20:59:00 2002 From: becker@scyld.com (Donald Becker) Date: Wed Jul 10 19:59:00 2002 Subject: [vortex] Question about linux 3com driver In-Reply-To: Message-ID: On Wed, 10 Jul 2002, Raymond Jennings wrote: > I have a question about your driver for 3Com for 905c & 905cx cards. I > have been using these cards because the driver supports the NETIF_F_SG > option as well as checksum offloading. > > I found through testing that this card/driver does not support zero-copy > for highmem pages. It's not clear that there is a performance advantage to doing so: locking and remapping pages is a very expensive operation on SMPs, and can easily cost more than just the copying into always-PCI-accessable skbuff. > I'm curious about this comment. Isn't it the case that zero-copy could > still work with CONFIG_HIGHMEM? The only catch would be for skbuff's that > contain highmem pages the skbuff would have to be "linearized" which the > network stack does automatically (at least as of 2.4.16 possibly earlier.) -- 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 rochberg@61Cnetworks.com Thu Jul 11 02:02:02 2002 From: rochberg@61Cnetworks.com (David Rochberg) Date: Thu Jul 11 01:02:02 2002 Subject: [vortex] Vortex hangs card (not machine) after "Too much work in interrupt" Message-ID: <1026363661.8523.68.camel@blastfurnace> I'm seeing the following difficult-to-reproduce behavior on a 3Com 3c905B (gory kernel/driver details at bottom): Under heavy loads I will see an occasional message: Jul 9 15:57:47 farm-1 kernel: eth0: Too much work in interrupt, status e401. which seems mostly-benign on its own. However, occasionally (>3, <10 times in the last month), we'll come in in the morning to find the machine unreachable over its ethernet with "Too much work" as the last message in the syslog. An ifdown/ifup will bring connectivity back. My big question is "Is there a fix for this"? I have a few subquestions 1. How do status notifications get turned back on after a 'too much work'? When "too much work" happens, the driver turns off status notification ("indications" in 3com's terminology) for all the currently-asserted interrupt sources. The comments say "The timer will reenable interrupts". When I look at vortex_timer(), though, I can't figure out how indications get turned back on. I see the FakeIntr request, but no obvious SetStatusEnb/SetIndicationEnable. How does this happen? Is there some undocumented feature of the chipset that restores this register after a FakeIntr/RequestInterrupt call? 2. Will raising max_interrupt_work help? If we assume that the "too much work" is leading to the interface failure, then a partial solution would be to reduce the frequency of these. To that end, I ran some experiments with an instrumented version of the driver that printed out the number of iterations through the loop in boomerang_interrupt (when the number of iterations exceeded a threshold). I was a little surprised to see that this number was very rarely large; even under loads that brought the machine to its knees, I rarely saw iteration counts as high as 10, let alone the 32 necessary to hit the max_interrupt_work threshold and trigger a "too much work". I tried to generate extra interrupts by catting files to /dev/null during the tests, and this didn't seem to increase the number of loop iterations. If my experiments are right, they unfortunately skewer my simplistic model of what causes "too much work" conditions. If it's not simple network load, then I don't really understand how to set max_interrupt_work. Any suggestions for a better model or values for max_interrupt_work? 3. Could this be caused by the FakeIntr from vortex_timer getting dropped somehow? Many thanks for your time, david rochberg Details follow: Kernel 2.4.2 with redhat's patches (that is, the stock RH7.1 kernel), which contains 3c59x driver "LK1.1.13 27 Jan 2001". Diffs with more recent 2.4 kernels show no relevant-seeming changes in the "too much work" or vortex_timer code. eth0: 3Com PCI 3c905B Cyclone 100baseTx at 0xdc00, 00:50:04:10:4d:3b, IRQ 3 product code 5450 rev 00.9 date 12-28-98 I'm running on a testbed of wimpy celeron 400s (HP Vectras) for the time being. They're hooked up to a Cisco 3548XL. When I say "heavy load" I mean routing two sorts of traffic through the machine: several streams of small UDP packets running at a few thousand packets/sec a few TCP streams fast enough to saturate the remaining bandwidth on some machines, this is traffic is being IPIP-encapsulated (that is, it comes in IP and leaves over an IPIP tunnel to another machine on the same switch). on others, the traffic enters and exits over IPIP tunnels. on some machines, CPU-intensive userland processes were also running I mention the IPIP encapsulation because my casual reading of the source (I've not yet instrumented to make sure) suggests that every IP packet that gets IPIP-encapsulated must be copied to make additional headroom in the skbuff, and this would further increase kernel CPU usage. From henrik.gram@teletopia.no Thu Jul 11 13:08:02 2002 From: henrik.gram@teletopia.no (Henrik Gram) Date: Thu Jul 11 12:08:02 2002 Subject: [vortex] 3c905C Tornado probs Message-ID: <001101c228f5$18fa7180$1e0aa8c0@devsenter.local> I have two different linux boxes and a number of 3c905C Tornado's - a few are made in ireland but most come from singapore and has a different chip on it. I mention this because only the ones that says made in ireland works 100%. I've switched pci slots, cables and switches/hunbs around endlessly, and here's what I've come up with: (they are now both connected from the same machine and to the same switch, a 3com 'OfficeConnect - dual speed switch'). henrik@gonzo:~> mii-diag -v eth0 mii-diag.c:v2.04 5/9/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Using the default interface 'eth0'. Using the new SIOCGMIIPHY value on PHY 24 (BMCR 0x3000). The autonegotiated capability is 01e0. The autonegotiated media type is 100baseTx-FD. Basic mode control register 0x3000: Auto-negotiation enabled. You have link beat, and everything is working OK. This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control. End of basic transceiver information. MII PHY #24 transceiver registers: 3000 782d 0040 6176 05e1 45e1 0003 0000 0000 0000 0000 0000 0000 0000 0000 0000 1000 0301 0000 0000 0000 02c8 0100 0000 003f fd3e 0f00 ff40 002f 0000 80a0 000b. 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:10:18:--:--:--, model 23 rev. 6. 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 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Negotiation completed. henrik@gonzo:~> mii-diag -v eth1 mii-diag.c:v2.04 5/9/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Using the new SIOCGMIIPHY value on PHY 24 (BMCR 0x3000). The autonegotiated capability is 0140. The autonegotiated media type is 100baseTx-FD. Basic mode control register 0x3000: Auto-negotiation enabled. You have link beat, and everything is working OK. This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control. End of basic transceiver information. MII PHY #24 transceiver registers: 3000 780d 0040 6174 0541 45e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1000 0301 0000 0000 0000 0132 0100 0000 003c 7006 0f00 ff40 052c 0000 0020 000b. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x780d ... 780d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 00:10:18:--:--:--, model 23 rev. 4. No specific information is known about this transceiver type. I'm advertising 0541: Flow-control 100baseTx-FD 10baseT-FD Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Negotiation completed. One thing I've noticed is that the autonegotiated capability is 0140 on the 'bad' NICs and 01e0 on the 'good' NICs and negotiation both says completed and not completed with the 'bad' NICs. ping flooding through the bad NICs results in a lot of RX errors and RX frame errors (~5 %), but I've seen 10%+ when the box was doing something useful instead of just the pings. More info: henrik@gonzo:~> vortex-diag -aa vortex-diag.c:v2.06 4/18/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a 3c905C Tornado 100baseTx adapter at 0xe400. The Vortex chip may be active, so FIFO registers will not be read. To see all register values use the '-f' flag. Initial window 4, registers values by window: Window 0: 0000 0000 d93f 0000 e3e3 00bf ffff 0000. Window 1: FIFO FIFO 0700 0000 0000 007f 0000 2000. Window 2: 0400 2476 c9c9 0000 0000 0000 0052 4000. Window 3: 0000 0180 05ea 0020 000a 0800 0800 6000. Window 4: 0000 0000 0000 0cfa 0001 8880 0000 8000. Window 5: 1ffc 0000 0000 0600 0807 06de 06c6 a000. Window 6: 0000 0000 0000 0000 1000 0000 0000 c000. Window 7: 0000 0000 0000 0000 0000 0000 0000 e000. Vortex chip registers at 0xe400 0xE410: **FIFO** 00000000 00000007 *STATUS* 0xE420: 00000020 01282a70 00080000 00001404 0xE430: 00000000 e4121bee 012828f0 00080004 Indication enable is 06c6, interrupt enable is 06de. No interrupt sources are pending. Transceiver/media interfaces available: 100baseTx 10baseT. Transceiver type in use: Autonegotiate. MAC settings: full-duplex. Station address set to 00:04:76:24:c9:c9. Configuration options 0052. Index #2: Found a 3c905C Tornado 100baseTx adapter at 0xe800. The Vortex chip may be active, so FIFO registers will not be read. To see all register values use the '-f' flag. Initial window 4, registers values by window: Window 0: 0000 0000 d93f 0000 e3e3 00bf ffff 0000. Window 1: FIFO FIFO 0700 0000 0000 007f 0000 2000. Window 2: 1000 fd22 0c9a 0000 0000 0000 0052 4000. Window 3: 0000 0180 05ea 0020 000a 0800 02f0 6000. Window 4: 0000 0000 0000 0ef6 0001 9c20 0000 8000. Window 5: 1ffc 0000 0000 0600 0807 06de 06c6 a000. Window 6: 0000 0000 0000 ae00 1000 526b 729f c000. Window 7: 0000 0000 0000 0000 0000 0000 0000 e000. Vortex chip registers at 0xe800 0xE810: **FIFO** 00000000 00000001 *STATUS* 0xE820: 00000020 07c68210 00080000 00001404 0xE830: 00000000 1f11e0ef 07c680b0 00080004 Indication enable is 06c6, interrupt enable is 06de. No interrupt sources are pending. Transceiver/media interfaces available: 100baseTx 10baseT. Transceiver type in use: Autonegotiate. MAC settings: full-duplex. Station address set to 00:10:22:fd:9a:0c. Configuration options 0052. henrik@gonzo:~> vortex-diag -mm vortex-diag.c:v2.06 4/18/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a 3c905C Tornado 100baseTx adapter at 0xe400. MII PHY found at address 24, status 782d. MII PHY 0 at #24 transceiver registers: 3000 782d 0040 6176 05e1 45e1 0003 0000 0000 0000 0000 0000 0000 0000 0000 0000 1000 0300 0000 0000 0000 0f35 0500 0000 003f 8d3e 0f00 ff40 002f 0000 80a0 000b. MII PHY #24 transceiver registers: 3000 782d 0040 6176 05e1 45e1 0003 0000 0000 0000 0000 0000 0000 0000 0000 0000 1000 0300 0000 0000 0000 012c 0600 0000 003f 8d3e 0f00 ff40 002f 0000 80a0 000b. 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:10:18:--:--:--, model 23 rev. 6. 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 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Negotiation completed. Index #2: Found a 3c905C Tornado 100baseTx adapter at 0xe800. MII PHY found at address 24, status 780d. MII PHY 0 at #24 transceiver registers: 3000 780d 0040 6174 0541 45e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1000 0300 0000 0000 0000 0132 0400 0000 003c 0006 0f00 ff40 012c 0000 0020 000b. MII PHY #24 transceiver registers: 3000 780d 0040 6174 0541 45e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1000 0300 0000 0000 0000 0132 0500 0000 003c 0006 0f00 ff40 012c 0000 0020 000b. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x780d ... 780d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 00:10:18:--:--:--, model 23 rev. 4. No specific information is known about this transceiver type. I'm advertising 0541: Flow-control 100baseTx-FD 10baseT-FD Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Negotiation completed. Any ideas at all? Regards, Henrik Gram From becker@scyld.com Thu Jul 11 13:37:01 2002 From: becker@scyld.com (Donald Becker) Date: Thu Jul 11 12:37:01 2002 Subject: [vortex] 3c905C Tornado probs In-Reply-To: <001101c228f5$18fa7180$1e0aa8c0@devsenter.local> Message-ID: On Thu, 11 Jul 2002, Henrik Gram wrote: > I have two different linux boxes and a number of 3c905C Tornado's - a few > are made in ireland but most come from singapore and has a different chip on > it. I mention this because only the ones that says made in ireland works > 100%. I've switched pci slots, cables and switches/hunbs around endlessly, > and here's what I've come up with: (they are now both connected from the > same machine and to the same switch, a 3com 'OfficeConnect - dual speed > switch'). What driver are you using? What is the detection message? > The autonegotiated capability is 01e0. > The autonegotiated media type is 100baseTx-FD. ... > MII PHY #24 transceiver registers: > 3000 782d 0040 6176 05e1 45e1 0003 0000 Good. > henrik@gonzo:~> mii-diag -v eth1 > The autonegotiated capability is 0140. Errmmm, > The autonegotiated media type is 100baseTx-FD. OK. > This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD > 10baseT. > Able to perform Auto-negotiation, negotiation not complete. There was a problem with autonegotiation. You got the link partner's capability information, but didn't finish the last stage of the transaction. > Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx > 10baseT-FD 10baseT, w/ 802.3X flow control. But here the transceiver claims everything is fine. > MII PHY #24 transceiver registers: > 3000 780d 0040 6174 0541 45e1 0000 0000 The curiousity is that you are only advertising 0x0140 -- full duplex modes. Did you pass a module option, or is there something set in the EEPROM? > One thing I've noticed is that the autonegotiated capability is 0140 on the > 'bad' NICs and 01e0 on the 'good' NICs and negotiation both says completed > and not completed with the 'bad' NICs. Yup. > ping flooding through the bad NICs results in a lot of RX errors and RX > frame errors (~5 %), but I've seen 10%+ when the box was doing something > useful instead of just the pings. This looks like a duplex mismatch. Perhaps the remote end didn't switch to full duplex mode because of the questionable completion of autonegotiation. > henrik@gonzo:~> vortex-diag -aa .. > MAC settings: full-duplex. What was the detection message? -- 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 Leon_Dague@speakeasy.net Thu Jul 11 13:55:00 2002 From: Leon_Dague@speakeasy.net (Leon Dague) Date: Thu Jul 11 12:55:00 2002 Subject: [vortex] Mini PCI - no link In-Reply-To: <20020627155236.GA1342@neo.realtors.org> References: <20020625140306.GA1428@neo.realtors.org> <20020627155236.GA1342@neo.realtors.org> Message-ID: <20020711165407.GB295@leon-laptop> Many thanks! This version 0.99Xc solved my no-link-light problem. I have the 3c556B/modem mini-pci card in a Dell Inspiron 8100. The card would sometimes get into a state where there was no link light, and the only way I could reset it was to boot into Windows 2000. Thanks to both of you! --Leon Dague On Thu, Jun 27, 2002 at 03:53:14PM +0000, Dave Dribin wrote: > On Thu, Jun 27, 2002 at 01:22:16AM -0400, Donald Becker wrote: > > OK, I've put up a new test version at > > http://www.scyld.com/network/vortex.html > > ftp://ftp.scyld.com/pub/network/3c59x.c > > > > Please send a report. > > 0.99Xc works. -- Leon_Dague@speakeasy.net. My opinions. From henrik.gram@teletopia.no Fri Jul 12 07:30:01 2002 From: henrik.gram@teletopia.no (Henrik Gram) Date: Fri Jul 12 06:30:01 2002 Subject: [vortex] 3c905C Tornado probs References: Message-ID: <006e01c2298f$0c717720$1e0aa8c0@devsenter.local> On Thu, July 11, 2002, Donald Becker wrote: > On Thu, 11 Jul 2002, Henrik Gram wrote: > > > I have two different linux boxes and a number of 3c905C Tornado's - a few > > are made in ireland but most come from singapore and has a different chip on > > it. I mention this because only the ones that says made in ireland works > > 100%. I've switched pci slots, cables and switches/hunbs around endlessly, > > and here's what I've come up with: (they are now both connected from the > > same machine and to the same switch, a 3com 'OfficeConnect - dual speed > > switch'). > > What driver are you using? I had been using LK1.1.16 (2.4.18) and LK1.1.17 (2.4.19-pre9), and later switched to your latest 3c95x driver. I did not notice much difference - if it matters any, the bad cards got ~10% errors under real use, while currently the test box is getting 2% errors when pingflooding from it. > What is the detection message? 3c59x.c:v0.99X 6/21/2002 Donald Becker, becker@scyld.com http://www.scyld.com/network/vortex.html eth0: 3Com 3c905C Tornado at 0xe400, 00:04:76:24:c9:c9, IRQ 5 8K buffer 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 782d. Using bus-master transmits and whole-frame receives. eth1: 3Com 3c905C Tornado at 0xe800, 00:10:22:fd:9a:0c, IRQ 12 8K buffer 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 782d. Using bus-master transmits and whole-frame receives. > > The autonegotiated capability is 01e0. > > The autonegotiated media type is 100baseTx-FD. > ... > > MII PHY #24 transceiver registers: > > 3000 782d 0040 6176 05e1 45e1 0003 0000 > > Good. > > > henrik@gonzo:~> mii-diag -v eth1 > > The autonegotiated capability is 0140. > > Errmmm, > > > The autonegotiated media type is 100baseTx-FD. > > OK. > > > This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD > > 10baseT. > > Able to perform Auto-negotiation, negotiation not complete. > > There was a problem with autonegotiation. You got the link partner's > capability information, but didn't finish the last stage of the > transaction. > > > Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx > > 10baseT-FD 10baseT, w/ 802.3X flow control. > > But here the transceiver claims everything is fine. > > > MII PHY #24 transceiver registers: > > 3000 780d 0040 6174 0541 45e1 0000 0000 > > The curiousity is that you are only advertising 0x0140 -- full duplex > modes. Did you pass a module option, or is there something set in the > EEPROM? I have not passed it any options. henrik@gonzo:~> vortex-diag -ee vortex-diag.c:v2.06 4/18/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a 3c905C Tornado 100baseTx adapter at 0xe400. EEPROM format 64x16, configuration table at offset 0: 00: 0004 7624 c9c9 9200 024f 0048 574d 6d50 0x08: 2940 0800 0004 7624 c9c9 0010 0000 00aa 0x10: 72a2 0000 0000 0180 0000 0000 0429 10b7 0x18: 1000 000a 0002 6300 ffb7 b7b7 0000 0000 0x20: 00ac 1234 5600 0000 0000 0000 0000 0000 ... The word-wide EEPROM checksum is 0x276c. Saved EEPROM settings of a 3Com Vortex/Boomerang: 3Com Node Address 00:04:76:24:C9:C9 (used as a unique ID only). OEM Station address 00:04:76:24:C9:C9 (used as the ethernet address). Device ID 9200, Manufacturer ID 6d50. Manufacture date (MM/DD/YYYY) 2/15/2001, division H, product MW. A BIOS ROM of size 0Kx8 is expected. Options: negotiated duplex, link beat required. Vortex format checksum is incorrect (003a vs. 10b7). Cyclone format checksum is incorrect (0xaa vs. 0xac). Hurricane format checksum is incorrect (0x83 vs. 0xac). Index #2: Found a 3c905C Tornado 100baseTx adapter at 0xe800. EEPROM format 64x16, configuration table at offset 0: 00: 0010 22fc 8894 9200 0032 0048 5245 6d50 0x08: 2940 0001 0010 22fd 9a0c c010 0000 00aa 0x10: 72a2 0000 0000 0180 0000 0004 0429 10b7 0x18: 1000 000a 0002 6300 ffb7 b7b7 0000 0000 0x20: 00de 1234 5600 0000 0000 0000 0000 0000 ... The word-wide EEPROM checksum is 0xc155. Saved EEPROM settings of a 3Com Vortex/Boomerang: 3Com Node Address 00:10:22:FC:88:94 (used as a unique ID only). OEM Station address 00:10:22:FD:9A:0C (used as the ethernet address). Device ID 9200, Manufacturer ID 6d50. Manufacture date (MM/DD/YYYY) 1/18/2000, division H, product ER. No BIOS ROM is present. Options: force full duplex, link beat check disabled. Vortex format checksum is incorrect (000e vs. 10b7). Cyclone format checksum is incorrect (0x9e vs. 0xde). Hurricane format checksum is incorrect (0xb7 vs. 0xde). hmmm no bios? and in the first interface a size zero bios "is expected" - what does this mean? The cards are all labelled 3C905C-TX-M, both those made in Singapore and in Ireland. So far I have only had luck with the irish ones. Further the good NICs are made in 2001 and have product code MW, while the bad one above have ER. No idea if any of this is significant. > > ping flooding through the bad NICs results in a lot of RX errors and RX > > frame errors (~5 %), but I've seen 10%+ when the box was doing something > > useful instead of just the pings. > > This looks like a duplex mismatch. Perhaps the remote end didn't switch > to full duplex mode because of the questionable completion of > autonegotiation. I've tried using mii-diag eth1 -F 100baseTX-HD (and FD, and the 10base combinations), the interface would just stop working until a mii-diag eth1 --Reset. Further if I ping from the box after having forced it one way or the other, I get TX errors instead and no replies at all - maybe it doens't send anything out at all in that case? Another oddity I've noticed is that after cold booting, the 100 mbit light is on.. but at some point after booting into linux and playing with the pings, it changes to the 10 mbit light - yet the diagnostics programs all say it's 100 mbit. It will change back to 100mbit if I force it to, but wont respond to anything after that. I'm getting really confused. Regards, Henrik Gram From epl@labyrinth.net.au Sat Jul 13 12:33:01 2002 From: epl@labyrinth.net.au (epl@labyrinth.net.au) Date: Sat Jul 13 11:33:01 2002 Subject: [vortex] 3c59x LK1.1.16 Linux-2.4 PCI bus error/Host error Message-ID: Using a 3com 905B-100BaseTX NIC with the 3c59x driver, I can induce the module to lock-up by transferring large amounts of data via the network. By bringing down the network I can stop flow of messages to syslog (see below). If I restart the network without unloading the module, the network stays locked up and the flow of messages to syslog resumes. If I stop the network, unload the module and restart the network, I can sanely use the network until the next lockup. I get the following (debug=7) error messages in my syslog: === Jul 10 23:32:55 localhost kernel: <7tatus e001 Jul 10 23:32:56 localhost kernel: eth0: vortex_error(), status=0xe081 Jul 10 23:33:02 localhost kernel: eth0: vortex_error(), status=0xe081 Jul 10 23:33:05 localhost kernel: <7ake queue Jul 10 23:33:05 localhost kernel: eth0: vortex_error(), status=0xe081 Jul 10 23:33:28 localhost last message repeated 4 times Jul 10 23:33:31 localhost kernel: e401. Jul 10 23:33:31 localhost kernel: eth0: vortex_error(), status=0xe081 Jul 10 23:33:47 localhost last message repeated 5 times Jul 10 23:33:48 localhost kernel: eth0: vortex_error(), status=0xe003 Jul 10 23:33:48 localhost kernel: eth0: Host error, FIFO diagnostic register 0000. Jul 10 23:33:48 localhost kernel: eth0: PCI bus error, bus status 80000020 Jul 10 23:33:48 localhost kernel: eth0: using NWAY device table, not 8 Jul 10 23:33:48 localhost kernel: eth0: MII #0 status 0080, link partner capability 0080, info1 0010, setting half-duplex. Jul 10 23:33:48 localhost kernel: eth0: vortex_error(), status=0xe003 Jul 10 23:33:48 localhost kernel: eth0: Host error, FIFO diagnostic register 0000. Jul 10 23:33:48 localhost kernel: eth0: PCI bus error, bus status 80000020 Jul 10 23:33:48 localhost kernel: eth0: using NWAY device table, not 8 Jul 10 23:33:48 localhost kernel: eth0: MII #0 status 0080, link partner capability 0080, info1 0010, setting half-duplex. === I haven't been able to find a perfect test case to trigger the above bug. However, scp'ing a large directory from a remote machine (and repeating if required) seems to work. I also suspect that this problem causes the ocassional kernel oops, although I haven't been able to track it down. The hardware is an Intel Pentium-100 with a built-in EIDE controller and S3 video. The only addon card is a 3c905B 100BaseTX PCI card working at 10Mbps connecting via a hub. I have experienced this bug with both the Red Hat supplied 2.4.9-31 kernel as well as a custom-compiled version of the 2.4.18 kernel. The captures in this e-mail are all from the 2.4.18 kernel with the modprobe options of "debug=7". The rest of the system is a Red Hat 7.2 system with the ocassional update patch. Looking around the web, it appears that others have encountered similar behaviour, but that no-one has been able to track it down sufficiently to fix it. Nonetheless, I should note that: - Bus-mastering is on. Turning it off might help, but I don't know how. - I am not using SMP. The kernel doesn't support it and nor does the hardware. - I have removed every other addon cards. The EIDE controllers and video are both built-in. - The machine has two slots for PCI cards. I have reproduced this bug in either slot. - Replacing the 3C905B with a NE2000 PCI NIC eliminates the bug. The NE2000 card probably doesn't have bus-mastering. - With the modprobe options of "debug=7" only, the card is in half- duplex. With the additional option of "options=512", full-duplex is on. Regardless of the duplex setting, the bug is reproducible. - On another system (Athlon-class) with the same NIC model (3c905B Cyclone 100baseTx) and essentially the same software (Red Hat 7.2), no problems occur. - Therefore, I decided to physically swap the two 3c905B NIC between the two systems -- to eliminate the theory that I got one dodgy NIC. The Pentium-class system continued to have problems and the Athlon- class system continued to be trouble-free. I've included some debugging information which may be of use below. I know this is a hard bug to track down and I'd be glad to perform any additional debugging required. While "I Am Not A Kernel Hacker", if difficult debugging is required I'll give it a go. However, some prior emails indicates that it is a hardware fault. If so, can someone clarify whether it is the NIC, PC or both? Output of ``lspci -vx'' as root: === 00:00.0 Host bridge: Intel Corporation 430FX - 82437FX TSC [Triton I] (rev 02) Flags: bus master, medium devsel, latency 64 00: 86 80 2d 12 06 00 00 22 02 00 00 06 00 40 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:07.0 ISA bridge: Intel Corporation 82371FB PIIX ISA [Triton I] (rev 02) Flags: bus master, medium devsel, latency 0 00: 86 80 2e 12 0f 00 80 02 02 00 01 06 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:08.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+] (prog-if 00 [VGA]) Flags: VGA palette snoop, medium devsel, IRQ 3 Memory at fe000000 (32-bit, non-prefetchable) [size=8M] Expansion ROM at [disabled] [size=64K] 00: 33 53 11 88 23 00 00 02 00 00 00 03 00 00 00 00 10: 00 00 00 fe 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 03 01 00 00 00:13.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24) Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100 Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at fc80 [size=128] Memory at fffbfc00 (32-bit, non-prefetchable) [size=128] Expansion ROM at [disabled] [size=128K] Capabilities: [dc] Power Management version 1 00: b7 10 55 90 17 01 10 22 24 00 00 02 08 40 00 00 10: 81 fc 00 00 00 fc fb ff 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 55 90 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 0a 0a === debug=7 output upon NIC initialisation === 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt 00:13.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xfc80. Vers LK1.1.16 00:10:4b:0a:19:95, IRQ 11 product code 4e47 rev 00.9 date 04-21-98 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/10baseT interface. Enabling bus-master transmits and whole-frame receives. 00:13.0: scatter/gather enabled. h/w checksums enabled eth0: using NWAY device table, not 0 eth0: MII #0 status 0080, link partner capability 0080, info1 0010, setting half-duplex. === Thanks Eddie From becker@scyld.com Sun Jul 14 00:24:01 2002 From: becker@scyld.com (Donald Becker) Date: Sat Jul 13 23:24:01 2002 Subject: [vortex] 3c59x LK1.1.16 Linux-2.4 PCI bus error/Host error In-Reply-To: Message-ID: On Sun, 14 Jul 2002 epl@labyrinth.net.au wrote: > Subject: [vortex] 3c59x LK1.1.16 Linux-2.4 PCI bus error/Host error > > Using a 3com 905B-100BaseTX NIC with the 3c59x driver, I can induce > the module to lock-up by transferring large amounts of data via the > network. > > By bringing down the network I can stop flow of messages to syslog > (see below). If I restart the network without unloading the module, the > network stays locked up and the flow of messages to syslog resumes. If > I stop the network, unload the module and restart the network, I can > sanely use the network until the next lockup. > > I get the following (debug=7) error messages in my syslog: Note that debug=7 will likely overload the system when logging the messages. You should reduce the effect by setting asynchronous logging in /etc/syslog.conf with a "-" before the log file name. kern.* -/var/log/debug > Jul 10 23:32:56 localhost kernel: eth0: vortex_error(), status=0xe081 This is reporting StatsFull. Here is the comment from my driver release: /* HACK: Disable statistics as an interrupt source. */ /* This occurs when we have the wrong media type! */ So I suspect that your NIC is forced to the wrong media type. > Jul 10 23:33:48 localhost kernel: eth0: Host error, FIFO diagnostic register 0000. > Jul 10 23:33:48 localhost kernel: eth0: PCI bus error, bus status 80000020 >From the driver comments /* 0x80000000 PCI master abort. */ Your machine isn't reacting well to something. > Jul 10 23:33:48 localhost kernel: eth0: using NWAY device table, not 8 > Jul 10 23:33:48 localhost kernel: eth0: MII #0 status 0080, link partner capability 0080, info1 0010, setting half-duplex. This is bogus. Either change your EEPROM setting to the default, or avoid passing an invalid media type as an option. You shouldn't need to pass a module option. > The hardware is an Intel Pentium-100 with a built-in EIDE controller > and S3 video. The only addon card is a 3c905B 100BaseTX PCI card > working at 10Mbps connecting via a hub. A old Pentium-100... > Looking around the web, it appears that others have encountered > similar behaviour, but that no-one has been able to track it down > sufficiently to fix it. They might not have reported that it was fixed, but there isn't an unresolved bug that I know of. > Nonetheless, I should note that: > - Bus-mastering is on. Turning it off might help, but I don't know how. Is the card is a real bus-mastering slot? Some Pentium motherboards cheated. > - Replacing the 3C905B with a NE2000 PCI NIC eliminates the bug. The > NE2000 card probably doesn't have bus-mastering. Correct. > 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html > See Documentation/networking/vortex.txt > 00:13.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xfc80. Vers LK1.1.16 > 00:10:4b:0a:19:95, IRQ 11 > product code 4e47 rev 00.9 date 04-21-98 > 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/10baseT interface. This should read autoselect/NWay, not 10baseT. > eth0: using NWAY device table, not 0 > eth0: MII #0 status 0080, link partner capability 0080, info1 0010, setting half-duplex. -- 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 linux@lapd.cj.edu.ro Mon Jul 15 07:48:01 2002 From: linux@lapd.cj.edu.ro (Lists (lst)) Date: Mon Jul 15 06:48:01 2002 Subject: [vortex] Another problem [was: Re: Problems with an 3Com driver ...] In-Reply-To: Message-ID: Hi, Why after the 25 minutes of uptime I have a lots of errors on a 3Com509C NIC? # uptime 1:40pm up 25 min, 4 users, load average: 1.14, 0.37, 0.23 # ifconfig eth4 eth4 Link encap:Ethernet HWaddr 00:50:DA:89:E9:BE IPX/Ethernet 802.3 addr:19821230:0050DA89E9BE UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:14604 errors:3135 dropped:0 overruns:0 frame:3362 TX packets:38012 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:15440034 (14.7 Mb) TX bytes:5217993 (4.9 Mb) Interrupt:5 Base address:0xe000 On other NICs (Intel eepro100) it's no error. Thank you, Cosmin From becker@scyld.com Mon Jul 15 11:18:02 2002 From: becker@scyld.com (Donald Becker) Date: Mon Jul 15 10:18:02 2002 Subject: [vortex] Another problem [was: Re: Problems with an 3Com driver ...] In-Reply-To: Message-ID: On Mon, 15 Jul 2002, Lists (lst) wrote: > Why after the 25 minutes of uptime I have a lots of errors on a 3Com509C > NIC? ... > # uptime > 1:40pm up 25 min, 4 users, load average: 1.14, 0.37, 0.23 > # ifconfig eth4 > eth4 Link encap:Ethernet HWaddr 00:50:DA:89:E9:BE > IPX/Ethernet 802.3 addr:19821230:0050DA89E9BE > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:14604 errors:3135 dropped:0 overruns:0 frame:3362 > TX packets:38012 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > RX bytes:15440034 (14.7 Mb) TX bytes:5217993 (4.9 Mb) > Interrupt:5 Base address:0xe000 This looks as if you forced full duplex on a autonegotiation link. -- 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 epl@labyrinth.net.au Mon Jul 15 22:29:01 2002 From: epl@labyrinth.net.au (epl@labyrinth.net.au) Date: Mon Jul 15 21:29:01 2002 Subject: [vortex] 3c59x LK1.1.16 Linux-2.4 PCI bus error/Host error In-Reply-To: Message-ID: On Sat, 13 Jul 2002 Donald Becker wrote: > On Sun, 14 Jul 2002 epl@labyrinth.net.au wrote: > > kern.* -/var/log/debug > Added - thanks, I didn't know about that. I've just realised that my previous logs didn't include kern.debug. The logs in this email does. > > Jul 10 23:32:56 localhost kernel: eth0: vortex_error(), status=0xe081 > > This is reporting StatsFull. Here is the comment from my driver release: > /* HACK: Disable statistics as an interrupt source. */ > /* This occurs when we have the wrong media type! */ > So I suspect that your NIC is forced to the wrong media type. > Hmm, discovered something odd, not sure if it is important. If the module is loaded for the first time (case A) the debug messages is: === 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt 00:13.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xfc80. Vers LK1.1.16 00:10:4b:0a:19:95, IRQ 11 product code 4e47 rev 00.9 date 04-21-98 Internal config register is 1800000, transceivers 0xa. 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 786d. Enabling bus-master transmits and whole-frame receives. 00:13.0: scatter/gather enabled. h/w checksums enabled eth0: Filling in the Rx ring. eth0: using NWAY device table, not 8 eth0: Initial media type Autonegotiate. vortex_up(): writing 0x1800000 to InternalConfig eth0: MII #24 status 786d, link partner capability 0020, info1 0010, setting half-duplex. === If I unload the module and load it again -- without rebooting (case B): === 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt 00:13.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xfc80. Vers LK1.1.16 00:10:4b:0a:19:95, IRQ 11 product code 4e47 rev 00.9 date 04-21-98 Internal config register is 1000000, transceivers 0xa. 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/10baseT interface. Enabling bus-master transmits and whole-frame receives. 00:13.0: scatter/gather enabled. h/w checksums enabled eth0: Filling in the Rx ring. eth0: using NWAY device table, not 0 eth0: Initial media type Autonegotiate. vortex_up(): writing 0x1800000 to InternalConfig eth0: MII #0 status 0787, link partner capability 0787, info1 0010, setting full-duplex. === That could be the cause of some other weirdness like the media type. > > Jul 10 23:33:48 localhost kernel: eth0: using NWAY device table, not 8 > > Jul 10 23:33:48 localhost kernel: eth0: MII #0 status 0080, link partner capability 0080, info1 0010, setting half-duplex. > > This is bogus. Either change your EEPROM setting to the default, or > avoid passing an invalid media type as an option. You shouldn't need to > pass a module option. > But I didn't pass in any media type! The only option is debug=7. With both cases (A & B) it is possible for the network to lockup. Although my *gut* feeling says that it is more likely with case B. Anyway, I tried to lock up the network again in both cases. I have skipped a lot of output between module initialisation and network lockup -- which I am unsure of its importance. Noentheless, there are some differences between the output of each case. case A === eth0: MII #24 status 786d, link partner capability 0020, info1 0010, setting half-duplex. eth0: vortex_up() InternalConfig 01800000. eth0: vortex_up() irq 11 media status 88a0. eth0: In interrupt loop, status e003. eth0: vortex_error(), status=0xe003 eth0: Host error, FIFO diagnostic register 8000. eth0: PCI bus error, bus status 80000020 eth0: using NWAY device table, not 8 eth0: Initial media type Autonegotiate. vortex_up(): writing 0x1800000 to InternalConfig === case B === eth0: MII #0 status 0787, link partner capability 0787, info1 0010, setting full-duplex. eth0: vortex_up() InternalConfig 01800000. eth0: vortex_up() irq 11 media status 8880. eth0: In interrupt loop, status e003. eth0: vortex_error(), status=0xe003 eth0: Host error, FIFO diagnostic register 0000. eth0: PCI bus error, bus status 80000020 eth0: using NWAY device table, not 8 eth0: Initial media type Autonegotiate. vortex_up(): writing 0x1800000 to InternalConfig === > Your machine isn't reacting well to something. > thanks > > Nonetheless, I should note that: > > - Bus-mastering is on. Turning it off might help, but I don't know how. > > Is the card is a real bus-mastering slot? Some Pentium motherboards > cheated. > I have no idea whether the motherboard cheats. Other than the lspci output in the last email, I can tell you that the system is an IBM 330-P100, machine type 6576, model number 57H, manufactured date 605 (shurgs). I've tried looking on Google and IBM.com, but no motherboard information. > > - Replacing the 3C905B with a NE2000 PCI NIC eliminates the bug. The > > NE2000 card probably doesn't have bus-mastering. > > Correct. > How would I explicitly turn off bus-mastering? I can work out how to explicitly turn it on, but I can't work out how to turn it off. I wouldn't be surprised if it is the NIC or motherboard, but I'd like a confirmation if possible. Thanks Eddie From becker@scyld.com Tue Jul 16 02:28:01 2002 From: becker@scyld.com (Donald Becker) Date: Tue Jul 16 01:28:01 2002 Subject: [vortex] 3c59x LK1.1.16 Linux-2.4 PCI bus error/Host error In-Reply-To: Message-ID: On Tue, 16 Jul 2002 epl@labyrinth.net.au wrote: > Hmm, discovered something odd, not sure if it is important. If the > module is loaded for the first time (case A) the debug messages is: > === > 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html > See Documentation/networking/vortex.txt You should try using my driver ftp://ftp.scyld.com/pub/network/netdrivers.tgz and send a report. > 00:13.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xfc80. Vers LK1.1.16 > 00:10:4b:0a:19:95, IRQ 11 > 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. ... > eth0: using NWAY device table, not 8 > eth0: Initial media type Autonegotiate. ... > If I unload the module and load it again -- without rebooting (case B): ... > Internal config register is 1000000, transceivers 0xa. > 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/10baseT interface. ... > eth0: using NWAY device table, not 0 > vortex_up(): writing 0x1800000 to InternalConfig > eth0: MII #0 status 0787, link partner capability 0787, info1 0010, > setting full-duplex. Bogus results. -- 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 epl@labyrinth.net.au Thu Jul 18 08:21:01 2002 From: epl@labyrinth.net.au (epl@labyrinth.net.au) Date: Thu Jul 18 07:21:01 2002 Subject: [vortex] 3c59x LK1.1.16 Linux-2.4 PCI bus error/Host error In-Reply-To: Message-ID: On Tue, 16 Jul 2002 Donald Becker wrote: > On Tue, 16 Jul 2002 epl@labyrinth.net.au wrote: > > > Hmm, discovered something odd, not sure if it is important. If the > > module is loaded for the first time (case A) the debug messages is: > > === > > 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html > > See Documentation/networking/vortex.txt > > You should try using my driver > ftp://ftp.scyld.com/pub/network/netdrivers.tgz > and send a report. > The code compiled cleanly, but wouldn't even load as it complained of unresolved dependences: __io_virt_debug() and do_BUG(). Your code does not call either of these functions directly. OK, I figured I'd just add the following functions at the end of 3c59x.c === void do_BUG(const char *file, int line) { } void * __io_virt_debug(unsigned long x, const char *file, int line) { return (x < PAGE_OFFSET) ? __va(x) : (void *)x; } === The code compiled and loaded, but syslog showed the following messages (notice the timestamp, the errors occurred immediately): === Jul 18 20:52:51 localhost kernel: 3c59x.c:v0.99Xc 6/27/2002 Donald Becker, becker@scyld.com Jul 18 20:52:51 localhost kernel: http://www.scyld.com/network/vortex.html Jul 18 20:52:51 localhost kernel: eth0: 3Com 3c905B Cyclone 100baseTx at 0xfc80, 00:10:4b:0a:19:95, IRQ 11 Jul 18 20:52:51 localhost kernel: Internal config register is 01800000, transceivers 0xa. Jul 18 20:52:51 localhost kernel: 8K buffer 5:3 Rx:Tx split, autoselect/Autonegotiate interface. Jul 18 20:52:52 localhost kernel: MII transceiver found at address 24, status 7849. Jul 18 20:52:52 localhost kernel: MII transceiver found at address 0, status 7849. Jul 18 20:52:52 localhost kernel: Using bus-master transmits and whole-frame receives. Jul 18 20:52:52 localhost kernel: eth0: Initial media type Autonegotiate half-duplex. Jul 18 20:52:52 localhost kernel: eth0: MII #24 status 7849, link partner capability 0000, setting half-duplex. Jul 18 20:52:52 localhost kernel: eth0: vortex_open() irq 11 media status 8080. Jul 18 20:52:52 localhost kernel: eth0: Media selection timer tick happened, Autonegotiate half duplex. Jul 18 20:52:52 localhost kernel: eth0: MII transceiver has status 7849. Jul 18 20:52:52 localhost kernel: eth0: Media selection timer finished, Autonegotiate. Jul 18 20:52:52 localhost kernel: eth0: Host error, status e003, FIFO diagnostic register 0000. Jul 18 20:52:52 localhost kernel: eth0: PCI bus error, bus status 800000a0, reset had 2000 tick left. Jul 18 20:52:52 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 18 20:52:52 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 18 20:52:52 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 18 20:52:52 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 18 20:52:53 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 18 20:52:53 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 18 20:52:53 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. === Did I mangle the driver? If so, how would I get it to load cleanly? Cheers Eddie From becker@scyld.com Fri Jul 19 08:33:01 2002 From: becker@scyld.com (Donald Becker) Date: Fri Jul 19 07:33:01 2002 Subject: [vortex] 3c59x LK1.1.16 Linux-2.4 PCI bus error/Host error In-Reply-To: Message-ID: On Thu, 18 Jul 2002 epl@labyrinth.net.au wrote: > On Tue, 16 Jul 2002 Donald Becker wrote: > > On Tue, 16 Jul 2002 epl@labyrinth.net.au wrote: > The code compiled cleanly, but wouldn't even load as it complained > of unresolved dependences: __io_virt_debug() and do_BUG(). Your code > does not call either of these functions directly. I hadn't heard of these functions, so I tracked them down. They are only used if CONFIG_DEBUG_IOVIRT is defined. You shouldn't have that defined unless you are debugging you kernel, as the debugging code adds overhead. (Remember, on modern machines it's not the extra instructions, it's the larger cache footprint.) It looks as if someone broke CONFIG_DEBUG_IOVIRT on your kernel+distribution. It's pretty difficult to see this as a driver problem. > The code compiled and loaded, but syslog showed the following > messages (notice the timestamp, the errors occurred immediately): > === > Jul 18 20:52:51 localhost kernel: 3c59x.c:v0.99Xc 6/27/2002 Donald Becker, becker@scyld.com > Jul 18 20:52:51 localhost kernel: http://www.scyld.com/network/vortex.html > Jul 18 20:52:51 localhost kernel: eth0: 3Com 3c905B Cyclone 100baseTx at 0xfc80, 00:10:4b:0a:19:95, IRQ 11 > Jul 18 20:52:51 localhost kernel: Internal config register is 01800000, transceivers 0xa. > Jul 18 20:52:51 localhost kernel: 8K buffer 5:3 Rx:Tx split, autoselect/Autonegotiate interface. > Jul 18 20:52:52 localhost kernel: MII transceiver found at address 24, status 7849. There is no link beat. > Jul 18 20:52:52 localhost kernel: MII transceiver found at address 0, status 7849. > Jul 18 20:52:52 localhost kernel: Using bus-master transmits and whole-frame receives. > Jul 18 20:52:52 localhost kernel: eth0: Initial media type Autonegotiate half-duplex. Normal, and apparently correct. > Jul 18 20:52:52 localhost kernel: eth0: MII #24 status 7849, link partner capability 0000, setting half-duplex. > Jul 18 20:52:52 localhost kernel: eth0: vortex_open() irq 11 media status 8080. > Jul 18 20:52:52 localhost kernel: eth0: Media selection timer tick happened, Autonegotiate half duplex. > Jul 18 20:52:52 localhost kernel: eth0: MII transceiver has status 7849. Still no link beat. What is the debugging level? High enough to see packet transmit attempts? Could there have been a received packet? > Jul 18 20:52:52 localhost kernel: eth0: Media selection timer finished, Autonegotiate. > Jul 18 20:52:52 localhost kernel: eth0: Host error, status e003, FIFO diagnostic register 0000. > Jul 18 20:52:52 localhost kernel: eth0: PCI bus error, bus status 800000a0, reset had 2000 tick left. OK, we had a real PCI bus error, a PCI master abort. We don't know what triggered the bus transaction Could there have been a received packet? The reset succeeded immediately, so the chip is responding. AFAIK, the driver is doing everything it needs to during a reset. > Did I mangle the driver? If so, how would I get it to load cleanly? The module load problem is unrelated to the operational problem here.. -- 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 Patrik.Schindler@reiff.de Mon Jul 22 06:56:00 2002 From: Patrik.Schindler@reiff.de (Patrik Schindler) Date: Mon Jul 22 05:56:00 2002 Subject: [vortex] Strange Link Behaviour of 3C90x Card with Fiber Converters Message-ID: Hello, I want to report a long standing problem, which I now chased down a bit. We use the following setup: +---------+ +--------+ +--------+ +--------+ | 3C90x +---+ LWL-TP +-------+ LWL-TP +---+ Switch | +---------+ +--------+ +--------+ +--------+ The Cards are both 3C900(B) and 3C905(B&C-TX). The Converters are Allied Telesyn with link-thru feature and Auto-Negotiation support (MC-xxx). We tested some types of switches: Allied Telesyn, 3Com 3300 Series and two No-Name products. All show the same behaviour. The most interesting part is that simple (single speed) hubs just work. After connecting the device(s) no link could be established. When I type an "ifconfig eth0 down" and thereafter an "ifconfig eth0 up" then I can see from the LEDs that the card establishes a link to the first converter. This device itself switches on the link of the fiber side. The other converter switches the link on the ethernet side on. Then the switch itself recognizes the signal and sends it's link-signal back. When the link arrives back at the card, the card (or the driver) has given up. The link is gone. The whole process takes only a few seconds, maybe 1 or 2. The only way to get the thing running is: Ifconfig card down Switch link test on the converter at switch side on ifconfig card up Switch link test off again. Than the link doesn't vanish. I'm sure that this problem is card/driver related, since a Intel EtherExpress Pro doesn't show this behaviour. The card itself performs a bit slower under linux and that's why I'd like to stay with 3Com. But to do this procedure everytime after a reboot is a bit nasty. Thanks for any advice. MfG, P. Schindler -------------------------------------------------------------------- Technische Administration / Technologiezentrum Fon 0781-504-4040 PGP-Key auf Anfrage Fax 0781-504-6309 From becker@scyld.com Mon Jul 22 11:02:01 2002 From: becker@scyld.com (Donald Becker) Date: Mon Jul 22 10:02:01 2002 Subject: [vortex] Strange Link Behaviour of 3C90x Card with Fiber Converters In-Reply-To: Message-ID: On Mon, 22 Jul 2002, Patrik Schindler wrote: > We use the following setup: > > +---------+ +--------+ +--------+ +--------+ > | 3C90x +---+ LWL-TP +-------+ LWL-TP +---+ Switch | > +---------+ +--------+ +--------+ +--------+ > > The Cards are both 3C900(B) and 3C905(B&C-TX). > The Converters are Allied Telesyn with link-thru feature and > Auto-Negotiation support (MC-xxx). What does 'mii-diag --watch' report? > We tested some types of switches: Allied Telesyn, 3Com 3300 Series and two > No-Name products. All show the same behaviour. The most interesting part > is that simple (single speed) hubs just work. That points out the problem is the autonegotiation timing. > After connecting the device(s) no link could be established. When I type > an "ifconfig eth0 down" and thereafter an "ifconfig eth0 up" then I can > see from the LEDs that the card establishes a link to the first converter. > This device itself switches on the link of the fiber side. The other > converter switches the link on the ethernet side on. Then the switch > itself recognizes the signal and sends it's link-signal back. When the > link arrives back at the card, the card (or the driver) has given up. The > link is gone. That means the media type converters tooks too long to establish link. Media type converters are notorious for violating the specs, and these appear to be no exception. > The whole process takes only a few seconds, maybe 1 or 2. Without knowing the the details of the devices I can't guess where the timing problem is, but process slow enough to observe is too slow for the autonegotiation protocol. > I'm sure that this problem is card/driver related, since a Intel > EtherExpress Pro doesn't show this behaviour. Which specific card? Again, what does 'mii-diag eth0 --watch' report? -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Tue Jul 23 12:48:01 2002 From: becker@scyld.com (Donald Becker) Date: Tue Jul 23 11:48:01 2002 Subject: [vortex] Re: [3c509] OEM/Ethernet Addr set to 00:00:00:00:00:00? In-Reply-To: <1027395093.68718.ON7dUzEgRXqQEcYpwCfHsvM6elsXH0SmEQq@micropixel.com> Message-ID: On Mon, 22 Jul 2002 achen-scyld@divo.net wrote: > Subject: [3c509] OEM/Ethernet Addr set to 00:00:00:00:00:00? Ahhh, a non-spam posting on the 3c509 list. I had to delete 34 other messages before I got to this one. > I'm using a 3c920 card included with an Asus A7M266-DL motherboard. Alas, it's a message that should have been sent to the vortex mailing list. Still, I'll answer it here. > The eeprom onboard (As read with vortex-diag), says that the ethernet MAC is > 00:00:00:00:00:00. This is evidently incorrect since the card has a real > MAC address, but why isn't it being used? Is this a fault in the driver > or in the eeprom? I'm using the driver out of the 2.4.18 kernel: > > 02:06.0: 3Com PCI 3c905C Tornado at 0xc400. Vers LK1.1.16 Note that the 920 and 905 are the same chip. The number is changed depending on the application (PCI card, on-motherboard implementation, etc.) > Thanks. Please find attached some debugging output: > > $ sudo ./vortex-diag -ee > vortex-diag.c:v2.06 4/18/2002 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a 3c905C Tornado 100baseTx adapter at 0xc400. > EEPROM format 64x16, configuration table at offset 0: Normal size and offset for a non-CardBus adapter without modified PCI IDs. > 00: 00e0 1886 4ce8 9200 ffff ffff ffff 6d51 > 0x08: 2940 0000 0000 0000 0000 0010 0000 00aa > 0x10: 72a2 0000 0000 0180 0000 0000 0000 10b7 > 0x18: 1000 000a 0000 6300 ffb7 b7b7 0000 0000 > 0x20: 0000 1234 5670 0000 0000 0000 0000 0000 > ... > > The word-wide EEPROM checksum is 0xa78b. > Saved EEPROM settings of a 3Com Vortex/Boomerang: > 3Com Node Address 00:E0:18:86:4C:E8 (used as a unique ID only). > OEM Station address 00:00:00:00:00:00 (used as the ethernet address). > Device ID 9200, Manufacturer ID 6d51. > Manufacture date (MM/DD/YYYY) 15/31/2027, division , product . > No BIOS ROM is present. > Options: negotiated duplex, link beat required. > Vortex format checksum is incorrect (00f6 vs. 10b7). > Cyclone format checksum is incorrect (0x4b vs. 00). > Hurricane format checksum is incorrect (0x60 vs. 00). OK, this interpreted information is correctly reporting the chip EEPROM contents. But I can't figure out how you managed to erase the station address! You didn't use "vortex-diag -H ...", because that wouldn't have left an incorrect checksum. The EEPROM didn't have some obvious hardware failure, because much of the other information is correct. (Although that Manufacture Date and other fields are either 0x0000 or 0xffff.) Before we fix this, how did it happen? How old is the motherboard? Did it work when you got it? What OS have you been running? The '1234' and '5670' fields in the EEPROM look suspiciously like some hand manipulation. The fix will involve adding a few lines in vortex-diag to replace the missing fields. -- 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 achen-scyld@divo.net Tue Jul 23 17:08:01 2002 From: achen-scyld@divo.net (Andrew A. Chen) Date: Tue Jul 23 16:08:01 2002 Subject: [vortex] Re: [3c509] OEM/Ethernet Addr set to 00:00:00:00:00:00? In-Reply-To: Message-ID: <1027454843.20348.1DON1UIYQO2xxtW0LFoC8y06MH1rfbt6E8J@micropixel.com> On Tue, 23 Jul 2002, Donald Becker wrote: > On Mon, 22 Jul 2002 achen-scyld@divo.net wrote: > > > Subject: [3c509] OEM/Ethernet Addr set to 00:00:00:00:00:00? > > Ahhh, a non-spam posting on the 3c509 list. I had to delete 34 other > messages before I got to this one. Quite a refreshing feeling, isn't it? :) > > I'm using a 3c920 card included with an Asus A7M266-DL motherboard. > > Alas, it's a message that should have been sent to the vortex mailing > list. > Still, I'll answer it here. > > > The eeprom onboard (As read with vortex-diag), says that the ethernet MAC is > > 00:00:00:00:00:00. This is evidently incorrect since the card has a real > > MAC address, but why isn't it being used? Is this a fault in the driver > > or in the eeprom? I'm using the driver out of the 2.4.18 kernel: > > > > 02:06.0: 3Com PCI 3c905C Tornado at 0xc400. Vers LK1.1.16 > > Note that the 920 and 905 are the same chip. The number is changed > depending on the application (PCI card, on-motherboard implementation, etc.) > > > Thanks. Please find attached some debugging output: > > > > $ sudo ./vortex-diag -ee > > vortex-diag.c:v2.06 4/18/2002 Donald Becker (becker@scyld.com) > > http://www.scyld.com/diag/index.html > > Index #1: Found a 3c905C Tornado 100baseTx adapter at 0xc400. > > EEPROM format 64x16, configuration table at offset 0: > > Normal size and offset for a non-CardBus adapter without modified PCI IDs. > > > 00: 00e0 1886 4ce8 9200 ffff ffff ffff 6d51 > > 0x08: 2940 0000 0000 0000 0000 0010 0000 00aa > > 0x10: 72a2 0000 0000 0180 0000 0000 0000 10b7 > > 0x18: 1000 000a 0000 6300 ffb7 b7b7 0000 0000 > > 0x20: 0000 1234 5670 0000 0000 0000 0000 0000 > > ... > > > > The word-wide EEPROM checksum is 0xa78b. > > Saved EEPROM settings of a 3Com Vortex/Boomerang: > > 3Com Node Address 00:E0:18:86:4C:E8 (used as a unique ID only). > > OEM Station address 00:00:00:00:00:00 (used as the ethernet address). > > Device ID 9200, Manufacturer ID 6d51. > > Manufacture date (MM/DD/YYYY) 15/31/2027, division , product . > > No BIOS ROM is present. > > Options: negotiated duplex, link beat required. > > Vortex format checksum is incorrect (00f6 vs. 10b7). > > Cyclone format checksum is incorrect (0x4b vs. 00). > > Hurricane format checksum is incorrect (0x60 vs. 00). > > OK, this interpreted information is correctly reporting the chip EEPROM > contents. But I can't figure out how you managed to erase the station > address! > You didn't use "vortex-diag -H ...", because that wouldn't have left an > incorrect checksum. > The EEPROM didn't have some obvious hardware failure, because much of > the other information is correct. (Although that Manufacture Date and > other fields are either 0x0000 or 0xffff.) > > Before we fix this, how did it happen? I dunno. "It came that way," as many say... (I pulled it out of the static bag and plugged it in :) > How old is the motherboard? Did it work when you got it? This isn't actually onboard the motherboard. It's a separate PCI adapter (also manafactured by Asus, however, and has a warning sticker on it saying "Only use in Asus motherboards"). This motherboard was first released last september, and I believe the revision I have was updated less than 2 months ago. The output as above is as I receieved it. It works fine when talking to the local subnet, but I suspect my default router (controlled by my isp) is filtering that MAC address (as it probably assumes it's bogus). > What OS have you been running? Linux Slackware 8.1, with a recompiled Linux 2.4.18 kernel. Thanks. -a > The '1234' and '5670' fields in the EEPROM look suspiciously like > some hand manipulation. > > The fix will involve adding a few lines in vortex-diag to replace the > missing fields. > > -- > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters > Annapolis MD 21403 410-990-9993 > From becker@scyld.com Tue Jul 23 19:46:02 2002 From: becker@scyld.com (Donald Becker) Date: Tue Jul 23 18:46:02 2002 Subject: [vortex] Re: [3c509] OEM/Ethernet Addr set to 00:00:00:00:00:00? In-Reply-To: <1027454843.20348.1DON1UIYQO2xxtW0LFoC8y06MH1rfbt6E8J@micropixel.com> Message-ID: On Tue, 23 Jul 2002, Andrew A. Chen wrote: > On Tue, 23 Jul 2002, Donald Becker wrote: > > On Mon, 22 Jul 2002 achen-scyld@divo.net wrote: > > > 00: 00e0 1886 4ce8 9200 ffff ffff ffff 6d51 > > > 0x08: 2940 0000 0000 0000 0000 0010 0000 00aa > > > 0x10: 72a2 0000 0000 0180 0000 0000 0000 10b7 > > > 0x18: 1000 000a 0000 6300 ffb7 b7b7 0000 0000 > > > 0x20: 0000 1234 5670 0000 0000 0000 0000 0000 > > > ... > > > The word-wide EEPROM checksum is 0xa78b. > > > Saved EEPROM settings of a 3Com Vortex/Boomerang: > > > 3Com Node Address 00:E0:18:86:4C:E8 (used as a unique ID only). > > > OEM Station address 00:00:00:00:00:00 (used as the ethernet address). > > > Manufacture date (MM/DD/YYYY) 15/31/2027, division , product . So this is a brand-new NIC, never used with another OS, correct? Did the NIC come with a custom driver? > This isn't actually onboard the motherboard. It's a separate PCI adapter > (also manafactured by Asus, however, and has a warning sticker on it > saying "Only use in Asus motherboards"). This motherboard was first > released last september, and I believe the revision I have was updated > less than 2 months ago. I think I now understand what is going on. This appears to be an OEM NIC. The vendor is supposed program the following EEPROM fields Offset Name 4 Manufacturing Data -- Date 5 Manufacturing Data -- Division 6 Manufacturing Data -- Product Code ... 10 OEM node address, word 0 11 OEM node address, word 1 12 OEM node address, word 2 This vendor (Asus) failed to program the device. > > The fix will involve adding a few lines in vortex-diag to replace the > > missing fields. Given that only the OEM fields are bogus, the existing '-H' option will make your EEPROM functional. vortex-diag -H 00:E0:18:86:4C:E8 -w -w -- 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 paulm@medent.com Thu Jul 25 16:32:01 2002 From: paulm@medent.com (Paul Meyers) Date: Thu Jul 25 15:32:01 2002 Subject: [vortex] 3c905c auto negotiation Message-ID: <200207251529.AA4063524@mail.medent.com> Hello, I am having a bit of trouble with my 3c905c's , about 4 of my 10 servers run poorly (about 15 mips throughput) when my hp switch (j4813a) is set to auto (the switch status indicates 100fdx). The only way I can get them up to 100 mips is by setting the switch to forced 100Hdx. For some reason mii-tools doesnt on these cards, maybe because they are add on (not hard coded into bios). The built in nic in these servers (amd or intel cards) , auto works fine (and mii-tools for that matter) I called hp, all our firmware is ok, and they are unaware of any linux 3com issues... apparently I have a magic combination problem, and to top it off, it only effects some 3com (3c905c and 3c905b) cards. If there is any debug info,etc, I can provide, please let me know... Thank You. Paul Meyers Systems Administrator Community Computer Service voice:315-255-0900 fax: 315-255-0416 paulm@medent.com __________________________________________________ Sent via WebMail @ Incoming/Outgoing mail is certified Virus Free! Checked by Symantec Carrier-Scan. From becker@scyld.com Thu Jul 25 17:21:01 2002 From: becker@scyld.com (Donald Becker) Date: Thu Jul 25 16:21:01 2002 Subject: [vortex] 3c905c auto negotiation In-Reply-To: <200207251529.AA4063524@mail.medent.com> Message-ID: On Thu, 25 Jul 2002, Paul Meyers wrote: > I am having a bit of trouble with my 3c905c's , about 4 of my 10 > servers run poorly (about 15 mips throughput) when my hp switch > (j4813a) is set to auto (the switch status indicates 100fdx). What driver version? What is the detection message? What does 'mii-diag' report? > The only > way I can get them up to 100 mips is by setting the switch to forced > 100Hdx. For some reason mii-tools doesnt on these cards, maybe because > they are add on (not hard coded into bios). Does 'mii-diag' work? Only on the problem card, or on all cards? Have you tried the current driver? v99Xc -- 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 epl@labyrinth.net.au Sat Jul 27 11:21:01 2002 From: epl@labyrinth.net.au (epl@labyrinth.net.au) Date: Sat Jul 27 10:21:01 2002 Subject: [vortex] 3c59x LK1.1.16 Linux-2.4 PCI bus error/Host error In-Reply-To: Message-ID: Apologies for the delay as the original email disappeared (with no bounce messages). I suspect it was due to an attachment in the first one. Let's hope there isn't a size limit too. On Tue, 19 Jul 2002 Donald Becker wrote: > It looks as if someone broke CONFIG_DEBUG_IOVIRT on your OK, my fault, I compiled my kernel with CONFIG_DEBUG_IOVIRT. The kernel and modules used to produce the logs within this email has since been recompiled. > > Jul 18 20:52:52 localhost kernel: eth0: MII #24 status 7849, link partner capability 0000, setting half-duplex. > > Jul 18 20:52:52 localhost kernel: eth0: vortex_open() irq 11 media status 8080. > > Jul 18 20:52:52 localhost kernel: eth0: Media selection timer tick happened, Autonegotiate half duplex. > > Jul 18 20:52:52 localhost kernel: eth0: MII transceiver has status 7849. > > Still no link beat. > What is the debugging level? debug=7 in the previous email as well as this one. > High enough to see packet transmit attempts? I guess so, since it is the highest debug level. > Could there have been a received packet? > I doubt it, though I can't rule it out. So I've repeated the test with the network cable physically disconnected -- surely no packets can be received now! The logs are at the end of this message. Anyway, there are three phases within the logs. 1) From 21:31:28 to 21:31:28 - I ran "modprobe 3c59x" 2) From 21:31:44 to 21:31:49 - I ran "/etc/init.d/network start" 3) From 21:31:52 to 21:31:52 - I ran "/etc/init.d/network stop" Before 1), the system have booted into multi-user mode without loading the 3c59x module beforehand. After 3), the system is fine, other than not being able to use the network. > > Jul 18 20:52:52 localhost kernel: eth0: Media selection timer finished, Autonegotiate. > > Jul 18 20:52:52 localhost kernel: eth0: Host error, status e003, FIFO diagnostic register 0000. > > Jul 18 20:52:52 localhost kernel: eth0: PCI bus error, bus status 800000a0, reset had 2000 tick left. > > OK, we had a real PCI bus error, a PCI master abort. > We don't know what triggered the bus transaction > Could there have been a received packet? > As above. > The reset succeeded immediately, so the chip is responding. > AFAIK, the driver is doing everything it needs to during a reset. > This driver is clearly more unstable than the standard Linux one. Eddie === Jul 21 21:31:28 localhost kernel: 3c59x.c:v0.99Xc 6/27/2002 Donald Becker, becker@scyld.com Jul 21 21:31:28 localhost kernel: http://www.scyld.com/network/vortex.html Jul 21 21:31:28 localhost kernel: eth0: 3Com 3c905B Cyclone 100baseTx at 0xfc80, 00:10:4b:0a:19:95, IRQ 11 Jul 21 21:31:28 localhost kernel: Internal config register is 01800000, transceivers 0xa. Jul 21 21:31:28 localhost kernel: 8K buffer 5:3 Rx:Tx split, autoselect/Autonegotiate interface. Jul 21 21:31:28 localhost kernel: MII transceiver found at address 24, status 7849. Jul 21 21:31:28 localhost kernel: MII transceiver found at address 0, status 7849. Jul 21 21:31:28 localhost kernel: Using bus-master transmits and whole-frame receives. Jul 21 21:31:44 localhost kernel: eth0: Initial media type Autonegotiate half-duplex. Jul 21 21:31:44 localhost kernel: eth0: MII #24 status 7849, link partner capability 0000, setting half-duplex. Jul 21 21:31:44 localhost kernel: eth0: vortex_open() irq 11 media status 8080. Jul 21 21:31:47 localhost kernel: eth0: Host error, status e003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 800000a0, reset had 2000 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:48 localhost kernel: eth0: Too much work in interrupt, status 8003. Temporarily disabling functions (7ffc). Jul 21 21:31:48 localhost kernel: eth0: Media selection timer tick happened, Autonegotiate half duplex. Jul 21 21:31:48 localhost kernel: eth0: MII transceiver has status 7849. Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:49 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:49 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:49 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:49 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:49 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:49 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:49 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:49 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:49 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:49 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:49 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:49 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:49 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. Jul 21 21:31:49 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. Jul 21 21:31:49 localhost kernel: eth0: Too much work in interrupt, status 8003. Temporarily disabling functions (7ffc). Jul 21 21:31:49 localhost kernel: eth0: Media selection timer finished, Autonegotiate. Jul 21 21:31:52 localhost kernel: eth0: vortex_close() status 8000, Tx status 00. Jul 21 21:31:52 localhost kernel: eth0: vortex close stats: rx_nocopy 0 rx_copy 0 tx_queued 2 Rx pre-checksummed 0. From pemmaiah@cc.usu.edu Sun Jul 28 04:52:02 2002 From: pemmaiah@cc.usu.edu (Anup Pemmaiah) Date: Sun Jul 28 03:52:02 2002 Subject: [vortex] 3c59x LK1.1.16 Linux-2.4 PCI bus error/Host error Message-ID: <3D435006@webmail.usu.edu> I have a similar problem as that of Eddie. I have 3c905 - 100 Base TX Boomerang NIC. I use 3c59x driver for this. Installation works on fine. When I start a tranmission, either the DHCP daemon to get th IP address or just try to transmit some message I get the PCI bus error/Host error as shown below. When the error occurs the status register will have the value 0xe803 and the FIFO diagnostic register will have 2000. When I went through the specifications of the driver, the first bit of the status register says the interrupt is latched and the second bit specifies that there is a host error. When I checked the reason for the Host error in the FIFO doagnostic register where the 13th bit is set, it states that the interrupt was generated because of "rxUnderrun".Since the reason it states that the "Host is trying to read from the receive FIFO faster than the network can fill it and therefore the host reads invalid data", should I reduce the reading speed of the Host? If so how to do it. I checked the status of the bus from PktStatus (DmaCtrl) register. According to it, the "upComplete" and the "upRxEarlyEnable" are set, from which I could not find any problems. It will be great if you can send me suggestions regarding this. Have a great day. The debug results are (The results does not vary much with differnet debug levels) -------------------------------------------------------------------- Jul 27 22:55:27 Anup kernel: PCI: Found IRQ 11 for device 00:11.0 Jul 27 22:55:27 Anup kernel: PCI: Sharing IRQ 11 with 00:07.2 Jul 27 22:55:27 Anup kernel: 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html Jul 27 22:55:27 Anup kernel: 00:11.0: 3Com PCI 3c905 Boomerang 100baseTx at 0xdc80. Vers LK1.1.16 Jul 27 22:55:27 Anup kernel: Jul 27 22:55:27 Anup kernel: --------- 3c59x ioaddr:- 56448<1> Jul 27 22:55:27 Anup kernel: --------- 3c59x IRQ:- 11<1> Jul 27 22:55:27 Anup kernel: --------- 3c59x base:- 128<1> Jul 27 22:55:27 Anup kernel: ----- 00<1> Jul 27 22:55:27 Anup kernel: -----:c0<1> Jul 27 22:55:27 Anup kernel: -----:4f<1> Jul 27 22:55:27 Anup kernel: -----:ae<1> Jul 27 22:55:27 Anup kernel: -----:6c<1> Jul 27 22:55:42 Anup kernel: -----:eb Jul 27 22:55:42 Anup kernel: boomerang_interrupt. status=0xe803 Jul 27 22:55:42 Anup kernel: eth0: Host error, FIFO diagnostic register 2000. Jul 27 22:55:42 Anup kernel: eth0: PCI bus error, bus status 00a00029 Jul 27 22:55:42 Anup kernel: Jul 27 22:55:42 Anup kernel: boomerang_interrupt. status=0xe201 Jul 27 22:55:42 Anup kernel: Jul 27 22:55:42 Anup kernel: boomerang_interrupt. status=0xe005 Jul 27 22:55:42 Anup kernel: eth0: Transmit error, Tx status register 90. Jul 27 22:55:42 Anup kernel: Flags; bus-master 1, dirty 1(1) current 1(1) Jul 27 22:55:42 Anup kernel: Transmit list 00000000 vs. c75e4240. Jul 27 22:55:42 Anup kernel: 0: @c75e4200 length 8000024e status 8000024e Jul 27 22:55:42 Anup kernel: 1: @c75e4240 length 00000000 status 00000000 Jul 27 22:55:42 Anup kernel: 2: @c75e4280 length 00000000 status 00000000 Jul 27 22:55:42 Anup kernel: 3: @c75e42c0 length 00000000 status 00000000 Jul 27 22:55:42 Anup kernel: 4: @c75e4300 length 00000000 status 00000000 Jul 27 22:55:42 Anup kernel: 5: @c75e4340 length 00000000 status 00000000 Jul 27 22:55:42 Anup kernel: 6: @c75e4380 length 00000000 status 00000000 Jul 27 22:55:42 Anup kernel: 7: @c75e43c0 length 00000000 status 00000000 Jul 27 22:55:42 Anup kernel: 8: @c75e4400 length 00000000 status 00000000 Jul 27 22:55:42 Anup kernel: 9: @c75e4440 length 00000000 status 00000000 Jul 27 22:55:42 Anup kernel: 10: @c75e4480 length 00000000 status 00000000 Jul 27 22:55:42 Anup kernel: 11: @c75e44c0 length 00000000 status 00000000 Jul 27 22:55:43 Anup kernel: 12: @c75e4500 length 00000000 status 00000000 Jul 27 22:55:43 Anup kernel: 13: @c75e4540 length 00000000 status 00000000 Jul 27 22:55:43 Anup kernel: 14: @c75e4580 length 00000000 status 00000000 Jul 27 22:55:43 Anup kernel: 15: @c75e45c0 length 00000000 status 00000000 Jul 27 22:55:51 Anup dhcpcd[1777]: terminating on signal 2 --------------------------------------------------------------------------- Thank you Anup >===== Original Message From epl@labyrinth.net.au ===== >Apologies for the delay as the original email disappeared (with no >bounce messages). I suspect it was due to an attachment in the first >one. Let's hope there isn't a size limit too. > >On Tue, 19 Jul 2002 Donald Becker wrote: > >> It looks as if someone broke CONFIG_DEBUG_IOVIRT on your > > OK, my fault, I compiled my kernel with CONFIG_DEBUG_IOVIRT. The >kernel and modules used to produce the logs within this email has since >been recompiled. > >> > Jul 18 20:52:52 localhost kernel: eth0: MII #24 status 7849, link partner capability 0000, setting half-duplex. >> > Jul 18 20:52:52 localhost kernel: eth0: vortex_open() irq 11 media status 8080. >> > Jul 18 20:52:52 localhost kernel: eth0: Media selection timer tick happened, Autonegotiate half duplex. >> > Jul 18 20:52:52 localhost kernel: eth0: MII transceiver has status 7849. >> >> Still no link beat. >> What is the debugging level? > > debug=7 in the previous email as well as this one. > >> High enough to see packet transmit attempts? > > I guess so, since it is the highest debug level. > >> Could there have been a received packet? >> > I doubt it, though I can't rule it out. So I've repeated the test >with the network cable physically disconnected -- surely no packets can >be received now! The logs are at the end of this message. > > Anyway, there are three phases within the logs. >1) From 21:31:28 to 21:31:28 - I ran "modprobe 3c59x" >2) From 21:31:44 to 21:31:49 - I ran "/etc/init.d/network start" >3) From 21:31:52 to 21:31:52 - I ran "/etc/init.d/network stop" > > Before 1), the system have booted into multi-user mode without >loading the 3c59x module beforehand. After 3), the system is fine, >other than not being able to use the network. > >> > Jul 18 20:52:52 localhost kernel: eth0: Media selection timer finished, Autonegotiate. >> > Jul 18 20:52:52 localhost kernel: eth0: Host error, status e003, FIFO diagnostic register 0000. >> > Jul 18 20:52:52 localhost kernel: eth0: PCI bus error, bus status 800000a0, reset had 2000 tick left. >> >> OK, we had a real PCI bus error, a PCI master abort. >> We don't know what triggered the bus transaction >> Could there have been a received packet? >> > As above. > >> The reset succeeded immediately, so the chip is responding. >> AFAIK, the driver is doing everything it needs to during a reset. >> > This driver is clearly more unstable than the standard Linux one. > >Eddie >=== >Jul 21 21:31:28 localhost kernel: 3c59x.c:v0.99Xc 6/27/2002 Donald Becker, becker@scyld.com >Jul 21 21:31:28 localhost kernel: http://www.scyld.com/network/vortex.html >Jul 21 21:31:28 localhost kernel: eth0: 3Com 3c905B Cyclone 100baseTx at 0xfc80, 00:10:4b:0a:19:95, IRQ 11 >Jul 21 21:31:28 localhost kernel: Internal config register is 01800000, transceivers 0xa. >Jul 21 21:31:28 localhost kernel: 8K buffer 5:3 Rx:Tx split, autoselect/Autonegotiate interface. >Jul 21 21:31:28 localhost kernel: MII transceiver found at address 24, status 7849. >Jul 21 21:31:28 localhost kernel: MII transceiver found at address 0, status 7849. >Jul 21 21:31:28 localhost kernel: Using bus-master transmits and whole-frame receives. > >Jul 21 21:31:44 localhost kernel: eth0: Initial media type Autonegotiate half-duplex. >Jul 21 21:31:44 localhost kernel: eth0: MII #24 status 7849, link partner capability 0000, setting half-duplex. >Jul 21 21:31:44 localhost kernel: eth0: vortex_open() irq 11 media status 8080. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status e003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 800000a0, reset had 2000 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:47 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:47 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:48 localhost kernel: eth0: Too much work in interrupt, status 8003. Temporarily disabling functions (7ffc). >Jul 21 21:31:48 localhost kernel: eth0: Media selection timer tick happened, Autonegotiate half duplex. >Jul 21 21:31:48 localhost kernel: eth0: MII transceiver has status 7849. >Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:48 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:48 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:49 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:49 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:49 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:49 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:49 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:49 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:49 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:49 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:49 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:49 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:49 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:49 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:49 localhost kernel: eth0: Host error, status 8003, FIFO diagnostic register 0000. >Jul 21 21:31:49 localhost kernel: eth0: PCI bus error, bus status 80000020, reset had 1999 tick left. >Jul 21 21:31:49 localhost kernel: eth0: Too much work in interrupt, status 8003. Temporarily disabling functions (7ffc). >Jul 21 21:31:49 localhost kernel: eth0: Media selection timer finished, Autonegotiate. > >Jul 21 21:31:52 localhost kernel: eth0: vortex_close() status 8000, Tx status 00. >Jul 21 21:31:52 localhost kernel: eth0: vortex close stats: rx_nocopy 0 rx_copy 0 tx_queued 2 Rx pre-checksummed 0. > >_______________________________________________ >vortex mailing list >vortex@scyld.com >http://www.scyld.com/mailman/listinfo/vortex ------------------------------------------------- Anup Pemmaiah 435-512-0935(mobile) pemmaiah@cc.usu.edu ------------------------------------------------- From becker@scyld.com Mon Jul 29 13:09:02 2002 From: becker@scyld.com (Donald Becker) Date: Mon Jul 29 12:09:02 2002 Subject: [vortex] 3c59x LK1.1.16 Linux-2.4 PCI bus error/Host error In-Reply-To: <3D435006@webmail.usu.edu> Message-ID: On Sun, 28 Jul 2002, Anup Pemmaiah wrote: > Subject: RE: [vortex] 3c59x LK1.1.16 Linux-2.4 PCI bus error/Host error > > I have a similar problem as that of Eddie. I have 3c905 - 100 Base TX > Boomerang NIC. I use 3c59x driver for this. Installation works on > fine. When I start a tranmission, either the DHCP daemon to get th IP > address or just try > to transmit some message I get the PCI bus error/Host error as shown below. > When the error occurs the status register will have the value 0xe803 and the > FIFO diagnostic register will have 2000. > When I went through the specifications of the driver, the first > bit of the > status register says the interrupt is latched and the second bit specifies > that there is a host error. Correct. > When I checked the reason for the Host error in the FIFO > doagnostic register where the 13th bit is set, it states that the > interrupt was generated because of "rxUnderrun".Since the reason it > states that the "Host is trying to read from the receive FIFO faster > than the network can fill it and therefore the host reads invalid > data", should I reduce the reading speed of the Host? This error can only occur when the host is using programmed-I/O to read the data from the NIC. The driver you are using should be using the bus-master capability, and never reading from the Rx FIFO. Something unusual is going on here. Unless Andrew or Bogdan has an idea, you should try the Scyld 3c59x.c driver to see if the problem exists with that driver as well. http://www.scyld.com/network/vortex.html ftp://ftp.scyld.com/pub/network/3c59x.c > Jul 27 22:55:42 Anup kernel: eth0: Host error, FIFO diagnostic register 2000. > Jul 27 22:55:42 Anup kernel: eth0: PCI bus error, bus status 00a00029 Hmmm, there is nothing unusual reported in that status. Specifically, it is not reporting a PCI bus error. This is not similar to the previous problem. -- 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