From ch@h111.hadiko.de Wed, 1 Aug 2001 12:08:57 +0200 Date: Wed, 1 Aug 2001 12:08:57 +0200 From: Christoph Heine ch@h111.hadiko.de Subject: [tulip-bug] tulip.c:v0.92w, FastLineFO-II (100BaseFX) Hello, I've tried tulip v0.92w from scyld and have problems with two FastLine FO-II (100BaseFX) using a 2.4.3 Kernel. It basically doesn't work. The 2.4.3 Kernel driver has Problems too, generating paketloss and so on, as described in another bugreport. Compiling tulip v0.92w works, but when doing insmod, it puts this messages in the syslog and the cards don't work: Aug 1 12:01:15 roto kernel: tulip.c:v0.92w 7/9/2001 Written by Donald Becker Aug 1 12:01:15 roto kernel: http://www.scyld.com/network/tulip.html Aug 1 12:01:15 roto kernel: eth1: Digital DS21143-xD Tulip rev 65 at 0xc898f000, 00:00:CB:55:06:67, IRQ 12. Aug 1 12:01:15 roto kernel: eth1: EEPROM default media type MII 100baseTx. Aug 1 12:01:15 roto kernel: eth1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Aug 1 12:01:15 roto kernel: eth1: Index #1 - Media Transceiver reset (#31) described by a 21143 reset method (5) block. Aug 1 12:01:15 roto kernel: eth1: ***WARNING***: No MII transceiver found! Aug 1 12:01:15 roto kernel: eth2: Digital DS21143-xD Tulip rev 65 at 0xc8991000, 00:00:CB:55:06:12, IRQ 10. Aug 1 12:01:15 roto kernel: eth2: EEPROM default media type MII 100baseTx. Aug 1 12:01:15 roto kernel: eth2: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Aug 1 12:01:15 roto kernel: eth2: Index #1 - Media Transceiver reset (#31) described by a 21143 reset method (5) block. Aug 1 12:01:15 roto kernel: eth2: ***WARNING***: No MII transceiver found! Aug 1 12:01:40 roto kernel: Trying to free nonexistent resource Aug 1 12:01:40 roto kernel: Trying to free nonexistent resource the last two entries appeard after doing rmmod tulip Best regards, Christoph Heine (still very unhappy with this card) From becker@scyld.com Wed, 1 Aug 2001 09:54:16 -0400 (EDT) Date: Wed, 1 Aug 2001 09:54:16 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [tulip-bug] tulip.c:v0.92w, FastLineFO-II (100BaseFX) On Wed, 1 Aug 2001, Christoph Heine wrote: > I've tried tulip v0.92w from scyld and have problems with two > FastLine FO-II (100BaseFX) using a 2.4.3 Kernel. It basically doesn't > work. Please confirm: this board has a fiber connection only, with no twisted pair. What part number is on the transceiver chip? > Compiling tulip v0.92w works, but when doing insmod, it puts this > messages in the syslog and the cards don't work: > > tulip.c:v0.92w 7/9/2001 Written by Donald Becker > http://www.scyld.com/network/tulip.html > eth1: Digital DS21143-xD Tulip rev 65 at 0xc898f000, 00:00:CB:55:06:67, IRQ 12. > eth1: EEPROM default media type MII 100baseTx. First problem -- the EEPROM states that the card has a MII 100baseTx twisted pair transceiver, and that the transceiver should be configured for fixed speed, half duplex. > eth1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. > eth1: Index #1 - Media Transceiver reset (#31) described by a 21143 reset method (5) block. > eth1: ***WARNING***: No MII transceiver found! Second problem -- the transceiver isn't found. I'm guessing that you don't really have a MII transceiver. I'm guessing that you have a 100baseFx __SYM__ transceiver, and that the setting should be full 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 ch@h111.hadiko.de Wed, 1 Aug 2001 19:33:47 +0200 Date: Wed, 1 Aug 2001 19:33:47 +0200 From: Christoph Heine ch@h111.hadiko.de Subject: [tulip-bug] tulip.c:v0.92w, FastLineFO-II (100BaseFX) On Wed, Aug 01, 2001 at 09:54:16AM -0400, Donald Becker wrote: > > I've tried tulip v0.92w from scyld and have problems with two > > FastLine FO-II (100BaseFX) using a 2.4.3 Kernel. It basically doesn't > > work. > > Please confirm: this board has a fiber connection only, with no twisted pair. Yes. absolutly sure. > What part number is on the transceiver chip? Is it possible to figure this out via software? This box located in a odd place far away. > > eth1: Index #1 - Media Transceiver reset (#31) described by a 21143 reset method (5) block. > > eth1: ***WARNING***: No MII transceiver found! > > Second problem -- the transceiver isn't found. > > I'm guessing that you don't really have a MII transceiver. > > I'm guessing that you have a 100baseFx __SYM__ transceiver, and that the > setting should be full duplex. This shows up in the syslog when using the driver that comes with the 2.4.3 Kernel: (perhaps it helps) Aug 1 12:17:20 roto kernel: Linux Tulip driver version 0.9.14 (February 20, 2001) Aug 1 12:17:20 roto kernel: PCI: Found IRQ 12 for device 00:0a.0 Aug 1 12:17:20 roto kernel: eth1: Digital DS21143 Tulip rev 65 at 0x9400, 00:00:CB:55:06:67, IRQ 12. Aug 1 12:17:20 roto kernel: eth1: EEPROM default media type MII 100baseTx. Aug 1 12:17:20 roto kernel: eth1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Aug 1 12:17:20 roto kernel: eth1: Index #1 - Media AUI (#2) described by a 21143 reset method (5) block. Aug 1 12:17:20 roto kernel: eth1: MII transceiver #1 config 2100 status 7809 advertising 0001. Aug 1 12:17:20 roto kernel: eth1: Advertising 01e1 on PHY 1, previously advertising 0001. Aug 1 12:17:20 roto kernel: eth1: Advertising 01e1 (to advertise is 01e1). Aug 1 12:17:20 roto kernel: PCI: Found IRQ 10 for device 00:0b.0 Aug 1 12:17:20 roto kernel: PCI: The same IRQ used for device 00:11.0 Aug 1 12:17:20 roto kernel: eth2: Digital DS21143 Tulip rev 65 at 0x9000, 00:00:CB:55:06:12, IRQ 10. Aug 1 12:17:20 roto kernel: eth2: EEPROM default media type MII 100baseTx. Aug 1 12:17:20 roto kernel: eth2: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Aug 1 12:17:20 roto kernel: eth2: Index #1 - Media AUI (#2) described by a 21143 reset method (5) block. Aug 1 12:17:20 roto kernel: eth2: MII transceiver #1 config 2100 status 7809 advertising 0001. Aug 1 12:17:20 roto kernel: eth2: Advertising 01e1 on PHY 1, previously advertising 0001. Aug 1 12:17:20 roto kernel: eth2: Advertising 01e1 (to advertise is 01e1). Do you need the output from tulip-diag or similar tools? Christoph From becker@scyld.com Wed, 1 Aug 2001 22:32:21 -0400 (EDT) Date: Wed, 1 Aug 2001 22:32:21 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [tulip-bug] tulip.c:v0.92w, FastLineFO-II (100BaseFX) On Wed, 1 Aug 2001, Christoph Heine wrote: > On Wed, Aug 01, 2001 at 09:54:16AM -0400, Donald Becker wrote: > > > I've tried tulip v0.92w from scyld and have problems with two > > > FastLine FO-II (100BaseFX) using a 2.4.3 Kernel. It basically doesn't > > > work. > > > > Please confirm: this board has a fiber connection only, with no twisted pair. > > Yes. absolutly sure. > > > What part number is on the transceiver chip? > > Is it possible to figure this out via software? This box located in a > odd place far away. No, not unless the board has a MII transceiver. Since the transceiver doesn't respond to a MII read (and the EEPROM media table is obviously wrong), we need to figure out what type of transceiver it has. > > I'm guessing that you have a 100baseFx __SYM__ transceiver, and that the > > setting should be full duplex. > > This shows up in the syslog when using the driver that comes with the > 2.4.3 Kernel: (perhaps it helps) > > Aug 1 12:17:20 roto kernel: Linux Tulip driver version 0.9.14 > (February 20, 2001) > Aug 1 12:17:20 roto kernel: PCI: Found IRQ 12 for device 00:0a.0 > Aug 1 12:17:20 roto kernel: eth1: Digital DS21143 Tulip rev 65 at > 0x9400, 00:00:CB:55:06:67, IRQ 12. > Aug 1 12:17:20 roto kernel: eth1: EEPROM default media type MII > 100baseTx. > Aug 1 12:17:20 roto kernel: eth1: Index #0 - Media MII (#11) > described by a 21142 MII PHY (3) block. > Aug 1 12:17:20 roto kernel: eth1: Index #1 - Media AUI (#2) described > by a 21143 reset method (5) block. This is bogus. The media description block is a MII reset. > Aug 1 12:17:20 roto kernel: eth1: MII transceiver #1 config 2100 > status 7809 advertising 0001. This is very curious. The transceiver reports that it is a twisted pair 10/100baseTx device, with autonegotation. 100baseFx is always single speed and has no autonegotiation. 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 fwunderlich@devbrain.de Fri, 03 Aug 2001 01:34:05 +0200 Date: Fri, 03 Aug 2001 01:34:05 +0200 From: Florian Wunderlich fwunderlich@devbrain.de Subject: [tulip-bug] ether= option on the kernel command line Because of the media type autoselect bug (see below), I want to force the compiled-in tulip driver to use a specific media type; according to http://www.scyld.com/network/tulip.html, I have to pass ether=0,0,media-type,eth0, which does not seem to work. I tried ether=0,0,5,eth0 on an append line in /etc/lilo.conf and on the lilo boot prompt, and /proc/cmdline shows that it was correctly parsed, but the tulip driver seems to ignore it. When built as a module it works fine when using options=5. Is there a working way to set the media type for a compiled-in tulip driver? What I assume is an autoselect bug has already been reported by a number of people: http://sourceforge.net/tracker/index.php?func=detail&aid=432622&group_id=13004&atid=113004 http://www.geocrawler.com/archives/3/6977/2001/6/0/5904481/ http://sourceforge.net/tracker/index.php?func=detail&aid=430617&group_id=13004&atid=113004 http://sourceforge.net/tracker/index.php?func=detail&aid=425571&group_id=13004&atid=113004 In my case, the driver selects 10Base-T half-duplex though the NIC is initially in 100Base-T half-duplex mode and the link partner capabilities are 100baseTx and 10baseT. I have to unplug the network cable every time a machine with a tulip card is booting after the driver initialized the card and set the wrong speed; after plugging it back in the NIC selects the correct speed again. Interestingly no communication is possible after the driver initialized the NIC incorrectly as the card now does 10baseT and the (dual speed) hub still expects 100baseT. BTW, the cards worked fine since kernel 2.0.0 or something. Index #1: Found a Digital DS21140 Tulip adapter at 0xec00. Port selection is MII, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. MII PHY found at address 1, status 0x782d. MII PHY #1 transceiver registers: 3000 782d 0181 b800 05e1 40a1 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0640 4018 6800 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x782d ... 782d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Vendor ID is 00:60:6e:--:--:--, model 0 rev. 0. Vendor/Part: Davicom DM9101. 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 40a1: 100baseTx 10baseT. Negotiation completed. Davicom vendor specific registers: 0x0640 0x4018 0x6800. From becker@scyld.com Thu, 2 Aug 2001 23:54:24 -0400 (EDT) Date: Thu, 2 Aug 2001 23:54:24 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [tulip-bug] ether= option on the kernel command line On Fri, 3 Aug 2001, Florian Wunderlich wrote: > Because of the media type autoselect bug (see below), I want to force > the compiled-in tulip driver to use a specific media type; according to > http://www.scyld.com/network/tulip.html, I have to pass > ether=0,0,media-type,eth0, which does not seem to work. ...or you can use 'mii-diag -F ' with a current driver. > I tried ether=0,0,5,eth0 on an append line in /etc/lilo.conf and on the > lilo boot prompt, and /proc/cmdline shows that it was correctly parsed, > but the tulip driver seems to ignore it. When built as a module it works > fine when using options=5. What driver are you using? > What I assume is an autoselect bug has already been reported by a number > of people: > http://sourceforge.net/tracker/index.php?func=detail&aid=432622&group_id=13004&atid=113004 > http://www.geocrawler.com/archives/3/6977/2001/6/0/5904481/ > http://sourceforge.net/tracker/index.php?func=detail&aid=430617&group_id=13004&atid=113004 > http://sourceforge.net/tracker/index.php?func=detail&aid=425571&group_id=13004&atid=113004 These are all different problems. 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 fwunderlich@devbrain.de Fri, 03 Aug 2001 12:19:26 +0200 Date: Fri, 03 Aug 2001 12:19:26 +0200 From: Florian Wunderlich fwunderlich@devbrain.de Subject: [tulip-bug] ether= option on the kernel command line Thanks for your quick reply. I assumed that the driver in the 2.4 kernels is the same as your tulip driver, because you are saying on http://www.scyld.com/network/tulip.html that "It has been integrated with the kernel source tree since 1.1.90". Obviously the tulip driver in 2.4.7 (what I am using) at least is not yours. You might want to change your page. Donald Becker wrote: > > On Fri, 3 Aug 2001, Florian Wunderlich wrote: > > > Because of the media type autoselect bug (see below), I want to force > > the compiled-in tulip driver to use a specific media type; according to > > http://www.scyld.com/network/tulip.html, I have to pass > > ether=0,0,media-type,eth0, which does not seem to work. > > ...or you can use 'mii-diag -F ' with a current driver. > > > I tried ether=0,0,5,eth0 on an append line in /etc/lilo.conf and on the > > lilo boot prompt, and /proc/cmdline shows that it was correctly parsed, > > but the tulip driver seems to ignore it. When built as a module it works > > fine when using options=5. > > What driver are you using? > > > What I assume is an autoselect bug has already been reported by a number > > of people: > > http://sourceforge.net/tracker/index.php?func=detail&aid=432622&group_id=13004&atid=113004 > > http://www.geocrawler.com/archives/3/6977/2001/6/0/5904481/ > > http://sourceforge.net/tracker/index.php?func=detail&aid=430617&group_id=13004&atid=113004 > > http://sourceforge.net/tracker/index.php?func=detail&aid=425571&group_id=13004&atid=113004 > > These are all different problems. > > 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 akpm@zip.com.au Mon, 06 Aug 2001 13:54:20 -0700 Date: Mon, 06 Aug 2001 13:54:20 -0700 From: Andrew Morton akpm@zip.com.au Subject: [tulip-bug] ether= option on the kernel command line Florian Wunderlich wrote: > > Thanks for your quick reply. > > I assumed that the driver in the 2.4 kernels is the same as your tulip > driver, because you are saying on > http://www.scyld.com/network/tulip.html that "It has been integrated > with the kernel source tree since 1.1.90". Obviously the tulip driver in > 2.4.7 (what I am using) at least is not yours. You might want to change > your page. > In kernel 2.4.2 (or thereabouts) the netdevice initialisation API was changed to fix a rather nasty race - init_etherdev() was replaced by alloc_etherdev(). Problem was, this broke `ether='. At present, and driver which uses alloc_etherdev() does not support `ether='. It took a surprising amount of time for this breakage to be noticed - I'll be looking to fix it in the 2.4.9-pre series. From pirho@knology.net Sat, 18 Aug 2001 23:15:57 -0500 Date: Sat, 18 Aug 2001 23:15:57 -0500 From: Tim Pollock pirho@knology.net Subject: [tulip-bug] Does the Profile 2's Intel 21145 work? I saw that back on June 6, 2001 Greg Hill said that the Intel 21145 in a Gateway Profile 2 was broken. Is it working now? Also does the HomePNA work properly? I'm planning on installing Debian on a Profile 2. -- Tim Pollock pirho@knology.net From palfrey@bits.bris.ac.uk Sun, 19 Aug 2001 17:50:34 +0100 Date: Sun, 19 Aug 2001 17:50:34 +0100 From: Tom Parker palfrey@bits.bris.ac.uk Subject: [tulip-bug] Problems with kne111tx I'm running a linux router/server off my cable modem, and I've been having a little problem with it. The two network cards in it are both KNE111TX's, and it seems that if traffic flow goes anything higher than about 100 kb/s (rough guess, figure may be higher, but the value is significantly lower than what the 10mb network can do) that we get a collision light on the hub, and also tcpdump reports my computer waiting for a sequence number that the server does not ever give out until it times out for the server to respond, with no luck. The first few packets get through, but then everything messes up. In other words, traffic to/from the 'net is fine, but any sort of file transfer across the LAN is impossible. I've tried using several different protocols (SMB, HTTP, FTP), all with the same results. The server talks to the LAN fine at low speeds, but once we get to anything higher, it cuts off. One example was with telnet, normally fine, but it cut out when I was cat'ing my /var/log/messages, because of the data flow rate exceeding temporarily whatever the limit is. I'm using a 2.4.9 kernel (same problems earlier with both 2.4.4 and 2.4.7). This did have the 0.9.5-pre16 tulip driver, and I'm now trying the 1.1.8 driver, same results with both. I've also tried this with another computer on the LAN, same results there. My system is running Windows '98, the other test system was running Windows Me. Any ideas? Because this is me completely lost here. Thanks, Tom Parker ----------------------- palfrey@bits.bris.ac.uk tp0945@bris.ac.uk "And the beast shall be made legion. Its numbers shall be increased a thousand thousand fold. The din of a million keyboards like unto a great storm shall cover the earth, and the followers of Mammon shall tremble." - From The Book of Mozilla, 3:31 (Red Letter Edition) From becker@scyld.com Sun, 19 Aug 2001 14:52:51 -0400 (EDT) Date: Sun, 19 Aug 2001 14:52:51 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [tulip-bug] Problems with kne111tx On Sun, 19 Aug 2001, Tom Parker wrote: > I'm running a linux router/server off my cable modem, and I've been > having a little problem with it. The two network cards in it are both > KNE111TX's, and it seems that if traffic flow goes anything higher than > about 100 kb/s (rough guess, figure may be higher, but the value is > significantly lower than what the 10mb network can do) that we get a > collision light on the hub, and also tcpdump reports my computer waiting > for a sequence number that the server does not ever give out until it > times out for the server to respond, with no luck. The first few packets > get through, but then everything messes up. This looks like a duplex mismatch problem, although it could also be a cable problem. The following information is needed to track down the problem the output the card detection message (use 'dmesg') the error counts from /proc/net/dev the output of 'tulip-diag -a' while the card is experiencing problems. > I'm using a 2.4.9 kernel (same problems earlier with both 2.4.4 and > 2.4.7). This did have the 0.9.5-pre16 tulip driver, and I'm now trying 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 palfrey@bits.bris.ac.uk Sun, 19 Aug 2001 22:23:50 +0100 Date: Sun, 19 Aug 2001 22:23:50 +0100 From: Tom Parker palfrey@bits.bris.ac.uk Subject: [tulip-bug] Problems with kne111tx Donald Becker wrote: > On Sun, 19 Aug 2001, Tom Parker wrote: >>I'm running a linux router/server off my cable modem, and I've been >>having a little problem with it. The two network cards in it are both >>KNE111TX's, and it seems that if traffic flow goes anything higher than >>about 100 kb/s (rough guess, figure may be higher, but the value is >>significantly lower than what the 10mb network can do) that we get a >>collision light on the hub, and also tcpdump reports my computer waiting >>for a sequence number that the server does not ever give out until it >>times out for the server to respond, with no luck. The first few packets >>get through, but then everything messes up. > This looks like a duplex mismatch problem, although it could also be a > cable problem. > > The following information is needed to track down the problem > the output the card detection message (use 'dmesg') > the error counts from /proc/net/dev > the output of 'tulip-diag -a' while the card is experiencing problems. dmesg output below (with comments) ---------------------------------- Linux Tulip driver version 1.1.8 (June 16, 2001) PCI: Found IRQ 10 for device 00:0b.0 PCI: Sharing IRQ 10 with 00:07.2 <- USB controller, on mainboard PCI: Sharing IRQ 10 with 00:07.3 <- 2nd USB controller also on mainboard eth0: Lite-On PNIC-II rev 37 at 0xd0800000, 00:C0:F0:76:66:8F, IRQ 10. ^^^^^ LAN Card PCI: Found IRQ 11 for device 00:0f.0 PCI: Sharing IRQ 11 with 00:0d.0 <- Soundcard (SB Live) eth1: Lite-On PNIC-II rev 37 at 0xd0802000, 00:C0:F0:76:66:93, IRQ 11. ^^^^^ Card to cable-modem -------------------------------- Motherboard is an ABIT KT7A-RAID (if that's needed). Error counts from /proc/net/dev are all zero, but the collision count is a different matter. Collsion count for the LAN interface (eth0) was 1218 after my server had been up for a while and a number of tests done that day (compare to eth1 (external, same model network card) with a count of 151). After an attempted file transfer by SMB (server->client) the collision count went up by 3 to 1221, with repeated tests upping the count by 3 each time. Attempted client->server SMB transfer adds 1 to collision count. 'tulip-diag -a' output is below, from during an attempted SMB file transfer (server->client). 1st card is LAN, 2nd is external. -------------------------------------------------------------- tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Lite-On PNIC-II adapter at 0xdc00. * A potential Tulip chip has been found, but it appears to be active. * Either shutdown the network, or use the '-f' flag to see all values. Lite-On PNIC-II chip registers at 0xdc00: 0x00: fff88000 ffffffff ffffffff 0ff31000 0ff31200 e4660000 01002002 effffbff Port selection is N-Way autonegotiation, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 72. The NWay status register is 000050ca. The current PNIC-II MAC address is 00:c0:f0:76:66:8f (c000c000 76f08f66). The current PNIC-II WOL address is 00:c0:f0:76:66:8f. Index #2: Found a Lite-On PNIC-II adapter at 0xe800. * A potential Tulip chip has been found, but it appears to be active. * Either shutdown the network, or use the '-f' flag to see all values. Lite-On PNIC-II chip registers at 0xe800: 0x00: fff88000 ffffffff ffffffff 0ff2e000 0ff2e200 e4660000 01002002 effffbff Port selection is N-Way autonegotiation, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 72. The NWay status register is 000050ca. The current PNIC-II MAC address is 00:c0:f0:76:66:93 (c000c000 76f09366). The current PNIC-II WOL address is 00:c0:f0:76:66:93. -------------------------------------------------------------- On possible server/client duplex problems, the client network card (a 'PRO120' - can't remember manufacturer. Other client had a 3com card, so I don't think that has any problems. It's been fine with every other network it's been on - 3 others, both 10mb and 100mb) is also set to auto-detect. Both cards at each end are 10/100, but the hub in the middle is only 10mb (getting replaced at some unknown point....). I doubt it's a cable problem, as all the cable is brand new, but I'm getting some new bits very soon anyway (the cable I'm using right now isn't long enough to properly go from room to room, it's all draped across my hallway right now). Think that's everything. Hope it's of some help. Tom Parker ----------------------- palfrey@bits.bris.ac.uk tp0945@bris.ac.uk From Edwin.Chiu@e-wares.com Wed, 22 Aug 2001 23:03:45 -0400 Date: Wed, 22 Aug 2001 23:03:45 -0400 From: Edwin Chiu Edwin.Chiu@e-wares.com Subject: [tulip-bug] Problems with 21041 in 2.4.9, worked in 2.2.19 Hi, Here is ths situation: I have a 21041, I think it's an Acer or D-link fast ethernet card that worked with 2.2.10 thru 2.2.19. The new driver in 2.4.9 doesn't seem to work with the card... I can see it sending packets on the switch, but it's definitely not receiving anything, b/c the arp tables are empty. Tried the stock 2.4.9 driver and the one that Jeff maintains on sourceforge (tulip-1.1.8) Here is some tulip-diag output: tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DC21041 Tulip adapter at 0xe400. Digital DC21041 Tulip chip registers at 0xe400: 0x00: ffe08000 ffffffff ffffffff 0ec50000 0ec50200 fc000112 fffe0200 fffe0000 0x40: fffe0000 ffff4bf0 ffffffff fffe0000 41e1d5c8 ffffef01 ffffffff ffff0008 Port selection is full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit unit is set to store-and-forward. The NWay status register is 41e1d5c8. Internal autonegotiation state is 'Negotiation complete'. Index #2: Found a Digital DS21140 Tulip adapter at 0xec00. * A potential Tulip chip has been found, but it appears to be active. * Either shutdown the network, or use the '-f' flag to see all values. Digital DS21140 Tulip chip registers at 0xec00: 0x00: ffa08000 ffffffff ffffffff 0fab5000 0fab5200 fc660000 32042202 ffffebef Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. -- (tulip-diag -a -f) tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DC21041 Tulip adapter at 0xe400. Digital DC21041 Tulip chip registers at 0xe400: 0x00: ffe08000 ffffffff ffffffff 0ec50000 0ec50200 fc000112 fffe0200 fffe0000 0x40: fffe0000 ffff4bf0 ffffffff fffe0000 41e1d5c8 ffffef01 ffffffff ffff0008 Port selection is full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit unit is set to store-and-forward. The NWay status register is 41e1d5c8. Internal autonegotiation state is 'Negotiation complete'. Index #2: Found a Digital DS21140 Tulip adapter at 0xec00. Digital DS21140 Tulip chip registers at 0xec00: 0x00: ffa08000 ffffffff ffffffff 0fab5000 0fab5200 fc660000 32042202 ffffebef 0x40: e0000000 fff583ff ffffffff fffe0000 ffffff40 ffffffff 1c09fdc0 fffffec8 Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. Any help would be appreciated... Thanks, Edwin From Edwin.Chiu@e-wares.com Thu, 23 Aug 2001 18:27:40 -0400 Date: Thu, 23 Aug 2001 18:27:40 -0400 From: Edwin Chiu Edwin.Chiu@e-wares.com Subject: [tulip-bug] Problems with 21041 in 2.4.9, worked in 2.2.19 Hi, I downloaded the tulip 0.9.14 driver and that seems to work. Kernel 2.4.9 comes with 0.9.15-pre6 The DE4x5 driver works as well, but I get carrier errors for every packet sent... Regards, Edwin Edwin Chiu wrote: > > Hi, > > Here is ths situation: > > I have a 21041, I think it's an Acer or D-link fast ethernet card that > worked with 2.2.10 thru 2.2.19. > > The new driver in 2.4.9 doesn't seem to work with the card... I can > see it sending packets on the switch, but it's definitely not receiving > anything, b/c the arp tables are empty. > > Tried the stock 2.4.9 driver and the one that Jeff maintains on > sourceforge (tulip-1.1.8) > > Here is some tulip-diag output: > > tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a Digital DC21041 Tulip adapter at 0xe400. > Digital DC21041 Tulip chip registers at 0xe400: > 0x00: ffe08000 ffffffff ffffffff 0ec50000 0ec50200 fc000112 fffe0200 fffe0000 > 0x40: fffe0000 ffff4bf0 ffffffff fffe0000 41e1d5c8 ffffef01 ffffffff ffff0008 > Port selection is full-duplex. > Transmit stopped, Receive stopped, full-duplex. > The Rx process state is 'Stopped'. > The Tx process state is 'Stopped'. > The transmit unit is set to store-and-forward. > The NWay status register is 41e1d5c8. > Internal autonegotiation state is 'Negotiation complete'. > Index #2: Found a Digital DS21140 Tulip adapter at 0xec00. > * A potential Tulip chip has been found, but it appears to be active. > * Either shutdown the network, or use the '-f' flag to see all values. > Digital DS21140 Tulip chip registers at 0xec00: > 0x00: ffa08000 ffffffff ffffffff 0fab5000 0fab5200 fc660000 32042202 ffffebef > Port selection is MII, full-duplex. > Transmit started, Receive started, full-duplex. > The Rx process state is 'Waiting for packets'. > The Tx process state is 'Idle'. > The transmit threshold is 128. > > -- > (tulip-diag -a -f) > > tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a Digital DC21041 Tulip adapter at 0xe400. > Digital DC21041 Tulip chip registers at 0xe400: > 0x00: ffe08000 ffffffff ffffffff 0ec50000 0ec50200 fc000112 fffe0200 fffe0000 > 0x40: fffe0000 ffff4bf0 ffffffff fffe0000 41e1d5c8 ffffef01 ffffffff ffff0008 > Port selection is full-duplex. > Transmit stopped, Receive stopped, full-duplex. > The Rx process state is 'Stopped'. > The Tx process state is 'Stopped'. > The transmit unit is set to store-and-forward. > The NWay status register is 41e1d5c8. > Internal autonegotiation state is 'Negotiation complete'. > Index #2: Found a Digital DS21140 Tulip adapter at 0xec00. > Digital DS21140 Tulip chip registers at 0xec00: > 0x00: ffa08000 ffffffff ffffffff 0fab5000 0fab5200 fc660000 32042202 ffffebef > 0x40: e0000000 fff583ff ffffffff fffe0000 ffffff40 ffffffff 1c09fdc0 fffffec8 > Port selection is MII, full-duplex. > Transmit started, Receive started, full-duplex. > The Rx process state is 'Waiting for packets'. > The Tx process state is 'Idle'. > The transmit threshold is 128. From Edwin.Chiu@e-wares.com Thu, 23 Aug 2001 18:59:18 -0400 Date: Thu, 23 Aug 2001 18:59:18 -0400 From: Edwin Chiu Edwin.Chiu@e-wares.com Subject: [tulip-bug] Problems with 21041 in 2.4.9, worked in 2.2.19 I did somemore testing, it's broken between 2.4.3 and 2.4.5 Just incase, here is the PCI entry... 00:0d.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 22) Subsystem: Acer Incorporated [ALI]: Unknown device 0310 Flags: bus master, medium devsel, latency 64, IRQ 10 I/O ports at ec00 [size=128] Memory at ea002000 (32-bit, non-prefetchable) [size=128] Expansion ROM at e9000000 [disabled] [size=256K] Edwin Chiu wrote: > > Hi, > > I downloaded the tulip 0.9.14 driver and that seems to work. > Kernel 2.4.9 comes with 0.9.15-pre6 > > The DE4x5 driver works as well, but I get carrier errors for > every packet sent... > > Regards, > Edwin > > Edwin Chiu wrote: > > > > Hi, > > > > Here is ths situation: > > > > I have a 21041, I think it's an Acer or D-link fast ethernet card that > > worked with 2.2.10 thru 2.2.19. > > > > The new driver in 2.4.9 doesn't seem to work with the card... I can > > see it sending packets on the switch, but it's definitely not receiving > > anything, b/c the arp tables are empty. > > > > Tried the stock 2.4.9 driver and the one that Jeff maintains on > > sourceforge (tulip-1.1.8) > > > > Here is some tulip-diag output: > > > > tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com) > > http://www.scyld.com/diag/index.html > > Index #1: Found a Digital DC21041 Tulip adapter at 0xe400. > > Digital DC21041 Tulip chip registers at 0xe400: > > 0x00: ffe08000 ffffffff ffffffff 0ec50000 0ec50200 fc000112 fffe0200 fffe0000 > > 0x40: fffe0000 ffff4bf0 ffffffff fffe0000 41e1d5c8 ffffef01 ffffffff ffff0008 > > Port selection is full-duplex. > > Transmit stopped, Receive stopped, full-duplex. > > The Rx process state is 'Stopped'. > > The Tx process state is 'Stopped'. > > The transmit unit is set to store-and-forward. > > The NWay status register is 41e1d5c8. > > Internal autonegotiation state is 'Negotiation complete'. > > Index #2: Found a Digital DS21140 Tulip adapter at 0xec00. > > * A potential Tulip chip has been found, but it appears to be active. > > * Either shutdown the network, or use the '-f' flag to see all values. > > Digital DS21140 Tulip chip registers at 0xec00: > > 0x00: ffa08000 ffffffff ffffffff 0fab5000 0fab5200 fc660000 32042202 ffffebef > > Port selection is MII, full-duplex. > > Transmit started, Receive started, full-duplex. > > The Rx process state is 'Waiting for packets'. > > The Tx process state is 'Idle'. > > The transmit threshold is 128. > > > > -- > > (tulip-diag -a -f) > > > > tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com) > > http://www.scyld.com/diag/index.html > > Index #1: Found a Digital DC21041 Tulip adapter at 0xe400. > > Digital DC21041 Tulip chip registers at 0xe400: > > 0x00: ffe08000 ffffffff ffffffff 0ec50000 0ec50200 fc000112 fffe0200 fffe0000 > > 0x40: fffe0000 ffff4bf0 ffffffff fffe0000 41e1d5c8 ffffef01 ffffffff ffff0008 > > Port selection is full-duplex. > > Transmit stopped, Receive stopped, full-duplex. > > The Rx process state is 'Stopped'. > > The Tx process state is 'Stopped'. > > The transmit unit is set to store-and-forward. > > The NWay status register is 41e1d5c8. > > Internal autonegotiation state is 'Negotiation complete'. > > Index #2: Found a Digital DS21140 Tulip adapter at 0xec00. > > Digital DS21140 Tulip chip registers at 0xec00: > > 0x00: ffa08000 ffffffff ffffffff 0fab5000 0fab5200 fc660000 32042202 ffffebef > > 0x40: e0000000 fff583ff ffffffff fffe0000 ffffff40 ffffffff 1c09fdc0 fffffec8 > > Port selection is MII, full-duplex. > > Transmit started, Receive started, full-duplex. > > The Rx process state is 'Waiting for packets'. > > The Tx process state is 'Idle'. > > The transmit threshold is 128.