From manching@hongkong.com Sun Aug 1 17:43:02 1999 Date: Sun Aug 1 17:43:02 1999 From: manching@hongkong.com manching@hongkong.com Subject: No subject Hi, I have installed RPM 6.0 + CLE 8.0 . My linux kernel is kernel-2.2.5-CLE15. I removed the RPM pcmcia packet and installed the pcmcia-cs-3.0.13 and tulip.c 0.91g . My LAN card is KingMax CardBus 10/100Mbps Ethernet card and my school network is 10Mbps, half duplex. I connect to the school network by DHCP client. Both the "Link" and the "TX/RX" LED light up properly. I can connect my linux to the internet and use my netscape. I may have done something wrong during the network and pcmcia setup because the Delaying network initializtion reported Fail. The eth0 can't connect to the network automatically when I reboot my linux. Any idea to solve the error? Here is my pcmcia config: "cardctl ident" Socket 1: product info: "CardBus", "10/100Mbps LAN Card", "PCB Rev3.2", "DTDKA25" manfid: 0x8a01, 0x0100 function: 6 (network) add info in "/etc/pcmcia/config.opts" card "KingMax CardBus 10/100Mbps Ethernet card" version "CardBus", "10/100Mbps LAN Card", "PCB Rev3.2", "DTDKA25" #manfid 0x8a01, 0x0100 bind "tulip_cb" "cat /var/log/messages" Starting PCMCIA services: pcmcia: modules kernel: Linux PCMCIA Card Services 3.0.13 kernel: kernel build: 2.2.5-15CLE #2 Sun Aug 1 02:08:15 EDT 1999 kernel: options: [pci] [cardbus] [apm] kernel: Intel PCIC probe: kernel: TI 1220 PCI-to-CardBus at bus 0 slot 10, mem 0x68000000, 2 sockets kernel: host opts [0]: [pwr save] [serial pci & irq] [no pci irq] [lat 168/1 76] [bus 32/34] kernel: host opts [1]: [pwr save] [serial pci & irq] [no pci irq] [lat 168/1 76] [bus 35/37] kernel: ISA irqs (scanned) = 3,4,5,11 status change on irq 11 modprobe: can't locate module eth0 modprobe: can't locate module eth0 pcmcia: cardmgr. cardmgr[362]: starting, version is 3.0.13 cardmgr[362]: config error, file 'config' line 1326: syntax error kernel: cs: IO port probe 0x1000-0x17ff: excluding 0x1000-0x103f 0x1400-0x140f kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x300-0x307 0x378-0x37f 0x388 -0x38f 0x4d0-0x4d7 kernel: cs: IO port probe 0x0a00-0x0aff: clean. cardmgr[362]: watching 2 sockets cardmgr[362]: initializing socket 0 cardmgr[362]: socket 0: Serial or Modem kernel: cs: memory probe 0xa0000000-0xa0ffffff: clean. cardmgr[362]: executing: 'insmod /lib/modules/2.2.5-15CLE/pcmcia/serial_cs.o' kernel: tty02 at 0x03e8 (irq = 3) is a 16550A cardmgr[362]: executing: './serial start ttyS2' rc: Starting pcmcia succeeded inet: inetd startup succeeded cardmgr[362]: initializing socket 1 cardmgr[362]: socket 1: KingMax CardBus 10/100Mbps Ethernet card cardmgr[362]: executing: 'insmod /lib/modules/2.2.5-15CLE/pcmcia/cb_enabler.o' cardmgr[362]: executing: 'insmod /lib/modules/2.2.5-15CLE/pcmcia/tulip_cb.o' kernel: cs: cb_config(bus 35): vendor 0x1011, device 0x0019 kernel: fn 0 bar 1: io 0x400-0x47f kernel: fn 0 bar 2: mem 0xa00c2000-0xa00c23ff kernel: fn 0 rom: mem 0xa0082000-0xa00c1fff kernel: tulip_attach(bus 35, function 0) kernel: tulip.c:v0.91g 7/16/99 becker@cesdis.gsfc.nasa.gov kernel: eth0: Digital DS21143 Tulip rev 65 at 0x400, 00:A0:0C:90:1F:DC, IRQ 5. kernel: eth0: EEPROM default media type Autosense. kernel: eth0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. kernel: eth0: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. kernel: eth0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. kernel: eth0: Index #3 - Media 100baseTx-FD (#5) described by a 21143 SYM PHY ( 4) block. cardmgr[362]: executing: './network start eth0' . . . amd[492]: No networks. amd[492]: My ip addr is 0x7f000001 . . . linuxconf: Linuxconf final setup rc: Starting linuxconf succeeded rc: Starting local succeeded PAM_pwdb[630]: (gdm) session opened for user root by (uid=0) gnome-name-server[733]: starting "cat /var/run/stab" Socket 1: KingMax CardBus 10/100Mbps Ethernet card 1 network tulip_cb 0 eth0 "ifconfig" eth0 Link encap:Ethernet HWaddr 00:A0:0C:90:1F:DC inet addr:169.226.233.71 Bcast:169.226.239.255 Mask:255.255.248.0 UP BROADCAST RUNNING MTU:1500 Metric:1 RX packets:3516 errors:0 dropped:0 overruns:0 frame:0 TX packets:336 errors:0 dropped:0 overruns:0 carrier:0 collisions:49 txqueuelen:100 Interrupt:5 Base address:0x400 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:66 errors:0 dropped:0 overruns:0 frame:0 TX packets:66 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 "tulip-diag -a" tulip-diag.c:v1.10 4/12/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0x400. Digital DS21143 Tulip chip registers at 0x400: f8000000 ffffffff ffffffff dfda47f7 5f0f5ffe f0000010 b2420200 f3fe0000 e0000000 ffffcbf8 ffffffff 00000000 000052ca ffff0001 fffbffff 8ffb8000 Port selection is 10mpbs-serial, full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. "tulip-diag -e" tulip-diag.c:v1.10 4/12/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0x400. Port selection is 10mpbs-serial, 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. Ethernet MAC Station Address 00:A0:0C:90:1F:DC. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 30, default media type 0800 (Autosense). 4 transceiver description blocks: Media 10baseT, block type 2, length 6. Serial transceiver for 10baseT (media type 0). GP pin direction 08af GP pin data 00a1. Media 10baseT-Full Duplex, block type 2, length 6. Serial transceiver for 10baseT-Full Duplex (media type 4). GP pin direction 08af GP pin data 00a1. Media 100baseTx, block type 4, length 8. SYM transceiver for 100baseTx (media type 3). GP pin direction 08af GP pin data 00a1. No media detection indication (command 80 61). Media 100baseTx Full Duplex, block type 4, length 8. SYM transceiver for 100baseTx Full Duplex (media type 5). GP pin direction 08af GP pin data 00a1. No media detection indication (command 80 61). "tulip-diag -m" tulip-diag.c:v1.10 4/12/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) tulip-diag.c:v1.10 4/12/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0x400. Port selection is 10mpbs-serial, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. tulip-diag.c:v1.10 4/12/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0x400. Port selection is 10mpbs-serial, 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. No MII transceivers found! Internal autonegotiation state is 'Negotiation complete'. manching email: manching@hongkong.com ___________________________________________________________________________ Get your hongkong.com freemail at http://www.hongkong.com Free newsletters center at http://post4u.hongkong.com From kaos@ocs.com.au Sun Aug 1 20:21:38 1999 Date: Sun Aug 1 20:21:38 1999 From: Keith Owens kaos@ocs.com.au Subject: No subject On 1 Aug 1999 21:44:32 -0000, manching@hongkong.com wrote: >Hi, I have installed RPM 6.0 + CLE 8.0 . My linux kernel is >kernel-2.2.5-CLE15. I removed the RPM pcmcia packet and installed the >pcmcia-cs-3.0.13 ... Please set your mailer to wrap lines, your original text was one long line of 660 characters! I reflowed it above. Redhat uses a modified set of pcmcia scripts. Removing the rpm and installing pcmcia-cs without using an rpm results in /etc/pcmcia files which are not compatible with Redhat's way of doing things, in particular /etc/pcmcia/network is incorrect for RH. This is not a tulip problem at all, it is a Redhat one. Best contact RH or look for an rpm of pcmcia-cs 3.0.13. From kevin_myer@elanco.k12.pa.us Mon Aug 2 11:41:53 1999 Date: Mon Aug 2 11:41:53 1999 From: Kevin Myer kevin_myer@elanco.k12.pa.us Subject: 0.91g and Kingston KNE100TX problems On Wed, 28 Jul 1999, Donald Becker wrote: > > Cables look ok. > > "Looks ok" isn't a good answer for this subject. > The pairing of TP cables isn't the obvious order. > But that's not the likely problem here, since bad cables usually cause more > Rx than Tx errors. The cables are ok. The pairs are matched up and I have tested these with other 10/100 cards that do work as I would expect them too. I set debug to 3 and here is what I get: tulip.c:v0.91g 7/16/99 becker@cesdis.gsfc.nasa.gov eth0: Digital DS21143 Tulip rev 65 at 0xec00, 00:C0:F0:3B:C0:5B, IRQ 11. eth0: EEPROM default media type Autosense. eth0: MII interface PHY 0, setup/reset sequences 0/0 long, capabilities e0 78. eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. eth0: Advertising 01e1 on PHY 0 (0). eth0: Using media type MII, CSR12 is c6. eth0: MII transceiver #1 config 3000 status 782d advertising 01e1. Found Digital DS21143 Tulip at PCI I/O address 0xec00. Found Digital DS21143 Tulip at PCI I/O address 0xec00. Found Digital DS21143 Tulip at PCI I/O address 0xec00. Found Digital DS21143 Tulip at PCI I/O address 0xec00. Found Digital DS21143 Tulip at PCI I/O address 0xec00. Found Digital DS21143 Tulip at PCI I/O address 0xec00. Found Digital DS21143 Tulip at PCI I/O address 0xec00. Found Digital DS21143 Tulip at PCI I/O address 0xec00. eth0: tulip_open() irq 11. eth0: Advertising 01e1 on PHY 0 (1). eth0: Using media type MII, CSR12 is c6. eth0: Using MII transceiver 1, status 782d. eth0: Done tulip_open(), CSR0 f8a08000, CSR5 f0360000 CSR6 b20e2002. eth0: Transmit error, Tx status 7fffbc00. eth0: Transmit error, Tx status 7fffbc00. eth0: Transmit error, Tx status 7fffbc00. eth0: Transmit error, Tx status 7fffbc00. eth0: Transmit error, Tx status 7fffbc00. eth0: Transmit error, Tx status 7fffbc00. eth0: Transmit error, Tx status 7fffbc00. eth0: Transmit error, Tx status 7fffbc00. eth0: Transmit error, Tx status 7fffbc00. eth0: Transmit error, Tx status 7fffbc00. eth0: Transmit error, Tx status 7fffbc00. eth0: Transmit error, Tx status 7fffbc00. eth0: Transmit error, Tx status 7fffbc00. eth0: Transmit error, Tx status 7fffbc00. eth0: Transmit error, Tx status 7fffbc00. eth0: Transmit error, Tx status 7fffbc00. eth0: Transmit error, Tx status 7fffbc00. eth0: 21143 negotiation status 000000c6, MII. eth0: MII status 782d, Link partner report 41e1. eth0: The transmitter stopped. CSR5 is f0678006, CSR6 b20e2202, new CSR6 820e0200. eth0: Setting full-duplex based on MII#1 link partner capability of 41e1. eth0: 21143 negotiation status 000000c6, MII. eth0: MII status 782d, Link partner report 41e1. eth0: 21143 negotiation status 000000c6, MII. eth0: MII status 782d, Link partner report 41e1. eth0: 21143 negotiation status 000000c6, MII. eth0: MII status 782d, Link partner report 41e1. eth0: 21143 negotiation status 000000c6, MII. eth0: MII status 782d, Link partner report 41e1. (ad infinitum with errors) Kevin -- ~ Kevin M. Myer . . Network/System Administrator /V\ ELANCO School District // \ /( )\ ^`~'^ From fox@foxtaur.com Mon Aug 2 15:36:06 1999 Date: Mon Aug 2 15:36:06 1999 From: Fuzzy Fox fox@foxtaur.com Subject: Macronix 98713 support? Hi there folks - I'm wondering what the current level of support is for the Macronix 98713 PMAC, in the Tulip driver? It seems to be a bit dodgy, I'm afraid... I'm currently using tulip v0.89H, as that seems to be mostly stable. However, perhaps every week or two, the card will suddenly and inexplicably stop responding. It requires an ifconfig down/up to restore the card to working order again. Here's my probe info, if that helps: tulip.c:v0.89H 5/23/98 becker@cesdis.gsfc.nasa.gov eth0: Macronix 98713 PMAC at 0x6800, 00 40 33 a4 e5 41, IRQ 11. eth0: EEPROM default media type 100baseTx. eth0: Index #0 - Media 10baseT (#0) described by a 21140 non-MII (0) block. eth0: Index #1 - Media 100baseTx (#3) described by a 21140 non-MII (0) block. eth0: Index #2 - Media 10baseT-FD (#4) described by a 21140 non-MII (0) block. eth0: Index #3 - Media 100baseTx-FD (#5) described by a 21140 non-MII (0) block. eth0: Using EEPROM-set media 100baseTx. One thing I noticed is that, even though the driver claims to be using the 100baseTx media, it doesn't work: eth0: 21140 transmit timed out, status fc265410, SIA fffffe0b ffffffff 1c09fdc0 fffffec8, resetting... eth0: transmit timed out, switching to 100baseTx media. However, I can easily force this in my conf.modules, using "options=3", so I've left it that way. I'm using a 100TX hub, so full duplex is out of the question. :) Here are my module options: options tulip options=3 max_interrupt_work=40 When the card freezes up, there are no console messages. However, when I upgraded my driver to (the latest?) v0.91e, the card would fail in the same way after only a few hours of run-time. This repeated enough that I was forced to revert back to 0.89H until a fix can be found. Here is the result from using 0.91e: tulip.c:v0.91e 5/27/99 becker@cesdis.gsfc.nasa.gov eth0: Macronix 98713 PMAC rev 0 at 0x6800, 00:40:33:A4:E5:41, IRQ 11. eth0: EEPROM default media type 100baseTx. eth0: Index #0 - Media 10baseT (#0) described by a 21140 non-MII (0) block. eth0: Index #1 - Media 100baseTx (#3) described by a 21140 non-MII (0) block. eth0: Index #2 - Media 10baseT-FD (#4) described by a 21140 non-MII (0) block. eth0: Index #3 - Media 100baseTx-FD (#5) described by a 21140 non-MII (0) block. eth0: Using user-specified media 100baseTx. eth0: Using user-specified media 100baseTx. eth0: Using user-specified media 100baseTx. [...8 hours later...] eth0: 21140 transmit timed out, status fc67dc55, SIA fffffe1b ffffffff 1c09fdc0 fffffec8, resetting... eth0: 21140 transmit timed out, status fc69dcd7, SIA fffffe1b ffffffff 1c09fdc0 fffffec8, resetting... last message repeated 7 times last message repeated 13 times last message repeated 13 times More configuration info: The card is sharing an interrupt with my USB controller, which of course has no Linux support. Linux version is 2.2.9. lspci info: 00:00.0 Host bridge: Intel Corporation 430TX - 82439TX MTXC (rev 01) Flags: bus master, medium devsel, latency 64 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 01) Flags: bus master, medium devsel, latency 0 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80) Flags: bus master, medium devsel, latency 64 I/O ports at f000 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at 6400 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 01) Flags: medium devsel 00:0f.0 VGA compatible controller: Cirrus Logic GD 5430/40 [Alpine] (rev 2d) Flags: VGA palette snoop, fast devsel, IRQ 10 Memory at e0000000 (32-bit, prefetchable) 00:11.0 Ethernet controller: Macronix, Inc. MX98713 Flags: bus master, stepping, medium devsel, latency 64, IRQ 11 I/O ports at 6800 Memory at e1000000 (32-bit, non-prefetchable) Does anyone have any ideas, or want more information? -- fox@dallas.net (Fuzzy Fox) || "Nothing takes the taste out of peanut sometimes known as David DeSimone || butter quite like unrequited love." http://www.dallas.net/~fox/ || -- Charlie Brown From cmusser@nlc.com Mon Aug 2 15:46:18 1999 Date: Mon Aug 2 15:46:18 1999 From: Chuck Musser cmusser@nlc.com Subject: more than 16 interfaces Hello all, I've tried configuring my kernel (Linux 2.2.10) to use more than 16 eth devices, but it didn't work. When the machine boots, it still only registers up to eth15. My machine has a built-in 3c905 and 4 Adaptec Quartec 4-port PCI ethernet boards. These have DEC DC21140 (rev 34) chips. Any advice? Thanks, Chuck p.s.: Here's what I added to devices/net/Space.c: static struct device eth16_dev = { "eth16", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, NEXT_DEV, ethif_probe }; static struct device eth15_dev = { "eth15", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, ð16_dev, ethif_probe }; static struct device eth14_dev = { "eth14", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, ð15_dev, ethif_probe }; static struct device eth13_dev = { "eth13", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, ð14_dev, ethif_probe }; static struct device eth12_dev = { "eth12", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, ð13_dev, ethif_probe }; static struct device eth11_dev = { "eth11", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, ð12_dev, ethif_probe }; static struct device eth10_dev = { "eth10", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, ð11_dev, ethif_probe }; static struct device eth9_dev = { "eth9", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, ð10_dev, ethif_probe }; static struct device eth8_dev = { "eth8", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, ð9_dev, ethif_probe }; From natarajs@yahoo.com Mon Aug 2 18:19:19 1999 Date: Mon Aug 2 18:19:19 1999 From: s nataraj natarajs@yahoo.com Subject: Kingston 110TX problem Problem: cannot ping my gateway or anyother machine except my own localhost. Evrything works fine with the gateway and nameserver on win98 Network card: Kingston 110TX i installed RH 6.0, and it auto detected tulip module for me for the kingston card.After setting up the IP address, gateway, dns servers..etc here are the error messages i get, and bottom line i cannot ping my gateway. Any help in trying to solve this would help. Here is the output from /var/log/messages when i do a /etc/rc.d/init.d/network restart ----- Aug 2 08:25:59 natarajlnx network: Disabling IPv4 packet forwarding succeeded Aug 2 08:25:59 natarajlnx network: Bringing up interface lo succeeded Aug 2 08:25:59 natarajlnx ifup: SIOCSIFFLAGS: Resource temporarily unavailable Aug 2 08:25:59 natarajlnx ifup: SIOCADDRT: Network is down Aug 2 08:25:59 natarajlnx ifup: SIOCADDRT: Network is unreachable Aug 2 08:25:59 natarajlnx ifup: SIOCADDRT: Network is unreachable Aug 2 08:26:00 natarajlnx network: Bringing up interface eth0 succeeded ----- netstat -r does not show my gateway except for the loopback. >netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 127.0.0.0 * 255.0.0.0 U 0 0 0 lo ----- [root@natarajlnx /root]# ifconfig -a eth0 Link encap:Ethernet HWaddr C0:00:2C:F0:05:A1 inet addr:209.76.109.154 Bcast:209.76.109.255 Mask:255.25 .......... .......... lo .......... .......... ----- also, when i do an "ifup eth0", i get the folowing output ifup: SIOCSIFFLAGS: Resource temporarily unavailable ifup: SIOCADDRT: Network is down ifup: SIOCADDRT: Network is unreachable ----- I have tried changing my netmodule from tulip to de4x5, but that doesnt seem to help. thanks for any help. natarajs@yahoo.com _____________________________________________________________ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com From aaronl@vitelus.com Mon Aug 2 20:29:57 1999 Date: Mon Aug 2 20:29:57 1999 From: Aaron Lehmann aaronl@vitelus.com Subject: more than 16 interfaces Look at the linux-kernel mailing list archives. This came up very recently (this week). On Mon, 2 Aug 1999, Chuck Musser wrote: > Hello all, > > I've tried configuring my kernel (Linux 2.2.10) to use more than 16 eth > devices, but it didn't work. When the machine boots, it still only > registers up to eth15. My machine has a built-in 3c905 and 4 Adaptec > Quartec 4-port PCI ethernet boards. These have DEC DC21140 (rev 34) > chips. > > Any advice? > > Thanks, > > Chuck > > p.s.: Here's what I added to devices/net/Space.c: > > static struct device eth16_dev = { > "eth16", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, NEXT_DEV, > ethif_probe }; > static struct device eth15_dev = { > "eth15", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, > ð16_dev, ethif_probe }; > static struct device eth14_dev = { > "eth14", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, > ð15_dev, ethif_probe }; > static struct device eth13_dev = { > "eth13", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, > ð14_dev, ethif_probe }; > static struct device eth12_dev = { > "eth12", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, > ð13_dev, ethif_probe }; > static struct device eth11_dev = { > "eth11", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, > ð12_dev, ethif_probe }; > static struct device eth10_dev = { > "eth10", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, > ð11_dev, ethif_probe }; > static struct device eth9_dev = { > "eth9", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, ð10_dev, > ethif_probe }; > static struct device eth8_dev = { > "eth8", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, ð9_dev, > ethif_probe }; > > From MTross@compu-shack.com Tue Aug 3 05:22:00 1999 Date: Tue Aug 3 05:22:00 1999 From: Michael Tross MTross@compu-shack.com Subject: tulip driver in the linux kernels I found that in the latest 2.3.12/2.2.10 kernel there is still the 0.89H tulip driver, but the 2.0.37 tulip driver has the revision 0.90. When will 0.90 or 0.91 be included in the current 2.2.x kernels? What reasons do prevent that these really important and vital driver enhancements - for the 21143 - will be inserted in the official kernel releases? Michael From geisj@pagestation.com Wed Aug 4 00:31:44 1999 Date: Wed Aug 4 00:31:44 1999 From: Jerry Geis geisj@pagestation.com Subject: tulip 21143 I am using 2.0.35 with modules and tulip. I use slakware 3.6. The tulip card is detected. indicating setting #11 MII autoselect. my network is 10baseT. THe card is 10/100. I try to ping a machine on the net and nothing. I tried /sbin/modprobe tulip options=0 int the /etc/rc.d/rc.modules file to select the 10baseT and still nothing on the ping. Any ideas? Thank you sir, Jerry Geis MessageNet Systems From ruediger@next12.Theo-Phys.Uni-Essen.DE Wed Aug 4 03:53:00 1999 Date: Wed Aug 4 03:53:00 1999 From: Ruediger Oberhage ruediger@next12.Theo-Phys.Uni-Essen.DE Subject: Problems with Adaptec 6911 card(s) Good morning! May I introduce myself with a cry for help :-). We do have several machines equipped with Adaptec 6911 cards (ours are ones with twisted-pair and BNC connector) and I do have the same problem that Sami Yousif (syousif@iname.com) reported on Mon, 26 Jul 1999 16:12:49 -0500 as "Adaptec ANA6911a not working w/ tulip driver, but works with de driver" (TUX archive for linux-tulip), but with a significant difference; for us, the de(4x5) driver also doesn't(!) work. The only difference I see to the previous message is, that for us the revision number of the card(s) reads rev 65 (instead of rev 21). Otherwise the diagnostic and error-dumps of that previous message would be exactly mine and it are the "No MII interrupt. No MII transceivers found!" that worry me, since the system is connected via 10baseT at the moment. With our (until now) main operating system (OPENSTEP), we have no problem driving the card with the (generic) 21x4x-driver! It does work and negotiate the link correctly [- it does have a problem, once it loses a previously established connection, but that's another probelm]. I can confirm this problem with Debian/GNU Linux 2.1 (slink) (kernel 2.0.36) for the driver versions 0.89, 0.91, 0.91e, and 0.91g and for SuSE version 6.1's (kernel 2.2) native driver (0.88?). Always the same problem. Is there any chance for a quick fix or solution - otherwise I would have to buy additional network cards for the machines going to or dualbooting as Linux systems - which would be a pity and waste, in my opinion. Thanks, Ruediger Oberhage -- H.-R. Oberhage Mail: Univ.-GH Essen E-Mail: phy070@sp2.power.Uni-Essen.DE Fachbereich 7 (Physik) ruediger@Theo-Phys.Uni-Essen.DE S05 V07 E88 Universitaetsstrasse 5 Phone: {+49|0} 201 / 183-2493 D-45117 Essen, Germany FAX: {+49|0} 201 / 183-2120 From jason@topic.com.au Wed Aug 4 03:55:46 1999 Date: Wed Aug 4 03:55:46 1999 From: Jason Thomas jason@topic.com.au Subject: tulip 21143 This may be a stupid question but have you set up your route and interfaces and stuff for the card..... Jerry Geis [geisj@pagestation.com] wrote: > I am using 2.0.35 with modules and tulip. > I use slakware 3.6. > > The tulip card is detected. indicating > setting #11 MII autoselect. > > my network is 10baseT. THe card is 10/100. > I try to ping a machine on the net and > nothing. > > I tried /sbin/modprobe tulip options=0 > int the /etc/rc.d/rc.modules file > to select the 10baseT and still nothing > on the ping. > > Any ideas? > > Thank you sir, > > Jerry Geis > MessageNet Systems -- Jason Thomas Phone: +61 2 6257 7111 System Administrator Fax: +61 2 6257 7311 tSA Consulting Group Pty. Ltd. Mobile: 0418 29 66 81 1 Hall Street Lyneham ACT 2602 http://www.topic.com.au/ From dave@artscans.com Wed Aug 4 16:52:31 1999 Date: Wed Aug 4 16:52:31 1999 From: David Coons dave@artscans.com Subject: Looking for Cardbus ethernet Does anyone have a good recommendation for a decent Tulip 10/100 Cardbus ethernet adapter for an IBM Thinkpad 570? ------------------------------------------------------------------------------- David Coons Tel: (310)545-2356 ArtScans Studio, Inc. Fax: (310)796-0807 2319 N. Sepulveda Blvd. Mail: dave@artscans.com Manhattan Beach, CA 90266 Web: http://www.imaginglabs.com/artscans.html Cel Phone: (310)480-2356 From ruediger@next12.Theo-Phys.Uni-Essen.DE Thu Aug 5 04:55:47 1999 Date: Thu Aug 5 04:55:47 1999 From: Ruediger Oberhage ruediger@next12.Theo-Phys.Uni-Essen.DE Subject: Problems with Adaptec 6911 card(s) (the second) Hello again, since I've obviously been kicked out of the TUX mail-archive, please pardon me reentering my request of yesterday, thanks: Good morning! May I introduce myself with a cry for help :-). We do have several machines equipped with Adaptec 6911 cards (ours are ones with twisted-pair and BNC connector) and I do have the same problem that Sami Yousif (syousif@iname.com) reported on Mon, 26 Jul 1999 16:12:49 -0500 as "Adaptec ANA6911a not working w/ tulip driver, but works with de driver" (TUX archive for linux-tulip), but with a significant difference; for us, the de(4x5) driver also doesn't(!) work. The only difference I see to the previous message is, that for us the revision number of the card(s) reads rev 65 (instead of rev 21). Otherwise the diagnostic and error-dumps of that previous message would be exactly mine and it are the "No MII interrupt. No MII transceivers found!" that worry me, since the system is connected via 10baseT at the moment. With our (until now) main operating system (OPENSTEP), we have no problem driving the card with the (generic) 21x4x-driver! It does work and negotiate the link correctly [- it does have a problem, once it loses a previously established connection, but that's another probelm]. I can confirm this problem with Debian/GNU Linux 2.1 (slink) (kernel 2.0.36) for the driver versions 0.89, 0.91, 0.91e, and 0.91g and for SuSE version 6.1's (kernel 2.2) native driver (0.88?). Always the same problem. Is there any chance for a quick fix or solution - otherwise I would have to buy additional network cards for the machines going to or dualbooting as Linux systems - which would be a pity and waste, in my opinion. Thanks, Ruediger Oberhage -- H.-R. Oberhage Mail: Univ.-GH Essen E-Mail: phy070@sp2.power.Uni-Essen.DE Fachbereich 7 (Physik) ruediger@Theo-Phys.Uni-Essen.DE S05 V07 E88 Universitaetsstrasse 5 Phone: {+49|0} 201 / 183-2493 D-45117 Essen, Germany FAX: {+49|0} 201 / 183-2120 From ruediger@next12.Theo-Phys.Uni-Essen.DE Thu Aug 5 12:54:56 1999 Date: Thu Aug 5 12:54:56 1999 From: Ruediger Oberhage ruediger@next12.Theo-Phys.Uni-Essen.DE Subject: Problems with Adaptec 6911 card(s) (the second) Got it working with help, thanks! Julian Highfield , after correctly stating, that I should have written 6911A instead of 6911, since this would make a difference, thanks, suggested to use version 0.90 of the tulip-driver, offering an URL for downloading, too , and lo and behold - it does work. According to Murphy, this version was what's missing between 0.88, 0.89, 0.91, 0.91e, and 0.91g :-). There's to be found out, why the 0.91 versions don't run, though, or has anyone run them successfully with a 6911A? But for now - and for me - that it's running is all that counts for the moment. Thank you very much, I'm delighted, Ruediger From nathan@premier1.net Fri Aug 6 04:02:19 1999 Date: Fri Aug 6 04:02:19 1999 From: Nathan Anderson nathan@premier1.net Subject: Looking for Cardbus ethernet David Coons wrote: > > Does anyone have a good recommendation for a decent > Tulip 10/100 Cardbus ethernet adapter for an IBM Thinkpad 570? David, I personally use the LinkSys EtherFast 10/100 CardBus. Uses a genuine Intel Tulip. I am running it on my ThinkPad 770 successfully. Regards, -- -- Nathan Anderson "Programming follows several 90% rules. One of those rules is 'The first 90% of the project takes 90% of the time, and the last 10% takes the other 90% of the time.'" -- Blake Watson, OS/2 Warp Programming for Dummies (IDG Press) From 9733848u@geminga.ucg.ie Fri Aug 6 07:08:28 1999 Date: Fri Aug 6 07:08:28 1999 From: stephen bourke 9733848u@geminga.ucg.ie Subject: ANA6911A/TXC & BNC This card is the Adaptec ANA-6911A/TX. It seems to be based on the 21143 chip. It works fine with TP using the de4x5 driver but will not work at all with BNC. It will not work at all with the tulip driver, I've tried the driver that comes with RH 6.0 and ver.91 I need to get it working with BNC. Any suggestions? From dave@artscans.com Fri Aug 6 17:55:52 1999 Date: Fri Aug 6 17:55:52 1999 From: David Coons dave@artscans.com Subject: Looking for Cardbus ethernet > I personally use the LinkSys EtherFast 10/100 CardBus. Uses a genuine > Intel Tulip. I am running it on my ThinkPad 770 successfully. Nathan, Someone else recommended a Farallon card as well. On what basis should I pick one of these... cost, size, driver support, ease of use? Our network consists of a bunch of identical SMC Etherpower 10/100 PCI cards in all the workstations and server, all connected to a cheap hub that I'd like to upgrade someday to a switch. I'd also be interested in how you partitioned your 770 for Linux. My 570 came with 2G Win98 hard partition and an empty 1.8G Fat32 logical partition attached to the second hard partition. I purchased Partition Magic, and could, of course use the standard FIPS and FDISK. David From qf24@dial.pipex.com Sat Aug 7 13:29:40 1999 Date: Sat Aug 7 13:29:40 1999 From: Neil MCGRANE qf24@dial.pipex.com Subject: Linux and the DEC "Tulip" chip This is a multi-part message in MIME format. ------=_NextPart_000_000A_01BEE102.4EA03920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear sir, I have Windows95/Redhat 5.2 dual boot on a Pentium pc. The PC has a = netgear EA201 Ethernet card in it. This card works because I can use it = with Windows95. I Spoke to the netgear support people they told me to = look at the website http://cesdis.gsfc.nasa.gov/linux/drivers/tulip.html = and follow the instructions, which I have done.=20 After downloading the tulip.c, I compiled it with gcc -DMODULE = -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -c tulip.c `[ -f = /usr/include/linux/modversions.h ] && echo -DMODVERSIONS`, which worked. = When I try the insmod I get the error message "tulip.c: init_module: = Device or resource busy" what is this Have I done something daft? Also your link to http://www.mxic.com.tw/publish/2276.htm. does not = work. Please help! Thanks Neil McGrane SingleScan Ltd Contract Web Developers www.singlescan.co.uk ------=_NextPart_000_000A_01BEE102.4EA03920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear sir,
 
I have Windows95/Redhat 5.2 dual = boot on a=20 Pentium pc. The PC has a netgear EA201 Ethernet card in it. This card = works=20 because I can use it with Windows95. I Spoke to the netgear support = people they=20 told me to look at the website http://cesd= is.gsfc.nasa.gov/linux/drivers/tulip.html=20 and follow the instructions, which I have done.
 
After downloading the tulip.c, I = compiled it=20 with gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -c tulip.c = `[ -f=20 /usr/include/linux/modversions.h ] && echo -DMODVERSIONS`, which = worked.=20 When I try the insmod I get the error message "tulip.c: = init_module: Device=20 or resource busy"  what is this Have I done something=20 daft?
 
Also your link to  http://www.mxic.com.tw/p= ublish/2276.htm.=20 does not work.
 
Please help!
 
Thanks
 
Neil McGrane
SingleScan = Ltd
Contract Web=20 Developers
www.singlescan.co.uk ------=_NextPart_000_000A_01BEE102.4EA03920-- From rgb@phy.duke.edu Sat Aug 7 23:27:11 1999 Date: Sat Aug 7 23:27:11 1999 From: Robert G. Brown rgb@phy.duke.edu Subject: Linux and the DEC "Tulip" chip On Sat, 7 Aug 1999, Neil MCGRANE wrote: > Dear sir, > I have Windows95/Redhat 5.2 dual boot on a Pentium pc. The PC has a > netgear EA201 Ethernet card in it. This card works because I can use it > with Windows95. I Spoke to the netgear support people they told me to > look at the website http://cesdis.gsfc.nasa.gov/linux/drivers/tulip.html > and follow the instructions, which I have done. > After downloading the tulip.c, I compiled it with gcc -DMODULE > -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -c tulip.c `[ -f > /usr/include/linux/modversions.h ] && echo -DMODVERSIONS`, which worked. > When I try the insmod I get the error message "tulip.c: init_module: > Device or resource busy" what is this Have I done something daft? Usually that means that the driver is already loaded. Indeed, if you installed RH 5.2 correctly, it should already have the tulip driver installed, and it should already automatically load the tulip driver at boot time without your doing a thing. Please capture the output of the "dmesg" command. You should find therein (or see scroll past at boot time) lines like: tulip.c:v0.89H 5/23/98 becker@cesdis.gsfc.nasa.gov eth0: Digital DS21140 Tulip at 0xe800, 00 20 18 58 5f b6, IRQ 5. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. eth0: MII transceiver found at MDIO address 1, config 1000 status 782d. eth0: Advertising 01e1 on PHY 1, previously advertising 05e1. eth1: Digital DS21140 Tulip at 0xec00, 00 20 18 58 50 7c, IRQ 10. eth1: EEPROM default media type Autosense. eth1: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. eth1: MII transceiver found at MDIO address 1, config 3100 status 7829. eth1: Advertising 01e1 on PHY 1, previously advertising 05e1. eth0: Advertising 01e1 on PHY 0 (1). eth0: Using user-specified media MII. eth0: Advertising 01e1 on PHY 0 (1). eth1: Advertising 01e1 on PHY 0 (1). (as you can see, I have TWO tulip cards in my system that work perfectly). If you do, there is no need (probably) to get a more recent version of the tulip driver or kernel and build them; indeed if you are a newbie at linux you could make life more difficult rather than simpler by your trying to figure out how to do so when all you want to do is get started using it. There are a couple more things that COULD be going on. Rarely, a tulip card gets into an interrupt fight with other hardware in the system, so that the message refers to ANOTHER device conflicting with the netgear card. In this case, moving the netgear card into a different PCI slot can sometimes fix it. Another possibility is that the 2.0.36 kernel in RH 5.2 is pretty old and contains a tulip driver that won't support every "new" tulip card; there are now various tulip clone card makers (like the lite-on) and I don't know if the netgear uses one of these or a genuine tulip or a new "Intel" tulip. The old driver works perfectly with genuine DEC 21140 tulips like I have, but may well fail for the newer ones or clones. The newer Red Hat 6.0 as well as its SUSE and Caldera cousins all use the 2.2.x kernel which is much improved and has much more recent drivers that should work fine with these newer chips. I'd personally recommend that you consider upgrading to RH 6.0 (or one of the 2.2.x distributions) in any event -- the 2.0.36 kernel is static at this point and lots of features in the distribution are greatly improved. You should be able to do this for free if you are good at net-surfing (you have to get a copy of the distribution from one of many Red Hat (or Suse or Caldera) mirrors or RH itself via the net) or you can always buy a box set of any of the above for prices from maybe $30 to $80 US. At this point, I can't give you much more advice without more information. If the tulip driver is NOT already loaded, you have one problem. Send me (or rather, the list) the output of dmesg if you can, as well as the contents of /proc/pci, /proc/interrupts. If you can download Don Becker's tulip-probe program, that might also help. If the tulip driver IS already loaded (so you do indeed have an eth0 device) then your problem is more likely to be that you just haven't set up the network correctly yet. Read about "linuxconf" (or just crank up linuxconf as root under X) and see if you can navigate it well enough to define and run your existing network adapter. rgb > Also your link to http://www.mxic.com.tw/publish/2276.htm. does not work. Not my link -- I'm just a list participant. But Don (if it is his) will probably notice and do something if appropriate. rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu From jon@brightconsulting.com Sun Aug 8 16:35:18 1999 Date: Sun Aug 8 16:35:18 1999 From: jon@brightconsulting.com jon@brightconsulting.com Subject: kne100tx problems hi. i just installed redhat 5.2 on my celeron 400 processor with abit bx_6 revision 2 motherboard, with a kingston kne100tx ethernet adapter. but it doesn't work. i always get an error message like no default root to host when i try telneting to another machine on my lan (giving its static ip address). as a boot nears completion, right before the loging prompt, my hug shows a lot of activity. after a while, my hub partitions my linux machine off the network. i've disabled all of the networking based services that i know about (samba, named, one or two more), so i don't know what initiates the activity. i tried leaving the linux machine off the network until the boot was finshed, and when i plug it back in, i no longer get all of the activity, but the telnets still don't work. just for fun, i just switch ip address with another linux machine that i have, and after rebooting, the other one is ok, and my celeron isn't so it has nothing to do with that. anyway, during bootup, the kernel refers to my adapter as a digial ds21142/3 model tulip at 0xe400, 00 c0 f0 3b ae 84 IRQ 12. tulip-diag adds something about port select is 100mbps SYM/PCS 100baseTx scrambler halfduplex transmit started, rx process state "waiting for packets" tx process state idle. i could gather more info, but in don't know what to gather. so, question 1, is this likely a hardware problem, device driver problem, or linux problem. and what step should i take next to either fix or diagnose the problem. and would i be better off just shelling out another $100 for a card that will work with no problems? (card recommendations please). thanks, jon bright From dsl@zai.com Sun Aug 8 20:03:31 1999 Date: Sun Aug 8 20:03:31 1999 From: David Lerner dsl@zai.com Subject: kne100tx problems jon@brightconsulting.com wrote: > hi. > i just installed redhat 5.2 on my celeron 400 processor with abit bx_6 revision 2 motherboard, > with a kingston kne100tx ethernet adapter. > but it doesn't work. i always get an error message like no default root to host when > i try telneting to another machine on my lan (giving its static ip address). > as a boot nears completion, right before the loging prompt, my hug shows a lot > of activity. after a while, my hub partitions my linux machine off the network. > i've disabled all of the networking based services that i know about (samba, named, one or two more), > so i don't know what initiates the activity. > i tried leaving the linux machine off the network until the boot was finshed, and > when i plug it back in, i no longer get all of the activity, but the telnets still don't work. > just for fun, i just switch ip address with another linux machine that i have, and after > rebooting, the other one is ok, and my celeron isn't so it has nothing to do with that. [snip] This sounds like a network software configuration issue , and not a tulip driver problem. You should problably post your question to the comp.os.linux.netwroking newsgroup. You might look up the Linux Network Administrator;s Guide that is part of the Linux Documentation Project. Dave From jon@brightconsulting.com Tue Aug 10 02:45:23 1999 Date: Tue Aug 10 02:45:23 1999 From: jon@brightconsulting.com jon@brightconsulting.com Subject: kne100tx problems hi. thanks to the people who responded with detailed explanations of the problem and what to do about it. apparently, the kne100tx card that i bought is a new model which is not compatible with the version of the driver that ships with redhat 5.2 or 6.0. it might have been nice if kingston gave the new model a new model name, but in this case they didn't go to the trouble. so when i recompile the v91 of the tulip.c driver, it worked great. this problem should be added to a faq somewhere, because i'm sure other people will hit it. thanks again. jon > > hi. > i just installed redhat 5.2 on my celeron 400 processor with abit bx_6 revision 2 motherboard, > with a kingston kne100tx ethernet adapter. > but it doesn't work. i always get an error message like no default root to host when > i try telneting to another machine on my lan (giving its static ip address). > as a boot nears completion, right before the loging prompt, my hug shows a lot > of activity. after a while, my hub partitions my linux machine off the network. > i've disabled all of the networking based services that i know about (samba, named, one or two more), > so i don't know what initiates the activity. > i tried leaving the linux machine off the network until the boot was finshed, and > when i plug it back in, i no longer get all of the activity, but the telnets still don't work. > just for fun, i just switch ip address with another linux machine that i have, and after > rebooting, the other one is ok, and my celeron isn't so it has nothing to do with that. > > anyway, during bootup, the kernel refers to my adapter as a digial ds21142/3 model tulip > at 0xe400, 00 c0 f0 3b ae 84 IRQ 12. > > tulip-diag adds something about > port select is 100mbps SYM/PCS 100baseTx scrambler halfduplex > transmit started, rx process state "waiting for packets" tx process state idle. > > i could gather more info, but in don't know what to gather. > > so, question 1, is this likely a hardware problem, device driver problem, or linux problem. > and what step should i take next to either fix or diagnose the problem. > and would i be better off just shelling out another $100 for a card that will work with no problems? > (card recommendations please). > > thanks, > jon bright From jon@brightconsulting.com Tue Aug 10 02:45:19 1999 Date: Tue Aug 10 02:45:19 1999 From: jon@brightconsulting.com jon@brightconsulting.com Subject: kne100tx problems hi. thanks to the people who responded with detailed explanations of the problem and what to do about it. apparently, the kne100tx card that i bought is a new model which is not compatible with the version of the driver that ships with redhat 5.2 or 6.0. it might have been nice if kingston gave the new model a new model name, but in this case they didn't go to the trouble. so when i recompile the v91 of the tulip.c driver, it worked great. this problem should be added to a faq somewhere, because i'm sure other people will hit it. thanks again. jon > > hi. > i just installed redhat 5.2 on my celeron 400 processor with abit bx_6 revision 2 motherboard, > with a kingston kne100tx ethernet adapter. > but it doesn't work. i always get an error message like no default root to host when > i try telneting to another machine on my lan (giving its static ip address). > as a boot nears completion, right before the loging prompt, my hug shows a lot > of activity. after a while, my hub partitions my linux machine off the network. > i've disabled all of the networking based services that i know about (samba, named, one or two more), > so i don't know what initiates the activity. > i tried leaving the linux machine off the network until the boot was finshed, and > when i plug it back in, i no longer get all of the activity, but the telnets still don't work. > just for fun, i just switch ip address with another linux machine that i have, and after > rebooting, the other one is ok, and my celeron isn't so it has nothing to do with that. > > anyway, during bootup, the kernel refers to my adapter as a digial ds21142/3 model tulip > at 0xe400, 00 c0 f0 3b ae 84 IRQ 12. > > tulip-diag adds something about > port select is 100mbps SYM/PCS 100baseTx scrambler halfduplex > transmit started, rx process state "waiting for packets" tx process state idle. > > i could gather more info, but in don't know what to gather. > > so, question 1, is this likely a hardware problem, device driver problem, or linux problem. > and what step should i take next to either fix or diagnose the problem. > and would i be better off just shelling out another $100 for a card that will work with no problems? > (card recommendations please). > > thanks, > jon bright From koye@uswest.net Tue Aug 10 05:23:01 1999 Date: Tue Aug 10 05:23:01 1999 From: Rev Kristian E. Oye koye@uswest.net Subject: Fw: Problems w/ LinkSys EtherFast 10/100 v2.0 I hope this is going out to the right place. I recently purchases a LinkSys EtherFast 10/100 LAN Card (version 2.0). I bought this thinking it was the same NIC which resides in my P90 MUD server (which seems to run well enough). The 2.0 card appears to be quite a different beast, however. I have tried using the card in the following environments: 1) using tulip.c (v0.91 4/14/99) under Linux 2.1.122 on an Intel Pentium 90 (Slackware 3.5). 2) using tulip.c (v0.91g 7/16/99) under Linux 2.2.10 on an Intel Pentium Pro 180 (Slackware 4.0) In both cases I get the following: eth0: Lite-On PNIC-II rev 37 at 0xf000, 00:A0:CC:32:A7:2C, IRQ 11. ...[ snipped hd and swapspace stuff ]... eth0: Transmit timed out, status e4060000, CSR12 000000c4, resetting... eth0: Transmit timed out, status e4060000, CSR12 000000c4, resetting... eth0: Transmit timed out, status e4060000, CSR12 000000c4, resetting... ...[ nonstop until I take the interface down]... I am wondering if I am doing something wrong? Do I need to manually modify the driver source to enable the MII stuff (I am not a kernel hacker to any degree)? Is this card not yet supported? I hope I didn't come off sounding too much the fool :P -Kris Oye koye@uswest.net [Note(s): Both of these machines are hooked up up to a PCI (PCI=Japanese manufacturer in this case) FT-08E Fast Ethernet 8-port hub (100baseT only). The network is also populated by two celeron machines running NT (both having 3Com 10/100's I believe) and a Cisco 675 DSL router. It is also worth mentioning that the card works fine under Windows 98 on the PPro using the drivers provided by LinkSys]. From koye@uswest.net Tue Aug 10 05:27:23 1999 Date: Tue Aug 10 05:27:23 1999 From: Rev Kristian E. Oye koye@uswest.net Subject: Problems w/ LinkSys EtherFast 10/100 v2.0 This is a multi-part message in MIME format. ------=_NextPart_000_00D7_01BEE2D8.0BAAAA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I hope this is going out to the right place. I recently purchases a LinkSys EtherFast 10/100 LAN Card (version 2.0). I bought this thinking it was the same NIC which resides in my P90 MUD server (which seems to run well enough). The 2.0 card appears to be quite a different beast, however. I have tried using the card in the following environments: 1) using tulip.c (v0.91 4/14/99) under Linux 2.1.122 on an Intel Pentium 90 (Slackware 3.5). 2) using tulip.c (v0.91g 7/16/99) under Linux 2.2.10 on an Intel Pentium Pro 180 (Slackware 4.0) In both cases I get the following: eth0: Lite-On PNIC-II rev 37 at 0xf000, 00:A0:CC:32:A7:2C, IRQ 11. ...[ snipped hd and swapspace stuff ]... eth0: Transmit timed out, status e4060000, CSR12 000000c4, resetting... eth0: Transmit timed out, status e4060000, CSR12 000000c4, resetting... eth0: Transmit timed out, status e4060000, CSR12 000000c4, resetting... ...[ nonstop until I take the interface down]... I am wondering if I am doing something wrong? Do I need to manually modify the driver source to enable the MII stuff (I am not a kernel hacker to any degree)? Is this card not yet supported? I hope I didn't come off sounding too much the fool :P -Kris Oye koye@uswest.net [Note(s): Both of these machines are hooked up up to a PCI (PCI=Japanese manufacturer in this case) FT-08E Fast Ethernet 8-port hub (100baseT only). The network is also populated by two celeron machines running NT (both having 3Com 10/100's I believe) and a Cisco 675 DSL router. It is also worth mentioning that the card works fine under Windows 98 on the PPro using the drivers provided by LinkSys]. ------=_NextPart_000_00D7_01BEE2D8.0BAAAA60 Content-Type: text/x-vcard; name="Kristian E Oye.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Kristian E Oye.vcf" BEGIN:VCARD VERSION:2.1 N:Oye;Kristian;E FN:Kristian E Oye NICKNAME:kris ORG:PAML;Information Systems TITLE:EDI Specialist NOTE;ENCODING=3DQUOTED-PRINTABLE:United Number: 03049587472 =3D0D=3D0A TEL;WORK;VOICE:(509)926-2400 / 6524 TEL;HOME;VOICE:(509)359-7212 ADR;WORK:;Argonne Building;;Spokane;Washington;;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Argonne = Building=3D0D=3D0ASpokane, Washington=3D0D=3D0AUSA ADR;HOME;ENCODING=3DQUOTED-PRINTABLE:;;218 North 10th = Street=3D0D=3D0AMorrison Hall 826=3D0D=3D0A;Cheney;WA;9004;USA LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:218 North 10th = Street=3D0D=3D0AMorrison Hall 826=3D0D=3D0A=3D0D=3D0ACheney, WA = 9004=3D0D=3D =3D0AUSA X-WAB-GENDER:2 URL:http://www.wolfenet.com/~kriton/ URL:http://www.paml.com/ EMAIL;PREF;INTERNET:kriton@wolfenet.com REV:19990810T091904Z END:VCARD ------=_NextPart_000_00D7_01BEE2D8.0BAAAA60-- From mark@louisville.edu Tue Aug 10 12:02:33 1999 Date: Tue Aug 10 12:02:33 1999 From: Mark E. Crane mark@louisville.edu Subject: kne100tx problems Hi, I have the same problem and have acquired the new driver, but I am a shameless newbie and am not sure where to place it so that it will be utilized when I recompile. Also, do I need to compile it first? Thanks, Mark "clueless and cluelesser" Crane From mark@louisville.edu Tue Aug 10 13:50:58 1999 Date: Tue Aug 10 13:50:58 1999 From: Mark E. Crane mark@louisville.edu Subject: Linux and the DEC "Tulip" chip On Sat, 7 Aug 1999, Robert G. Brown wrote: ::: should be able to do this for free if you are good at net-surfing (you ::: have to get a copy of the distribution from one of many Red Hat (or Suse ::: or Caldera) mirrors or RH itself via the net) or you can always buy a ::: box set of any of the above for prices from maybe $30 to $80 US. http://www.cheapbytes.com has RH 6.0 and other distributions on CD for about $5.00 + shipping. MC From eppdm@netmaster.ca Tue Aug 10 15:49:40 1999 Date: Tue Aug 10 15:49:40 1999 From: Dana M. Epp eppdm@netmaster.ca Subject: kne100tx problems I don't know what to say with the Kingston cards. Ever since they were moved to the 21143 chip, I can NOT get multiple cards in a single box to work. When trying to make a routing bridge with the cards, one card will come up, but the other won't. If it DOES come up, after about a minute I get eth0: Tx hung, 24 vs. 9. I am using the 0.91g driver and its not seeming to work. Funny thing was that the 21140 NEVER gave me problems. I was running multiport cards up to 16 ethernet segments in one box without problems. Now.... I can't even get 2 working. I have tried FORCING modes with the options in the module, but to no avail. Anyone else have this problem, and have a solution? -- Dana M. Epp NetMaster Networking Solutions, Inc eppdm@netmaster.ca http://www.netmaster.ca "Connecting Networks to the Internet" From bas@brijn.nu Wed Aug 11 14:34:27 1999 Date: Wed Aug 11 14:34:27 1999 From: Bas Rijniersce bas@brijn.nu Subject: Compex FL110-TX + Abit BP6 -> SMP problems Hello, Today I installed my new Abit BP6 with dual Celeron 333. My NIC is a Compex RL-100TX: eth0: Digital DS21143 Tulip rev 65 at 0xa400, 00:80:48:CD:53:8B, IRQ 9. Under Linux 2.2.11 with both the driver in the tar.gz (0.83H?) and 0.91e and 0.91g work perfectly when used in a uniprocessor compiled kernel. With SMP enabled in the kernel I get: tulip.c:v0.91g 7/16/99 becker@cesdis.gsfc.nasa.gov eth0: Digital DS21143 Tulip rev 65 at 0xa400, 00:80:48:CD:53:8B, IRQ 9. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. eth0: MII transceiver #8 config 3000 status 782d advertising 01e1. eth0: Tx hung, 7 vs. 0. eth0: Tx hung, 15 vs. 0. I also tried to load as module, but that didn't help either :( The bootup messages in both situations are the same, exept for the errors :-) Any suggestions on what to do? TIA, Bas ---- Bas Rijniersce Phone +31 341 550545 Oude Telgterweg 81 Fax +31 341 562940 3851 EA Ermelo http://www.brijn.nu The Netherlands bas@brijn.nu From bas@brijn.nu Wed Aug 11 15:46:07 1999 Date: Wed Aug 11 15:46:07 1999 From: Bas Rijniersce bas@brijn.nu Subject: Compex RL100-TX, ABit BP6 SMP -> problem Hi, I thought I had send this message already, but I can find it in my outbox and not in my inbox, so I guess I have been dreaming. Sorry if it is the second copy :) I installed an Abit BP 6 with dual Celeron chips today. In the bord I have a Compex RL100-TX 100 Mb NIC: eth0: Digital DS21143 Tulip rev 65 at 0xa400, 00:80:48:CD:53:8B, IRQ 9. This bord and NIC is running Linux 2.2.11 compiled without SMP OK. But if I compile it as SMP I get get: tulip.c:v0.91g 7/16/99 becker@cesdis.gsfc.nasa.gov eth0: Digital DS21143 Tulip rev 65 at 0xa400, 00:80:48:CD:53:8B, IRQ 9. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. eth0: MII transceiver #8 config 3000 status 782d advertising 01e1. eth0: Tx hung, 7 vs. 0. eth0: Tx hung, 15 vs. 0. I tried both the tulip.c that comes with 2.2.1 (0.83H), 0.91e and 0.91g. All the same problem, I also tried to use tulip as a module without succes. Any suggestions? Tia, Bas ---- Bas Rijniersce Phone +31 341 550545 Oude Telgterweg 81 Fax +31 341 562940 3851 EA Ermelo http://www.brijn.nu The Netherlands bas@brijn.nu From travis.johnson@wcom.com Wed Aug 11 18:03:37 1999 Date: Wed Aug 11 18:03:37 1999 From: Travis Johnson travis.johnson@wcom.com Subject: Compex RL100-TX, ABit BP6 SMP -> problem Did you compile the tulip.c with the SMP compile command when you switched to the SMP kernel? "gcc -D__SMP__ -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -c tulip.c `[ -f /usr/include/linux/modversions.h ] && echo -DMODVERSIONS`" Travis Bas Rijniersce wrote: > > Hi, > > I thought I had send this message already, but I can find it in my > outbox and not in my inbox, so I guess I have been dreaming. Sorry if it > is the second copy :) > > I installed an Abit BP 6 with dual Celeron chips today. In the bord I > have a Compex RL100-TX 100 Mb NIC: > eth0: Digital DS21143 Tulip rev 65 at 0xa400, 00:80:48:CD:53:8B, IRQ 9. > > This bord and NIC is running Linux 2.2.11 compiled without SMP OK. But > if I compile it as SMP I get get: > tulip.c:v0.91g 7/16/99 becker@cesdis.gsfc.nasa.gov > eth0: Digital DS21143 Tulip rev 65 at 0xa400, 00:80:48:CD:53:8B, IRQ 9. > eth0: EEPROM default media type Autosense. > eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) > block. > eth0: MII transceiver #8 config 3000 status 782d advertising 01e1. > eth0: Tx hung, 7 vs. 0. > eth0: Tx hung, 15 vs. 0. > > I tried both the tulip.c that comes with 2.2.1 (0.83H), 0.91e and 0.91g. > All the same problem, I also tried to use tulip as a module without > succes. > > Any suggestions? > > Tia, > Bas > > ---- > Bas Rijniersce Phone +31 341 550545 > Oude Telgterweg 81 Fax +31 341 562940 > 3851 EA Ermelo http://www.brijn.nu > The Netherlands bas@brijn.nu From bas@brijn.nu Thu Aug 12 02:53:30 1999 Date: Thu Aug 12 02:53:30 1999 From: Bas Rijniersce bas@brijn.nu Subject: Compex RL100-TX, ABit BP6 SMP -> problem Travis Johnson wrote: > > Did you compile the tulip.c with the SMP compile command when you > switched to the SMP kernel? > > "gcc -D__SMP__ -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -c > tulip.c `[ -f /usr/include/linux/modversions.h ] && echo -DMODVERSIONS`" The problem is solved, the BP6 bios has two settings voor the SMP "protocol" it uses (thanx Bryan :). Switching this solved the problem. > Travis Bas ---- Bas Rijniersce Phone +31 341 550545 Oude Telgterweg 81 Fax +31 341 562940 3851 EA Ermelo http://www.brijn.nu The Netherlands bas@brijn.nu From 9733848u@geminga.ucg.ie Thu Aug 12 05:55:57 1999 Date: Thu Aug 12 05:55:57 1999 From: stephen bourke 9733848u@geminga.ucg.ie Subject: ANA6911A/TXC & BNC (fwd) Forwarded message: From pfr@math.tu-dresden.de Mon Aug 9 16:06:28 1999 Date: Mon Aug 9 16:06:28 1999 From: Roland Pfretzschner pfr@math.tu-dresden.de Subject: ANA6911A/TXC & BNC Hello, Mr. Bourke, I tested the ANA6911A/TXC at our site with the following results: tulip version 0.89H (delivered with delix DLD 6.01) doesn't work at all tulip version 0.90 works with TX10 and TX100, but doesn't with BNC tulip version 0.91 works with BNC, if called with "options=1" i.e. the /etc/conf.modules contains the lines: alias eth0 tulip options tulip options=1 tulip version 0.91 doesn't work with TX (with or without options) I would like to post this message to the right newsgroup, but I found your message in the "tux" archive and don't know, to which newsgroup it belongs. Greetings R. Pfretzschner --------------------------------------------------------------------------- Dr. Roland Pfretzschner pfr@math.tu-dresden.de Sysadmin Technische Universitaet Dresden Tel: (0351)463 5030 Fachrichtung Mathematik Fax: (0351)463 6027 Mommsenstr. 13 01062 Dresden From david@cs.ucsb.edu Thu Aug 12 17:17:52 1999 Date: Thu Aug 12 17:17:52 1999 From: David Watson david@cs.ucsb.edu Subject: strange behavior with 21143 cards I am working on a linux cluster which is being built, and I am having some strange problems with tulip cards in the machines. I'm hoping someone can help me out with a little advise (or a patch!) Setup: tulip.c = v0.91g cards = Kingston KNE100TX. There are 2 of these PCI cards in each machine. /proc/pci reports DEC DC21142 (rev 65). tulip driver reports Digital DS21143 Tulip rev 65 kernel = 2.2.5 arch = ix86(P2), 2 proc. SMP Problem: TCP connection tend to "lock up". Interactive telnet and ssh connections work fine, but ftp, scp, and http connections lock up almost immediatly. I'm assuming that this has something to do with the larger packet size generated by the file transfers. Upon locking up, no more data is transfered over the open tcp stream, although new ones can be started. netstat reveals that the connection is still ESTABLISHED on both sides. Either on or both of the sides will have stuff in it's send-queue for that connection, which never goes away. Replacing the cards with some 3com and intel cards we have seems to fix the problem. Also these cards appear to function correctly when there is only one in each box. Does this sound familiar to anyone? At this point we are looking to get the cards replaced (with a different brand) by the vendor, but since we have 100+ cards involved here, this isn't the most attractive option. Please respond to my email "david@cs.ucsb.edu", as I'm not subscribed to this list. Thanks. -david From tim@thereviewguide.com Thu Aug 12 23:38:38 1999 Date: Thu Aug 12 23:38:38 1999 From: Tim Hotze tim@thereviewguide.com Subject: Sorry, problem Sorry for the last message from me, it was an honest mistake. Anyway, I've got a problem with a Netgear FA310TX (rev. D1) card and Linux. The card is a relabled tulip 'clone'. I am running Red Hat 6.0 and kernel 2.2.5-15. According to linuxconf, my card should be initized upon start up. When I am booting the kernel, all I get is 'Bringing up interface eth0' then on the next line 'Delaying eth0 initization' then the module fails to load. However, when I shutdown the kernel it gladly says that OK to shutting down eth0. I've tried the RedHat 6.0 list with no success. I THINK that I've tried most of the stupid mistakes. The first thing is yes, I've recompiled my kernel with tulip support. Yes, I have updated my vmlinuz kernel image on my bootdisk that I use to load linux. I've tried both the driver that Netgear (http://www.netgearinc.com) supplied as well as the latest driver from the tulip website. So is the 'delay' message simply saying that it doesn't want to start eth0 or does it mean that it can't figure out what the heck's going on and is giving up? I honestly don't know. Although the card is currently not connected to a network (per se, it's connected to a cable modem), I still get no /dev/eth0 . Has anyone had a similiar story and found a solution? Thankss a billion, Tim D. Hotze From metod.kozelj@rzs-hm.si Fri Aug 13 02:16:16 1999 Date: Fri Aug 13 02:16:16 1999 From: Metod Kozelj metod.kozelj@rzs-hm.si Subject: strange behavior with 21143 cards Hello, On Thu, 12 Aug 1999, David Watson wrote: > I am working on a linux cluster which is being built, and I am having some > strange problems with tulip cards in the machines. I'm hoping someone can > help me out with a little advise (or a patch!) > > Setup: > tulip.c = v0.91g > cards = Kingston KNE100TX. There are 2 of these PCI cards in each machine. > /proc/pci reports DEC DC21142 (rev 65). > tulip driver reports Digital DS21143 Tulip rev 65 > kernel = 2.2.5 > arch = ix86(P2), 2 proc. SMP Are you using these cards in full-duplex mode? Try to force them to half-duplex, it did make difference to me. Here we have a small cluster (5 machines, Alpha SX164), tied up using a 10/100baseT HD/FD switch. The main node has two DE500 NICs, one with 21140 and the other with 21143, slave nodes have all some TrendNET NICs with 21140. The communication between the cluster nodes is done FD, the communication to the rest of the universe is done HD. At first I used the 21143-based DE500 for the FD communication and the performance was horrible (about 96kBps for FTP). Then I changed it so that the DE500 with 21140 is used for FD operation and the FTP is running at wire speed (about 1.1MBps). The 21143 is happy running HD (about 1.0MBps transfer rate). Regards, Metod Metod Kozelj mailto:Metod.Kozelj@rzs-hm.si /\ Ne posiljajte mi smeti ker grizem! http://www.rzs-hm.si/ / \ Don't spam me for I bite! _______________________________________/ \__________________________________ ---- perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' From rdynes@varcom.com Fri Aug 13 10:08:27 1999 Date: Fri Aug 13 10:08:27 1999 From: Richard Dynes rdynes@varcom.com Subject: 2.2.11 and tulip.c issues Alan Cox wrote: > > > > Do we need to download Donald's 0.91 and test it or what? > > Try it - the more data we get (especially Don gets) the better I've cross posted this to the tulip list. I've been running v0.91 for months since all of the hardware I get now (Znyx 4 port ethercards, Ziatech CPUs) has tulip 21143s on them, and I've occasionally experienced some really bad network jams when I boot with 89H on a 21143. Fortunately, I've only got genuine Intel/DEC 21143s, so I haven't had to deal with any clone issues. Except for some autonegotiate things with some of the boards I have (Znyx), I haven't had any problems that I attribute to v0.91. But then I mostly telnet in, and occassionally ftp new kernels over. Most of the ethernet traffic doesn't go up the network stack, see below. I haven't set up a test plan for testing the driver exhaustively for large files, full utilization at 100mbit, and full duplex, etc. Actually, 100% utilization at 100mbit may be a bit much, to think about it. Disclaimer: I'm hacking the tulip driver itself (see http://www.tidalwave.net/~rdynes for a patch and driver tarball), thus I associate any trouble with tulip with my own hacks. -Richard -- Richard Dynes rdynes@varcom.com From rw@firstpr.com.au Fri Aug 13 11:34:37 1999 Date: Fri Aug 13 11:34:37 1999 From: Robin Whittle rw@firstpr.com.au Subject: Linksys PNIC II glitches Short version: 1 - The Linksys LNE100TX NICs I recently purchased with the *excellent* super-cost-effective EZXS55W 5 port 10/100 Meg switch are more trouble that they are worth for me, due to difficulties with drivers under Linux, and a few other intermittent problems which have been reported, and observed. 2 - Positive appraisal and defanning of the EZXS55W. - - - - Dear Donald and Linksys people, (Also to the Tulip driver development list.) Thanks, Donald, for your Ethernet drivers for Linux! I am writing to report that your currently valid driver version (v0.91 4/14/99) at http://cesdis.gsfc.nasa.gov/linux/drivers/tulip.c does not work with my particular Linksys NICs, but that the version which comes on a floppy from Linksys does. "v0.90f 12/17/98 Originally written by becker@cesdis.gsfc.nasa.gov Driver modified for Linksys LNE100TX Fast Ethernet PCI Adapter on 01/13/99" Here is a description of the NIC. PCB says: Part No.: LNE100TX Version 2.0 P/N:6804057404 REV:A2 (Date code on foil side of PCB: "9816".) LSI, 128 pins: LINKSYS LNE100TX LC82C115 C9914 T4023702 37BDX This card has a "WOL" Wake On LAN connector and a 6 pin jumper to configure it. These NICs works fine with Windows 98. They are not recognised at all by the Red Hat 6.0 installation procedure. (This is a pest even if the card is subsequently made to work, since I find it easier to install via LAN and set up all the networking details during installation, rather than later.) Once RH6.0 is installed, attempts to use the normal tulip.o driver fail, with an error message pointing out that the card ID of: 11ad c115 is not recognised. Therefore, I looked up the Ethernet HowTo, which took me to the Linksys page: http://www.linksys.com/support/solution/nos/linux_lne100tx.htm which directed me to use the latest available driver at: http://cesdis.gsfc.nasa.gov/linux/drivers/tulip.c (v0.91 4/14/99) which I compiled and installed. The driver was happy with the NIC, but it would not in fact send or receive any packets to the LAN (actually to a magnificent Linksys 100 Mbps 5 port *switch*). (BTW, the Linksys page says to "depmod -a", which I did, but this is not mentioned on the development page.) I tried every other possible configuration thing, and still it would not work. When I compiled the driver from the floppy, the worked fine. (Althoug I have not extensively tested it.) Clearly the "v0.91 4/14/99" driver is supposed to work with this chip, since: 1 - The source mentions its PCI ID and has special provisions for it. 2 - The Linksys site indicates that this is the driver code to use. 3 - The driver recognises the chip and installs itself happily, with the message: "Lite-On PNIC-II rev 37 at . . . . IRQ 9" 4 - TCP-DUMP reports activity of packets sent to this interface. However, it simply doesn't work! (I have not tried the "testing" version of the driver, currently "v0.91g".) Here are some suggestions for Linksys to improve matters: 1 - Correct the page: http://www.linksys.com/support/solution/nos/linux_lne100tx.htm which states that for RH5.2 and 6.0 the standard drivers will work. (Below that, there is a qualification, for if they don't!) Also, it states that the current driver from the Tulip team should work, which it doesn't - for these particular cards. 2 - Make the Floppy 2 /linux/ directory more helpful than simply the tulip.c file and the GPL copying file. Point the user to the web support page, and the Tulip development site. Give explicit compilation and installation instructions in a readme.txt file. Other concerns -------------- I note in the Errata of: http://cesdis.gsfc.nasa.gov/linux/drivers/tulip.html "Due inaccurate documentation, autonegotiation cannot be enabled on the PNIC chip." This sounds like a good reason to use another kind of NIC! This NIC card in my Windows machine occasionally (say every ten or twenty minutes - or more often with lots of activity?) appears to die for a second or so. The three LEDs for this card on the 5 port switch go off together, and then come back on together. According to the mailing list archives, a number of incorrect behaviours have been observed with some PNIC based cards. I am not sure if these are exactly the same cards as I have, but I would prefer to avoid using cards which occasionally send invalid data to the LAN. Whether these problems are caused by faulty driver design or not, I cannot tell. The point is, life is too way short to be spending time debugging other people's hardware and software when all you want is a handfull of bulletproof NICs! I can buy tried-and-tested Intel NICs (S/H 82557s for USD$33) and not have to worry about any of this! I only got these Linksys NICs as part of the switch package, and I don't plan to buy any more, or use them except perhaps on Windows machines . . . but even then, I want real-time audio through the LAN, so I can't have NICs going to sleep for a moment. The Tulip Development Page has details of joining the mailing list. Here are some URLs of recent postings in the archive pointing to anomalous behaviour of PNIC cards (not necessarily the same type as mine): Problem with Linksys etherfast 10/100 http://www.tux.org/hypermail/linux-tulip-bug/1999-Jul/0014.html Linksys PNIC card hangs up under load (v. 0.91g) http://www.tux.org/hypermail/linux-tulip-bug/1999-Jul/0012.html Odd bug when using tulip v0.91g on a LinkSys EtherFast 10/100 card http://www.tux.org/hypermail/linux-tulip-bug/1999-Aug/0003.html " . . . Whenever I send data from this card, it randomly (as far as I can tell) cuts 2 characters within the file and moves them forward a character before replacing them. . . . " (Seriously low-level user debugging!) - - - - I have put the tulip.c from the floppy, this email, and any other related files at: http://gair.firstpr.com.au/temp/tulip/ - - - - All hail the Linksys EZXS55W 5 port 10/100 Ethernet Switch! ----------------------------------------------------------- Finally, lest someone think I have something against Linksys, let me say that I think their new 5 port 10/100 Ethernet EZXS55W *Switch* is a beauty! The cost here, ex-tax, with two NICs and two cables as a kit was AUD$330, which is USD$215. If you look around, such as: http://www.1stcomputersource.com/cgi-win/detail.exe?443980 the switch itself can be purchased for USD$124. It is small, and has a fan - which is a source of noise and a dust and long-term maintenance issue. (The fan is a 40mm sleeve bearing Sunon.) I modified my EZXS55W for fanless operation by removing the rear panel, replaceing the top panel with a metal grid, adding a large heatsink to the heatsink on the main LSI (I found one which interdigitated nicely, used silicone grease, and cut some sheet aluminium to slot into the side-slots of the case and work as a spring to hold it in place) and adding a heatsink to the second largest LSI (Allayer AL102). As far as I know, this device is a faultless full-duplex 5 port 10/100 meg switch. Apart from perhaps its use of a fan, I think it is beautifully made - and its cost is extremely attractive! - Robin =============================================================== Robin Whittle rw@firstpr.com.au http://www.firstpr.com.au Heidelberg Heights, Melbourne, Australia First Principles Research and expression: Consulting and technical writing. Music. Internet music marketing. Telecommunications. Consumer advocacy in telecommunications, especially privacy. M-F relationships. Kinetic sculpture. Real World Electronics and software for music including: Interfaces Devil Fish mods for the TB-303, Akai sampler memory and Csound synthesis software. =============================================================== From kevin_myer@elanco.k12.pa.us Fri Aug 13 12:19:56 1999 Date: Fri Aug 13 12:19:56 1999 From: Kevin Myer kevin_myer@elanco.k12.pa.us Subject: strange behavior with 21143 cards I'm also having a similar problem here. Lest I ever get the feeling that my NIC works ok, it always seems to do something. After ironing out a duplex mismatch between switch and card, I'm back to the same problem you describe. Some services work fine but an ftp session causes the card to hang badly and requires a restart of networking (thank goodness its not NT or I'd be rebooting really often). I haven't come up with a good explanation for this. I'm using the 0.91g driver with a 2.2.10 kernel. Although I thought I had eliminated wiring, I'm beginning to second guess all my troubleshooting at this point, as I have an identical card in another machine (our main server) and it works fine. The card in my workstation is the flaky one. Sorry I can't help other than to confirm that at least someone else is having this problem. I suspect others are as I've seen several posts regarding eth 0 XXX vs. XXX hung error messages, which I suspect is related. Kevin -- ~ Kevin M. Myer, I.H.N.C . . Network/System Administrator /V\ ELANCO School District // \ /( )\ ^`~'^ From agriffis@bigfoot.com Fri Aug 13 14:25:27 1999 Date: Fri Aug 13 14:25:27 1999 From: Aron Griffis agriffis@bigfoot.com Subject: 2.2.11 and tulip.c issues On Thu, Aug 12, 1999 at 10:58:07PM +0100, Alan Cox wrote: > Try it - the more data we get (especially Don gets) the better This is is cc'd to linux-tulip; I assume Don will read it there. I have an Alpha Miata on which 0.91g does not work. The module loads, but no traffic gets across the interface. I can provide whatever debugging information you'd like if you'll instruct me what to do. 0.89H works fine on this machine, at least until I start X, at which point it stops working. If I exit X, then "ifdown eth0; rmmod tulip; ifup eth0", it starts working again. -- Aron Griffis Compaq Computer Corporation, ZKO3-3/T30 Tru64 Hardware Support 110 Spitbrook Rd, Nashua, NH 03062 603/884-1276 http://bigfoot.com/~agriffis/ From khuber@yuck.net Fri Aug 13 14:51:32 1999 Date: Fri Aug 13 14:51:32 1999 From: Kevin Huber khuber@yuck.net Subject: Linksys PNIC II glitches "Robin" == Robin Whittle writes: Robin> does not work with my particular Linksys NICs, but that the version Robin> which comes on a floppy from Linksys does. Same here, but mine is only reporting 10Mb/s with the .90f driver. I'm ready to replace the NIC... -Kevin From khuber@yuck.net Fri Aug 13 22:12:31 1999 Date: Fri Aug 13 22:12:31 1999 From: Kevin Huber khuber@yuck.net Subject: Linksys PNIC II glitches "Becker" == Donald Becker writes: Becker> What is reporting 10Mbps? The default media type when the module loads, and tulip-diag port selection. I guess that needn't correlate with the autoselect media type. (ifport eth0 reports auto.) tulip-diag reports "10mpbs-serial 100baseTx scrambler, full-duplex". The full-duplex there seems odd since it's connected to a hub. ( Obviously I don't understand the output I'm seeing; I appreciate your patience ). I can transfer with ftp at around 1200-1300K/sec which seems higher than 10mbps ethernet cards, but not 10x faster. My expectations may just be too high. /var/log/messages: tulip.c:v0.90f 12/17/98 Originally written by becker@cesdis.gsfc.nasa.gov Driver modified for Linksys LNE100TX Fast Ethernet PCI Adapter on 01/13/99 eth0: PNIC II at 0xfc00, 00 a0 cc 33 4b e2, IRQ 10. eth0: EEPROM default media type 10baseT. Becker> Remember that 'ifconfig' isn't reporting the speed, only the link Becker> encapsulation type. Good to know. Thank you for your help and good work! It would still be nice to find out why .91g doesn't work with this card -- I'm not sure what diagnostics would be helpful other than those I posted earlier. -Kevin ./tulip-diag: tulip-diag.c:v1.10 4/12/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Lite-On PNIC-II adapter at 0xfc00. Port selection is 10mpbs-serial 100baseTx scrambler, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. Use '-a' to show device registers, '-e' to show EEPROM contents, or '-m' to show MII management registers. From tmolina@home.com Fri Aug 13 22:31:03 1999 Date: Fri Aug 13 22:31:03 1999 From: Thomas Molina tmolina@home.com Subject: 2.2.11 and tulip.c issues On Fri, 13 Aug 1999, Richard Dynes wrote: > Alan Cox wrote: > > > > > > > Do we need to download Donald's 0.91 and test it or what? > > > > Try it - the more data we get (especially Don gets) the better > > I've cross posted this to the tulip list. I tested 0.91 with 2.2.11 and a Kingston card with a 21041 chipset. 0.91 works, but performance doesn't seem as good as with 0.89H. downloading a 50MB file from contrib.redhat.com results in 17Kb/s as opposed to 19Kb/s with 0.89H. CPU utilization was somewhat higher and there were a large number of collisions according to ifconfig (ca. 10000). The Kingston card is the interface for my Cox cable modem. I haven't given it a full shakedown with my standard netscape session and masquerading for the rest of the network. From tytso@MIT.EDU Tue Aug 17 18:54:44 1999 Date: Tue Aug 17 18:54:44 1999 From: tytso@MIT.EDU tytso@MIT.EDU Subject: Trying to obtain tulip.c:v0.89K Hi there, I'm trying to obtain a clean copy of the v0.89K version of the tulip.c driver, so I can figure out what changes Netgear hacked into the tulip driver, with a view towards getting the changes possibly merged into the latest 0.91 tulip.c driver. The current, latest tulip.c driver if used with cards that use the 82C168 PNIC Tulip clone, will lock up under heavy load (we can reliably reproduce the lockup in roughly 2-3 seconds by pointing a NFS benchmarking test at an NFS server using the tulip driver). The driver provided by Netgear appears avoids the lockup, but it is an oldish driver that apparently doesn't completely work correctly under SMP. It's definitely missing some SMP fixes in the 0.91 driver. This is the ID string found in the Netgear's driver: static const char version[] = "tulip.c:v0.89K 8/8/98 Originally written by becker@cesdis.gsfc.nasa.gov\nDriver modified by Netgear for FA310TX\nNetgear technical support: support@netgear.matrixx.net\n"; So anyway, if I can get the v0.89K driver, I'd like to do a three-way merge with the latest 0.91 driver, and then see whether people think the changes make sense, or whether they're so grody that some anonymous engineer at NetGear should be strung up :-) ---- and if the latter, what the Correct Fix ought to be so that the tulip driver can adequately support the PNIC clone chip. If anyone can help me with this bit of software archeology, I would greatly appreciate it. Thanks!! - Ted P.S. I'm not on the Linux-tulip mailing list, so please cc any responses back to me. Thanks!! From agriffis@bigfoot.com Wed Aug 18 15:13:49 1999 Date: Wed Aug 18 15:13:49 1999 From: Aron Griffis agriffis@bigfoot.com Subject: 2.2.11 and tulip.c issues I haven't received any feedback about the tulip driver versions and my card. Suggestions would be welcome. The interface reports as eth0: Digital DS21142/3 Tulip at 0x8000, 00 00 f8 75 36 98, IRQ 24. As I said earlier: > This is is cc'd to linux-tulip; I assume Don will read it there. > > I have an Alpha Miata on which 0.91g does not work. The module > loads, but no traffic gets across the interface. I can provide > whatever debugging information you'd like if you'll instruct me what > to do. > > 0.89H works fine on this machine, at least until I start X, at which > point it stops working. If I exit X, then "ifdown eth0; rmmod tulip; > ifup eth0", it starts working again. -- Aron Griffis Compaq Computer Corporation, ZKO3-3/T30 Tru64 Hardware Support 110 Spitbrook Rd, Nashua, NH 03062 603/884-1276 http://bigfoot.com/~agriffis/ From rgb@phy.duke.edu Wed Aug 18 16:35:39 1999 Date: Wed Aug 18 16:35:39 1999 From: Robert G. Brown rgb@phy.duke.edu Subject: 2.2.11 and tulip.c issues On Wed, 18 Aug 1999, Aron Griffis wrote: > I haven't received any feedback about the tulip driver versions and my > card. Suggestions would be welcome. The interface reports as > > eth0: Digital DS21142/3 Tulip at 0x8000, 00 00 f8 75 36 98, IRQ 24. > > As I said earlier: > > > This is is cc'd to linux-tulip; I assume Don will read it there. > > > > I have an Alpha Miata on which 0.91g does not work. The module > > loads, but no traffic gets across the interface. I can provide > > whatever debugging information you'd like if you'll instruct me what > > to do. > > > > 0.89H works fine on this machine, at least until I start X, at which > > point it stops working. If I exit X, then "ifdown eth0; rmmod tulip; > > ifup eth0", it starts working again. IIRC, the tulip very rarely has interrupt/ioport conflicts with mmap video cards. You might try the following: a) Look carefully at /proc/pci to see if you can see anything obvious that appears to be a conflict; b) Move the NIC to a different PCI slot. I know, this shouldn't matter (especially with 2.2.x and IO-APIC, although it was fairly common with 2.0.x kernels) but I've definitely had it resolve problems with tulip cards in the past. c) Finally (and most likely) there is an affliction that MANY tulip cards of years past have had in which they basically lie when they pass their PCI configuration back to the kernel. The lie involved a dysfunctional ioport. The characteristic of this bug is that it was repaired with exactly the same sequence of unloading and reloading the module you describe above. In those cards, the ioport shifted between the first load and the second -- this was one characteristic of the bug. I wrote a patch to solve this problem for 0.89H that I include below. Note that according to Don this patch "should" not be necessary, but the sad fact is that for many systems it works to solve the problem (both for the tulip and de4x5 drivers) regardless of where the problem REALLY lies. It isn't entirely without documentary support -- the algorithm employed I adopted from something given in Rubini's Linux Device Drivers (O'Reilly bronco) book. rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu %< Snip snip snip ===================================================== --- tulip.c-0.89H Mon Jan 11 07:59:21 1999 +++ tulip.c-0.89H.ioport Mon Jan 11 08:28:48 1999 @@ -18,7 +18,7 @@ */ #define SMP_CHECK -static const char version[] = "tulip.c:v0.89H 5/23/98 becker@cesdis.gsfc.nasa.gov\n"; +static const char version[] = "tulip.c:v0.89H.ioport 5/23/98 becker@cesdis.gsfc.nasa.gov\n"; /* A few user-configurable values. */ @@ -523,15 +523,53 @@ pcibios_read_config_dword(pci_bus, pci_device_fn, PCI_BASE_ADDRESS_0, &pci_ioaddr); #endif + /* + * Patch to (maybe) fix ioport bug. This fragment is from the book + * Linux Device Drivers, page 353, and polls each possible ioport + * until one is found that is writeable. I think that this is the + * correct and robust approach to pci initialization. + */ { - u32 pci_ioaddr_check; - pcibios_read_config_dword(pci_bus, pci_device_fn, - PCI_BASE_ADDRESS_0, &pci_ioaddr_check); - if (pci_ioaddr != pci_ioaddr_check) - printk("Buggy PCI BIOS - pcibios_read_config_dword(" - "%d,%d,%#x) = %#x / %#x.\n", - pci_bus, pci_device_fn, PCI_BASE_ADDRESS_0, - pci_ioaddr, pci_ioaddr_check); + int iio; + u32 pci_ioaddr_check,pci_ioaddr_mask; + u32 addresses[] = { + PCI_BASE_ADDRESS_0, + PCI_BASE_ADDRESS_1, + PCI_BASE_ADDRESS_2, + PCI_BASE_ADDRESS_3, + PCI_BASE_ADDRESS_4, + PCI_BASE_ADDRESS_5, + 0 + }; + for(iio=0;addresses[iio];iio++){ + pcibios_read_config_dword(pci_bus, pci_device_fn, + addresses[iio], &pci_ioaddr_check); + pcibios_write_config_dword(pci_bus, pci_device_fn, + addresses[iio], ~0); + pcibios_read_config_dword(pci_bus, pci_device_fn, + addresses[iio], &pci_ioaddr_mask); + pcibios_write_config_dword(pci_bus, pci_device_fn, + addresses[iio], pci_ioaddr_check); + if (!pci_ioaddr_mask){ + printk("Buggy PCI BIOS - pcibios_read_config_dword(" + "%d,%d,%#x) = %#x / %#x.\n", + pci_bus, pci_device_fn, PCI_BASE_ADDRESS_0, + pci_ioaddr, pci_ioaddr_check); + printk("ioport %x probably unusable. Continuing scan...\n", + pci_ioaddr_check); + } else { + pci_ioaddr = pci_ioaddr_check; /* Good one? */ + if(tulip_debug) printk(KERN_INFO "tulip_probe: ioport found at %x\n",pci_ioaddr); + break; + } + if (pci_ioaddr != pci_ioaddr_check) + } + if (!pci_ioaddr){ + pcibios_read_config_dword(pci_bus, pci_device_fn, + PCI_BASE_ADDRESS_0, &pci_ioaddr_check); + printk("No valid ioport found. Falling back on (failed) ioport %d\n",pci_ioaddr_check); + pci_ioaddr = pci_ioaddr_check; + } } /* Remove I/O space marker in bit 0. */ pci_ioaddr &= ~3; From alex@africaland.com Thu Aug 19 05:09:35 1999 Date: Thu Aug 19 05:09:35 1999 From: Alex Mahiva alex@africaland.com Subject: tulip fast ethernet I have a Tulip Vision Line dt 5/166 Machine which has been partitioned to run Redhat Linux release 5.2 apollo kernel 2.0.36 and windows NT 4 with 16mb ram. I installed a Tulip fast ethernet controller and hooked it on to a LAN it works fine in NT mode.The problem comes in when it comes to Linux. I used the tulip driver under the network settings,during the shut down and restart there were this errors. modprobe:can't locate module eth0 eth0:unknown interface I downloaded the driver tulip.c from ftp://cesdis.gsfc.nasa.gov...... followed the instructions but I was getting the following errors -f invalid option /usr/include/linux/version.h invalid directory If -f option is ommited the invalid directory error appears but the tulip.c is compiled to tulip.o I still carry on with insmod tulip.o then test it by pinging my gateway and other machines on the network but no luck even after restarting. Help me out am still new to the linux world and would like to test Linux on our Enterprise Says Alex From agriffis@bigfoot.com Thu Aug 19 10:32:52 1999 Date: Thu Aug 19 10:32:52 1999 From: Aron Griffis agriffis@bigfoot.com Subject: 2.2.11 and tulip.c issues Hello Robert, Thanks for the response. I have investigated further and here is what I have found. On Wed, Aug 18, 1999 at 04:35:10PM -0400, Robert G. Brown wrote: > IIRC, the tulip very rarely has interrupt/ioport conflicts with mmap > video cards. You might try the following: > > a) Look carefully at /proc/pci to see if you can see anything obvious > that appears to be a conflict; I don't see a conflict here but somebody with more understanding of this might see something. PCI devices found: Bus 0, device 3, function 0: Ethernet controller: DEC DC21142 (rev 48). Medium devsel. Fast back-to-back capable. IRQ 24. Master Capable. Latency=255. Min Gnt=20.Max Lat=40. I/O at 0x8000 [0x8001]. Non-prefetchable 32 bit memory at 0x9000000 [0x9000000]. Bus 0, device 4, function 0: IDE interface: CMD 646 (rev 1). Medium devsel. Fast back-to-back capable. Master Capable. Latency=248. Min Gnt=2.Max Lat=4. I/O at 0x8800 [0x8801]. Bus 0, device 7, function 0: Non-VGA device: Intel 82378IB (rev 67). Medium devsel. Master Capable. No bursts. Bus 0, device 12, function 0: VGA compatible controller: S3 Inc. Trio32/Trio64 (rev 0). Medium devsel. IRQ 32. Non-prefetchable 32 bit memory at 0x9800000 [0x9800000]. Bus 0, device 20, function 0: PCI bridge: DEC DC21152 (rev 1). Medium devsel. Fast back-to-back capable. Master Capable. Latency=255. Min Gnt=4. Bus 1, device 9, function 0: SCSI storage controller: Q Logic ISP1020 (rev 5). Medium devsel. IRQ 40. Master Capable. Latency=248. I/O at 0x9000 [0x9001]. Non-prefetchable 32 bit memory at 0xa000000 [0xa000000]. > b) Move the NIC to a different PCI slot. I know, this shouldn't > matter (especially with 2.2.x and IO-APIC, although it was fairly common > with 2.0.x kernels) but I've definitely had it resolve problems with > tulip cards in the past. The NIC is integrated on the motherboard. I tried moving the video card around but it changed nothing. > c) Finally (and most likely) there is an affliction that MANY tulip > cards of years past have had in which they basically lie when they pass > their PCI configuration back to the kernel. The lie involved a > dysfunctional ioport. The characteristic of this bug is that it was > repaired with exactly the same sequence of unloading and reloading the > module you describe above. In those cards, the ioport shifted between > the first load and the second -- this was one characteristic of the bug. In my case, the ioport hasn't changed when I've unloaded and reloaded the module. Additionally, although the bug is "repaired", if I re-enter X, the interface breaks again. > I wrote a patch to solve this problem for 0.89H that I include below. > Note that according to Don this patch "should" not be necessary, but the > sad fact is that for many systems it works to solve the problem (both > for the tulip and de4x5 drivers) regardless of where the problem REALLY > lies. It isn't entirely without documentary support -- the algorithm > employed I adopted from something given in Rubini's Linux Device Drivers > (O'Reilly bronco) book. I will give the patch a try. Thanks. -- Aron Griffis Compaq Computer Corporation, ZKO3-3/T30 Tru64 Hardware Support 110 Spitbrook Rd, Nashua, NH 03062 603/884-1276 http://bigfoot.com/~agriffis/ From jim@morris.net Thu Aug 19 12:31:47 1999 Date: Thu Aug 19 12:31:47 1999 From: Jim Morris jim@morris.net Subject: Spontaneous Slowdowns on SMP System Hi all. I have a dual-processor system running the Linux 2.2.10 kernel. I am using a very recently acquired LinkSys Etherfast 10/100 PCI card, based on the PNIC-II chipset. When running an SMP-enabled kernel, things will run great for a while, and then I suddenly start getting calls from users complaining that the "network is slow". Sure enough, I can do a telnet, or a domain logon to Samba from a Windows PC, and it appears as though the network connetion to the server is running at about 1/100th speed. I.e. everything works, but VERY slowly. If I take the network down on the server, and rmmod the tulip module, and then run "/etc/rc.d/init.d/network start" to bring networking backup, everything will be fine again for a while. All in all, the slowdowns occur somewhat randomly, at least once or twice per day. If I build and run a non-SMP kernel (and tulip driver), then everything runs fine indefinitely. In fact, I went on vacation last week, and left the server running the uniprocessor kernel, and its been running for almost 2 weeks solid with no network slowdowns. I have tried the Linksys-modified driver that came on the floppy with the card (a modified 0.90f), as well as 0.91, and the latest test version, 0.91g. The problem occurs with all 3 drivers. I *thought* I had seen mention of this, but looking through the mailing list archives on Tux, as well as the newsgroup archives on Dejanews doesn't turn up anything. Any help will be greatly appreciated! /-------------------------------\ | Jim Morris | jim@morris.net | \-------------------------------/ From jim@morris.net Thu Aug 19 12:46:50 1999 Date: Thu Aug 19 12:46:50 1999 From: Jim Morris jim@morris.net Subject: LinkSys 10/100 PNIC-II Transciever trouble Hi all. Using a recent version of the LinkSys Etherfast 10/100 card, based on the PNIC-II, I have found that the 0.91 and 0.91g versions of the stock Tulip driver do not appear to work properly when the card is connected to a 10/100 switching hub. At boot time, prior to loading the tulip driver, both the card and hub show a proper link indicator. As soon as the tulip module is loaded, the link LED's and 10/100 indicator LED's on the hub begins to switch on and off rapidly - about 1 or 2 times per second. At the same time, you can hear a relay or something in the transciever on the card clicking on and off. With a straight 10BaseT hub, the 0.91 versions of the Tulip driver work fine. Note that I *did* try forcing the media selection to 10BaseT when connected to the 100BaseTX hub, and it had no effect. If I used the Linksys-modified version of the 0.90f driver that is included on the Linksys floppies with this card, the card works fine with the 100BaseTX switching hub. For what its worth, and older LinkSys 10/100 Etherfast based on the *PNIC* (not PNIC-II) chipset works fine with the same hub, and the 0.91 or 0.91g driver. /-------------------------------\ | Jim Morris | jim@morris.net | \-------------------------------/ From becker@cesdis1.gsfc.nasa.gov Thu Aug 19 12:52:46 1999 Date: Thu Aug 19 12:52:46 1999 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: Spontaneous Slowdowns on SMP System On Thu, 19 Aug 1999, Jim Morris wrote: > I have a dual-processor system running the Linux 2.2.10 kernel. I am > using a very recently acquired LinkSys Etherfast 10/100 PCI card, based on > the PNIC-II chipset. When running an SMP-enabled kernel, things will run > great for a while, and then I suddenly start getting calls from users > complaining that the "network is slow". Sure enough, I can do a telnet, > or a domain logon to Samba from a Windows PC, and it appears as though the > network connetion to the server is running at about 1/100th speed. I.e. > everything works, but VERY slowly. I've gotten many reports of this type, with many different card types, all runing the 2.2.10 kernel. I've even experienced it with an instrumented version of the eepro100 driver. The driver appeared to be fine, it was the kernel that was delaying the packets. > If I take the network down on the server, and rmmod the tulip module, and > then run "/etc/rc.d/init.d/network start" to bring networking backup, > everything will be fine again for a while. All in all, the slowdowns > occur somewhat randomly, at least once or twice per day. Doing this not only resets the network card, it reset the queue layer as well. > I *thought* I had seen mention of this, but looking through the mailing > list archives on Tux, as well as the newsgroup archives on Dejanews > doesn't turn up anything. You likely saw it on other driver mailing lists, or on linux-net/linux-kernel. Try 2.2.11. Donald Becker becker@cesdis.gsfc.nasa.gov USRA-CESDIS, Center of Excellence in Space Data and Information Sciences. Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html From rgb@phy.duke.edu Thu Aug 19 14:41:52 1999 Date: Thu Aug 19 14:41:52 1999 From: Robert G. Brown rgb@phy.duke.edu Subject: 2.2.11 and tulip.c issues On Thu, 19 Aug 1999, Aron Griffis wrote: > The NIC is integrated on the motherboard. I tried moving the video > card around but it changed nothing. > > > c) Finally (and most likely) there is an affliction that MANY tulip > > cards of years past have had in which they basically lie when they pass > > their PCI configuration back to the kernel. The lie involved a > > dysfunctional ioport. The characteristic of this bug is that it was > > repaired with exactly the same sequence of unloading and reloading the > > module you describe above. In those cards, the ioport shifted between > > the first load and the second -- this was one characteristic of the bug. > > In my case, the ioport hasn't changed when I've unloaded and reloaded > the module. Additionally, although the bug is "repaired", if I > re-enter X, the interface breaks again. > > > I wrote a patch to solve this problem for 0.89H that I include below. > > Note that according to Don this patch "should" not be necessary, but the > > sad fact is that for many systems it works to solve the problem (both > > for the tulip and de4x5 drivers) regardless of where the problem REALLY > > lies. It isn't entirely without documentary support -- the algorithm > > employed I adopted from something given in Rubini's Linux Device Drivers > > (O'Reilly bronco) book. > > I will give the patch a try. Thanks. Unfortunately, if the ioport doesn't shift I'm going to guess that the patch doesn't help. Its beginning to sound more like some kernel resource is overlapping -- perhaps a memory-mapped region? -- with the X server. Because I've used the tulip driver for a long time with many cards, I'd like to think that it isn't the NIC driver but is more likely a bug in the X server. Sorry, I wish I could help more, but it sounds like you're going to have to get more information to proceed. Check to be sure that the memory regions assigned to each device (but especially the VGA card and NIC) are not overlapping (/proc/ioports). Maybe somebody else on the list(s) has a better idea. rgb > > -- > Aron Griffis Compaq Computer Corporation, ZKO3-3/T30 > Tru64 Hardware Support 110 Spitbrook Rd, Nashua, NH 03062 > 603/884-1276 http://bigfoot.com/~agriffis/ > Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu From jim@morris.net Thu Aug 19 15:30:50 1999 Date: Thu Aug 19 15:30:50 1999 From: Jim Morris jim@morris.net Subject: Spontaneous Slowdowns on SMP System On Thu, 19 Aug 1999, Donald Becker wrote: > I've gotten many reports of this type, with many different card types, all > runing the 2.2.10 kernel. < Stuff deleted > > Try 2.2.11. Hmmm. I unfortunately am running Software RAID for my root partition - and the latest RAID patches are for 2.2.10 - and I cannot get them to apply cleanly enough to 2.2.11 for me to trust it. What I can and will try is reverting to the 2.2.5 kernel, which was pretty stable AFAIK, and give that a spin. Thanks! /-------------------------------\ | Jim Morris | jim@morris.net | \-------------------------------/ From agriffis@zk3.dec.com Thu Aug 19 16:59:12 1999 Date: Thu Aug 19 16:59:12 1999 From: Aron Griffis agriffis@zk3.dec.com Subject: 2.2.11 and tulip.c issues On Thu, 19 Aug 1999, Robert G. Brown wrote: > Unfortunately, if the ioport doesn't shift I'm going to guess that the > patch doesn't help. Its beginning to sound more like some kernel > resource is overlapping -- perhaps a memory-mapped region? -- with the > X server. Because I've used the tulip driver for a long time with many > cards, I'd like to think that it isn't the NIC driver but is more likely > a bug in the X server. > > Sorry, I wish I could help more, but it sounds like you're going to have > to get more information to proceed. Check to be sure that the memory > regions assigned to each device (but especially the VGA card and NIC) > are not overlapping (/proc/ioports). Maybe somebody else on the list(s) > has a better idea. Thanks for the attention to the problem, Robert. I consulted with the guy here that wrote the tulip driver for Tru64, and he made some recommendations, none of which changed the behavior I'd been seeing. He mentioned, though, that the Trio64 card was never supported on the Miatas, partially because of conflicts with other devices. At the moment I'm going to take a Mach64 for a spin and see if that changes things. Thanks, Aron Griffis -- Aron Griffis Compaq Computer Corporation, ZKO3-3/T30 Tru64 Hardware Support 110 Spitbrook Rd, Nashua, NH 03062 603/884-1276 http://bigfoot.com/~agriffis/ From cbrown@denalics.net Thu Aug 19 17:59:56 1999 Date: Thu Aug 19 17:59:56 1999 From: Christopher E. Brown cbrown@denalics.net Subject: Spontaneous Slowdowns on SMP System On Thu, 19 Aug 1999, Jim Morris wrote: > On Thu, 19 Aug 1999, Donald Becker wrote: > > > I've gotten many reports of this type, with many different card types, all > > runing the 2.2.10 kernel. > > < Stuff deleted > > > > Try 2.2.11. > > Hmmm. I unfortunately am running Software RAID for my root partition - > and the latest RAID patches are for 2.2.10 - and I cannot get them to > apply cleanly enough to 2.2.11 for me to trust it. What I can and will > try is reverting to the 2.2.5 kernel, which was pretty stable AFAIK, and > give that a spin. 2.2.12-final is out and has the latest raid included. ---- First Law of System Requirements: "Anything is possible if you don't know what you're talking about..." From jfr1@shs.starkville.k12.ms.us Thu Aug 19 18:57:39 1999 Date: Thu Aug 19 18:57:39 1999 From: Joe Robertson jfr1@shs.starkville.k12.ms.us Subject: D1 vs. D2 (KMM42892C0KM) (fwd) FYI.. for those of you with Netgears, thought this might be of interest :) Joe ---------- Forwarded message ---------- Date: Thu Aug 19 18:57:39 1999 From: NETGEAR Technical Support Subject: D1 vs. D2 (KMM42892C0KM) Resent-Date: Wed, 18 Aug 1999 17:54:30 -0500 (CDT) Resent-To: Joe Robertson Resent-Subject: D1 vs. D2 (KMM42892C0KM) Hello, Thanks for contacting NETGEAR technical support. According to our engineers the D1 and D2 basically are the same design. D1 uses Level-one ST10040/LXT970 phy and the MAC controller 82C169B is designed to work with that particular phy. With D2 card, we modified the MAC controller (82C169C) to make it work with the Broadcom PHY (BCM5202). There is no performance variation between the two cards. -Michael Bailey Netgear Technical Support. From dan@vrx.net Thu Aug 19 20:55:38 1999 Date: Thu Aug 19 20:55:38 1999 From: Dan dan@vrx.net Subject: please delete me! Someone please get me off this stupid list! From al764984@mail.mty.itesm.mx Thu Aug 19 23:53:15 1999 Date: Thu Aug 19 23:53:15 1999 From: Alejandro Borges Sanchez al764984@mail.mty.itesm.mx Subject: please delete me! On Thu, 19 Aug 1999, Dan wrote: > Someone please get me off this stupid list! > > Its not stupid...... Its kewl...... U dont deserve a tulip set...... Come to think of it....I dont think anyone does. Alex From becker@cesdis1.gsfc.nasa.gov Fri Aug 20 03:07:54 1999 Date: Fri Aug 20 03:07:54 1999 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: 2.2.11 and tulip.c issues On Thu, 19 Aug 1999, Aron Griffis wrote: > On Thu, 19 Aug 1999, Robert G. Brown wrote: > > Unfortunately, if the ioport doesn't shift I'm going to guess that the > > patch doesn't help. Its beginning to sound more like some kernel > > resource is overlapping -- perhaps a memory-mapped region? -- with the ... > Thanks for the attention to the problem, Robert. I consulted with the > guy here that wrote the tulip driver for Tru64, and he made some > recommendations, none of which changed the behavior I'd been seeing. The current Tulip driver uses I/O space accesses to registers. I've known for a while that using memory space would produce better code on machines like the Alpha and PPC that don't have native I/O space instructions. It turns out that using memory space results in dramatically better performance on certain x86 SMP machines as well. The trivial single processor performance improvement is multiplied because the tiny number of I/O writes occur in locked critical regions. Using memory space allows the writes to "complete" into the write buffer immediately, instead of waiting until the PCI bus transaction has finished. I have a test version of the Tulip driver that uses memory operations. This might fix the problem above, and will likely avoid the need for udelay(2) on the PNIC to work around the write-buffer-delay bug. This is a major change, and I'll have to test a lot of boards. I expect the biggest issue to be timing changes for the serial bit streams used to read the EEPROM and MII registers. I initially validated the original code by probing the traces on the circuit board and checking that actual bit rate was in-spec. Since then I've used a software approach (reading a real-time counter) to verify that the bit rate hasn't changed. The software method may no longer be accurate with the write buffers in the memory subsystem that arbitrarily changes the timing of writes. A second issue is checking that all of the chips are reliable with memory operations. Some chips, notably the VIA Rhine, were only design-tested with I/O operations. [[ Please hold any follow-up discussions about Tulip or general driver issues on linux-tulip@beowulf.gsfc.nasa.gov instead of on the linux-kernel list. ]] Donald Becker becker@cesdis.gsfc.nasa.gov USRA-CESDIS, Center of Excellence in Space Data and Information Sciences. Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html From agriffis@zk3.dec.com Fri Aug 20 10:37:49 1999 Date: Fri Aug 20 10:37:49 1999 From: Aron Griffis agriffis@zk3.dec.com Subject: 2.2.11 and tulip.c issues Donald, I would be happy to try your test version and report if it fixes the problem for me. However if it's dependent on Linus' new resource allocation, I will have to wait for 2.3.x to be able to compile on Alpha. I also forwarded your message to Kirt Gillum, the author of the Tru64 tulip driver. I thought he might be interested in it, however he might not have the time to comment. Aron On Fri, 20 Aug 1999, Donald Becker wrote: > The current Tulip driver uses I/O space accesses to registers. I've > known for a while that using memory space would produce better code > on machines like the Alpha and PPC that don't have native I/O space > instructions. > > It turns out that using memory space results in dramatically better > performance on certain x86 SMP machines as well. The trivial single > processor performance improvement is multiplied because the tiny > number of I/O writes occur in locked critical regions. Using memory > space allows the writes to "complete" into the write buffer > immediately, instead of waiting until the PCI bus transaction has > finished. > > I have a test version of the Tulip driver that uses memory > operations. This might fix the problem above, and will likely avoid > the need for udelay(2) on the PNIC to work around the > write-buffer-delay bug. > > This is a major change, and I'll have to test a lot of boards. I > expect the biggest issue to be timing changes for the serial bit > streams used to read the EEPROM and MII registers. I initially > validated the original code by probing the traces on the circuit > board and checking that actual bit rate was in-spec. Since then > I've used a software approach (reading a real-time counter) to > verify that the bit rate hasn't changed. The software method may no > longer be accurate with the write buffers in the memory subsystem > that arbitrarily changes the timing of writes. > > A second issue is checking that all of the chips are reliable with > memory operations. Some chips, notably the VIA Rhine, were only > design-tested with I/O operations. -- Aron Griffis Compaq Computer Corporation, ZKO3-3/T30 Tru64 Hardware Support 110 Spitbrook Rd, Nashua, NH 03062 603/884-1276 http://bigfoot.com/~agriffis/ From rgb@phy.duke.edu Fri Aug 20 11:19:05 1999 Date: Fri Aug 20 11:19:05 1999 From: Robert G. Brown rgb@phy.duke.edu Subject: 2.2.11 and tulip.c issues On Fri, 20 Aug 1999, Donald Becker wrote: > On Thu, 19 Aug 1999, Aron Griffis wrote: > > > On Thu, 19 Aug 1999, Robert G. Brown wrote: > > > Unfortunately, if the ioport doesn't shift I'm going to guess that the > > > patch doesn't help. Its beginning to sound more like some kernel > > > resource is overlapping -- perhaps a memory-mapped region? -- with the > ... > > Thanks for the attention to the problem, Robert. I consulted with the > > guy here that wrote the tulip driver for Tru64, and he made some > > recommendations, none of which changed the behavior I'd been seeing. > > The current Tulip driver uses I/O space accesses to registers. I've known > for a while that using memory space would produce better code on machines > like the Alpha and PPC that don't have native I/O space instructions. > > It turns out that using memory space results in dramatically better performance > on certain x86 SMP machines as well. The trivial single processor performance > improvement is multiplied because the tiny number of I/O writes occur in > locked critical regions. Using memory space allows the writes to "complete" > into the write buffer immediately, instead of waiting until the PCI bus > transaction has finished. > > I have a test version of the Tulip driver that uses memory operations. > This might fix the problem above, and will likely avoid the need for > udelay(2) on the PNIC to work around the write-buffer-delay bug. This sounds good. If you give me a URL I'd be happy to give it a spin here. I'm probably just going to be "playing" compared to the rigorous testing sequence you describe below, but maybe I can break something with it, you never know;-). I'll probably be playing anyway... rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu From jim@morris.net Fri Aug 20 11:47:54 1999 Date: Fri Aug 20 11:47:54 1999 From: Jim Morris jim@morris.net Subject: Spontaneous Slowdowns on SMP System On Thu, 19 Aug 1999, Christopher E. Brown wrote: > 2.2.12-final is out and has the latest raid included. Cool. I'll go look for it. /-------------------------------\ | Jim Morris | jim@morris.net | \-------------------------------/ From jfr1@shs.starkville.k12.ms.us Fri Aug 20 17:19:13 1999 Date: Fri Aug 20 17:19:13 1999 From: Joe Robertson jfr1@shs.starkville.k12.ms.us Subject: How to delete yourself from the list Here's the message that you got when you first joined.. it's all in there. It said you should save it.. ;) Joe ---------- Forwarded message ---------- Date: Fri Aug 20 17:19:13 1999 From: Majordomo@beowulf.gsfc.nasa.gov To: jfr1@shs.starkville.k12.ms.us Subject: Welcome to linux-tulip -- Welcome to the linux-tulip mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, send the following command in email to : unsubscribe Or you can send mail to with the following command in the body of your email message: unsubscribe linux-tulip or from another account, besides jfr1@shs.starkville.k12.ms.us: unsubscribe linux-tulip jfr1@shs.starkville.k12.ms.us If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: A mailing list for information and bug reports on the Linux Tulip device driver From jrochate@ualg.pt Fri Aug 20 21:42:23 1999 Date: Fri Aug 20 21:42:23 1999 From: Joao Rochate jrochate@ualg.pt Subject: Problemas with 21142/3 cards Hi... I saw you post on the Linux-tulip-bug mailing list archives: http://www.tux.org/hypermail/linux-tulip-bug/1999-May/0001.html I got exactly the same problem as you, and I haven't managed to solve the problem. Recompiled as module, recompiled as normal, updated to the latest version (0.91), and allways got the same error: "Wrong Data Byte #8 should be..." I can post more info, if some got any clues... :| Have you come to a solution? If so, I think it could be useful to everybody and to the archives. Data: * RedHat Linux/Alpha 6.0 * MIATA 600au * 2.2.15 (original from the RH dist) Cheers, Joao Rochate ------------------------------------------------------- Joao Pedro Rochate | EMail: jrochate@ualg.pt Servicos de Informatica | URL: w3.ualg.pt/~jrochate Universidade do Algarve | Phone: +351 (0)89 800 961 8000 Gambelas - FARO | ISDN: +351 (0)89 860 125 P O R T U G A L (pt) | GSM: +351 (0)931 950xxxx -=[ http://www.ualg.pt ]=- | Fax: +351 (0)89 860 129 ------------------------------------------------------- Eng. de Sistemas e Computacao - UCEH - Univ. do Algarve From GSaraber@unlimitedsolutions.com Mon Aug 23 11:48:34 1999 Date: Mon Aug 23 11:48:34 1999 From: Gerard Saraber GSaraber@unlimitedsolutions.com Subject: porting tulip driver from 2.2.x to 2.3.14 Hi linux-tulip folks, It has been suggested by someone to forward the message below to this list as well, I've posted it to linux-kernel@vger a couple of hours ago.. Regards, Gerard Saraber Hi :-) I've been having trouble with my tulip (Linksys LNE10/100TX - PNIC) network card since I bought it, It got much better since someone on the #stampede irc channel pointed me to Donald Becker's Network card driver page .. my card works much better with driver v91 i think it was revision e, not sure. Anyway .. feeling adventerous and always running the latest kernel I decided to upgrade to 2.3.14 .. which comes with the tulip.c v89H which doesn't work with my card .. so no problem , just copy over the version 91e .. wrong, that doesn't compile anymore.. So I've spend yesterday all day trying to fix the driver .. I've gotten it to compile and actually send/receive some packets, but I've locked my system up solid doing that, replacing dev_alloc_skb( ) with DEV_ALLOC_SKB( ) and #defining it as #define DEV_ALLOC_SKB( len ) dev_alloc_skb( len+2 ) fixed the hard lockup .. but i't still not very solid.. If I try to ping the other two systems on my net I get something like: reply from 192.168.13.2 - 1999 ms reply from 192.168.13.2 - 1000 ms reply from 192.168.13.2 - 0.1 ms then it stops .. I've noticed there have been some changes in the IRQ handling code as well ( SA_SHIRQ ) in the driver lots of comments about "shared irq" stuff .. so no problem I ported that stuff from the kernel driver too, as best I could.. then the card stopped working all together so i thought I might have broken the driver .. tore up too much. ( I've been working on the module mainly .. load module, ifconfig eth0 up, ping gateway unload fix, compile etc.) anyway, so i got a later driver found through a link on Donald Becker's site to v91g and started over, I've pretty much replaced all the "struct device" declarations with "struct net_device" replaced "ioaddr = pdev->base_addr &~3" with ioaddr = pdev->resource[0].start &~3; But I can't get my card to do anything anymore .. "even" in windows98 (where the card worked (almost) flawless before) it doesn't ping or reply to pings anymore .. So right now the card could have died :-( So my questions (after all this) are: 1. could I have actually broken the card by messing with it's driver ? 2. Are there any documents about the required driver changes that I could read to make my "porting" a little more educated .. I did a diff between the 89H kernel driver and Donald's 91c (i think) driver.. the kernel driver is 88k, the 91c driver is 104k .. and the diff was 95k .. so straightforward porting wasn't really possible. Any help / hints would be appreciated .. If anyone is interested I'd gladly make the "hacked up" drivers available for anyone to look at .. Thanks, --====================================================================-- Gerard Saraber | http://saraber.dhs.org work: gsaraber@unlimitedsolutions.com | If you don't like Linux you home: gerard@saraber.dhs.org | didn't configure it right. From becker@cesdis1.gsfc.nasa.gov Mon Aug 23 15:09:03 1999 Date: Mon Aug 23 15:09:03 1999 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: 3 x Cogent multi ports problems ! On Mon, 23 Aug 1999, Yann Dupont wrote: > I think there is a way to improve the logic of detecting multiport .. > new PCI BUS number, and the SAME for the 4 ports. ... > So maybe, during the probe, it should be useful to memorize the current > PCI bus number before deciding the new port probed is just another port of > a multiport board, or a new port of a new board ... Excellent idea! This wont' help with the hack work-around for the BIOS IRQ bug (all ports interrupt on the first IRQ, even though the BIOS claims they are on different IRQs), but it will avoid problems such as yours. Donald Becker becker@cesdis.gsfc.nasa.gov USRA-CESDIS, Center of Excellence in Space Data and Information Sciences. Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html From FarneyR@rucker.army.mil Mon Aug 23 16:59:07 1999 Date: Mon Aug 23 16:59:07 1999 From: Farney, Robert C. FarneyR@rucker.army.mil Subject: Install Problem w/RedHat 5.2 Hi Don, This is Bob Farney from Fort Rucker, Alabama (Home of Army Aviation). I am having trouble installing the Tulip driver for an SMC card in a Gateway Pentium II (PCI) that I in fact know works in that computer. This facet of Linux is still new to me. Would it be possible to obtain telephone assistance from you again. I don't know if you recall I talked with you several months back regarding PCMCIA cards being installed in an IBM 770X laptop for a simulation called Modsaf. This would be greatly appreciated. What have I done so far you may be asking yourself: 1. I down loaded the tulip driver that I believe you created 2. I modified the Kernel to add all the possible SMC Ethernet cards that were available. 3. I tried to compile the driver, but that is a new area to me and I may not be doing this correctly. 4. If you look on this request favorably I could call you at your convenience. Again Don, thanks in advance.. Bob Farney Computer Specialist From barrie@calvin.demon.co.uk Mon Aug 23 17:04:10 1999 Date: Mon Aug 23 17:04:10 1999 From: Barrie Spence barrie@calvin.demon.co.uk Subject: choosing a pukka 2114x card? Are there any advantages with a 21143 card over the older 21140? I believe I can still obtain some Acer 21140 cards (I have one working nicely in a PowerMac), but from what I've noticed recently, it would appear that some of the newer Kingston cards may be using 21143s. I also have a Faralon card (21143) destined for the second PowerMac, but if it was advantageous, I'd replace the Netgear PNIC (rev D1) based cards in my Intel machines. I've also noticed that the the real 21140 may be the most reliable and stable :) Advice anyone? Thanks, Barrie -- Barrie Spence Sanity Clause? There is no Sanity Clause Home: barrie@calvin.demon.co.uk Telephone +44 1506 442304 Play: b.spence@computer.org From evay@oa.cnet.com.tw Tue Aug 24 02:54:13 1999 Date: Tue Aug 24 02:54:13 1999 From: =?ISO-8859-1?Q?=B7=A8=B2=D3=AC=FC?= evay@oa.cnet.com.tw Subject: We have compiled the tulip.c driver on our machines We have compiled the tulip.c driver on our machines running Caldera 2.2 OpenLinux and Linux version 2.2.6(slackware 4.0). PCI Fast Ethernet Adapter Controller is AX88140 (ASIX). Then installed it correctly. We are not,however,able to ping the Linux machine from the Novell, Win95,Win98 and NT.We cannot telnet to it,ftp,etc.They are on the same Hub(no gateways,switches,firewalls or bridges). In earlier version Linux can ping everyone,although others (ex: Novell,Win95,Win98 and NT) can not ping Linux until Linux ping them. But version is on the Web site now,Linux can not ping everyone,and everyone can not ping Linux . We look forward to your answer and new version. Thank you, evay@oa.cnet.com.tw Best Regards Eva Yang From GSaraber@unlimitedsolutions.com Tue Aug 24 09:05:19 1999 Date: Tue Aug 24 09:05:19 1999 From: Gerard Saraber GSaraber@unlimitedsolutions.com Subject: porting tulip driver from 2.2.x to 2.3.14 [update] Hi, I got a hint from Brian Perkins on how to get my tulip card back to life again .. I basically ran the "install eeprom" utility that comes with the NIC, that brought it back to life, thanks! Anyway, I opened up the case and my nic is not a PNIC, that's just what the driver says LiteOn pnic, I'm using 2.2.3 (some tarball i had floating around my system) now with the 91g driver and absolutely no problems, it's rocksolid.. So I'll probably continue my porting of the driver tonight.. and if anyone would like to volunteer some information about the required network card changes [resources stuff etc.] for a 2.3.14+ kernel I would really appreciate it. I've gotten great email about how to get the card back to life and where to look for info on that .. but nothing yet on how to "properly" adapt the driver, I would like to be able to make some more educated guesses as to how to fix the driver, right now I'm looking at how things are done in the 89 driver that came with the kernel, but because a lot of other stuff having to do with the NIC has changed i sometimes can't tell what to "port" ps. did I mention that it was fun mucking with driver source and actually have it almost work ? Thanks, --====================================================================-- Gerard Saraber | http://saraber.dhs.org work: gsaraber@unlimitedsolutions.com | If you don't like Linux you home: gerard@saraber.dhs.org | didn't configure it right. From bryan@terran.org Tue Aug 24 22:16:03 1999 Date: Tue Aug 24 22:16:03 1999 From: B. James Phillippe bryan@terran.org Subject: 21143-xD: any success stories with tulip.c? Greetings, Anyone get a DS21143-TD NIC with MII working using the tulip.c driver? If so, could you tell me which PHY chip your board has and which driver worked for you? I'm particularly interested in LevelOne PHY's. thanks, -bp -- # bryan at terran dot org # http://www.terran.org/~bryan From bryan@terran.org Wed Aug 25 19:10:33 1999 Date: Wed Aug 25 19:10:33 1999 From: B. James Phillippe bryan@terran.org Subject: Problems with 21143-TD and LXT970ATC Hello, I have a board which has a DC21143-TD MAC and LXT970ATC LevelOne PHY w/MII, which is not usable with any version of the tulip driver. I'm currently working with 91g. The device is detected, but it seems the PHY is not being initialized or woken up. The symptom is an error-free detection (until you try to transmit), and a solidly lit ACT LED and blinking 10/100 LED. Here is some information: Aug 25 16:03:12 kernel: Found Digital DS21143 Tulip at PCI I/O address 0xfc00. Aug 25 16:03:12 kernel: tulip.c:v0.91g 7/16/99 becker@cesdis.gsfc.nasa.gov Aug 25 16:03:12 kernel: eth1: Digital DS21143 Tulip rev 65 at 0xfc00, 00:90:7F:00:00:78, IRQ 10. Aug 25 16:03:12 kernel: eth1: EEPROM default media type Autosense. Aug 25 16:03:12 kernel: eth1: MII interface PHY 0, setup/reset sequences 2/2 long, capabilities 0f 08. Aug 25 16:03:12 kernel: eth1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Aug 25 16:03:12 kernel: eth1: Advertising 01e1 on PHY 0 (0). Aug 25 16:03:12 kernel: eth1: Using media type MII, CSR12 is c6. Aug 25 16:03:12 kernel: eth1: MII transceiver #31 config 3000 status 7809 advertising 01e1. Aug 25 16:03:17 kernel: eth1: tulip_open() irq 10. Aug 25 16:03:17 kernel: eth1: Advertising 01e1 on PHY 0 (31). Aug 25 16:03:17 kernel: eth1: Using media type MII, CSR12 is c6. Aug 25 16:03:17 kernel: eth1: Using MII transceiver 31, status 7809. Aug 25 16:03:17 kernel: eth1: Done tulip_open(), CSR0 f8a08000, CSR5 f0660000 CSR6 b20e2002. Aug 25 16:03:20 kernel: eth1: 21143 negotiation status 000000c6, MII. Aug 25 16:03:20 kernel: eth1: MII status 7829, Link partner report 40a1. Aug 25 16:04:20 kernel: eth1: 21143 negotiation status 000000c6, MII. Aug 25 16:04:20 kernel: eth1: MII status 7809, Link partner report 0000. Aug 25 16:04:20 kernel: eth1: No link beat on the MII interface, status 7809. tulip-diag.c:v1.10 4/12/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #3: Found a Digital DS21143 Tulip adapter at 0xfc00. Digital DS21143 Tulip chip registers at 0xfc00: f8a08000 ffffffff ffffffff 00fdb028 00fdb228 f0660000 b20e2002 fbfffbff e0000000 fffd83ff ffffffff 00000000 000000c6 ffff0000 fff80000 8fff0000 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. tulip-diag.c:v1.10 4/12/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #3: Found a Digital DS21143 Tulip adapter at 0xfc00. 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 31, status 0x7809. MII PHY #31 transceiver registers: 3000 7809 7810 0003 01e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 4000 0000 07fb 0010 0000 0002 0001 0000 0000 0000 0000 0000 0000 0000. Internal autonegotiation state is 'Autonegotiation disabled'. tulip-diag.c:v1.10 4/12/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #3: Found a Digital DS21143 Tulip adapter at 0xfc00. 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. EEPROM contents: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0104 9000 007f 7800 1e00 0000 0800 9501 0003 0f02 0f08 0200 080f 000f 7800 01e0 5000 1800 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ced4 ID CRC 0xe3 (vs. 00), complete CRC d48cd1a9. Ethernet MAC Station Address 00:90:7F:00:00:78. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 30, default media type 0800 (Autosense). 1 transceiver description blocks: Media MII, block type 3, length 21. MII interface PHY 0 (media type 11). 21143 MII initialization sequence is 2 words: 080f 000f. 21143 MII reset sequence is 2 words: 080f 000f. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. No MII interrupt. MII PHY found at address 31, status 0x7809. MII PHY #31 transceiver registers: 3000 7809 7810 0003 01e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 4000 0000 0069 0010 0000 0002 0001 0000 0000 0000 0000 0000 0000 0000. Any ideas? -bp -- # bryan at terran dot org # http://www.terran.org/~bryan From bryan@terran.org Thu Aug 26 14:48:04 1999 Date: Thu Aug 26 14:48:04 1999 From: B. James Phillippe bryan@terran.org Subject: Problems with 21143-TD and LXT970ATC On Wed, 25 Aug 1999, Donald Becker wrote: > On Wed, 25 Aug 1999, B. James Phillippe wrote: > > > I have a board which has a DC21143-TD MAC and LXT970ATC LevelOne PHY > > w/MII, which is not usable with any version of the tulip driver. I'm ... > You might try 'mii-diag -R'. Okay, I tries that (and no go), but here is some new information from mii-diag: [root@localhost /root]# mii-diag -v mii-diag.c:v1.05 2/17/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Using the default interface 'eth0'. MII PHY #24 transceiver registers: 3100 786f 2000 5c01 01e1 40a1 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0004 0000 0000 0001 8060 8020 0c38 0000 1800 a3b9 007f 2c05 001b. Basic mode control register 0x3100: Auto-negotiation enabled. Basic mode status register 0x786f ... 786f. Link status: established. This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. *** Link Jabber! *** Your link partner can do 40a1: 100baseTx 10baseT. I have noticed that if I restart negotiation with no cable present, the link status does go to fail, and the partner report is 0 (sounds right). Then if I plug this into my hub and run mii-diag -r (or -R) the device goes into this state. I'll continue running some tests today. -bp -- # bryan at terran dot org # http://www.terran.org/~bryan From lierman@comm.mot.com Thu Aug 26 17:41:56 1999 Date: Thu Aug 26 17:41:56 1999 From: Ken Lierman lierman@comm.mot.com Subject: SROM and crc's Hi all, I'm working on some code to read and write from the srom's on some 2114x boards. Anyway, i'm having a problem w/ the srom crc. I copied the sample code from appendix a of the srom documentation, but it doesn't generate the same CRC as the one stored in the "known good" board i'm testing with.... any ideas? Anyone know of other sources for a similar crc routine? Any help would be GREATLY appreciated! Thx! Ken Lierman kliermanm@bigfoot.com From bernieb@vogon.capescott.net Fri Aug 27 23:36:03 1999 Date: Fri Aug 27 23:36:03 1999 From: Andy Barlak bernieb@vogon.capescott.net Subject: repeated time outs, dec tulip network stops When this 2.2.12 kernel networking dies, the eth0 kernel logs show repeated attempts to discover the appropriate medium as shown below. kernel 2.2.12, tulip.v091g (or stock v0.89) debug=2, kernel 2.3.15, stock kernel-tulip.c, debug=2 Acer ALN-310 NIC(21140-AF), AMD-K6 400, 128M, FIC VA-503+ mobo; both gcc-2.7.2.3 and gcc-2.95, Telnet to a peer on the same subnet and ping -f back to the local machine; the local machine's ethernet transmitter breaks. Networking has died with kernels 2.2.10, 2.2.11, and present 2.2.12 when eth0 usage has ranged from high: intentional ping -f, intentional "mtr" with a high rate, large ftp; to very low: when the system has been up but idle. High traffic can stop the network in seconds. Only the transmitter stops, the receiver keeps working: that is a ping -f from a peer keeps sending pings, it's just the replys that stop being sent. Network comes back up after /etc/rc.d/init.d/network stop network start Aug 27 15:46:59 boska kernel: eth0: Link beat detected for 100baseTx. Aug 27 15:46:59 boska kernel: eth0: MII status 782d, Link partner report 40a1. Aug 27 15:47:59 boska kernel: eth0: Media selection tick, 100baseTx, status fc660000 mode 32042002 SIA ffffff20 ffffffff 1c09fdc0 fffffec8. Aug 27 15:47:59 boska kernel: eth0: Transceiver monitor tick: CSR12=0xffffff20 b it 6 is 0, expecting 0. Aug 27 15:47:59 boska kernel: eth0: Link beat detected for 100baseTx. Aug 27 15:47:59 boska kernel: eth0: MII status 782d, Link partner report 40a1. Aug 27 15:48:13 boska kernel: eth0: 21140 transmit timed out, status fc660000, S IA ffffff20 ffffffff 1c09fdc0 fffffec8, resetting... Aug 27 15:48:13 boska kernel: eth0: Using a 21140 non-MII transceiver with control setting 00. Aug 27 15:48:13 boska kernel: eth0: Using media type 100baseTx-FD, CSR12 is 20. Aug 27 15:48:13 boska kernel: eth0: transmit timed out, switching to 100baseTx-FD media. Aug 27 15:48:13 boska kernel: eth0: The transmitter stopped. CSR5 is fc678006, CSR6 32042002, new CSR6 2040000. Aug 27 15:48:18 boska kernel: eth0: 21140 transmit timed out, status fc660000, SIA ffffff20 ffffffff 1c09fdc0 fffffec8, resetting... Aug 27 15:48:18 boska kernel: eth0: Using a 21140 non-MII transceiver with control setting 00. Aug 27 15:48:18 boska kernel: eth0: Using media type 10baseT, CSR12 is 20. Aug 27 15:48:18 boska kernel: eth0: transmit timed out, switching to 10baseT media. Aug 27 15:48:18 boska kernel: eth0: The transmitter stopped. CSR5 is fc678006, CSR6 32442002, new CSR6 2440000. Aug 27 15:48:23 boska kernel: eth0: 21140 transmit timed out, status fc660000, SIA ffffff20 ffffffff 1c09fdc0 fffffec8, resetting... Aug 27 15:48:23 boska kernel: eth0: Using a 21140 non-MII transceiver with control setting 00. Aug 27 15:48:23 boska kernel: eth0: Using media type 100baseTx-FD, CSR12 is 20. Aug 27 15:48:23 boska kernel: eth0: transmit timed out, switching to 100baseTx-FD media. Aug 27 15:48:23 boska kernel: eth0: The transmitter stopped. CSR5 is fc678006, CSR6 32042002, new CSR6 2040000. Aug 27 15:48:28 boska kernel: eth0: 21140 transmit timed out, status fc660000, SIA ffffff20 ffffffff 1c09fdc0 fffffec8, resetting... Aug 27 15:48:28 boska kernel: eth0: Using a 21140 non-MII transceiver with control setting 00. Aug 27 15:48:28 boska kernel: eth0: Using media type 10baseT, CSR12 is 20. Aug 27 15:48:28 boska kernel: eth0: transmit timed out, switching to 10baseT media. Aug 27 15:48:28 boska kernel: eth0: The transmitter stopped. CSR5 is fc678006, CSR6 32442002, new CSR6 2440000. and so on ------------------------------------------------------------------------------- Andy Barlak Q) When was the last time your computer was backed up? A) My computer is against a wall and cannot be backed up any further From bryan@terran.org Sat Aug 28 02:56:21 1999 Date: Sat Aug 28 02:56:21 1999 From: B. James Phillippe bryan@terran.org Subject: repeated time outs, dec tulip network stops On Fri, 27 Aug 1999, Andy Barlak wrote: > When this 2.2.12 kernel networking dies, the eth0 kernel logs show > repeated attempts to discover the appropriate medium as shown below. > kernel 2.2.12, tulip.v091g (or stock v0.89) debug=2, I have seen the exact same thing with 91g on a 21143-xC w/QSI6611 non-MII PHY on 2.0.3X. Only under high load (we have an intensive throughput lab with 4 100Mb/s Alpha's used as end-points), and always under high load. Plain 91 dated April seems solid under identical conditions. cheers, -bp -- # bryan at terran dot org # http://www.terran.org/~bryan From gerard@saraber.dhs.org Sat Aug 28 13:53:16 1999 Date: Sat Aug 28 13:53:16 1999 From: Gerard Saraber gerard@saraber.dhs.org Subject: tulip 91g success on 2.3.15 Hi, I would like to report success in modifying the tulip.c version 91g to work with linux kernel 2.3.14 and above, I have tested it on my home network by transferring linux-2.3.12.tar.bz2 from one system on my network to my development system which is using the tulip driver. The first time I tried to transfer the kernel it stalled (the tulip dropped off the network) at 7.5Mb transferred (at over 700kbps) I did ifconfig eth0 down and ifconfig eth0 up right after .. telnetted some, sent some email ftpd some more and tried to ftp the linux-2.3.12.tar.bz2 again .. this time success, again the speed is over 700kbps. So it works for me :-) Since the driver is over 100kb (39kb gzipped) I'm not attaching it here, If you want to try it, it can be optained through ftp: ftp://saraber.dhs.org/pub/tulip/ I have the tulip.c, a gzipped version and a patch against the tulip v91g from http://cesdis.gsfc.nasa.gov/linux/drivers/tulip.html up there. I have made it clear in the header of the file and the startup banner that I'm the one who modified the file, so please don't send any nasty bugreports to Donald or the linux-tulip list without verifying that the bug exsists in the original tulip driver as well. I would also like to thank Richard Dynes [rdynes@sun1.varcom.com] and Jonathan A. George [jageorge@att.net] for their help with the tulip driver. ps. if you can't ftp I'd be glad to email the driver to you.. Regards, Gerard Saraber gerard@saraber.dhs.org -------------------------------------------------------------- eth0 Link encap:Ethernet HWaddr 00:A0:CC:21:77:04 inet addr:192.168.13.12 Bcast:192.168.13.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:23995 errors:0 dropped:0 overruns:0 frame:0 TX packets:12631 errors:6 dropped:0 overruns:0 carrier:0 collisions:9266 txqueuelen:100 Interrupt:12 Base address:0xe400 From wheagy@erols.com Sat Aug 28 22:11:26 1999 Date: Sat Aug 28 22:11:26 1999 From: Win Heagy wheagy@erols.com Subject: Linksys Etherfast 10/100 Card problem? Hi, I am new to the list. I recently purchased the Linksys Fast Ethernet starter kit. It came with two PCI 10/100 cards based on the PNIC chips. I am using (as recommended by Linksys) the tulip driver dated tulip.c:v0.91 4/14/99. The other machine currently on the network is a notebook using a Linksys PCMCIA 10/100 card. On the desktop machine (90 mhz Pentium), I compiled the tulip driver into the kernel (2.0.36). The network works well for about 20 or 30 minutes and then starts to slow down until it eventually locks requiring a reboot of the desktop machine. I usually notice this when using the notebook machine and running a telnet session to the desktop and piping a Netscape session back to the notebook display. The X server on the notebook becomes unresponsive. If I exit the X server, I can still use the notebook, but get extremely slow response over the network to the desktop machine. If I reboot the desktop, performance returns to normal for a period of time and then the above starts over again. I tried Linksys tech support and their answer was to ask on this list. Sort of strange tech support. Anyway, if anyone has any suggestions, I would greatly appreciate it. Thanks, Win wheagy@erols.com From jason@topic.com.au Sun Aug 29 19:27:11 1999 Date: Sun Aug 29 19:27:11 1999 From: Jason Thomas jason@topic.com.au Subject: Linksys Etherfast 10/100 Card problem? I think someone else mentioned this on the list only a few days ago. not sure what the outcome was.... check back through the archive Win Heagy [wheagy@erols.com] wrote: > Hi, > > I am new to the list. I recently purchased the Linksys > Fast Ethernet starter kit. It came with two PCI 10/100 > cards based on the PNIC chips. I am using (as recommended by > Linksys) the tulip driver dated tulip.c:v0.91 4/14/99. > The other machine currently on the network is a notebook using > a Linksys PCMCIA 10/100 card. On the desktop machine (90 mhz Pentium), > I compiled the tulip driver into the kernel (2.0.36). The network > works well for about 20 or 30 minutes and then starts to slow down > until it eventually locks requiring a reboot of the desktop machine. > I usually notice this when using the notebook machine and > running a telnet session to the desktop and piping a Netscape > session back to the notebook display. The X server on the notebook > becomes unresponsive. If I exit the X server, I can still > use the notebook, but get extremely slow response over the > network to the desktop machine. If I reboot the desktop, > performance returns to normal for a period of time and then the above > starts over again. > > I tried Linksys tech support and their answer was to ask on this list. > Sort of strange tech support. Anyway, if anyone has any suggestions, > I would greatly appreciate it. > > Thanks, > > Win > > wheagy@erols.com -- Jason Thomas Phone: +61 2 6257 7111 System Administrator - UID 0 Fax: +61 2 6257 7311 tSA Consulting Group Pty. Ltd. Mobile: 0418 29 66 81 1 Hall Street Lyneham ACT 2602 http://www.topic.com.au/ From bernieb@vogon.capescott.net Sun Aug 29 22:04:08 1999 Date: Sun Aug 29 22:04:08 1999 From: Andy Barlak bernieb@vogon.capescott.net Subject: repeated time outs, dec tulip network stops Have solved the hang problem here, it was the result of a default bios setting addressed in the linux-kernel mailing list. Disabling "CPU to PCI write buffer" in my VA-503+ FIC Via motherboard stopped all the ethernetwork hangs I have been experiencing: ftp hangs, netperf hangs, ping -f hangs, and random hangs with light traffic. ------------------------------------------------------------------------------- Andy Barlak Q) When was the last time your computer was backed up? A) My computer is against a wall and cannot be backed up any further From pmonta@halibut.imedia.com Mon Aug 30 05:18:47 1999 Date: Mon Aug 30 05:18:47 1999 From: Peter Monta pmonta@halibut.imedia.com Subject: via-rhine SMP problems There seem to be some SMP-related problems with the via-rhine NIC hardware or network driver; at least, all problems go away when running under a UP kernel with identical configuration. There was some linux-kernel discussion on 11-12 August ("via-rhine nic crazyness"), but no hints there that I could see. I'm using 2.2.13pre1, except that its via-rhine.c has been replaced with v1.03a. All kernels are nonmodular (these are diskless Beowulf nodes); the motherboard is an Abit BP-6 with two Celeron 400s. Running ttcp using the SMP kernel causes a number of "something wicked happened" messages, and using the default ring sizes of TX=8 and RX=16, very shortly no more packets will go in or out of the box. After increasing to TX=16 and RX=128, the network never actually goes down, and indeed a single ttcp works perfectly however long; but with back-to-back ttcp's, there are again the "wicked" messages, with roughly an even mixture of 0009, 000a, and 000b. The driver source says 0008 is TxAbort. (I think the "wicked" printk() is active only when some other bit, like TxDone or RxDone, is set as well.) I don't see what the transmit subsystem could be getting unhappy about---the other end is a 5-port Linksys switch, and everything is correctly at 100baseT full-duplex. Sigh, the VT86C100A data sheet says this TxAbort bit is set when there are excessive collisions; this is absurd, because the driver is setting the chip full-duplex ("eth0: Setting full-duplex based on MII #8 link partner capability of 41e1."). The card is VT3043-based though (D-Link DFE-530TX, chip marked "DL10030"), so who knows what the bit really means. What is the simplest way to isolate the TX and RX processing with some sort of lock? Would making start_tx() and netdev_rx() mutually exclusive be a good idea, so as to approach the UP case? Or should I just dump the cards? Beginning of log messages after faulty run: Aug 30 01:03:39 n00 kernel: eth0: Something Wicked happened! 000a. Aug 30 01:03:39 n00 kernel: eth0: Something Wicked happened! 0009. Aug 30 01:03:39 n00 kernel: eth0: Something Wicked happened! 0009. Aug 30 01:03:39 n00 kernel: eth0: Something Wicked happened! 000b. Aug 30 01:03:39 n00 kernel: eth0: Something Wicked happened! 0009. Aug 30 01:03:40 n00 kernel: eth0: Something Wicked happened! 0009. Aug 30 01:03:40 n00 kernel: eth0: Something Wicked happened! 000a. Aug 30 01:03:40 n00 kernel: eth0: Something Wicked happened! 0809. Aug 30 01:03:40 n00 kernel: eth0: Something Wicked happened! 000a. Aug 30 01:03:40 n00 kernel: eth0: Something Wicked happened! 0009. Aug 30 01:03:40 n00 last message repeated 2 times Aug 30 01:03:41 n00 kernel: eth0: Something Wicked happened! 000b. Aug 30 01:03:41 n00 kernel: eth0: Something Wicked happened! 0009. Aug 30 01:03:41 n00 kernel: eth0: Something Wicked happened! 000a. Aug 30 01:03:41 n00 kernel: eth0: Something Wicked happened! 0009. Aug 30 01:03:42 n00 kernel: eth0: Something Wicked happened! 0009. Aug 30 01:03:42 n00 kernel: eth0: Something Wicked happened! 000b. Aug 30 01:03:43 n00 kernel: eth0: Something Wicked happened! 000a. Aug 30 01:03:43 n00 kernel: eth0: Something Wicked happened! 0009. Aug 30 01:03:43 n00 kernel: eth0: Something Wicked happened! 0809. Aug 30 01:03:43 n00 kernel: eth0: Oversized Ethernet frame spanned multiple buffers, entry 0x176a5 length 0 status 0600! Aug 30 01:03:43 n00 kernel: eth0: Oversized Ethernet frame c7fde250 vs c7fde250. Aug 30 01:03:43 n00 kernel: eth0: Oversized Ethernet frame spanned multiple buffers, entry 0x176a6 length 82 status 528d00! Aug 30 01:03:43 n00 kernel: eth0: Oversized Ethernet frame c7fde260 vs c7fde260. Aug 30 01:03:43 n00 kernel: eth0: Something Wicked happened! 000b. Aug 30 01:03:43 n00 kernel: eth0: Something Wicked happened! 0009. Aug 30 01:03:43 n00 kernel: eth0: Something Wicked happened! 000a. Aug 30 01:03:43 n00 kernel: eth0: Something Wicked happened! 080b. Cheers, Peter Monta pmonta@imedia.com Imedia Corp. From pmonta@halibut.imedia.com Tue Aug 31 06:26:54 1999 Date: Tue Aug 31 06:26:54 1999 From: Peter Monta pmonta@halibut.imedia.com Subject: update, via-rhine SMP Running with the "noapic" kernel option causes everything to work well with via-rhine under SMP (thanks to Pierre Brua for the hint). So it must be an interrupt racing with the other CPU that's confusing the hardware. Cheers, Peter Monta pmonta@imedia.com Imedia Corp. From esmith@psych.purdue.edu Tue Aug 31 10:50:39 1999 Date: Tue Aug 31 10:50:39 1999 From: Eliot R. Smith esmith@psych.purdue.edu Subject: tulip v0.91g versus built-in 21143 on Compaq Presario 5600i I have a Compaq Presario 5600i-350, bought in January 99. This uses a DEC 21143 chip for a built-in 10baseT networking port. However, the tulip driver does not seem to find the right transceiver and the interface will never become active. This is under basically a Debian 2.1 installation but with kernel upgraded to 2.2.10. (Of course, the same hardware works fine under win98, grumble, grumble.) Here's the detail provided by the tulip driver when it's loaded (dmesg output) DMESG output from insmod tulip Linux version 2.2.10 (root@esmith2) (gcc version 2.7.2.3) #2 Mon Jul 5 17:54:29 EST 1999 ... tulip.c:v0.91g 7/16/99 becker@cesdis.gsfc.nasa.gov eth0: Digital DS21143 Tulip rev 65 at 0x1000, 00:08:C7:13:DB:D5, IRQ 11. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media AUI (#2) described by a 21142 Serial PHY (2) block. eth0: Index #1 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. eth0: Index #2 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. eth0: Index #3 - Media MII (#11) described by a 21142 MII PHY (3) block. eth0: ***WARNING***: No MII transceiver found! tulip.c:v0.91g 7/16/99 becker@cesdis.gsfc.nasa.gov eth0: Digital DS21143 Tulip rev 65 at 0x1000, 00:08:C7:13:DB:D5, IRQ 11. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media AUI (#2) described by a 21142 Serial PHY (2) block. eth0: Index #1 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. eth0: Index #2 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. eth0: Index #3 - Media MII (#11) described by a 21142 MII PHY (3) block. eth0: ***WARNING***: No MII transceiver found! eth0: Using user-specified media 10baseT(forced). [the second time I added an "options" string to the insmod] Here are the outputs from the tulip diag program with various flags. I would be more than happy to run diag with different flags, etc. to gather more info if that is necessary. Thanks -- Eliot Smith diag -a output tulip-diag.c:v1.12 7/31/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0x1000. Digital DS21143 Tulip chip registers at 0x1000: f8208400 ffffffff ffffffff 00008054 000080d4 f0200500 b2420200 f3fe0065 e0000000 ffffcbf8 ffffffff 00000000 000000c6 ffff0000 fff8ffff 8ff50000 Port selection is 10mpbs-serial, full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Waiting for Tx to finish'. The transmit threshold is 72. The NWay status register is 000000c6. Ethernet MAC Station Address 00:08:C7:13:DB:D5. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 30, default media type 0800 (Autosense). 4 transceiver description blocks: Serial transceiver for AUI (media type 18). Serial transceiver for 10baseT (media type 0). Serial transceiver for 10baseT-Full Duplex (media type 4). MII interface PHY 0 (media type 11). 21143 MII initialization sequence is 2 words: 0803 0003. 21143 MII reset sequence is 0 words:. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. No MII interrupt. 21140 Non-MII transceiver for media 0 (10baseT). CSR12 control port setting 00, command 00 00. Media detection by looking for a 1 on bit 0 of the CSR12 control port. 21140 Non-MII transceiver for media 0 (10baseT). CSR12 control port setting 00, command 00 00. Media detection by looking for a 1 on bit 0 of the CSR12 control port. 21140 Non-MII transceiver for media 0 (10baseT). CSR12 control port setting 00, command 00 00. Media detection by looking for a 1 on bit 0 of the CSR12 control port. No MII transceivers found! Internal autonegotiation state is 'Autonegotiation disabled'. diag -m output tulip-diag.c:v1.12 7/31/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0x1000. Port selection is 10mpbs-serial, full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Waiting for Tx to finish'. The transmit threshold is 72. The NWay status register is 000000c6. Ethernet MAC Station Address 00:08:C7:13:DB:D5. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 30, default media type 0800 (Autosense). 4 transceiver description blocks: Serial transceiver for AUI (media type 18). Serial transceiver for 10baseT (media type 0). Serial transceiver for 10baseT-Full Duplex (media type 4). MII interface PHY 0 (media type 11). 21143 MII initialization sequence is 2 words: 0803 0003. 21143 MII reset sequence is 0 words:. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. No MII interrupt. 21140 Non-MII transceiver for media 0 (10baseT). CSR12 control port setting 00, command 00 00. Media detection by looking for a 1 on bit 0 of the CSR12 control port. 21140 Non-MII transceiver for media 0 (10baseT). CSR12 control port setting 00, command 00 00. Media detection by looking for a 1 on bit 0 of the CSR12 control port. 21140 Non-MII transceiver for media 0 (10baseT). CSR12 control port setting 00, command 00 00. Media detection by looking for a 1 on bit 0 of the CSR12 control port. No MII transceivers found! Internal autonegotiation state is 'Autonegotiation disabled'. diag -e output tulip-diag.c:v1.12 7/31/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0x1000. Port selection is 10mpbs-serial, full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Waiting for Tx to finish'. The transmit threshold is 72. The NWay status register is 000000c6. EEPROM size is 6. Ethernet MAC Station Address 00:08:C7:13:DB:D5. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 30, default media type 0800 (Autosense). 4 transceiver description blocks: Media AUI, block type 2, length 6. Serial transceiver for AUI (media type 18). GP pin direction 080f GP pin data 0001. Media 10baseT, block type 2, length 6. Serial transceiver for 10baseT (media type 0). GP pin direction 08af GP pin data 0001. Media 10baseT-Full Duplex, block type 2, length 6. Serial transceiver for 10baseT-Full Duplex (media type 4). GP pin direction 08af GP pin data 0001. Media MII, block type 3, length 17. MII interface PHY 0 (media type 11). 21143 MII initialization sequence is 2 words: 0803 0003. 21143 MII reset sequence is 0 words:. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. No MII interrupt. 21140 Non-MII transceiver for media 0 (10baseT). CSR12 control port setting 00, command 00 00. Media detection by looking for a 1 on bit 0 of the CSR12 control port. 21140 Non-MII transceiver for media 0 (10baseT). CSR12 control port setting 00, command 00 00. Media detection by looking for a 1 on bit 0 of the CSR12 control port. 21140 Non-MII transceiver for media 0 (10baseT). CSR12 control port setting 00, command 00 00. Media detection by looking for a 1 on bit 0 of the CSR12 control port. No MII transceivers found! Internal autonegotiation state is 'Autonegotiation disabled'.