From jburke@asitatech.ie Wed Sep 1 13:20:31 1999 Date: Wed Sep 1 13:20:31 1999 From: Jarlath Burke jburke@asitatech.ie Subject: de4x5 driver source code Hi all, Can anyone tell me where I can get the latest source code for the de4x5 DECchip driver? Thanks in advance, Jarlath. Jarlath Burke Asita Technologies Intl. Ltd. Unit 2, Ballybrit Business Park Galway. Ireland. Ph: +353 91 758353 Email: jburke@asitatech.ie Web: http://www.asitatech.com From bryan@terran.org Wed Sep 1 15:34:05 1999 Date: Wed Sep 1 15:34:05 1999 From: B. James Phillippe bryan@terran.org Subject: Full vs. 1/2 duplex oddity Greetings, We have a lab environment at work where we are doing IP forwarding performance testing with several versions of the 0.91 tulip driver (under 2.0.3x). We have noticed that when the media type autonegotiates to 100BaseTX-FD, the performance is worse than with 1/2 duplex, by as much as 30Mbit/sec. There are very few errors or collisions on FD, and performance there is about 12Mb/sec, so I do not believe the problem is caused by a duplex mismatch. Both the tulip-diag and the ethernet switch report FD and the ethernet driver emits no errors. The switches we've tried are Compaq SW3322 and SW3323 with latest firmware. Again, there are no apparent errors being reported, performance is just lower. The clients are 533Mhz 21164's at 1/2 duplex. The only FD connection is between our system and the switch. For now we have simply masked out 100BaseTX-FD capability from the NWay advertisement to guarantee 100Mbit FD is not negotiation. This improves performance. Anyone know what might cause this phenomenon? -bp -- # bryan at terran dot org # http://www.terran.org/~bryan From jason@topic.com.au Wed Sep 1 18:32:46 1999 Date: Wed Sep 1 18:32:46 1999 From: Jason Thomas jason@topic.com.au Subject: de4x5 driver source code All I can find, email this person.. /usr/src/linux/CREDITS N: David Davies E: davies@wanton.lkg.dec.com D: Network driver author - depca, ewrk3 and de4x5 D: Wrote shared interrupt support S: Digital Equipment Corporation S: 550 King Street S: Littleton, Massachusetts 01460 S: USA Jarlath Burke [jburke@asitatech.ie] wrote: > Hi all, > Can anyone tell me where I can get the latest source code for the de4x5 > DECchip driver? > Thanks in advance, > Jarlath. > > > Jarlath Burke > Asita Technologies Intl. Ltd. > Unit 2, Ballybrit Business Park > Galway. > Ireland. > Ph: +353 91 758353 > Email: jburke@asitatech.ie > Web: http://www.asitatech.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 murray@pa.dec.com Wed Sep 1 20:48:23 1999 Date: Wed Sep 1 20:48:23 1999 From: Hal Murray murray@pa.dec.com Subject: de4x5 driver source code > All I can find, email this person.. > N: David Davies > E: davies@wanton.lkg.dec.com That part of Digital was sold to Cabletron ages ago. My copy of the source file says: The author may be reached at davies@maniac.ultranet.com. I have no idea if that will work. From tridzungn@yahoo.com Wed Sep 1 22:06:44 1999 Date: Wed Sep 1 22:06:44 1999 From: Tri-Dzung Nguyen tridzungn@yahoo.com Subject: Driver for LNE100TX Hi, I have a Linksys Etherfast LNE100TX PCI card with LC82C115 chipset. The Tulip drivers came with Linksys disks and Redhat 6.0 and downloaded versions from NASA, all don't work. I kept having error message on "Unknown Tulip-style chip ...". Does anyone have a solution to this problem? The 0.9g version has this chipset for the CARDBUS not PCI. Thanks __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com From jason@topic.com.au Wed Sep 1 22:56:45 1999 Date: Wed Sep 1 22:56:45 1999 From: Jason Thomas jason@topic.com.au Subject: de4x5 driver source code i just grabed it from 2.2.12 Hal Murray [murray@pa.dec.com] wrote: > > > All I can find, email this person.. > > > N: David Davies > > E: davies@wanton.lkg.dec.com > > That part of Digital was sold to Cabletron ages ago. > > My copy of the source file says: > > The author may be reached at davies@maniac.ultranet.com. > > I have no idea if that will work. -- 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 rajiv@alum.mit.edu Wed Sep 1 23:46:28 1999 Date: Wed Sep 1 23:46:28 1999 From: Rajiv Aaron Manglani rajiv@alum.mit.edu Subject: mac driver for tulip cards? Is anyone out there working a mac driver for tulip-based cards such as the netgear fa310tx? -- Rajiv A. Manglani Macintosh PCI Page From trangxn@netzero.net Thu Sep 2 13:56:27 1999 Date: Thu Sep 2 13:56:27 1999 From: Denise Nguyen trangxn@netzero.net Subject: Tulip Driver for LNE100TX This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BEF4C5.CEB29FA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have a Linksys Etherfast LNE100TX PCI card with LC82C115 chipset. The = Tulip drivers came with Linksys disks and Redhat 6.0 and downloaded versions = from NASA, all don't work. I kept having error message on "Unknown = Tulip-style chip ...". Does anyone have a solution to this problem? The 0.9g version has this chipset for the CARDBUS not PCI. Thanks ------=_NextPart_000_0005_01BEF4C5.CEB29FA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have a Linksys Etherfast LNE100TX PCI = card with=20 LC82C115 chipset.  The Tulip
drivers came with Linksys disks and = Redhat=20 6.0 and downloaded versions from
NASA, all don't work.  I kept = having=20 error message on "Unknown Tulip-style
chip ...".  Does anyone = have a=20 solution to this problem?

The 0.9g version has this chipset for = the=20 CARDBUS not PCI.
 
Thanks

------=_NextPart_000_0005_01BEF4C5.CEB29FA0-- ________________________________________________________ NetZero - We believe in a FREE Internet. Shouldn't you? Get your FREE Internet Access and Email at http://www.netzero.net/download/index.html From zhang@iris1.chem.ohiou.edu Thu Sep 2 16:46:47 1999 Date: Thu Sep 2 16:46:47 1999 From: Lin Zhang zhang@iris1.chem.ohiou.edu Subject: Bug: tulip v0.91 problem on Compaq Presario 5600i I have a Compaq Presario 5600i, bought recently. It uses a DEC 21143 chip for a 10baseT port. However, the tulip driver does not work at all. Here is part of the dmesg output tulip.c:v0.91g 7/16/99 becker@cesdis.gsfc.nasa.gov eth0: Digital DS21143 Tulip rev 65 at 0x2000, 00:08:C7:13:CF:9B, 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: Tx hung, 24 vs. 9. eth0: 21140 transmit timed out, status f0260000, SIA 000000c6 ffff0000 fff8ffff 8ff50000, resetting... eth0: transmit timed out, switching to AUI media. eth0: Tx hung, 24 vs. 9. eth0: 21140 transmit timed out, status f0260000, SIA 000000c6 ffff0000 fff8ffff 8ff50000, resetting... eth0: transmit timed out, switching to MII media. Here is the tulip-diag output: Script started on Thu Sep 2 16:12:03 1999 [root@hp1 modules]# ./tulip-diag tulip-diag.c:v1.10 4/12/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0x2000. 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 'Waiting for Tx to finish'. The transmit threshold is 128. Use '-a' to show device registers, '-e' to show EEPROM contents, or '-m' to show MII management registers. [root@hp1 modules]# [root@hp1 modules]# ./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 0x2000. A potential Tulip chip has been found, but it appears to be active. Either shutdown the network, or use the '-f' flag. [root@hp1 modules]# [root@hp1 modules]# [root@hp1 modules]# ./tulip-diag -a m tulip-diag.c:v1.10 4/12/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0x2000. 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 'Waiting for Tx to finish'. The transmit threshold is 128. No MII transceivers found! Internal autonegotiation state is 'Autonegotiation disabled'. [root@hp1 modules]# [root@hp1 modules]# [root@hp1 modules]# ./tulip-diag -m 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 0x2000. 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 'Waiting for Tx to finish'. The transmit threshold is 128. Ethernet MAC Station Address 00:08:C7:13:CF:9B. 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 with 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 with 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 with 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! [root@hp1 modules]# ./tulip-diag -ema               exit exit Script done on Thu Sep 2 16:13:11 1999 From shrike@il.fontys.nl Thu Sep 2 18:01:20 1999 Date: Thu Sep 2 18:01:20 1999 From: M.Brands shrike@il.fontys.nl Subject: tulip v0.91g versus built-in 21143 on Compaq Presario 5600i On Tue, Aug 31, 1999 at 09:50:35AM -0500, Eliot R. Smith allegedly wrote: > 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 Strange, only 10baseT? > 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! This seems correct if your NIC is supposed to only be capable of 10baseT. A MII or PHY tranceiver is only used for 100 mbit connectionsi, as far as I know. Too bad I can't help you any further. I haven't seem this problem myself. Maybe somebody else has an idea? Mathijs From root@jeff.home.net Thu Sep 2 20:39:59 1999 Date: Thu Sep 2 20:39:59 1999 From: root root@jeff.home.net Subject: Olicom RapidFire 2327 NIC w/ DEC 21143 I'm running RH 6 on a Pentium 3, any I'm trying to get a Olicom RapidFire 2327 NIC to work RedHat auto-detects this card and loads the tulip driver without any problems, and the device if ifconfig'd and turns into eth0. That is as far as you get, after that no traffic will go through the card, and it constantly sends out some kind of signal because my hub activity light goes on and stays blinking pretty consistently (due to this card), and when you try to unload the driver (rmmod) it says device busy. The card has a single twisted-pair port. Any insights into how to resolve this problem would be greatly appreciated. In the mean time I'll try to add a card descriptor entry for the card. Thank's for your help! Patrick Marks mmarks@interlog.com From jason@topic.com.au Thu Sep 2 23:06:54 1999 Date: Thu Sep 2 23:06:54 1999 From: Jason Thomas jason@topic.com.au Subject: Olicom RapidFire 2327 NIC w/ DEC 21143 Unless someone else on the list knows about a specific problem with this card, you need to give abit more info. like, output from 'ifconfig' and 'route'. you can't rmmod the device while the interface is up. do 'ifconfig eth0 down' then you should be able to remove the device. or on redhat 'ifdown eth0' either will work. also have a look at the options you can pass to the module.. http://cesdis.gsfc.nasa.gov/linux/drivers/tulip.html also grab the diagnostics prog from: http://cesdis.gsfc.nasa.gov/linux/diag/tulip-diag.c compile that, the instructions are in the last few lines of the code.. then run it and send the info back with the other stuff... root [root@jeff.home.net] wrote: > I'm running RH 6 on a Pentium 3, any I'm trying to get a Olicom RapidFire > 2327 NIC to work RedHat auto-detects this card and loads the tulip driver > without any problems, and the device if ifconfig'd and turns into eth0. > > That is as far as you get, after that no traffic will go through the card, > and it constantly sends out some kind of signal because my hub activity light > goes on and stays blinking pretty consistently (due to this card), and when you try > to unload the driver (rmmod) it says device busy. > > The card has a single twisted-pair port. > > Any insights into how to resolve this problem would be greatly appreciated. > In the mean time I'll try to add a card descriptor entry for the > card. Thank's for your help! > > Patrick Marks > mmarks@interlog.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 jason@topic.com.au Thu Sep 2 23:08:58 1999 Date: Thu Sep 2 23:08:58 1999 From: Jason Thomas jason@topic.com.au Subject: Fwd: Returned mail: Host unknown (Name server: jeff.home.net: host not found) how am i supposed to reply to someone how doesn't even have a vaild email address..... ----- Forwarded message from Mail Delivery Subsystem ----- > Date: Fri, 3 Sep 1999 13:06:56 +1000 > From: Mail Delivery Subsystem > To: > Subject: Returned mail: Host unknown (Name server: jeff.home.net: host not found) > Auto-Submitted: auto-generated (failure) > > The original message was received at Fri, 3 Sep 1999 13:05:58 +1000 > from charon.ext.tsa [192.168.11.10] > > ----- The following addresses had permanent fatal errors ----- > > > ----- Transcript of session follows ----- > 550 ... Host unknown (Name server: jeff.home.net: host not found) > Reporting-MTA: dns; set.topic.com.au > Received-From-MTA: X-Unix; charon.ext.tsa > Arrival-Date: Fri, 3 Sep 1999 13:05:58 +1000 > > Final-Recipient: rfc822; root@jeff.home.net > Action: failed > Status: 5.1.2 > Remote-MTA: DNS; jeff.home.net > Last-Attempt-Date: Fri, 3 Sep 1999 13:06:06 +1000 > Date: Fri, 3 Sep 1999 13:08:03 +1000 > From: Jason Thomas > Reply-To: jason@topic.com.au > To: root > Cc: linux-tulip@cesdis1.gsfc.nasa.gov > Subject: Re: Olicom RapidFire 2327 NIC w/ DEC 21143 > In-Reply-To: <199909030034.UAA01830@jeff.home.net> > User-Agent: Mutt/1.0pre1i > > Unless someone else on the list knows about a specific problem with this card, you need to give abit more info. like, output from 'ifconfig' and 'route'. > > you can't rmmod the device while the interface is up. do 'ifconfig eth0 down' > then you should be able to remove the device. or on redhat 'ifdown eth0' either will work. > > also have a look at the options you can pass to the module.. > http://cesdis.gsfc.nasa.gov/linux/drivers/tulip.html > > also grab the diagnostics prog from: http://cesdis.gsfc.nasa.gov/linux/diag/tulip-diag.c > > compile that, the instructions are in the last few lines of the code.. then run it and send the info back with the other stuff... > > > root [root@jeff.home.net] wrote: > > I'm running RH 6 on a Pentium 3, any I'm trying to get a Olicom RapidFire > > 2327 NIC to work RedHat auto-detects this card and loads the tulip driver > > without any problems, and the device if ifconfig'd and turns into eth0. > > > > That is as far as you get, after that no traffic will go through the card, > > and it constantly sends out some kind of signal because my hub activity light > > goes on and stays blinking pretty consistently (due to this card), and when you try > > to unload the driver (rmmod) it says device busy. > > > > The card has a single twisted-pair port. > > > > Any insights into how to resolve this problem would be greatly appreciated. > > In the mean time I'll try to add a card descriptor entry for the > > card. Thank's for your help! > > > > Patrick Marks > > mmarks@interlog.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/ ----- End forwarded message ----- -- 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 mb@sime.com Fri Sep 3 04:08:40 1999 Date: Fri Sep 3 04:08:40 1999 From: Martin Bene mb@sime.com Subject: tulip v0.91g versus built-in 21143 on Compaq Presario 5600i At 00:01 03.09.99 +0200, M.Brands wrote: >> This uses a DEC 21143 chip for a built-in >> 10baseT networking port. However, the tulip driver does not > >Strange, only 10baseT? > >This seems correct if your NIC is supposed to only be capable of 10baseT. >A MII or PHY tranceiver is only used for 100 mbit connectionsi, as far as >I know. > No solution unfortunately, but same problem: 10Mbit Network interface in Sony Vaio Docking station is based on the same chipset and produces the same error messages. I've tried anything I could think of, and have given up now. I'm using a PCMCIA card now.. Bye, Martin "you have moved your mouse, please reboot to make this change take effect" -------------------------------------------------- Martin Bene vox: +43-664-3251047 simon media fax: +43-316-813824-6 Andreas-Hofer-Platz 9 e-mail: mb@sime.com 8010 Graz, Austria -------------------------------------------------- finger mb@mail.sime.com for PGP public key From mharnois@willinet.net Fri Sep 3 13:27:35 1999 Date: Fri Sep 3 13:27:35 1999 From: Michael Harnois mharnois@willinet.net Subject: tulip v0.91g versus built-in 21143 on Compaq Presario 5600i On Fri, 3 Sep 1999 00:01:17 +0200, "M.Brands" said: > Strange, only 10baseT? Yeah. Isn't that a bitch? -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois@willinet.net aa0bt@aa0bt.ampr.org There can be no transforming of darkness into light and of apathy into movement without emotion. - Carl Jung From ericfurn@erols.com Sun Sep 5 22:51:28 1999 Date: Sun Sep 5 22:51:28 1999 From: Eric Furness ericfurn@erols.com Subject: Compaq 5686 The Compaq 5686 has a partial implementation of the 21143 chip on the system board. Apparently there is no MII tranciever and is capable of 10baseT only. I cannot get the tulip driver in any of it's versions to work. I tried different options when loading the module, but the only one to get the active led to light is autosense. Ifconfig shows a valid NIC address, IRQ, and IO address. No link led with a known good net connection. Am I doomed with this chip? Eric Furness ericfurn@erols.com From Scubadoo@WriteMe.com Wed Sep 8 00:08:10 1999 Date: Wed Sep 8 00:08:10 1999 From: Y. T. Chow Scubadoo@WriteMe.com Subject: Tulip Driver Info This is a multi-part message in MIME format. ------=_NextPart_000_0011_01BEF97D.78F36D80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0012_01BEF97D.78F36D80" ------=_NextPart_001_0012_01BEF97D.78F36D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit echo subscribe | /bin/mail linux-tulip-request@cesdis.gsfc.nasa.gov ======================================== Y. T. Chow 404 Edgebank Place NW Calgary AB T3A 4S3 Canada Phone: (403) 239-2361 E-mail: Scubadoo@WriteMe.com Web Site: http://members.home.com/2826651556/ ------=_NextPart_001_0012_01BEF97D.78F36D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
echo subscribe | /bin/mail  =
linux-tulip-request@cesdis.gsfc.nasa.gov

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Y. T. Chow

404 Edgebank Place = NW

Calgary AB  T3A 4S3

Canada

Phone:  (403) 239-2361

E-mail:  Scubadoo@WriteMe.com

Web Site:  http://members.home.com/2826651556/

 

------=_NextPart_001_0012_01BEF97D.78F36D80-- ------=_NextPart_000_0011_01BEF97D.78F36D80 Content-Type: application/octet-stream; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhQAZcAfUAAP////7//vz//Pv/+/r/+vn/+fj/+Pb/9vX/9fT/9PP/8/L/8vD/8O//7+7/ 7uz/7Ov/6+r/6un/6ej/6Of/5+T/5OP/4+L/4uH/4eD/4N//393/3dz/3Nv/29n/2dj/2Nf/19b/ 1tL/0s//z83/zcz/zAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C01TT0ZGSUNFOS4wDQAAAAFzUkdC AK7OHOkAIf8LTVNPRkZJQ0U5LjAYAAAADG1zT1BNU09GRklDRTkuMEBpS5QqACH/C01TT0ZGSUNF OS4wGAAAAAxjbVBQSkNtcDA3MTICAAAJAtxSKQAsAAAAAEAGXAEABv9AgHBILBqPyKRyyWw6n9Co dEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4CBgoOEhYaHiImKi4yNjo+Q kZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJ ysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAMK HBiwBMGDCBMqXMiw4RCDDiNKnEixosVqEC9q3Mixo8ePozKCHEmypMmTKOOITMmypcuXMGGujEmz ps2bOAvm3Mmzp8//n+JmAh1KtKjRo7iEIl3KtKnTp5OUQp1KtarVq26kYt3KtavXr0m0gh1LtqzZ oWLPql3Lti3ItG7jyp1LFyDcunjz6t1r7i7fv4ADC2bmd7Dhw4gTyyqsuLHjx5AxMY5MubLly34m Y97MubNnMpo/ix5NurSS0KZTq15tGTXr17Bj/4UbAMGDChtAiBhBgsQIESA2VHiAIIDs48iTb9U6 wMGFECE0UHCQoICAAAEEFEjggIIG6BccDFBOvrx5oEoVVAixQQICKAgkbAhRQcH5+/jzp5y5AMMH Cu9VgQAFH2CwgH4IJqjgRCIdYIEHEYyXxQAReGDBAQtmqOGG/UAE/wEEIExAgBcETAACBBymqOKK 7JRgwAUZZJCAGAlkcIEBLOao447alNCBBGdI0MGBPBZp5JHHNFACA2kw4EEDSEYp5ZS2OMCBa1Uk wIEDDlDp5ZdgjtIABwdgWcUBHHAAZZhstukmJAt4MKOZWSbgAZFv5qnnnn0Y0AGTANBpBQMd4Mjn oYgm2sYFQAohqBUSXKDopJRW2gUEGRDxqBUZoGjpp6CGqsQBIMz4UBwJgIChqKy2aqkFExSxqRUT WODqrbjuGeeImspBwJ25BissWCUUa+yxyCar7LLMNuvss9BGK+201FY767DYZruZAh9I2KscA3xg n7bklrtgBRQccf+tFRRUYO678Jo3QAgBykoHAiF4G+++/KrmwAZIrGvFBl32a/DBnzEacB2RIuzw w5QFQO/C94ZgHMQYZzwYvmHZMbHGIIeM1wMadFyHBg+IrPLKbKFrMh3tsizzzF8R/PIc/9Ks885U lXqzHKnyLPTQR4lQwM9xFCAC0Uw3zZPRSMOhtNNUVw3TCAJE/YYAI1jt9dclkXCxunYEQALYaKet kdhau2G22nDH3RDWbbfBtdx45y0Q1BTTMbXegAeOj899zxG04Ign/o7NhcuRs+KQR26Oy43HEbPk mGfeDcl1s4Gy5qCHXg3HlcPxseiop66MxPXaW/HYqscuezAKk03/R8Oz5677Lo8bIXAVjO8u/PCx zNs6HvjqS/zyzJ9CuR6XNy/99KFwq3wd4Y5L/fbcZ4JBBHpEgEH35Jc/ya54/Iqn+ey3jwiseNTq /vz0D0KqqXSkumr9/PefB6Z26JT/BkhAOtRODrgroAIXqAY/AQoOhDIUAydIQTHECX9sSICd1lfB DnowC2PanxrQpKYPmvCEVrASBs+gJS6h8IUwfEIDPPBAMzhpTTHMoQ6PsIAfBWlIOwyiEIXwohit sAs1utEQlxjED4WIV1wo0YmYSMUgOghC16MChSwkwip6EYb9+c/xojCgAnHwi2h8oXrY4x74yIc+ 2kujHGPYnOdE/2c61blOdrbTne+EIDxZnKMgUVib2+RmN735TXCGU5xBOtJc1oqkJCdJyUpa8pKY tNYjN8nJTnryk6AMpShHScpSmvKUqEylKlfJyla68pWwjKUsZ0nLWtrylrjMpS53ycte+vKXwAym MIdJzGIa85jITKYyl8nMZjrzmdCMpjSnSc1qWvOa2MymNrfJzW5685vgDKc4x0nOcprznOhMpzrX yc52upOAv3unPJETz3na8zX1vKc+TZPPffrzM/38p0AxE9CBGjQyBT2oQhWT0IU6dDANfahEsVJI 3OhmN5nMqEY3ytFITvSjz6gjdKRDnQJYJwoRBalKjbLG9oxxCv8pXalMexJGAHEhpjPNaU2uGCEv 4FSnQG0JiEQEhp8G9agkKeIRb4rUpmKlh40Sg1GdStWKzLCGYZhqVbfaEBWaQatcDetBQngGsIr1 rAAh61fRytacXBANZm2rXOvhwDTEda54hccBy5rXvp4EgGq4q18HW477rUGwhE0sOOB3WMU6tiLo a+xjJ+uQ77UBsZTNbDSsd1nNepYgz5PsZ0fbD+NlhbSo3Ufv2IDZ1Lr2F3sV7Wtn+w7WvaG1tM1t LUh3Wt36Nh2cu+1vhzu5dAmXuMgNR/A6m9zmdoNwvXWudLHBt+hO97rToNtxsctdaLBtu90N7zK+ a13xmtcY2i3/73nXG4zqMpe98AUGdN8b3/ruYrmsta9+dRHa/O73v7UIrnoBTGBW8Ja+jsBtgXVr 2wEvQsELzm1sAysJCEd4tquVbYIvzGErmBbBjbBwh1PbX7tWeMQojgJn/QsJEad4tJZl8SNc/GLP RpbCkaBxjTXLWBy3eMdAToJhfTzjIAMYNYA1cY6N/F/XTBg0J2ayfp0cVb4uWcr2dU1d4RplLMcX S2+18o+9/GUsqLUMOkYpmcuMBa+iuctrPq+grvrmK8dZzluAKpTtfGfxbkqpUoVzn7t7raFCsQtp hkKiBw3SdfE0kFZYtBMkzWiJ/q6mL60CpZmw6UovtJ4tbSMW/zp9Gk8TugwivWNJT6poQZt6tB2N taxnTetJvtqxaSZ1526t21y7mtfE9TWfgY1cYY+Z2Mk1dpGRnWxB6Lp0zM6tsjcc7WA7+9fVnu20 s81tTl+72+D2diCeHe7mbrvc6A7Ut9PNbnWPu93tPje8uS3veVe73vZmNr7zTex985vX/v73qwMu cE8TvOCMPjjC+6zwhce54Q4nM8QjjuWJU5zJFr94kDOu8R1zvOMv/jjIUSzykXe45Ca/MMpTvuCV s5zALn95k9ct84fTvOYSvznOK67znWO85z7fONCD7vGhEz3kRj86yZOu9JMzvekqfzrUWy71qcO8 6laf+buzXv/jmHP9ul7/unTDLnZzY73s8CU72q2N6Fq7/e3WUqRwiIOdta9T7YPQDne8A50/isfu 58R7IhAQn/nUB/DkFDwjymggxIdT8Y3Y4oUc703IO0KKnqK8Ni3/iCRKUPPW5DwkhHRG0EdT9JC4 oemriXpItHD102w9JNCEQ9g7U/auB5btb3/2VURw983EfSQSCPxkCj8SAiy+8XvPCv0pH5nHj4T8 nm/M6ENCfdQvpvUfgf3sD3P7jxCf97/P/FZkb/zBBP8joof+XqrfEclrvy/f7wj8yh+X9G8E8e+P //K7Al+ww3+2lH+NcDoCOID+5wqfc4C3RICMwH4MOEsOuAj/GRaBsTSBinA4FiiBCdgKf7OBsoSB iXA3IBiCHcgKb1OCF3iCq5CCKvhKIogIJPiCrhSDh/CBNMhKNmgIGpiDq7SDhVCBPnhKQEgIEDiE RMiCqrCASJhKRTgIBtiEpvSEgQCAUuiESogK+3eFpESFgGB/XChK6dUHM+gL8ReGpuRefICDvXCE aBhK88UHPcgL5/eGpQSGeSCEuSB+dlhKJQY97uIL3deHoyRgfcCEvDB9hDhKB8YHUZgLzreIo9Rg fGCFvZB8kjhKT3YHW4gLnZiJnqSHdoCHtfB7oDhKH6YHZ6gLG3SKfmhcgMgLtOeKpWQ9kAYHdQiJ W0KLpvQ98uCDB3yYC6rHi6UUJx5waHMwiLdAesR4ShbQY3SgiLbgec14SgcwZIajKreAedWIStcY h3AQibXAjd2ISkkmB5g4C5LXReVYSpu4Bp/YCoxXeu1ISlv2Bqb4CoT3RodXj6wUZm3Qiqqgd33U d4Dkj690ZiNUQmMAdxsld4xUdwgZS26WBq83kZRFZ2gwjBhJWXpmBszYkZoFaDRiI58nkpllaF9A jig5Wo+mBQOwji3pWphmBWVkRjNJW6GWaUhQeHAURzk5W6lGUnmEHQTJd353i0H5WhV1SLzhG8Ax d420lFRZlVZ5lViZlVq5lVyZU0EAADs= ------=_NextPart_000_0011_01BEF97D.78F36D80-- From becker@cesdis1.gsfc.nasa.gov Thu Sep 9 02:21:16 1999 Date: Thu Sep 9 02:21:16 1999 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: New test version of tulip.c, PNIC-2, 21041 and ASIX updates. If you have a PNIC-II (82c115), ASIX 88140 or 21041 board, please try the updated tulip driver. http://cesdis.gsfc.nasa.gov/linux/drivers/kern-2.3/index.html ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3/tulip.c Note that you'll now need a few additional support files. 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 redin@cendio.se Thu Sep 9 08:35:33 1999 Date: Thu Sep 9 08:35:33 1999 From: Magnus Redin redin@cendio.se Subject: Tulip cards in production? Hi! We are using a lot of Dlink DFE-570 4 port cards and Kingston KNE-100TX cards at our company. It would be good for us to have alternatives since cards sooner or later goes out of production. Unfortunately its a maze to find the good current in production Tulip cards. Do anyone here buy fair sized lots of new cards that are in production right now? It might be intresting with a clone manufacturer since that makes the card independant from Intel and their whims. But I have no idea about how good the clone cards are and I have not found any to test easily in Sweden. (If you have cubic meter of Dlink DFE-500 Rev C6 send an even quicker email. I wonder if I ever will find the same price/performance. ;-) ) Regards, --- Free software - Ibland får man mer än vad man betalar för. Magnus Redin redin@cendio.se http://www.cendio.se/ From brian@chpc.utah.edu Fri Sep 10 15:44:29 1999 Date: Fri Sep 10 15:44:29 1999 From: Brian Haymore brian@chpc.utah.edu Subject: bug in tulip ver .91g and kernel version 2.2.11 - 2.2.12 This I'm sure will not be a popular report as I don't really have enough detail to help solve the problem. So I'm just making the problem I've had known. We have a dual Intel Pentium II 450 with an ASUS P2B-D motherboard with 512MB RAM and IDE Hard Drive and 2 Kingston KNE100TX (DEC 21140-AF) NICS. I had linux-2.2.12 (vanilla) installed and then patched in tulip version .91g to use. This worked fine until I installed PBS to manage the cluster that sits behind this interactive node. When I started the PBS Server and asked the server to check the status of the nodes the machine died. Now to clarify this a bit, it didn't die in the sence of a kernel panic or a total crash. It did however kill all network connectivity and also seemed to hang up the kernel or catch it in some loop so that very little happened. I've now moved back to ver .91 of the tulip driver and life seems better. -- Brian D. Haymore, Systems Administrator Center for High Performance Computing University of Utah Email: brian@chpc.utah.edu Phone: (801) 585-1755 From jon@seainc.com Fri Sep 10 19:08:19 1999 Date: Fri Sep 10 19:08:19 1999 From: Jonathan French jon@seainc.com Subject: Bizarre tulip behavior I have a HP Pavilion 4550z - Celeron type machine, and a Linksys 10/100 LAN card which works under windows but not RH6.0 or a little Linux distro called LRP (Linux Router Project). I freed up all of my IRQs from my serial & parallel ports in BIOS, to be certain that there are several free. I even pulled the silly Winmodem/soundcard. Under RH, I ran tulip-diag, which reported thay my NIC can't get a valid IRQ (although it does get the right memory location). I ran the version of tulip.o that came with RH, as well as the latest 0.91g, with no success. LRP, which uses a 1998 version of tulip, reports that it is trying to use IRQ 255, and fails. Under RH, ifconfig -a does report the eth0, and I can ping the local address, but when a route is requested, it fails with an "Network Unavailable" or something like that. I can only figure that the computer has the problem, not the card or the driver. The BIOS can only reserve IRQs for ISA devices, so that won't help. Any ideas would be appreciated. Thanks, Jonathan French From becker@cesdis1.gsfc.nasa.gov Fri Sep 10 20:31:22 1999 Date: Fri Sep 10 20:31:22 1999 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: Bizarre tulip behavior On Fri, 10 Sep 1999, Jonathan French wrote: > I have a HP Pavilion 4550z - Celeron type machine, and a Linksys 10/100 > LAN card which works under windows but not RH6.0 or a little Linux > distro called LRP (Linux Router Project). I freed up all of my IRQs ... > Under RH, I ran tulip-diag, which reported thay my NIC can't get a > valid IRQ (although it does get the right memory location). I ran the You should believe the statement from tulip-diag. That's why it's there. > version of tulip.o that came with RH, as well as the latest 0.91g, with > no success. LRP, which uses a 1998 version of tulip, reports that it is > trying to use IRQ 255, and fails. Yup, no IRQ has been assigned. Read http://cesdis.gsfc.nasa.gov/linux/misc/irq-conflict.html 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 syousif@iname.com Fri Sep 10 22:13:05 1999 Date: Fri Sep 10 22:13:05 1999 From: Sami Yousif syousif@iname.com Subject: Bizarre tulip behavior Jonathan French wrote: > I have a HP Pavilion 4550z - Celeron type machine, and a Linksys 10/100 > LAN card which works under windows but not RH6.0 or a little Linux > distro called LRP (Linux Router Project). I freed up all of my IRQs > from my serial & parallel ports in BIOS, to be certain that there are > several free. I even pulled the silly Winmodem/soundcard. > Under RH, I ran tulip-diag, which reported thay my NIC can't get a > valid IRQ (although it does get the right memory location). I ran the > version of tulip.o that came with RH, as well as the latest 0.91g, with > no success. LRP, which uses a 1998 version of tulip, reports that it is > trying to use IRQ 255, and fails. > Under RH, ifconfig -a does report the eth0, and I can ping the local > address, but when a route is requested, it fails with an "Network > Unavailable" or something like that. > I can only figure that the computer has the problem, not the card or > the driver. The BIOS can only reserve IRQs for ISA devices, so that > won't help. Any ideas would be appreciated. > Thanks, > Jonathan French [I know this answer may sound a little confusing... there are several versions of the card so it depends on which version you have... read the whole reply.....] http://cesdis.gsfc.nasa.gov/linux/misc/irq-conflict.html may have some hints.... (try setting the pnp setting to off) http://www.linksys.com/support/solution/nos/linux%5Flne100tx.htm is linksys's "official" blurb on the matter.... does the machine have a scsi card? is it assigning the same IRQ to different devices (like scsi and ethernet even though there are free irqs)? on a related note, linksys may have a modified tulip driver... which exact version of the card do you have? The linksys page mentioned above states that there is a modified driver on "disk2" if you have the wake on lan version of the card. The following link has links to driver disks... (not all have a linux driver included since the standard driver should work with them) http://www.linksys.com/dlc/howtotelllne100tx.htm -- - Sami Yousif mailto:syousif@iname.com mailto:syousif@alug.org http://www.alug.org/ Amarillo Linux Users Group http://www.mav.net/teddyr/syousif/ Personal Page [eMail sent to any of my addresses is subject to the Conditions outlined in https://www.mav.net/teddyr/emailtos.shtml] From space19@earthlink.net Sun Sep 12 07:02:13 1999 Date: Sun Sep 12 07:02:13 1999 From: Shawn Anderson space19@earthlink.net Subject: PNIC LC82C169-9902 Hi, I am having troubles getting my asante 10/100 ethernet card to see my other linux box. And am hoping someone could help me out. I insmod the tulip driver, start eth0 and try to telnet or ping etc... and I get no network activity at all. sa@space$ uname -a Linux space 2.2.10 #15 Sat Sep 11 02:39:26 MDT 1999 ppc unknown the tulip driver sees my card as a: Lite-On 82c168 PNIC asante tech support says it is a PNIC LC82C169-9902 /proc/pci says it is: Bus 0, device 14, function 0: Ethernet controller: LiteOn LNE100TX (rev 32). Medium devsel. Fast back-to-back capable. IRQ 25. Master Capable. Latency=32. I/O at 0x400 [0x401]. Non-prefetchable 32 bit memory at 0x80800000 [0x80800000]. here is the debug log (debug=6): Sep 11 03:45:26 space kernel: Found Lite-On 82c168 PNIC at PCI I/O address 0x400. Sep 11 03:45:26 space kernel: The PCI BIOS has not enabled the device at 0/112! Updating PCI command 0004->0005. Sep 11 03:45:26 space kernel: tulip.c:v0.91g 7/16/99 becker@cesdis.gsfc.nasa.gov Sep 11 03:45:26 space kernel: eth0: Lite-On 82c168 PNIC rev 32 at 0x400, 00:00:B4:94:ED:99, IRQ 25. Sep 11 03:45:26 space kernel: eth0: MII transceiver #1 config 3100 status 7809 advertising 01e1. Sep 11 03:45:32 space kernel: eth0: tulip_open() irq 25. Sep 11 03:45:32 space kernel: eth0: interrupt csr5=0x02699084 new csr5=0x02681000. Sep 11 03:45:32 space kernel: In tulip_rx(), entry 0 80000000. Sep 11 03:45:32 space kernel: eth0: PNIC link changed state 0201f878, CSR5 02699084. Sep 11 03:45:32 space kernel: eth0: interrupt csr5=0x02001000 new csr5=0x02001000. Sep 11 03:45:32 space kernel: eth0: exiting interrupt, csr5=0x2001000. Sep 11 03:45:32 space kernel: eth0: interrupt csr5=0x02001000 new csr5=0x02001000. Sep 11 03:45:32 space kernel: eth0: exiting interrupt, csr5=0x2001000. Sep 11 03:45:32 space kernel: eth0: Done tulip_open(), CSR0 00008000, CSR5 02001000 CSR6 01420000. Sep 11 03:45:35 space kernel: eth0: MII status 7809, Link partner report 0000. Sep 11 03:45:35 space kernel: eth0: No link beat on the MII interface, status 7809. Sep 11 03:46:35 space kernel: eth0: MII status 7829, Link partner report 0020. Sep 11 03:47:35 space kernel: eth0: MII status 782d, Link partner report 0020. Sep 11 03:47:47 space kernel: eth0: Transmit timeout using MII device. Sep 11 03:47:47 space kernel: eth0: interrupt csr5=0x02699084 new csr5=0x02681000. ** then it keeps repeating the following: Sep 11 03:47:47 space kernel: In tulip_rx(), entry 0 80000000. Sep 11 03:47:47 space kernel: eth0: PNIC link changed state 0201f878, CSR5 02699084. Sep 11 03:47:47 space kernel: eth0: interrupt csr5=0x02001000 new csr5=0x02001000. Sep 11 03:47:47 space kernel: eth0: exiting interrupt, csr5=0x2001000. Sep 11 03:47:47 space kernel: eth0: interrupt csr5=0x02001000 new csr5=0x02001000. Sep 11 03:47:47 space kernel: eth0: exiting interrupt, csr5=0x2001000. Sep 11 03:47:52 space kernel: eth0: Transmit timeout using MII device. Sep 11 03:47:52 space kernel: eth0: interrupt csr5=0x02699084 new csr5=0x02681000. any ideas would be appreaciated. Thanks, sa space19@earthlink.net From mob-rules@home.com Sun Sep 12 10:22:45 1999 Date: Sun Sep 12 10:22:45 1999 From: MOB-RULES mob-rules@home.com Subject: I have an etherfast 10/100 and would like to know what is the best way to get it to work with a linksys 100 base 5 port work group hub. I get major upload errors with what I have now and I get to soft reboot exactly three times before I have to turn the machine off so my card will sync up to the hub. I am using .91 of tulip.o and any help would greatly be appreciated. From mob-rules@home.com Sun Sep 12 10:24:21 1999 Date: Sun Sep 12 10:24:21 1999 From: MOB-RULES mob-rules@home.com Subject: I have an etherfast 10/100 and would like to know what is the best way to get it to work with a linksys 100 base 5 port work group hub. I get major upload errors with what I have now and I get to soft reboot exactly three times before I have to turn the machine off so my card will sync up to the hub. I am using .91 of tulip.o and any help would greatly be appreciated. From morbid@warzone.com Sun Sep 12 17:49:49 1999 Date: Sun Sep 12 17:49:49 1999 From: Jeff morbid@warzone.com Subject: No subject From space19@earthlink.net Mon Sep 13 05:41:39 1999 Date: Mon Sep 13 05:41:39 1999 From: Shawn Anderson space19@earthlink.net Subject: PNIC LC82C169-9902 Shawn Anderson wrote: > > Donald Becker wrote: > > > > On Sun, 12 Sep 1999, Shawn Anderson wrote: > > > > > I am having troubles getting my asante 10/100 ethernet card to see my > > > other linux box. And am hoping someone could help me out. I insmod the > > > tulip driver, start eth0 and try to telnet or ping etc... and I get no > > > network activity at all. > > ... > > > Sep 11 03:45:26 space kernel: tulip.c:v0.91g 7/16/99 > > > becker@cesdis.gsfc.nasa.gov > > > Sep 11 03:45:26 space kernel: eth0: Lite-On 82c168 PNIC rev 32 at 0x400, > > > 00:00:B4:94:ED:99, IRQ 25. > > > > That's an unusual I/O addrss and IRQ. What type of machine are you using? > > Its a PowerPC box (Performa 6400/180) > > > > > > Sep 11 03:45:26 space kernel: eth0: MII transceiver #1 config 3100 > > > status 7809 advertising 01e1. > > ... > > > Sep 11 03:45:35 space kernel: eth0: MII status 7809, Link partner report > > > 0000. > > > Sep 11 03:45:35 space kernel: eth0: No link beat on the MII interface, > > > status 7809. > > > Sep 11 03:46:35 space kernel: eth0: MII status 7829, Link partner report > > > 0020. > > > Sep 11 03:47:35 space kernel: eth0: MII status 782d, Link partner report > > > 0020. > > > > Hmmm, you are having problems with link beat -- it apparently is going away > > frequently. > > > > What does 'mii-diag -w' report? > whoops, in my last post I forgot to add a -w to mii-diag root@space # ./mii-diag -w Using the default interface 'eth0'. Basic registers of MII PHY #1: 3100 782d 0302 d008 01e1 0020 0004 2801. Basic mode control register 0x3100: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner is generating 10baseT link beat. 03:13:21.25080 Baseline value of MII BMSR (basic mode status register) is 782d. > thanks, > sa From lkuczyns@emc.com Mon Sep 13 08:52:31 1999 Date: Mon Sep 13 08:52:31 1999 From: Leslie Kuczynski lkuczyns@emc.com Subject: adaptec ANA-6911A/TX: Too much work during an interrupt & Tx-hung Hello, I am using an adaptec ANA-6911A/TX on a 686 running RedHat 6.0 with th 2.2.11-4 kernel. The Ethernet card is sharing interrupt 9 with channel A of a dual port scsi card (adaptec AHA-3944AUWD). Channel B reports using interrupt 15. The box also contains 2 3Com Ethernet ISA cards (interrupts 10 and 11) running as eth0 and eth1 respectively. The adaptec ANA is running as eth2 with the tulip.c:v0.91g driver. After a period of time (hours to a few days) the adaptec Ethernet card hangs reporting "Too much work during an interrupt" and "Tx hung". I have provided some information below from the system log and from tulip-diag. If more info is needed please let me know. Any help in this matter is appreciated. Best regards, Leslie Kuczynski [root@snms0251 log]# uname -a Linux snms0251 2.2.11-4 #1 Wed Aug 18 20:38:06 EDT 1999 i686 unknown /var/log/messages: Sep 10 07:24:35 snms0251 kernel: Found Digital DS21143 Tulip at PCI I/O address 0xe480. Sep 10 07:24:35 snms0251 kernel: tulip.c:v0.91g 7/16/99 becker@cesdis.gsfc.nasa.gov Sep 10 07:24:35 snms0251 kernel: eth2: Digital DS21143 Tulip rev 33 at 0xe480, 00:00:D1:1B:BC:F8, IRQ 9. Sep 10 07:24:35 snms0251 kernel: eth2: EEPROM default media type Autosense. Sep 10 07:24:35 snms0251 kernel: eth2: MII interface PHY 0, setup/reset sequences 2/3 long, capabilities 00 00. Sep 10 07:24:35 snms0251 kernel: eth2: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Sep 10 07:24:35 snms0251 kernel: eth2: MII transceiver #1 config 3100 status 7849 advertising 0101. ... Sep 10 07:24:45 snms0251 network: Bringing up interface eth2 succeeded Sep 10 07:24:48 snms0251 kernel: eth2: 21143 negotiation status 000000c6, MII. Sep 10 07:24:48 snms0251 kernel: eth2: MII status 786b, Link partner report 41e1. Sep 10 07:24:48 snms0251 kernel: eth2: The transmitter stopped. CSR5 is f0068002, CSR6 b20e0202, new CSR6 820e0200. Sep 10 07:24:48 snms0251 kernel: eth2: Setting full-duplex based on MII#1 link partner capability of 41e1. ... Sep 13 03:25:33 snms0251 kernel: eth2: MII status 786f, Link partner report 41e1. Sep 13 03:25:40 snms0251 kernel: eth2: Too much work during an interrupt, csr5=0xf0670040. Sep 13 03:26:03 snms0251 kernel: eth2: Re-enabling interrupts, f06988c0. Sep 13 03:26:03 snms0251 kernel: eth2: Too much work during an interrupt, csr5=0xf06988c0. Sep 13 03:26:33 snms0251 kernel: eth2: 21143 negotiation status 000000c6, MII. Sep 13 03:26:33 snms0251 kernel: eth2: MII status 786f, Link partner report 41e1. ... Sep 13 03:34:33 snms0251 kernel: eth2: 21143 negotiation status 000000c6, MII. Sep 13 03:34:33 snms0251 kernel: eth2: MII status 786f, Link partner report 41e1. Sep 13 03:34:33 snms0251 kernel: eth2: Tx hung, 540 vs. 533. Sep 13 03:34:33 snms0251 kernel: eth2: Transmit timeout using MII device. [root@snms0251 tulip-diag]# ./tulip-diag -avfme tulip-diag.c:v1.12 7/31/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0xe480. Digital DS21143 Tulip chip registers at 0xe480: ffa08000 ffffffff ffffffff 00225010 00225210 f06988c7 b20e2002 f3fe6b2f e0000275 fff583ff ffffffff fffe0000 000000c6 ffff0000 fff80000 8ff00000 Port selection is MII, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Suspended -- no Rx buffers'. The Tx process state is 'Idle'. The transmit threshold is 128. Interrupt sources are pending! CSR5 is f06988c7. Tx done indication. Tx complete indication. Tx out of buffers indication. Rx Done indication. Receiver out of buffers indication. Timer expired indication. The NWay status register is 000000c6. EEPROM size is 6. Ethernet MAC Station Address 00:00:D1:1B:BC:F8. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 40, default media type 0800 (Autosense). 1 transceiver description blocks: Media MII, block type 3, length 23. MII interface PHY 0 (media type 11). 21143 MII initialization sequence is 2 words: 0821 0000. 21143 MII reset sequence is 3 words: 0821 0001 0000. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. No MII interrupt. MII PHY found at address 1, status 0x786f. MII PHY #1 transceiver registers: 3100 786f 2000 5c01 01e1 41e1 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0037 0000 0000 0001 8060 8020 0ca1 0000 1800 a3b9 0085 2805 001b. Internal autonegotiation state is 'Autonegotiation disabled'. From bdemirjian@greeley-hansen.com Mon Sep 13 09:45:42 1999 Date: Mon Sep 13 09:45:42 1999 From: brad demirjian bdemirjian@greeley-hansen.com Subject: Please Help me w/ Compiling I have a system running redhat 6.0 I installed all packages provided on the CD. I have a DEC 21140 based NIC. The system is running on two celerons and is in SMP "mode", at least that is what the info provided by KDE tells me. When I run the compile command provided w/ the latest tulip driver (9/13/99) for smp 2.2.9 kernel systems I get the following messages implicit declaration of function 'Get_APIC_ID' ... 'APIC_Base' undeclared ... 'APIC_ID' undeclared... I am quite new to linux, thus I did not edit the tulip.c file at all do I need to edit it? Also How do I assign IRQs and memory ranges? Thank you brad ===================================== Brad Demirjian Detroit Office Of Greeley and Hansen Engineers 211 West Fort Street Suite 710 Detroit, MI 48226 Tel:313.628.0730 Fax: 313.967.0365 email: bdemirjian@greeley-hansen.com From becker@cesdis1.gsfc.nasa.gov Mon Sep 13 11:19:19 1999 Date: Mon Sep 13 11:19:19 1999 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: PNIC LC82C169-9902 On Mon, 13 Sep 1999, Shawn Anderson wrote: > > Donald Becker wrote: > > > On Sun, 12 Sep 1999, Shawn Anderson wrote: > > > > > > > I am having troubles getting my asante 10/100 ethernet card to see my > > > > other linux box. And am hoping someone could help me out. I insmod the > > > > tulip driver, start eth0 and try to telnet or ping etc... and I get no > > > > network activity at all. > > > ... > > > > Sep 11 03:45:26 space kernel: tulip.c:v0.91g 7/16/99 > > > > becker@cesdis.gsfc.nasa.gov > > > > Sep 11 03:45:26 space kernel: eth0: Lite-On 82c168 PNIC rev 32 at 0x400, > > > > 00:00:B4:94:ED:99, IRQ 25. > > > > > > That's an unusual I/O addrss and IRQ. What type of machine are you using? > > Its a PowerPC box (Performa 6400/180) That's the problem. The pre-0.91j Tulip drivers work on the PowerPC, but used the descriptor byte-swapping feature of the Tulip so that the driver wouldn't need to byte swap on the PPC. (It still must in the setup, but not during operation.) But the most of the Tulip clones, including the PNIC, didn't both to implement the byte-swap feature. I used to advise just buying a real Tulip board. But I decided that I had spent way too much answering "bug" reports, and it was only going to get worse with the increasing number of clone chips. So the v0.91j and later drivers have explicit byte swapping. Get the new driver from http://cesdis.gsfc.nasa.gov/linux/drivers/kern-2.3/index.html ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3/ You *must* get the new support files (k_compat.h pci-netif.[ch]) as well! While I don't have a PowerPC system to test with, I believe that every PCI network driver in that directory, except for rtl8139.c, should work with the PowerPC. The rtl8139.c driver *might* require at line 344 - ((u16 *)(dev->dev_addr))[i] = read_eeprom(ioaddr, i+7, addr_len); + put_unaligned(le16_to_cpu(read_eeprom(ioaddr, i+7, addr_len), + (u16 *)(dev->dev_addr))[i]); at line 1157 - u32 rx_status = *(u32*)(rx_ring + ring_offset); + u32 rx_status = le32_to_cpu(get_unaligned((u32*)(rx_ring + ring_offset)); If someone with a PPC and RTL8139 card would like to test.. 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 jon@seainc.com Mon Sep 13 13:25:29 1999 Date: Mon Sep 13 13:25:29 1999 From: Jonathan French jon@seainc.com Subject: Bizarre tulip behavior Thank you, sir, The irq-conflict.html page did the trick. The HP Pavilion BIOS didn't have an explicit PnP option, but it did have an "Installed OS" option - Other / Win95 / Win98 WinNT. I just switched it to Other, and bingo. I missed the Other option earlier. Thanks to all who suggested turning BIOS PnP off, it was just figuring out where the switch was hidden. - Jon French Donald Becker wrote: > > On Fri, 10 Sep 1999, Jonathan French wrote: > > > I have a HP Pavilion 4550z - Celeron type machine, and a Linksys 10/100 > > LAN card which works under windows but not RH6.0 or a little Linux > > distro called LRP (Linux Router Project). I freed up all of my IRQs > ... > > Under RH, I ran tulip-diag, which reported thay my NIC can't get a > > valid IRQ (although it does get the right memory location). I ran the > > You should believe the statement from tulip-diag. That's why it's there. > > > version of tulip.o that came with RH, as well as the latest 0.91g, with > > no success. LRP, which uses a 1998 version of tulip, reports that it is > > trying to use IRQ 255, and fails. > > Yup, no IRQ has been assigned. > Read > http://cesdis.gsfc.nasa.gov/linux/misc/irq-conflict.html > > 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 space19@earthlink.net Mon Sep 13 14:22:05 1999 Date: Mon Sep 13 14:22:05 1999 From: Shawn Anderson space19@earthlink.net Subject: PNIC LC82C169-9902 Donald Becker wrote: > > On Mon, 13 Sep 1999, Shawn Anderson wrote: > > > Donald Becker wrote: > > > > On Sun, 12 Sep 1999, Shawn Anderson wrote: > > > > > > > > > I am having troubles getting my asante 10/100 ethernet card to see my > > > > > other linux box. And am hoping someone could help me out. I insmod the > > > > > tulip driver, start eth0 and try to telnet or ping etc... and I get no > > > > > network activity at all. > > > > ... > > > > > Sep 11 03:45:26 space kernel: tulip.c:v0.91g 7/16/99 > > > > > becker@cesdis.gsfc.nasa.gov > > > > > Sep 11 03:45:26 space kernel: eth0: Lite-On 82c168 PNIC rev 32 at 0x400, > > > > > 00:00:B4:94:ED:99, IRQ 25. > > > > > > > > That's an unusual I/O addrss and IRQ. What type of machine are you using? > > > Its a PowerPC box (Performa 6400/180) > > That's the problem. > The pre-0.91j Tulip drivers work on the PowerPC, but used the descriptor > byte-swapping feature of the Tulip so that the driver wouldn't need to byte > swap on the PPC. (It still must in the setup, but not during operation.) > > But the most of the Tulip clones, including the PNIC, didn't both to > implement the byte-swap feature. > > I used to advise just buying a real Tulip board. But I decided that I had > spent way too much answering "bug" reports, and it was only going to get > worse with the increasing number of clone chips. So the v0.91j and later > drivers have explicit byte swapping. > > Get the new driver from > http://cesdis.gsfc.nasa.gov/linux/drivers/kern-2.3/index.html > ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3/ > > You *must* get the new support files (k_compat.h pci-netif.[ch]) as well! thank you, It is working like a charm now!. sa, From space19@earthlink.net Tue Sep 14 05:42:48 1999 Date: Tue Sep 14 05:42:48 1999 From: Shawn Anderson space19@earthlink.net Subject: PNIC LC82C169-9902 with PowerPC Donald Becker wrote: > > On Mon, 13 Sep 1999, Shawn Anderson wrote: > > > Get the new driver from > > > http://cesdis.gsfc.nasa.gov/linux/drivers/kern-2.3/index.html > > > ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3/ > > > > > > You *must* get the new support files (k_compat.h pci-netif.[ch]) as well! > > > > thank you, It is working like a charm now!. > > Please confirm: the tulip driver from the kern-2.3 directory is working with > the LiteOn PNIC on a PowerPC. yes its true. the 2.3 tulip driver is working for my card (asante 10/100 PNIC LC82C169-9902), I have been testing it for a few hours and havent seen any problems, however when I compiled the drivers I get a bunch of warning messages like: /usr/include/linux/string.h:31: warning: conflicting types for built-in function `memset' /usr/include/linux/string.h:32: warning: conflicting types for built-in function `memcpy' /usr/include/linux/string.h:35: warning: conflicting types for built-in function `memcmp' it's probably because I'm still using linux 2.2.10 there where few more warnings, I can send you the whole output if you like. > If that is the case, please also send a note the PPC mailing list. ok thanks again, s.a. From bryan@terran.org Tue Sep 14 13:16:45 1999 Date: Tue Sep 14 13:16:45 1999 From: B. James Phillippe bryan@terran.org Subject: Location of older tulip drivers Greetings, Does anyone know where interim tulip.c driver versions are located? For example, the 0.91 dated 4/14. It would be nice if these interim versions were available so that we can peruse the changes between driver revisions. This would greatly aid debugging. -bp -- # bryan at terran dot org # http://www.terran.org/~bryan From taneja.5@osu.edu Wed Sep 15 04:08:41 1999 Date: Wed Sep 15 04:08:41 1999 From: Raj Taneja taneja.5@osu.edu Subject: skbuff errors with new tulip driver under linuxppc I have a Motorola Starmax with a PowerPC 604 processor running LinuxPPC R4. In it I have installed 2 Asante 10/100 PCI ethernet cards. One is based on the Digital chipset, the other on the PNIC chipset. The Digital one worked fine with the de4x5 driver, but the newer one requires use of the v0.91j++ tulip driver to work at all. Since the new tulip driver detects both cards, I decided to use it alone. Anytime any network traffic is sent over either interface (eth0 or eth1), I get nonstop errors at the console to the following effect: eth0: Internal fault: The skbuff addresses do not match in tulip_rx: d0986401 vs. c1649800 / c1649810. This happens with both interfaces and with various addresses. This basically slows my network to a crawl (one of the cards is connected to a cable modem, the other to my hub. The machine is doing masquerading for my internal network). I am using kernel 2.2.10 with the new tulip driver. How can this problem be fixed? Thanks. raj From arcane@verinet.com Wed Sep 15 11:10:44 1999 Date: Wed Sep 15 11:10:44 1999 From: Bryan Stillwell arcane@verinet.com Subject: Problems with LNE100TX I've been messing around with trying to get my LinkSys LNE100TX to work under linux for some time now, but with not much success. I've tried it in two different computers with different distributions of linux (Redhat and Mandrake), multiple kernels, and different versions of the tulip.c and de4x5.c source code. When I compile the tulip driver as a module in kernel 2.2.12, I get a message about the device or resource is busy... Which I believe means that it couldn't find the card. So the next thing I did was try the 2.3.15 kernel, but same results. I figured that it would since the source didn't change between the two versions as far as I can tell... Then I tried updating the tulip.c file to v0.91j++ dated 9/8/99 off the ftp site: ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3/ I do get a little farther after doing that, but now I get this when I try a 'insmod tulip.o': tulip.o: unresolved symbol pci_drv_unregister tulip.o: unresolved symbol pci_drv_register Doing a 'depmod -a' gives: /lib/modules/2.3.15/net/tulip.o: unresolved symbol(s) Which also should be expected. But now I don't know what else there is to do, but expose the problems I've been having. I have two of these LNE100TX cards that I bought at Best Buy for $30 each, so I'm hoping I can get them to work since they're such a good deal. (They were down to $20 each the last time I went into Best Buy) I did go ahead and install the tulip-diag program and it seems to find the card just fine. Here is the output from it: # ./tulip-diag tulip-diag.c:v1.12 7/31/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Lite-On PNIC-II adapter at 0xf400. Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. The NWay status register is 000020ce. Internal autonegotiation state is 'Ability detect'. Use '-a' to show device registers, '-e' to show EEPROM contents, or '-m' to show MII management registers. # ./tulip-diag -a tulip-diag.c:v1.12 7/31/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Lite-On PNIC-II adapter at 0xf400. Lite-On PNIC-II chip registers at 0xf400: fe580000 ffffffff ffffffff 7cf5bff2 f452b9ed e4000000 e1000000 e7fe0000 fffe0000 00fecf08 fffe0466 fffe0000 000020ce ffff0000 ffffffff fff00000 03300000 03300000 03300000 f00ffff0 00004200 00001140 33ccf630 a000a000 33ccf630 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. The NWay status register is 000020ce. Internal autonegotiation state is 'Ability detect'. # ./tulip-diag -e tulip-diag.c:v1.12 7/31/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Lite-On PNIC-II adapter at 0xf400. Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. The NWay status register is 000020ce. EEPROM size is 6. Ethernet MAC Station Address 00:a0:cc:33:30:f6. Wake-On-Lan ID bytes a0:00:33:cc:f6:30. PCI Subsystem IDs Vendor 11ad Device 01c0 Internal autonegotiation state is 'Ability detect'. # ./tulip-diag -m tulip-diag.c:v1.12 7/31/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Lite-On PNIC-II adapter at 0xf400. Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. The NWay status register is 000020ce. No MII transceivers found! Internal autonegotiation state is 'Ability detect'. That's all the information I could think of that would help someone help me find my problem, but if you need any more feel free to ask. Thank you very much for any help you can provide, Bryan From space19@earthlink.net Wed Sep 15 16:23:25 1999 Date: Wed Sep 15 16:23:25 1999 From: Shawn Anderson space19@earthlink.net Subject: Problems with LNE100TX Bryan Stillwell wrote: > I do get a little farther after doing that, but now I get this when I try > a 'insmod tulip.o': > > tulip.o: unresolved symbol pci_drv_unregister > tulip.o: unresolved symbol pci_drv_register > > Doing a 'depmod -a' gives: > /lib/modules/2.3.15/net/tulip.o: unresolved symbol(s) > > Bryan try a: # insmod pci-netif.o && insmod tulip.o From taneja.5@osu.edu Wed Sep 15 16:41:40 1999 Date: Wed Sep 15 16:41:40 1999 From: Raj Taneja taneja.5@osu.edu Subject: skbuff errors with new tulip driver under linuxppc Donald Becker wrote: > > > eth0: Internal fault: The skbuff addresses do not match in tulip_rx: > > d0986401 vs. c1649800 / c1649810. > > Thanks for the report. > > The work-around is to compile the driver with -Dfinal_version=1 to disable > the checking code. > > The fix is make the following change > #ifndef final_version > - if (cpu_to_virt(tp->rx_ring[entry].buffer1) != temp) > + if (le32desc_to_virt(tp->rx_ring[entry].buffer1) != temp) > printk(KERN_ERR "%s: Internal fault: The skbuff addresses " > "do not match in tulip_rx: %p vs. %p / %p.\n", > dev->name, bus_to_virt(tp->rx_ring[entry].buffer1), > skb->head, temp); > #endif > > This change is in v0.91m, along with > Turning on 21143 interrupt mitigation mode if a packet overload ("too > much work at interrupt") occurs. > > Refilling the Rx buffer list during more events, to recover more quickly > from running out of Rx buffers. > > Please send a second report if this fix or new version corrects the problem. > It it does I should remove the check above, since it now involves additional > instructions instead of only an almost-free comparison. I implemented the fix in the code (btw, in 0.91j++, the original string is bus_to_virt, not cpu_to_virt), recompiled and now it works just fine. Thanks. raj From GSaraber@unlimitedsolutions.com Wed Sep 15 17:29:29 1999 Date: Wed Sep 15 17:29:29 1999 From: Gerard Saraber GSaraber@unlimitedsolutions.com Subject: Problems with LNE100TX Hi, I have an LNE100TX from linksys as well, and I have no problems whatsoever as long as i use a later version of the driver than the one included in the linux kernel, the one I currently use is v91g - also note that I use the "tulip" driver , tulip.c , not the de4x5 driver. Let me know if you need anything else. btw. the driver I use with kernel 2.3.15 can be found on ftp://saraber.dhs.org/pub/tulip/ Regards, --====================================================================-- 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. > -----Original Message----- > From: Bryan Stillwell [SMTP:arcane@verinet.com] > Sent: Wednesday, September 15, 1999 11:11 > To: linux-tulip@cesdis1.gsfc.nasa.gov > Subject: Problems with LNE100TX > > I've been messing around with trying to get my LinkSys LNE100TX to > work > under linux for some time now, but with not much success. I've tried > it > in two different computers with different distributions of linux > (Redhat > and Mandrake), multiple kernels, and different versions of the tulip.c > and > de4x5.c source code. > > When I compile the tulip driver as a module in kernel 2.2.12, I get a > message about the device or resource is busy... Which I believe means > that it couldn't find the card. > > So the next thing I did was try the 2.3.15 kernel, but same results. > I > figured that it would since the source didn't change between the two > versions as far as I can tell... > > > Then I tried updating the tulip.c file to v0.91j++ dated 9/8/99 off > the > ftp site: ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3/ > > I do get a little farther after doing that, but now I get this when I > try > a 'insmod tulip.o': > > tulip.o: unresolved symbol pci_drv_unregister > tulip.o: unresolved symbol pci_drv_register > > > Doing a 'depmod -a' gives: > /lib/modules/2.3.15/net/tulip.o: unresolved symbol(s) > > Which also should be expected. > > > But now I don't know what else there is to do, but expose the problems > I've been having. I have two of these LNE100TX cards that I bought at > Best Buy for $30 each, so I'm hoping I can get them to work since > they're > such a good deal. (They were down to $20 each the last time I went > into > Best Buy) > > I did go ahead and install the tulip-diag program and it seems to find > the > card just fine. Here is the output from it: > > # ./tulip-diag > tulip-diag.c:v1.12 7/31/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > Index #1: Found a Lite-On PNIC-II adapter at 0xf400. > Port selection is 10mpbs-serial, half-duplex. > Transmit stopped, Receive stopped, half-duplex. > The Rx process state is 'Stopped'. > The Tx process state is 'Stopped'. > The transmit threshold is 72. > The NWay status register is 000020ce. > Internal autonegotiation state is 'Ability detect'. > Use '-a' to show device registers, > '-e' to show EEPROM contents, > or '-m' to show MII management registers. > > > # ./tulip-diag -a > tulip-diag.c:v1.12 7/31/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > Index #1: Found a Lite-On PNIC-II adapter at 0xf400. > Lite-On PNIC-II chip registers at 0xf400: > fe580000 ffffffff ffffffff 7cf5bff2 f452b9ed e4000000 e1000000 > e7fe0000 > fffe0000 00fecf08 fffe0466 fffe0000 000020ce ffff0000 ffffffff > fff00000 > 03300000 03300000 03300000 f00ffff0 00004200 00001140 33ccf630 > a000a000 > 33ccf630 00000000 00000000 00000000 00000000 00000000 00000000 > 00000000 > Port selection is 10mpbs-serial, half-duplex. > Transmit stopped, Receive stopped, half-duplex. > The Rx process state is 'Stopped'. > The Tx process state is 'Stopped'. > The transmit threshold is 72. > The NWay status register is 000020ce. > Internal autonegotiation state is 'Ability detect'. > > > # ./tulip-diag -e > tulip-diag.c:v1.12 7/31/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > Index #1: Found a Lite-On PNIC-II adapter at 0xf400. > Port selection is 10mpbs-serial, half-duplex. > Transmit stopped, Receive stopped, half-duplex. > The Rx process state is 'Stopped'. > The Tx process state is 'Stopped'. > The transmit threshold is 72. > The NWay status register is 000020ce. > EEPROM size is 6. > Ethernet MAC Station Address 00:a0:cc:33:30:f6. > Wake-On-Lan ID bytes a0:00:33:cc:f6:30. > PCI Subsystem IDs Vendor 11ad Device 01c0 > Internal autonegotiation state is 'Ability detect'. > > > # ./tulip-diag -m > tulip-diag.c:v1.12 7/31/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > Index #1: Found a Lite-On PNIC-II adapter at 0xf400. > Port selection is 10mpbs-serial, half-duplex. > Transmit stopped, Receive stopped, half-duplex. > The Rx process state is 'Stopped'. > The Tx process state is 'Stopped'. > The transmit threshold is 72. > The NWay status register is 000020ce. > No MII transceivers found! > Internal autonegotiation state is 'Ability detect'. > > > That's all the information I could think of that would help someone > help > me find my problem, but if you need any more feel free to ask. > > Thank you very much for any help you can provide, > > Bryan > From gordonw@apexxtech.com Wed Sep 15 20:34:25 1999 Date: Wed Sep 15 20:34:25 1999 From: Chen-Yuan Wu gordonw@apexxtech.com Subject: Problems with LNE100TX Hi: Can you tell me what is the motherboard you are using? If you are using a motherboard with award bios and VIA chipset, please check the following: when your system boot up, do you see the vender id the production correctly? I forget ther vender id, but the product id should be c115. I have encountered some problems with LNE 100TX with some motherboards that the Motherboard couldn't correctly recognize the NIC( either miss it totally, or come up with false vender id and production id, such as c115 will become 4115, then tulip.o will have some problem with the NIC), I have try serveral different motherboards (via 82c5856, via 82c598 and intel TX chipset) and more than twenty linksys LNE 100TXs. The problem is that some NICs work ok, but some NICs are just couldn't be recgonized correctly(sometimes swap slot helps, but once it wouln't work in that particular slot, it will never work in that particular slot). I have contact the MB manufacturers and linksys. It looks like a hardware mismatch for me, but these motherboards work fine with other NICs such as the old PNIC, DEC base, eepro100,via-rhine base, real-tek 8139 base, NICs. I tend to think there is some problem in the LNE100TX NICs. I hope I can hear from linksys soon. Ok, I found your device ID from your post, and it maybe wrong > PCI Subsystem IDs Vendor 11ad Device 01c0 Gordon From arcane@verinet.com Thu Sep 16 01:26:55 1999 Date: Thu Sep 16 01:26:55 1999 From: Bryan Stillwell arcane@verinet.com Subject: Problems with LNE100TX > > I do get a little farther after doing that, but now I get this when I try > > a 'insmod tulip.o': > > > > tulip.o: unresolved symbol pci_drv_unregister > > tulip.o: unresolved symbol pci_drv_register > > You also need pci-netif.c. The instructions are at > http://cesdis.gsfc.nasa.gov/linux/drivers/kern-2.3/index.html > ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3/ > > Do 'insmod pci-netif.o' before 'insmod tulip.o'. Oops, I should have figured that one out myself. Anyways when I do the 'insmod pci-netif.o' before the 'insmod tulip.o', I still get this message 'tulip.o: unresolved symbol pci_drv_unregister'. The 'pci_drv_register' message did go away however. I verified that the 'pci_drv_unregister' message shows up in both kernels 2.2.12 and 2.3.15. > > But now I don't know what else there is to do, but expose the problems > > I've been having. I have two of these LNE100TX cards that I bought at > > Best Buy for $30 each, so I'm hoping I can get them to work since they're > > such a good deal. (They were down to $20 each the last time I went into > > Best Buy) > > That's a pretty good deal -- the PNIC-II cards can do Wake-On-LAN. I just hope I can get them working without too much trouble. They do work under windoze, but I don't have windoze installed on that computer any more, so it doesn't do any good. :) Thanks for the help! Bryan From arcane@verinet.com Thu Sep 16 01:30:14 1999 Date: Thu Sep 16 01:30:14 1999 From: Bryan Stillwell arcane@verinet.com Subject: Problems with LNE100TX It appears that the LNE100TX came with at least two different chips on them. Most likely yours is the older one using the original PNIC chip from lite-on, but mine uses the newer PNIC-II chip which would explain my problems. Just to be sure, do you have the wake-on-lan option on your card? Thanks for helping, Bryan On Wed, 15 Sep 1999, Gerard Saraber wrote: > Hi, > I have an LNE100TX from linksys as well, and I have no problems > whatsoever as long as i use > a later version of the driver than the one included in the linux kernel, > the one I currently use is > v91g - also note that I use the "tulip" driver , tulip.c , not the de4x5 > driver. > Let me know if you need anything else. btw. the driver I use with kernel > 2.3.15 can be found on > ftp://saraber.dhs.org/pub/tulip/ > > Regards, > --====================================================================-- > 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. > > > -----Original Message----- > > From: Bryan Stillwell [SMTP:arcane@verinet.com] > > Sent: Wednesday, September 15, 1999 11:11 > > To: linux-tulip@cesdis1.gsfc.nasa.gov > > Subject: Problems with LNE100TX > > > > I've been messing around with trying to get my LinkSys LNE100TX to > > work > > under linux for some time now, but with not much success. I've tried > > it > > in two different computers with different distributions of linux > > (Redhat > > and Mandrake), multiple kernels, and different versions of the tulip.c > > and > > de4x5.c source code. > > > > When I compile the tulip driver as a module in kernel 2.2.12, I get a > > message about the device or resource is busy... Which I believe means > > that it couldn't find the card. > > > > So the next thing I did was try the 2.3.15 kernel, but same results. > > I > > figured that it would since the source didn't change between the two > > versions as far as I can tell... > > > > > > Then I tried updating the tulip.c file to v0.91j++ dated 9/8/99 off > > the > > ftp site: ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3/ > > > > I do get a little farther after doing that, but now I get this when I > > try > > a 'insmod tulip.o': > > > > tulip.o: unresolved symbol pci_drv_unregister > > tulip.o: unresolved symbol pci_drv_register > > > > > > Doing a 'depmod -a' gives: > > /lib/modules/2.3.15/net/tulip.o: unresolved symbol(s) > > > > Which also should be expected. > > > > > > But now I don't know what else there is to do, but expose the problems > > I've been having. I have two of these LNE100TX cards that I bought at > > Best Buy for $30 each, so I'm hoping I can get them to work since > > they're > > such a good deal. (They were down to $20 each the last time I went > > into > > Best Buy) > > > > I did go ahead and install the tulip-diag program and it seems to find > > the > > card just fine. Here is the output from it: > > > > # ./tulip-diag > > tulip-diag.c:v1.12 7/31/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > > Index #1: Found a Lite-On PNIC-II adapter at 0xf400. > > Port selection is 10mpbs-serial, half-duplex. > > Transmit stopped, Receive stopped, half-duplex. > > The Rx process state is 'Stopped'. > > The Tx process state is 'Stopped'. > > The transmit threshold is 72. > > The NWay status register is 000020ce. > > Internal autonegotiation state is 'Ability detect'. > > Use '-a' to show device registers, > > '-e' to show EEPROM contents, > > or '-m' to show MII management registers. > > > > > > # ./tulip-diag -a > > tulip-diag.c:v1.12 7/31/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > > Index #1: Found a Lite-On PNIC-II adapter at 0xf400. > > Lite-On PNIC-II chip registers at 0xf400: > > fe580000 ffffffff ffffffff 7cf5bff2 f452b9ed e4000000 e1000000 > > e7fe0000 > > fffe0000 00fecf08 fffe0466 fffe0000 000020ce ffff0000 ffffffff > > fff00000 > > 03300000 03300000 03300000 f00ffff0 00004200 00001140 33ccf630 > > a000a000 > > 33ccf630 00000000 00000000 00000000 00000000 00000000 00000000 > > 00000000 > > Port selection is 10mpbs-serial, half-duplex. > > Transmit stopped, Receive stopped, half-duplex. > > The Rx process state is 'Stopped'. > > The Tx process state is 'Stopped'. > > The transmit threshold is 72. > > The NWay status register is 000020ce. > > Internal autonegotiation state is 'Ability detect'. > > > > > > # ./tulip-diag -e > > tulip-diag.c:v1.12 7/31/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > > Index #1: Found a Lite-On PNIC-II adapter at 0xf400. > > Port selection is 10mpbs-serial, half-duplex. > > Transmit stopped, Receive stopped, half-duplex. > > The Rx process state is 'Stopped'. > > The Tx process state is 'Stopped'. > > The transmit threshold is 72. > > The NWay status register is 000020ce. > > EEPROM size is 6. > > Ethernet MAC Station Address 00:a0:cc:33:30:f6. > > Wake-On-Lan ID bytes a0:00:33:cc:f6:30. > > PCI Subsystem IDs Vendor 11ad Device 01c0 > > Internal autonegotiation state is 'Ability detect'. > > > > > > # ./tulip-diag -m > > tulip-diag.c:v1.12 7/31/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > > Index #1: Found a Lite-On PNIC-II adapter at 0xf400. > > Port selection is 10mpbs-serial, half-duplex. > > Transmit stopped, Receive stopped, half-duplex. > > The Rx process state is 'Stopped'. > > The Tx process state is 'Stopped'. > > The transmit threshold is 72. > > The NWay status register is 000020ce. > > No MII transceivers found! > > Internal autonegotiation state is 'Ability detect'. > > > > > > That's all the information I could think of that would help someone > > help > > me find my problem, but if you need any more feel free to ask. > > > > Thank you very much for any help you can provide, > > > > Bryan > > > From arcane@verinet.com Thu Sep 16 01:57:42 1999 Date: Thu Sep 16 01:57:42 1999 From: Bryan Stillwell arcane@verinet.com Subject: Problems with LNE100TX > Can you tell me what is the motherboard you are using? If you are using > a motherboard with award bios and VIA chipset, please check the following: > when your system boot up, do you see the > vender id the production correctly? I forget ther vender id, but the product > id should be c115. I have an Intel AN430TX motherboard running a K6-233 processor. The BIOS is by Phoenix. If you want me to I can install it in another computer that has a Soyo 5EMA+ motherboard in it which I believe uses the VIA chipset (even though it's labeled ETEQ). > I have encountered some problems with LNE 100TX with some motherboards > that the Motherboard couldn't correctly recognize the NIC( either miss it > totally, or come up with false vender id and production id, such as c115 > will become 4115, then tulip.o will have some problem with the NIC), I have > try serveral different motherboards (via 82c5856, via 82c598 and intel TX > chipset) and more than twenty linksys LNE 100TXs. The problem is that some > NICs work ok, but some NICs are just couldn't be recgonized > correctly(sometimes swap slot helps, but once it wouln't work in that > particular slot, it will never work in that particular slot). I have contact > the MB manufacturers and linksys. It looks like a hardware mismatch for me, > but these motherboards work fine with other NICs > such as the old PNIC, DEC base, eepro100,via-rhine base, real-tek 8139 base, > NICs. I tend to think there is some problem in the LNE100TX NICs. > I hope I can hear from linksys soon. It looks like the time before I didn't do an 'insmod pci-netif.o' before the 'insmod tulip.o', but when I do do this I still get an error message. The message is 'tulip.o: unresolved symbol pci_drv_unregister'. The 'tulip.o: unresolved symbol pci_drv_register' message went away after I loaded the pci-netif module. This seems kind of strange, because when I looked at the source for pci-netif.c it had a function for it. > Ok, I found your device ID from your post, and it maybe wrong > > > PCI Subsystem IDs Vendor 11ad Device 01c0 I don't know, the messages I've been getting seem more related to the latest driver. It looks like I have the PNIC-II chip on my LNE100TX, so I think I have to use the latest driver for it to work. I also looked in the source for tulip.c and noticed this line: { "Lite-On LC82C115 PNIC-II", { 0xc11511AD, 0xffffffff }, TULIP_IOTYPE, 256, PNIC2 }, So for some reason it seems to be pulling the wrong word out of the long, because it has both c115 in it (which you said it should be) and 11AD (which is what my card is reporting). Any ideas on that one? I'm running glibc-2.1.1-9mdk, maybe I should upgrade to the latest? Thanks for the help and ideas, Bryan From gordonw@apexxtech.com Thu Sep 16 11:13:38 1999 Date: Thu Sep 16 11:13:38 1999 From: Chen-Yuan Wu gordonw@apexxtech.com Subject: Problems with LNE100TX -----Original Message----- From: Bryan Stillwell To: Chen-Yuan Wu Cc: linux-tulip@cesdis1.gsfc.nasa.gov Date: Thu Sep 16 11:13:38 1999 Subject: RE: Problems with LNE100TX >> Can you tell me what is the motherboard you are using? If you are using >> a motherboard with award bios and VIA chipset, please check the following: >> when your system boot up, do you see the >> vender id the production correctly? I forget ther vender id, but the product >> id should be c115. > >I have an Intel AN430TX motherboard running a K6-233 processor. The BIOS >is by Phoenix. If you want me to I can install it in another computer >that has a Soyo 5EMA+ motherboard in it which I believe uses the VIA >chipset (even though it's labeled ETEQ). > I believe I have tested the same MB as yours with the inconsistence result as I describe in the last mail. So you don't need to install another MB, unless you feel it would work. > >> Ok, I found your device ID from your post, and it maybe wrong >> >> > PCI Subsystem IDs Vendor 11ad Device 01c0 > >I don't know, the messages I've been getting seem more related to the >latest driver. It looks like I have the PNIC-II chip on my LNE100TX, so I >think I have to use the latest driver for it to work. I also looked in >the source for tulip.c and noticed this line: > >{ "Lite-On LC82C115 PNIC-II", { 0xc11511AD, 0xffffffff }, > TULIP_IOTYPE, 256, PNIC2 }, > >So for some reason it seems to be pulling the wrong word out of the long, >because it has both c115 in it (which you said it should be) and 11AD >(which is what my card is reporting). Any ideas on that one? I'm running >glibc-2.1.1-9mdk, maybe I should upgrade to the latest? 11AD is the vender ID (as linksys or Lite-on), C115 (as LC82c115)is the product ID. The phoenix bios will not show them when system boots up. Under award bios, I can see the ids from a device table. I believe at the system bootup time, the NIC has been false recognized as verder 11AD, device ID 01c0 in your case. What make me feel strange is that since you NIC was recognized falsely, I don't think insmod tulip would recgonized the NIC, and it would fail. The tulip.c I use were 0.91g and 0.90f (0.90f with linksys patch, this one came with the NIC, I believe linksys did the patch), I did not try 0.91j, since, I basically think it is a hardware problem. So I don't think upgrade to latest glibc will help Best Regards Gordon From mi@imarko.dhs.org Thu Sep 16 16:25:27 1999 Date: Thu Sep 16 16:25:27 1999 From: Istvan Marko mi@imarko.dhs.org Subject: ANA-62044? Our vendor has just surprised us with an ANA-62044 instead of the trusty old ANA-6944. Is anyone familiar with this card? Should we just return it or is there any hope for it? The card has four chips labelled AIC-6915P that look somewhat like the Tulip chips used on the 6944. Please let me know if you'd like me to provide more info... Thanks, -- Istvan From becker@cesdis1.gsfc.nasa.gov Thu Sep 16 16:55:47 1999 Date: Thu Sep 16 16:55:47 1999 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: ANA-62044? On 16 Sep 1999, Istvan Marko wrote: > Our vendor has just surprised us with an ANA-62044 instead of the > trusty old ANA-6944. Is anyone familiar with this card? Should we just > return it or is there any hope for it? > > The card has four chips labelled AIC-6915P that look somewhat like the > Tulip chips used on the 6944. Please let me know if you'd like me to > provide more info... Ask Adaptec -- they now claim to support Linux. Report their answer here for our amusement. Then get starfire.c from http://cesdis.gsfc.nasa.gov/linux/drivers/kern-2.3/index.html ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3/ or http://cesdis.gsfc.nasa.gov/linux/drivers/ethercard.html ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/test/starfire.c 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 mi@imarko.dhs.org Thu Sep 16 18:28:06 1999 Date: Thu Sep 16 18:28:06 1999 From: Istvan Marko mi@imarko.dhs.org Subject: ANA-62044? Donald Becker writes: > On 16 Sep 1999, Istvan Marko wrote: > > > Our vendor has just surprised us with an ANA-62044 instead of the > > trusty old ANA-6944. Is anyone familiar with this card? Should we just > > return it or is there any hope for it? [...] > Ask Adaptec -- they now claim to support Linux. > Report their answer here for our amusement. Heh, why didn't I think of that ;-/ > Then get starfire.c from > http://cesdis.gsfc.nasa.gov/linux/drivers/kern-2.3/index.html > ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3/ > or > http://cesdis.gsfc.nasa.gov/linux/drivers/ethercard.html > ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/test/starfire.c Donald, is there a network card you haven't yet written a driver for? The work you put into this stuff truly amazes me. You just keep churning out one high quality driver after the other. The starfire driver works great so far, using ttcp I got 11450KB/sec between the ANA-62044 and an EEpro-100, I could just smell the wires burning! Thanks! PS: Is there a more appropriate forum for starfire users? The page mentioned in starfire.c (http://cesdis.gsfc.nasa.gov/linux/drivers/starfire.html) doesn't seem to exist. -- Istvan From arcane@verinet.com Fri Sep 17 01:33:06 1999 Date: Fri Sep 17 01:33:06 1999 From: Bryan Stillwell arcane@verinet.com Subject: Problems with LNE100TX On Thu, 16 Sep 1999, Donald Becker wrote: > On Wed, 15 Sep 1999, Bryan Stillwell wrote: > > > It looks like the time before I didn't do an 'insmod pci-netif.o' before > > the 'insmod tulip.o', but when I do do this I still get an error message. > > The message is 'tulip.o: unresolved symbol pci_drv_unregister'. The > > Doh! > > I didn't do a EXPORT_SYMBOL_NOVERS(pci_drv_unregister) > > I didn't catch this before because it only matters with some kernel versions > combined with some module options. > > Now fixed. > ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3/pci-netif.c > http://cesdis.gsfc.nasa.gov/linux/drivers/kern-2.3/index.html That did the trick! Thanks a ton!!! It even works quite a bit better than the Windoze driver does! Yes! I'm going to test it for the couple of weeks to see if I want to buy more of these babies at only $20 a piece. :) Bryan From mob-rules@home.com Fri Sep 17 09:09:43 1999 Date: Fri Sep 17 09:09:43 1999 From: MOB-RULES mob-rules@home.com Subject: The new tulip and compile problems I downloaded everything and stuck them into a separate directory and did a make. Seems I can't get it to compile anything as the very first 3c59x.c has too many warnings and it reports make: *** [3c59x.o] Error 1 How am I suppose to accomplish the make? Thanks From zivago@ziff.net Fri Sep 17 19:09:58 1999 Date: Fri Sep 17 19:09:58 1999 From: Zivago 'Jaeman' Lee zivago@ziff.net Subject: The new tulip and compile problems Hm, that drive seems to be for the 3COM 3c59x cards. If you are sure you have a tulip card, you don't have to compile that driver in at all. On Fri, 17 Sep 1999, MOB-RULES wrote: > I downloaded everything and stuck them into a separate directory and did > a make. Seems I can't get it to compile anything as the very first > 3c59x.c has too many warnings and it reports make: *** [3c59x.o] Error 1 > > How am I suppose to accomplish the make? > > Thanks > From mob-rules@home.com Fri Sep 17 20:03:19 1999 Date: Fri Sep 17 20:03:19 1999 From: MOB-RULES mob-rules@home.com Subject: The new tulip and compile problems I do not, I have a Linksys with the PNIC I chip and up to this version of tulip I have not had problems. Since this is the "wave of the future" I need to be able to compile this sucker with all of the intended parts. Zivago 'Jaeman' Lee wrote: > Hm, that drive seems to be for the 3COM 3c59x cards. If you are sure you > have a tulip card, you don't have to compile that driver in at all. > > On Fri, 17 Sep 1999, MOB-RULES wrote: > > > I downloaded everything and stuck them into a separate directory and did > > a make. Seems I can't get it to compile anything as the very first > > 3c59x.c has too many warnings and it reports make: *** [3c59x.o] Error 1 > > > > How am I suppose to accomplish the make? > > > > Thanks > > From hui@alum.mit.edu Sat Sep 18 03:47:34 1999 Date: Sat Sep 18 03:47:34 1999 From: Michael Hui hui@alum.mit.edu Subject: Isolated disconnection Hi, I have a MIPS box that runs a linux 2.0.33 kernel. This box apparently uses a modified version of tulip.c version 0.79, (modified to work with the box, I guess). I ran into a strange problem and I would like to know if anyone have experienced it before. I'm not exactly sure if it is the kernel or the driver. I'm running some tests between the MIPS box and a PC running RH6.0. After running the test for a while (15 minutes or longer), these two machines stop talking to each other. However, I can connect to either one of these machines from another machine on the network. When I do a ping from the PC to the MIPS box, I saw that the packet goes to the MIPS box and then a reply gets sent to the PC. However, the PC doesn't see it. My application sets up some IP aliases on the MIPS box. If I bring any of the aliases down, the connection between these two machines resumes. Also, when this happens, I always see a connection in the SYNC_RECV state on the MIPS box using netstat. Anyone seen this before or have any idea how I can solve this problem ? Thanks. Mike From mulin@lisco.net Tue Sep 21 02:14:14 1999 Date: Tue Sep 21 02:14:14 1999 From: Mike Ulin mulin@lisco.net Subject: unrecognized card Hello, My name is Mike Ulin. I have a Linksys EtherFast card model #LNE100TX and am having trouble getting the tulip module to work with it. I am running redhat 5.2 secure server edition. I have followed the directions on your webpage to compile and install, but I get a message tulip.o: tulip.o: No such file or directory. I don't know where it goes after I compile it. If you can help please reply. Thank you. From arcane@verinet.com Tue Sep 21 10:55:49 1999 Date: Tue Sep 21 10:55:49 1999 From: Bryan Stillwell arcane@verinet.com Subject: unrecognized card On Mon, 20 Sep 1999, Mike Ulin wrote: > Hello, > My name is Mike Ulin. I have a Linksys EtherFast card model > #LNE100TX and am having trouble getting the tulip module to work with > it. I am running redhat 5.2 secure server edition. I have followed the > directions on your webpage to compile and install, but I get a message > tulip.o: tulip.o: No such file or directory. I don't know where it goes > after I compile it. If you can help please reply. Thank you. Just to help clear things up, I have a few questions for you first. What version of tulip.c do you have? It will usually say near the top of the file and look something like this: static const char version[] = "tulip.c:v0.91 4/14/99 becker@cesdis.gsfc.nasa.gov\n"; If you have a version that is within the last couple of months like this one that came out about a week ago, you'll also need pci-netif.c. static const char version[] = "tulip.c:v0.91m 9/15/99 becker@cesdis.gsfc.nasa.gov\n"; What is the command you are using to compile the tulip.c file? You'll find it near the end of the source code. It'll look like: * compile-command: "gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -c tulip.c `[ -f /usr/include/linux/modversions.h ] && echo -DMODVERSIONS`" Also you might want to download and compile this file: http://cesdis.gsfc.nasa.gov/linux/diag/tulip-diag.c That way you can tell what chip your card really has on it. Mine had the PNIC II chip, but sometimes they have the plain PNIC chip on them. Any other info that you think would help us solve your problem, then please send that info too. Bryan From rdynes@varcom.com Thu Sep 23 12:43:08 1999 Date: Thu Sep 23 12:43:08 1999 From: Richard Dynes rdynes@varcom.com Subject: eth0: Tx hung, 7 vs. 0. Hello... I thought I would post this here before the l-l list... I've just jumped from Linux 2.3.11 to Linux 2.3.18ac8, to try out the new tulip.c v0.91m. I'm have a couple of problems, but I need suggestions on just this first one, and then I'll work on the rest. First, my situation: H/W Configuration: Ziatech 5521 with two on-board Tulip 21143's, Tx interface. eth0 and eth1 Znyx 414 or something: quad Tulip 21143, Tx (copper) interface. eth2 - eth5 Osicom dual Tulip (not sure what kind) 100Base Fx. eth6 and eth7 Previously: Linux 2.3.11, with tulip.c:v0.91 4/14/99 as a module I was able to use the on-board tulip interfaces without any problems: ifconfig up down, all around. No issues. The quad board I had to be less free with. I wasn't able to get the Fx board going easily, but I didn't spend much time on it. The tulip driver _would_ recognize all 8 tulip chips, and assign logical names to them, eg eth0 - eth7. Currently: Linux 2.3.18ac8 ==> tulip.c:v0.91m 9/15/99, as a module Problem: I cannot use eth0- I get the following repeating error: > Sep 23 11:54:45 probe2 kernel: eth0: Tx hung, 7 vs. 0. When I take the _same_ cable, and move it over to the (also on-board) eth1 port, things work just fine, I can ifconfig the interface, telnet to it, etc. Everything appears as normal. I've never had the experience of the two port behaving differently: they're the same chips, same interfaces, on the same processor. So what gives? Suggestions? Thanks for any help.... -Richard Here's some output from lspci, tulip-diag, and ifconfig with eth0 and eth1 'up': lspci: 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 02) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 02) 00:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 00:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) 00:08.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 02) 00:0c.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 02) 01:00.0 VGA compatible controller: Cirrus Logic GD 5465 [Laguna] (rev 03) 02:09.0 SCSI storage controller: Adaptec AIC-7880U (rev 01) 02:0a.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) 02:0b.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 02) 02:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 02) 03:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 03:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 03:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 03:07.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 04:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 30) 04:07.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 30) 05:00.0 Network controller: Brooktree Corporation Bt8474 (rev 02) 05:00.1 Bridge: Brooktree Corporation Bt8474 (rev 02) tulip-diag: [root@probe2 tulip_diag]# ./tulip-diag tulip-diag.c:v1.14 9/19/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0x1080. 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. Interrupt sources are pending! CSR5 is f0678006. Tx complete indication. Tx out of buffers indication. The NWay status register is 000000c6. Internal autonegotiation state is 'Autonegotiation disabled'. Index #2: Found a Digital DS21143 Tulip adapter at 0x1400. 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. The NWay status register is 000000c6. Internal autonegotiation state is 'Autonegotiation disabled'. Index #3: Found a Digital DS21143 Tulip adapter at 0x3000. 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. The NWay status register is 000022c6. Internal autonegotiation state is 'Ability detect'. Index #4: Found a Digital DS21143 Tulip adapter at 0x3080. 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. The NWay status register is 000020c6. Internal autonegotiation state is 'Ability detect'. Index #5: Found a Digital DS21143 Tulip adapter at 0x3400. 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. The NWay status register is 000020c6. Internal autonegotiation state is 'Ability detect'. Index #6: Found a Digital DS21143 Tulip adapter at 0x3480. 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. The NWay status register is 000020c6. Internal autonegotiation state is 'Ability detect'. Index #7: Found a Digital DS21143 Tulip adapter at 0x4000. Port selection is MII, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. The NWay status register is 000000c6. Internal autonegotiation state is 'Autonegotiation disabled'. Index #8: Found a Digital DS21143 Tulip adapter at 0x4080. Port selection is MII, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. The NWay status register is 000000c6. Internal autonegotiation state is 'Autonegotiation disabled'. ifconfig: [root@probe2 tulip_diag]# ifconfig eth0 Link encap:Ethernet HWaddr 00:80:50:01:1E:A9 inet addr:10.10.10.1 Bcast:10.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:24 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:10 Base address:0x1000 eth1 Link encap:Ethernet HWaddr 00:80:50:01:1E:AA inet addr:205.xxx.xxx.61 Bcast:205.xxx.xxx.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:204000 errors:0 dropped:6 overruns:0 frame:0 TX packets:747 errors:0 dropped:0 overruns:0 carrier:0 collisions:104 txqueuelen:100 Interrupt:5 Base address:0x3400 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:64 errors:0 dropped:0 overruns:0 frame:0 TX packets:64 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 -- Richard Dynes rdynes@varcom.com From becker@cesdis1.gsfc.nasa.gov Thu Sep 23 13:33:58 1999 Date: Thu Sep 23 13:33:58 1999 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: eth0: Tx hung, 7 vs. 0. On Thu, 23 Sep 1999, Richard Dynes wrote: > I've just jumped from Linux 2.3.11 to Linux 2.3.18ac8, to try out the > new tulip.c v0.91m. You can get the same code for earlier kernels at http://cesdis.gsfc.nasa.gov/linux/drivers/kern-2.3/index.html ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3/ > Ziatech 5521 with two on-board Tulip 21143's, Tx interface. eth0 and > eth1 A multiport board? Oh, I looked it up on the web. What was the detection message? Specifically, did the driver find an EEPROM on both interfaces? > Znyx 414 or something: quad Tulip 21143, Tx (copper) interface. eth2 - > eth5 > Osicom dual Tulip (not sure what kind) 100Base Fx. eth6 and eth7 SYM or MII transceiver? > The tulip driver _would_ recognize all 8 tulip chips, and assign > logical names to them, eg eth0 - eth7. > I cannot use eth0- I get the following repeating error: > > > Sep 23 11:54:45 probe2 kernel: eth0: Tx hung, 7 vs. 0. > tulip-diag.c:v1.14 9/19/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > Index #1: Found a Digital DS21143 Tulip adapter at 0x1080. ... > Interrupt sources are pending! CSR5 is f0678006. Ouch! The interrupt line isn't working. What is the detection message? What interrupts are assigned according to /proc/pci? 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 rdynes@varcom.com Thu Sep 23 15:18:49 1999 Date: Thu Sep 23 15:18:49 1999 From: Richard Dynes rdynes@varcom.com Subject: eth0: Tx hung, 7 vs. 0. Hello, Sorry for taking so long- I went out to lunch.... Donald Becker wrote: > > On Thu, 23 Sep 1999, Richard Dynes wrote: > > > I've just jumped from Linux 2.3.11 to Linux 2.3.18ac8, to try out the > > new tulip.c v0.91m. > > You can get the same code for earlier kernels at > http://cesdis.gsfc.nasa.gov/linux/drivers/kern-2.3/index.html > ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3/ > After I send this, I'll get one for 2.3.11, and give it a spin. > > Ziatech 5521 with two on-board Tulip 21143's, Tx interface. eth0 and > > eth1 > > A multiport board? Oh, I looked it up on the web. > What was the detection message? > Specifically, did the driver find an EEPROM on both interfaces? > This is the output from insmod for eth0, eth1. Note no eth6 or eth7 (I was wrong in my original email, as I note below): from /var/log/messages: Sep 23 10:59:39 probe2 kernel: tulip.c:v0.91m 9/15/99 becker@cesdis.gsfc.nasa.go v Sep 23 10:59:39 probe2 kernel: eth0: Digital DS21143 Tulip rev 65 at 0xd0041000, 00:80:50:01:1E:A9, IRQ 10. Sep 23 10:59:39 probe2 kernel: eth0: EEPROM default media type Autosense. Sep 23 10:59:39 probe2 kernel: eth0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. Sep 23 10:59:39 probe2 kernel: eth0: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. Sep 23 10:59:39 probe2 kernel: eth0: Index #2 - Media 10base2 (#1) described by a 21142 Serial PHY (2) block. Sep 23 10:59:39 probe2 kernel: eth0: Index #3 - Media AUI (#2) described by a 2 1142 Serial PHY (2) block. Sep 23 10:59:39 probe2 kernel: eth0: Index #4 - Media MII (#11) described by a 21142 MII PHY (3) block. Sep 23 10:59:39 probe2 kernel: eth0: MII transceiver #0 config 1000 status 782d advertising 0061. Sep 23 10:59:39 probe2 kernel: eth1: Digital DS21143 Tulip rev 65 at 0xd0043400, 00:80:50:01:1E:AA, IRQ 5. Sep 23 10:59:39 probe2 kernel: eth1: EEPROM default media type Autosense. Sep 23 10:59:39 probe2 kernel: eth1: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. Sep 23 10:59:39 probe2 kernel: eth1: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. Sep 23 10:59:39 probe2 kernel: eth1: Index #2 - Media 10base2 (#1) described by a 21142 Serial PHY (2) block. Sep 23 10:59:39 probe2 kernel: eth1: Index #3 - Media AUI (#2) described by a 2 1142 Serial PHY (2) block. Sep 23 10:59:39 probe2 kernel: eth1: Index #4 - Media MII (#11) described by a 21142 MII PHY (3) block. Sep 23 10:59:39 probe2 kernel: eth1: MII transceiver #0 config 1000 status 782d advertising 0061. Sep 23 10:59:39 probe2 kernel: eth2: Digital DS21143 Tulip rev 65 at 0xd0045000, 00:C0:95:E0:7F:2C, IRQ 5. Sep 23 10:59:39 probe2 kernel: eth2: EEPROM default media type Autosense. Sep 23 10:59:39 probe2 kernel: eth2: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. Sep 23 10:59:39 probe2 kernel: eth2: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. Sep 23 10:59:39 probe2 kernel: eth2: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. Sep 23 10:59:39 probe2 kernel: eth2: Index #3 - Media 100baseTx-FD (#5) describ ed by a 21143 SYM PHY (4) block. Sep 23 10:59:39 probe2 kernel: eth3: Digital DS21143 Tulip rev 65 at 0xd0047400, 00:C0:95:E0:7F:2D, IRQ 9. Sep 23 10:59:39 probe2 kernel: eth3: EEPROM default media type Autosense. Sep 23 10:59:39 probe2 kernel: eth3: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. Sep 23 10:59:39 probe2 kernel: eth3: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. Sep 23 10:59:39 probe2 kernel: eth3: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. Sep 23 10:59:39 probe2 kernel: eth3: Index #3 - Media 100baseTx-FD (#5) describ ed by a 21143 SYM PHY (4) block. Sep 23 10:59:39 probe2 kernel: eth4: Digital DS21143 Tulip rev 65 at 0xd0049800, 00:C0:95:E0:7F:2E, IRQ 11. Sep 23 10:59:39 probe2 kernel: eth4: EEPROM default media type Autosense. Sep 23 10:59:39 probe2 kernel: eth4: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. Sep 23 10:59:39 probe2 kernel: eth4: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. Sep 23 10:59:39 probe2 kernel: eth4: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. Sep 23 10:59:39 probe2 kernel: eth4: Index #3 - Media 100baseTx-FD (#5) describ ed by a 21143 SYM PHY (4) block. Sep 23 10:59:39 probe2 kernel: eth5: Digital DS21143 Tulip rev 65 at 0xd004bc00, 00:C0:95:E0:7F:2F, IRQ 10. Sep 23 10:59:39 probe2 kernel: eth5: EEPROM default media type Autosense. Sep 23 10:59:39 probe2 kernel: eth5: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. Sep 23 10:59:39 probe2 kernel: eth5: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. Sep 23 10:59:39 probe2 kernel: eth5: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. Sep 23 10:59:39 probe2 kernel: eth5: Index #3 - Media 100baseTx-FD (#5) describ ed by a 21143 SYM PHY (4) block. Sep 23 11:00:13 probe2 kernel: eth0: Tx hung, 7 vs. 0. Sep 23 11:00:46 probe2 kernel: eth1: Setting full-duplex based on MII#0 link par tner capability of 01e1. Sep 23 11:04:07 probe2 kernel: eth1: Promiscuous mode enabled. Sep 23 11:04:07 probe2 kernel: device eth1 entered promiscuous mode Sep 23 11:04:26 probe2 kernel: eth1: Promiscuous mode enabled. Sep 23 11:04:26 probe2 kernel: device eth1 left promiscuous mode Sep 23 11:15:46 probe2 kernel: eth1: Setting half-duplex based on MII#0 link par tner capability of 0021. Sep 23 11:52:45 probe2 kernel: eth0: Tx hung, 5 vs. 0. Sep 23 11:53:33 probe2 kernel: eth0: Promiscuous mode enabled. Sep 23 11:53:33 probe2 kernel: device eth0 entered promiscuous mode Sep 23 11:53:45 probe2 kernel: eth0: Tx hung, 7 vs. 0. Sep 23 11:54:45 probe2 kernel: eth0: Tx hung, 7 vs. 0. Sep 23 11:56:45 probe2 last message repeated 2 times .... Note that eth6 and eth7 aren't detected (!) > > Znyx 414 or something: quad Tulip 21143, Tx (copper) interface. eth2 - > > eth5 > > Osicom dual Tulip (not sure what kind) 100Base Fx. eth6 and eth7 > > SYM or MII transceiver? > I'll find out. > > The tulip driver _would_ recognize all 8 tulip chips, and assign > > logical names to them, eg eth0 - eth7. Now I'm confusing myself: I guess that lspci saw the chips, so I assumed tulip would as well... I can't configure the interfaces: [root@probe2 log]# ifconfig eth6 10.11.10.1 SIOCSIFADDR: No such device eth6: unknown interface: No such device > > I cannot use eth0- I get the following repeating error: > > > > > Sep 23 11:54:45 probe2 kernel: eth0: Tx hung, 7 vs. 0. > > > tulip-diag.c:v1.14 9/19/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > > Index #1: Found a Digital DS21143 Tulip adapter at 0x1080. > ... > > Interrupt sources are pending! CSR5 is f0678006. > > Ouch! The interrupt line isn't working. > > What is the detection message? Is the output from the insmod the detection message? If so it's all above. If not, give me some guidance on what to do. > What interrupts are assigned according to /proc/pci? > cat /proc/pci PCI devices found: Bus 0, device 0, function 0: Host bridge: Intel 440BX - 82443BX Host (rev 2). Master Capable. Latency=64. Prefetchable 32 bit memory at 0xf8000000 [0xfbffffff]. Bus 0, device 1, function 0: PCI bridge: Intel 440BX - 82443BX AGP (rev 2). Master Capable. Latency=128. Min Gnt=140. Bus 0, device 5, function 0: Ethernet controller: DEC DC21142 (rev 65). IRQ 10. Master Capable. Latency=165. Min Gnt=20.Max Lat=40. I/O at 0x1080 [0x10ff]. Non-prefetchable 32 bit memory at 0xf0000000 [0xf00003ff]. Bus 0, device 6, function 0: Ethernet controller: DEC DC21142 (#2) (rev 65). IRQ 5. Master Capable. Latency=165. Min Gnt=20.Max Lat=40. I/O at 0x1400 [0x147f]. Non-prefetchable 32 bit memory at 0xf0000400 [0xf00007ff]. Bus 3, device 4, function 0: Ethernet controller: DEC DC21142 (#3) (rev 65). IRQ 5. Master Capable. Latency=165. Min Gnt=20.Max Lat=40. I/O at 0x3000 [0x307f]. Non-prefetchable 32 bit memory at 0xf4100000 [0xf41003ff]. Bus 3, device 5, function 0: Ethernet controller: DEC DC21142 (#4) (rev 65). IRQ 9. Master Capable. Latency=165. Min Gnt=20.Max Lat=40. I/O at 0x3080 [0x30ff]. Non-prefetchable 32 bit memory at 0xf4100400 [0xf41007ff]. Bus 3, device 6, function 0: Ethernet controller: DEC DC21142 (#5) (rev 65). IRQ 11. Master Capable. Latency=165. Min Gnt=20.Max Lat=40. I/O at 0x3400 [0x347f]. Non-prefetchable 32 bit memory at 0xf4100800 [0xf4100bff]. Bus 3, device 7, function 0: Ethernet controller: DEC DC21142 (#6) (rev 65). IRQ 10. Master Capable. Latency=165. Min Gnt=20.Max Lat=40. I/O at 0x3480 [0x34ff]. Non-prefetchable 32 bit memory at 0xf4100c00 [0xf4100fff]. Bus 4, device 4, function 0: Ethernet controller: DEC DC21142 (#7) (rev 48). IRQ 9. Master Capable. Latency=165. Min Gnt=20.Max Lat=40. I/O at 0x4000 [0x407f]. Non-prefetchable 32 bit memory at 0xf4200000 [0xf420007f]. Bus 4, device 7, function 0: Ethernet controller: DEC DC21142 (#8) (rev 48). IRQ 5. Master Capable. Latency=165. Min Gnt=20.Max Lat=40. I/O at 0x4080 [0x40ff]. Non-prefetchable 32 bit memory at 0xf4200400 [0xf420047f]. Bus 0, device 7, function 0: ISA bridge: Intel 82371AB PIIX4 ISA (rev 2). Bus 0, device 7, function 1: IDE interface: Intel 82371AB PIIX4 IDE (rev 1). Master Capable. Latency=64. I/O at 0x1050 [0x105f]. Bus 0, device 7, function 2: USB Controller: Intel 82371AB PIIX4 USB (rev 1). IRQ 9. Master Capable. Latency=64. I/O at 0x1060 [0x107f]. Bus 0, device 7, function 3: Bridge: Intel 82371AB PIIX4 ACPI (rev 2). Bus 0, device 8, function 0: PCI bridge: DEC DC21154 (rev 2). Master Capable. Latency=64. Min Gnt=4. Bus 0, device 12, function 0: PCI bridge: DEC DC21154 (#2) (rev 2). Master Capable. Latency=64. Min Gnt=4. Bus 1, device 0, function 0: VGA compatible controller: Cirrus Logic Laguna 3DA (rev 3). IRQ 11. Master Capable. Latency=128. Min Gnt=16.Max Lat=16. Non-prefetchable 32 bit memory at 0xf2000000 [0xf3ffffff]. Non-prefetchable 32 bit memory at 0xf0100000 [0xf010ffff]. Bus 2, device 9, function 0: SCSI storage controller: Adaptec AIC-7880U (rev 1). IRQ 10. Master Capable. Latency=64. Min Gnt=8.Max Lat=8. I/O at 0x2000 [0x20ff]. Non-prefetchable 32 bit memory at 0xf4000000 [0xf4000fff]. Bus 2, device 10, function 0: PCI bridge: DEC DC21152 (rev 3). Master Capable. Latency=64. Min Gnt=4. Bus 2, device 11, function 0: PCI bridge: DEC DC21152 (#2) (rev 2). Master Capable. Latency=64. Min Gnt=4. warning: page-size limit reached! ========================= I'll go and try the drivers you referred to at the top of the message on 2.3.11... -Richard -- Richard Dynes rdynes@varcom.com From cbrown@denalics.net Thu Sep 23 20:23:42 1999 Date: Thu Sep 23 20:23:42 1999 From: Christopher E. Brown cbrown@denalics.net Subject: eth0: Tx hung, 7 vs. 0. On Thu, 23 Sep 1999, Richard Dynes wrote: > > Hello... > > I thought I would post this here before the l-l list... > > I've just jumped from Linux 2.3.11 to Linux 2.3.18ac8, to try out the > new tulip.c v0.91m. I have had hang problems with v91g with *both* 21140 and 21143 boards under heavy use on AWARD bios (AMI bios seems to work fine), v91 no problems at all. --- As folks might have suspected, not much survives except roaches, and they don't carry large enough packets fast enough... --About the Internet and nuclear war. From simon@iweb.net.au Thu Sep 23 23:15:51 1999 Date: Thu Sep 23 23:15:51 1999 From: Simon Lindsay simon@iweb.net.au Subject: eth0: Tx hung, 7 vs. 0. On Thu, 23 Sep 1999, Christopher E. Brown wrote: > > I've just jumped from Linux 2.3.11 to Linux 2.3.18ac8, to try out the > > new tulip.c v0.91m. > I have had hang problems with v91g with *both* 21140 and 21143 > boards under heavy use on AWARD bios (AMI bios seems to work fine), > v91 no problems at all. We're got some boxes with high ide load, and they seem to have problems with .91e, whereas the scsi based boxes work fine with it. I've gone back to .91 yesterday to see how that goes. Simon Lindsay simon@iweb.net.au Technical Manager Icq. 1485568 The Internet Company Pty. Ltd. http://www.iweb.net.au/~simon InterWeb Connections and Portal.net Ph. (08) 8221 5444 ------- Speed with Service -------- Fx. (08) 8221 5450 From cbrown@denalics.net Fri Sep 24 17:32:38 1999 Date: Fri Sep 24 17:32:38 1999 From: Christopher E. Brown cbrown@denalics.net Subject: eth0: Tx hung, 7 vs. 0. On Fri, 24 Sep 1999, Simon Lindsay wrote: > On Thu, 23 Sep 1999, Christopher E. Brown wrote: > > > > I've just jumped from Linux 2.3.11 to Linux 2.3.18ac8, to try out the > > > new tulip.c v0.91m. > > I have had hang problems with v91g with *both* 21140 and 21143 > > boards under heavy use on AWARD bios (AMI bios seems to work fine), > > v91 no problems at all. > > We're got some boxes with high ide load, and they seem to have problems > with .91e, whereas the scsi based boxes work fine with it. I've gone back > to .91 yesterday to see how that goes. I would not know about IDE specific stuff, none of our internal boxes are less than UltraSCSI units. We sell office servers (IDE and SCSI based), and have had trouble with anything later than 91 on AWARD BIOS. 91 however works very well, even on a box with 3 quad cards --- As folks might have suspected, not much survives except roaches, and they don't carry large enough packets fast enough... --About the Internet and nuclear war. From carlos@torroja.dmt.upm.es Sat Sep 25 07:35:05 1999 Date: Sat Sep 25 07:35:05 1999 From: carlos@torroja.dmt.upm.es carlos@torroja.dmt.upm.es Subject: tulip.c compiling problems I have got this problem compiling tulip.c on a DS10: I get some warnings and can not find tulip.o. The warnings are: [root@babieca modules]# gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -c tulip.c `[ -f /usr/include/linux/modversions.h ] && echo -DMODVERSIONS` In file included from /usr/include/asm/semaphore.h:11, from /usr/include/linux/fs.h:163, from /usr/include/linux/capability.h:13, from /usr/include/linux/binfmts.h:5, from /usr/include/linux/sched.h:8, from tulip.c:118: /usr/include/asm/current.h:4: global register variable follows a function defini tion /usr/include/asm/current.h:4: warning: call-clobbered register used for global r egister variable tulip.c: In function `tulip_timer': tulip.c:1866: warning: `mleaf' might be used uninitialized in this function tulip.c:1867: warning: `p' might be used uninitialized in this function Thanks, Carlos From rdynes@varcom.com Mon Sep 27 09:42:03 1999 Date: Mon Sep 27 09:42:03 1999 From: Richard Dynes rdynes@varcom.com Subject: Osicom 2300C33FSC FYI: I was able to get the Osicom 2300C33FSC operating under Linux 2.3.11 tulip v0.91 with the following command: mii-diag eth[.] -F 100baseTx-FD That obviously set it up for 100baseFD operation. It may be possible for it to do things like 10baseHD, etc... I'll test those next week. If I can get a media converter, then I'll try it on a live network. Prior to doing that command, the board showed _no_ sign of working. -Richard -- Richard Dynes rdynes@varcom.com From dsf+@andrew.cmu.edu Tue Sep 28 13:40:22 1999 Date: Tue Sep 28 13:40:22 1999 From: David Sean Friedman dsf+@andrew.cmu.edu Subject: 21143 specific problems I've been having some problems with the tulip driver on 21143-based cards. The problem is that the cards seem unable to sustain more than 1 Mb/s on a 100 Mb link when transmitting tcp traffic. All other traffic has great performance. UDP traffic is ~90Mb/s in either direction, and receiving TCP traffic is ~60Mb/s. However, if I use a 21140-based SMC NIC, the TCP transmit traffic is ~60Mb/s. The setup I am using is as follows. Two PII's hooked up to an Intel 510T Switch, one with a tulip NIC, the other with an Intel EtherExpress100. I use ttcp to measure the performance of the tulip. The debug output from the tulip driver indicates that both tulip NICs were operating at full duplex. Switching to Intel NICs, or older tulips is not an option in the short term. Is there any way to achieve the same performance on the 21143 tulips? Thanks in advance for any insight, David Friedman Carnegie Mellon University From becker@cesdis1.gsfc.nasa.gov Tue Sep 28 15:35:21 1999 Date: Tue Sep 28 15:35:21 1999 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: 21143 specific problems On Tue, 28 Sep 1999, David Sean Friedman wrote: > I've been having some problems with the tulip driver on 21143-based > cards. The problem is that the cards seem unable to sustain more than 1 > Mb/s on a 100 Mb link when transmitting tcp traffic. What driver version? Only v0.91 and later does autonegotiation correctly when using a 21143 with a SYM mode transceiver that requires specific output value on the general-purpose pins. (Yes, that's a very specific set of conditions. Two years ago MII transceivers were the common connection type, and the older driver works correctly with them. The changes in the newer 21143 chips and the lower cost of SYM mode transceivers has made 21143+SYM designs popular.) > However, if I use a 21140-based SMC NIC, the TCP transmit traffic is ~60Mb/s. My guess is that the link partner is seeing the autonegotiation complete, but then isn't getting the 100Mbps link beat quickly enough. It then drops to speed-sensing mode and ends up with a 100baseTx half duplex link. Getting the updated driver should fix this problem. 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 dsf+@andrew.cmu.edu Tue Sep 28 16:25:06 1999 Date: Tue Sep 28 16:25:06 1999 From: David Sean Friedman dsf+@andrew.cmu.edu Subject: 21143 specific problems Excerpts from tulip: 28-Sep-99 Re: 21143 specific problems by Donald Becker@cesdis.gsf > What driver version? I've tried several versions. The default (0.89H?) included with 2.2.12, 0.91, and even the test version 0.91g. All exhibited the same problem. > > Only v0.91 and later does autonegotiation correctly when using a 21143 with > a SYM mode transceiver that requires specific output value on the > general-purpose pins. > > (Yes, that's a very specific set of conditions. Two years ago MII > transceivers were the common connection type, and the older driver works > correctly with them. The changes in the newer 21143 chips and the lower > cost of SYM mode transceivers has made 21143+SYM designs popular.) The output of the driver does indicate the NIC is 21143+SYM. > > > However, if I use a 21140-based SMC NIC, the TCP transmit traffic is ~60Mb/s. > > My guess is that the link partner is seeing the autonegotiation complete, > but then isn't getting the 100Mbps link beat quickly enough. It then drops > to speed-sensing mode and ends up with a 100baseTx half duplex link. > Getting the updated driver should fix this problem. My first thoughts were also that it was a half duplex problem, since I've seen similar results on some more inferior switches. However, the fact that TCP traffic in the other direction works fine leads me to believe the problem is elsewhere. I've also tried using 'options=16' to force full duplex mode. With or without this option, the driver reports 'Using NWay-set 100BaseTx-FD media' at every timeout, and throughput is unaffected. Is there any other way to diagnose this problem? Thanks, David Friedman From metod.kozelj@rzs-hm.si Wed Sep 29 01:40:14 1999 Date: Wed Sep 29 01:40:14 1999 From: Metod Kozelj metod.kozelj@rzs-hm.si Subject: 21143 specific problems Hello, On Tue, 28 Sep 1999, David Sean Friedman wrote: > > > However, if I use a 21140-based SMC NIC, the TCP transmit traffic is > ~60Mb/s. > > > > My guess is that the link partner is seeing the autonegotiation complete, > > but then isn't getting the 100Mbps link beat quickly enough. It then drops > > to speed-sensing mode and ends up with a 100baseTx half duplex link. > > Getting the updated driver should fix this problem. > > My first thoughts were also that it was a half duplex problem, since > I've seen similar results on some more inferior switches. However, the > fact that TCP traffic in the other direction works fine leads me to > believe the problem is elsewhere. I've had similar problems regarding performance of 21143-based NIC in FD mode. I solved it by using the NIC in HD mode. My setup: alpha linux with 2 NICs (21143 and 21140). One NIC is connected to some TrendNet 10/100 switch (FD link), second NIC is connected to 100TX hub. At first, I tried to link 21140 to hub and 21143 to switch. I got about 1.5MBps throughput through 21143. Then I changed setup so that 21140 is connected to switch and 21143 to hub. Now I'm getting transfers at >90% of wire speed on both connections. I'm using tulip.c v0.91 and kernel 2.2.12. I guess something's wrong with FD on 21143. 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 dsf+@andrew.cmu.edu Thu Sep 30 00:31:08 1999 Date: Thu Sep 30 00:31:08 1999 From: David Sean Friedman dsf+@andrew.cmu.edu Subject: 21143 specific problems Excerpts from tulip: 29-Sep-99 Re: 21143 specific problems by Metod Kozelj@rzs-hm.si > I've had similar problems regarding performance of 21143-based NIC in FD > mode. I solved it by using the NIC in HD mode. You're right. By forcing the NIC into half duplex mode, performance went up to ~80Mb/s. I was also surprised to see TCP receive performance improve from ~60 to ~80Mb/s in half duplex mode. Using half duplex should clearly not have better performance for TCP measurements. > > My setup: alpha linux with 2 NICs (21143 and 21140). One NIC is connected > to some TrendNet 10/100 switch (FD link), second NIC is connected to 100TX > hub. At first, I tried to link 21140 to hub and 21143 to switch. I got > about 1.5MBps throughput through 21143. Then I changed setup so that 21140 > is connected to switch and 21143 to hub. Now I'm getting transfers at >90% > of wire speed on both connections. I'm using tulip.c v0.91 and kernel > 2.2.12. > > I guess something's wrong with FD on 21143. Just out of curiousity, I tried using the de4x5 (alternative tulip) driver. It came up in half duplex mode by default, but TCP performance was wore (~65Mb/s I think). I'm not completely convinced FD is broken on the 21143. One thing I'd like to try tomorrow is connecting the two machines directly with a crossover cable, and setting them to 100Tx-FD. That should show whether this is a negotiation or FD problem. Thanks again, David Friedman From dsf+@andrew.cmu.edu Thu Sep 30 14:21:45 1999 Date: Thu Sep 30 14:21:45 1999 From: David Sean Friedman dsf+@andrew.cmu.edu Subject: 21143 specific problems Excerpts from tulip: 30-Sep-99 Re: 21143 specific problems by David Sean Friedman@andr > I'm not completely convinced FD is broken on the 21143. One thing I'd > like to try tomorrow is connecting the two machines directly with a > crossover cable, and setting them to 100Tx-FD. That should show whether > this is a negotiation or FD problem. I just finished this. By setting both the tulip and the eepro100 to 100baseTx-FD and connecting them with a crossover cable, both TCP and UDP performance were ~90Mb/s either transmitting or receiving. So I guess it's only a problem when autonegotiation is used. David Friedman