From billiejoe@home.net Sun Jan 31 21:20:23 1999 Date: Sun Jan 31 21:20:23 1999 From: Alan Jones billiejoe@home.net Subject: Accton en1102, more info Ok, i compiled the tulip driver as a module and using the info from Gerhard Wiesinger, forced it into 10baseT mode, now it is constantly spewinf error messages to my terminal reading: eth0: 21140 transmit timed out, status FC260400, SIA ffffff0b ffffffff 1c09fdc0 fffffec8 or eth0: 21140 transmit timed out, status FC260000, SIA ffffff0b ffffffff 1c09fdc0 fffffec8 ifconfig shows a climbing # of errors, 1 for each message, that dosent seem to stop, but with it as a module it sends some TX packets.. still no RX packets... >> Hi, >> I have a Accton en1207 card that has an old eeprom, it has a 21140-AC >> chipset, and it dosent seem to be working... I have the newest driver >> (.90f) installed and it detects it on boot, but when my box gets to the >> IPv4 packet forwarding part of it's boot, the computer sits for about 5 >> min, then the card reports that it is changing modes, then it goes on 2 >> mins later and complains about bad addresses. ifconfig reports about 1 >> TX error a second, no RX anything errors or packets... any >> suggestions??? >> > >I have two Accton EN1207 (without any extension, the one with BNC) working >under Linux. > >For further information: http://stud1.tuwien.ac.at/~e9125884/linux/ >> >> Thanks, >> Alan Jones From shrike@charm.il.fontys.nl Sun Jan 31 22:02:21 1999 Date: Sun Jan 31 22:02:21 1999 From: M.Brands shrike@charm.il.fontys.nl Subject: Accton Cheetah 10/100 PCI (EN1207D) On Mon, 1 Feb 1999, Peter Burns wrote: > I bought this card and I have been trying to get it to > work under linux without much success. > > I have compiled a module for the tulip driver (from > 2.0.34) but when I use "insmod tulip.o" it responds > with a message stating "device or resource busy". We have also have an Accton EN1207 (w/ BNC) and it has been working very well for over a year now. We're using the driver that comes standard with the kernel (0.89H) because I'm a bit lazy. I don't know what type the EN1207D is, but our EN1207 has a 21140-AC chipset. Could it be the problems you have are caused by the fact that the card has to share it's IRQ with another device? We had similar problems when the Accton EN1207 and an NCR 52c810 SCSI controller were sharing the same IRQ. Moving the NCR card to another slot solved the problem. Mathijs Ps. The info below probably isn't useful... It's an SMP machine, in case you were wondering about the use of IRQ 17. SMP machines have an extra IO APIC. ----------------------8<--------------------8<-------------------- tulip.c:v0.89H 5/23/98 becker@cesdis.gsfc.nasa.gov eth0: Digital DS21140 Tulip at 0x6500, 00 00 e8 2e 79 26, IRQ 17. eth0: Old format EEPROM on 'Accton EN1207' board. Using substitute media control info. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media 10base2 (#1) described by a 21140 non-MII (0) block. eth0: Index #1 - Media 100baseTx (#3) described by a 21140 non-MII (0) block. eth0: Index #2 - Media 10baseT (#0) described by a 21140 non-MII (0) block. From astromas@us.oracle.com Mon Feb 1 07:39:26 1999 Date: Mon Feb 1 07:39:26 1999 From: Aaron Stromas astromas@us.oracle.com Subject: libc6 and kernel 2.0.34 it started with my needing to compile the tulip drivers for my ethernet card. as i am running kernel version 2.0.34, i installed kernel-source-2.0.34 package. it turns out, it requires libc6 package which installs /usr/include/linux/version.h which defines UTS_RELEASE as "2.0.33"! furthermore, it was explained to me that /usr/include/linux should symlink into include/linux of the current source (in my case, 2.0.34) but libc6 package instead of symlinking /usr/include/linux creates a directory /usr/include/linux and populates it. how can i resolve those dependencies? another question is, the driver compilation instruction indicates that -I/usr/src/linux/net/inet chould be included. which package installs that directory? , -- Aaron Stromas | "Tick-tick-tick!!!... ja, Pantani is weg...." Oracle Corp. | BRTN commentator, L'Alpe d'Huez, 1995 Tour de France +1 703 917 48 72 | From astromas@us.oracle.com Mon Feb 1 11:54:17 1999 Date: Mon Feb 1 11:54:17 1999 From: Aaron Stromas astromas@us.oracle.com Subject: libc6 and kernel 2.0.34 well, i finally was able to compile the tulip driver and "depmod -a" didn't complain. i had to change the include path but perhaps it's due to the fact that my box is debian while the instructions are for red hat? unfortunately, i still can't use the card and dmesg returns eth0: Changing PNIC configuration to half-duplex, CSR6 0042c000 eth0: Changing PNIC configuration to half-duplex, CSR6 0186c000 what does it mean and what needs to be done to correct it? tia, Aaron Stromas wrote: > it started with my needing to compile the tulip drivers for my ethernet > card. as i am running kernel version 2.0.34, i installed > kernel-source-2.0.34 package. it turns out, it requires libc6 package > which installs /usr/include/linux/version.h which defines UTS_RELEASE as > "2.0.33"! > > furthermore, it was explained to me that /usr/include/linux should > symlink into include/linux of the current source (in my case, 2.0.34) > but libc6 package instead of symlinking /usr/include/linux creates a > directory /usr/include/linux and populates it. > > how can i resolve those dependencies? > > another question is, the driver compilation instruction indicates that > -I/usr/src/linux/net/inet chould be included. > which package installs that directory? > > , > > -- > Aaron Stromas | "Tick-tick-tick!!!... ja, Pantani is weg...." > Oracle Corp. | BRTN commentator, L'Alpe d'Huez, 1995 Tour > de France > +1 703 917 48 72 | -- Aaron Stromas | "Tick-tick-tick!!!... ja, Pantani is weg...." Oracle Corp. | BRTN commentator, L'Alpe d'Huez, 1995 Tour de France +1 703 917 48 72 | From pburns@firstdata.com.au Mon Feb 1 17:01:50 1999 Date: Mon Feb 1 17:01:50 1999 From: Peter Burns pburns@firstdata.com.au Subject: Accton Cheetah 10/100 PCI (EN1207D) "M.Brands" on 01/02/99 13:03:22 >We have also have an Accton EN1207 (w/ BNC) and it has been working very >well for over a year now. We're using the driver that comes standard with >the kernel (0.89H) because I'm a bit lazy. I don't know what type the >EN1207D is, but our EN1207 has a 21140-AC chipset. >Could it be the problems you have are caused by the fact that the card >has to share it's IRQ with another device? We had similar problems when >the Accton EN1207 and an NCR 52c810 SCSI controller were sharing the same >IRQ. Moving the NCR card to another slot solved the problem. I don't think its a conflict. The card is not detected at boot. It shows up in /proc/pci though. Here's its entry. Bus 0, device 9, function 0: Ethernet controller: Unknown vendor Unknown device (rev 16). Vendor id=1113. Device id=1211. Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=64. Min Gnt=32.Max Lat=64. I/O at 0xe400. Non-prefetchable 32 bit memory at 0xe6000000. I tried out tulip-diag with the following results. #./tulip-diag Unable to find a Tulip card in /proc/pci. If there is a Tulip card in the machine, explicitly set the I/O port address using '-p #./tulip-diag -p 0xe400 -a tulip-diag.c:v1.06 9/18/98 Donald Becker (becker@cesdis.gsfc.nasa.gov) Digital DC21040 Tulip Tulip chip registers at 0xe400: 6ce80000 00000008 00002000 00002000 00000000 00000000 00000000 0000fff0 70000000 072e2c2a 000d1000 0000e10c 1000000f 00000000 00000004 78fa8388 The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. Transmit stopped, Receive stopped, half-duplex. The transmit threshold is 72. Port selection is 10mpbs-serial, half-duplex. #./tulip-diag -p 0xe400 -e tulip-diag.c:v1.06 9/18/98 Donald Becker (becker@cesdis.gsfc.nasa.gov) #./tulip-diag -p 0xe400 -m tulip-diag.c:v1.06 9/18/98 Donald Becker (becker@cesdis.gsfc.nasa.gov) ***WARNING***: No MII transceivers found! >Mathijs >From what I can guess the card is not detected since it has a different vendor and device id. Hmmm ... While I was writing this I took a visit to Acctons home page at http://www.accton.com.tw and low and behold there's a linux driver for it just sitting there. I'll have to take it home and try it out. It wasn't on the disk that came with it. Peter Burns From billiejoe@home.net Mon Feb 1 17:34:57 1999 Date: Mon Feb 1 17:34:57 1999 From: Alan Jones billiejoe@home.net Subject: Accton en1102, more info nope, its not a MII trancever i dont think, tulip-diag and tulip driver id's it as a non-MII card, but if their is anotehr way to check, id look... Donald Becker wrote: > On Sun, 31 Jan 1999, Alan Jones wrote: > > > Ok, i compiled the tulip driver as a module and using the info from > > Gerhard Wiesinger, forced it into 10baseT mode, now it is constantly > > spewinf error messages to my terminal reading: > > eth0: 21140 transmit timed out, status FC260400, SIA ffffff0b ffffffff > > 1c09fdc0 fffffec8 > ... > > ifconfig shows a climbing # of errors, 1 for each message, that dosent > > seem to stop, but with it as a module it sends some TX packets.. still > > no RX packets... > > Does this board use a MII transceiver (which handles both 10 and 100mbps), > or a SYM mode transceiver (which uses the on-board 10baseT encoder for > 10mbps)? > > If it's an MII transceiver you must use MII mode, perhaps as media type #9, > "MII 10baseT". Nothing is attached to the on-board encoder, and the > transmitter will time out waiting for link beat. > > 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 shrike@charm.il.fontys.nl Mon Feb 1 19:18:19 1999 Date: Mon Feb 1 19:18:19 1999 From: M.Brands shrike@charm.il.fontys.nl Subject: Accton Cheetah 10/100 PCI (EN1207D) On Tue, 2 Feb 1999, Peter Burns wrote: > I don't think its a conflict. The card is not detected at boot. > It shows up in /proc/pci though. Here's its entry. > > Bus 0, device 9, function 0: > Ethernet controller: Unknown vendor Unknown device (rev 16). > Vendor id=1113. Device id=1211. > Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. > Latency=64. Min Gnt=32.Max Lat=64. > I/O at 0xe400. > Non-prefetchable 32 bit memory at 0xe6000000. Here's ours: Bus 0, device 19, function 0: Ethernet controller: DEC DC21140 (rev 32). Medium devsel. Fast back-to-back capable. IRQ 17. Master Capable. Latency=32. Min Gnt=20.Max Lat=40. I/O at 0x6500 [0x6501]. Non-prefetchable 32 bit memory at 0xe0001000 [0xe0001000]. Well, it seems to be a different card. I just looked op de vendor ID in de Linix 2.2 kernel source (include/linux/pci.h). It seems SMC2 is the vendor that goes with that ID. Also the, device ID identifies it as an 1211TX card made by SMC. The 2.2 kernel at least recognizes this card. Just checked the 2.0.36 source: it never heard of this card. I also checked the 2.1.126 source: same result. > I tried out tulip-diag with the following results. I've never tried these diag tools, so I'm afraid the output isn't telling me much. > #./tulip-diag -p 0xe400 -m > tulip-diag.c:v1.06 9/18/98 Donald Becker (becker@cesdis.gsfc.nasa.gov) > ***WARNING***: No MII transceivers found! The EN1207 we have also doesn't have a MII tranceiver. It uses some other, cheaper tranceiver. > >From what I can guess the card is not detected since it has a different > vendor and device id. > > Hmmm ... While I was writing this I took a visit to Acctons home page at > http://www.accton.com.tw and low and behold there's a linux driver > for it just sitting there. I'll have to take it home and try it > out. It wasn't on the disk that came with it. I think they'll give you a copy of the tulip driver, but I could ofcourse be wrong. They did point me to the right version when we were having trouble with our Accton. Maybe you could try booting from a diskette with a 2.2 kernel just to see if it recognizes your card. I have a suitable kernel, if you don't feel like upgrading to 2.2 right now. It could very well be that your card isn't detected because the IDs are unknown. On the other hand, maybe they've changed the chipset (although I doubt that). Sorry I can't be of more assistance. Mathijs From astromas@us.oracle.com Tue Feb 2 07:54:36 1999 Date: Tue Feb 2 07:54:36 1999 From: Aaron Stromas astromas@us.oracle.com Subject: are options needed for netgear 10/100 ethernet card? still trying to get my netgear card to work. it occurred to me that i may need to set options. is it true or false? if true, do i provide the required options through /etc/conf.modules? tia, -- Aaron Stromas | "Tick-tick-tick!!!... ja, Pantani is weg...." Oracle Corp. | BRTN commentator, L'Alpe d'Huez, 1995 Tour de France +1 703 917 48 72 | From astromas@us.oracle.com Tue Feb 2 10:32:00 1999 Date: Tue Feb 2 10:32:00 1999 From: Aaron Stromas astromas@us.oracle.com Subject: are options needed for netgear 10/100 ethernet card? --------------A592AFA4750D3AD62A72DCC0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Put the options in /etc/conf.modules only if you have it compiled in as a > module,but yes,you very well may need to pass options off to it. > -Jay > yes, i compiled the driver as a module. i'd very much appreciate a suggestion which options are needed, if any, for this particular card or a pointer where i should look for this information. i searched http://maximus.bmen.tulane.edu/~siekas/tulip.html as well other sites, so far, all in vain. -a > > Aaron Stromas wrote: > > > still trying to get my netgear card to work. it occurred to me that i > > may need to set options. is it true or false? > > if true, do i provide the required options through /etc/conf.modules? > > tia, > > > -- Aaron Stromas | "Tick-tick-tick!!!... ja, Pantani is weg...." Oracle Corp. | BRTN commentator, L'Alpe d'Huez, 1995 Tour de France +1 703 917 48 72 | --------------A592AFA4750D3AD62A72DCC0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Put the options in /etc/conf.modules only if you have it compiled in as a
module,but yes,you very well may need to pass options off to it.
-Jay


yes, i compiled the driver as a module. i'd very much appreciate a suggestion which options are needed, if any, for this particular card or a pointer where i should look for this information. i searched  http://maximus.bmen.tulane.edu/~siekas/tulip.html as well other sites, so far, all in vain.

-a 


Aaron Stromas wrote:

> still trying to get my netgear card to work. it occurred to me that i
> may need to set options. is it true or false?
> if true, do i provide the required options through /etc/conf.modules?
> tia,
>

--
Aaron Stromas     |   "Tick-tick-tick!!!... ja, Pantani is weg...."
Oracle Corp.        |       BRTN commentator, L'Alpe d'Huez, 1995 Tour de France
+1 703 917 48 72  |
  --------------A592AFA4750D3AD62A72DCC0-- From webnut@icx.net Tue Feb 2 22:10:09 1999 Date: Tue Feb 2 22:10:09 1999 From: webnut webnut@icx.net Subject: Accton Cheetah 10/100 PCI (EN1207D) I downloaded it. Here is the first few lines of MPX5030.C: /* Written 1997 by Donald Becker. This software may be used and distributed according to the terms of the GNU Public License, incorporated herein by reference. All other rights reserved. This driver is for boards based on the MPX5030 and MPX5038 PCI ethernet chips.(Accton EN1207D-TX and SMC EZ Card 10/100(SMC1211TX). ) */ static const char *version = "mpx5030.c:v0.13 10/27/97 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/mpx5030.html\n"; I wonder if there is anything unique to the Cheetah here? Bill Shirley > > > Hmmm ... While I was writing this I took a visit to Acctons home page at > > http://www.accton.com.tw and low and behold there's a linux driver > > for it just sitting there. I'll have to take it home and try it > > out. It wasn't on the disk that came with it. > From shrike@charm.il.fontys.nl Tue Feb 2 22:59:01 1999 Date: Tue Feb 2 22:59:01 1999 From: M.Brands shrike@charm.il.fontys.nl Subject: Accton Cheetah 10/100 PCI (EN1207D) On Tue, 2 Feb 1999, webnut wrote: > chips.(Accton EN1207D-TX and SMC EZ Card > 10/100(SMC1211TX). ) > I wonder if there is anything unique to the Cheetah here? I wonder if you can keep the Accton and the SMC card apart by looking at the vender and device ID. The Accton Cheetah returns vendor=SMC and device=1211TX. I assume the SMC EZ Card does too... Do these cards maybe share a common manufacturer? Mathijs From doo@shroom.com Wed Feb 3 02:08:01 1999 Date: Wed Feb 3 02:08:01 1999 From: Adam Crews doo@shroom.com Subject: Problems with LinkSys 10/100 cards Hello all, I have 2 machines both with 2 network cards in each. Machine A's eth0 is a Intel eepro 100 card, running at 10mb connected to a hub. It works fine. Machine B's eth0 is a Linksys pci ne2000 card that also is working fine. I added a Linksys 10/100 card to both machines as eth1 and have connected them together with a crossover cable. I am using the tulip.c:v0.90 version of the driver on a 2.0.36 kernel. I have tried the tulip.c:v0.90h version with the same results. Both host's eth1 get the errors: eth1: The transmitter stopped! CSR5 is 2678016, CSR6 812e2202. eth1: Changing PNIC configuration to full-duplex, CSR6 812e0200. This happens shortly after starting the network interface, then again a few more times in the first 5 minutes or so that the machine is up. Pinging from host A to host B I get no response back to host A. A tcpdump on host B shows: tcpdump: listening on eth1 23:07:34.306367 arp who-has 192.168.0.2 tell 192.168.0.1 23:07:34.306367 arp reply 192.168.0.2 is-at 0:a0:cc:25:58:c9 23:07:34.306367 192.168.0.1 > 192.168.0.2: icmp: echo request 23:07:35.306367 192.168.0.1 > 192.168.0.2: icmp: echo request 23:07:36.306367 211.192.168.0 > 1.192.168.0: (frag 21516:-20@4096) [ttl 0] 23:07:37.326367 209.192.168.0 > 1.192.168.0: (frag 21516:64@8192) [ttl 0] 23:07:38.326367 207.192.168.0 > 1.192.168.0: (frag 21516:-20@12288) [ttl 0] 23:07:39.326367 205.192.168.0 > 1.192.168.0: icmp: type-#2 A ping from host B to host a shows: [doo@www doo]$ ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=-238747.-2 ms wrong data byte #8 should be 0x8 but was 0x0 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 0 0 0 0 0 0 0 0 0 0 0 0 64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.4 ms wrong data byte #15 should be 0xf but was 0xe 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 0 0 0 0 0 0 0 0 0 0 0 0 --- 192.168.0.1 ping statistics --- 4 packets transmitted, 2 packets received, 50% packet loss round-trip min/avg/max = -238747.-2/214628991.4/0.4 ms A tcpdump on host A shows normal packet responses. 22:56:01.527554 192.168.0.2 > 192.168.0.1: icmp: echo request 22:56:01.527554 192.168.0.1 > 192.168.0.2: icmp: echo reply The tulip-diag tool on host A shows: [doo@doo doo]$ sudo ./tulip-diag -p 0xfc00 -f -a -D tulip-diag.c:v1.06 9/18/98 Donald Becker (becker@cesdis.gsfc.nasa.gov) Digital DC21040 Tulip Tulip chip registers at 0xfc00: 00008000 01ff0000 00450008 00096028 00096228 02660010 812e2202 0001ebef 00000000 00000000 00096288 00094ce4 00000020 00000000 00000000 10000001 The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. Transmit started, Receive started, full-duplex. The transmit unit is set to store-and-forward. Port selection is MII 100baseTx scrambler, full-duplex. and from B: [doo@www doo]$ sudo ./tulip-diag -p 0x6200 -a -f tulip-diag.c:v1.06 9/18/98 Donald Becker (becker@cesdis.gsfc.nasa.gov) Digital DC21040 Tulip Tulip chip registers at 0x6200: 00008000 01ff0000 01000608 0031e028 0031e228 02660010 812e2202 0001ebef 00000000 00000000 0031e308 0031e308 00000020 00000000 00000000 10000001 The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. Transmit started, Receive started, full-duplex. The transmit unit is set to store-and-forward. Port selection is MII 100baseTx scrambler, full-duplex. Both cards have the link light, FD light and 100mb light showing green on the back of the card. Why am I getting the ping errors above? How do I fix it? I have changed cables with proven good one's. I have swaped network cards between the machines and get the same results on the same machines (the problesm doesnt seem to follow the nic card). I have even replaced both nic cards with new ones (and do some mixing and matching to see if there was a posibility that 2 of the 4 nic hard I have are bad.) The problem remained the same. Does anyone have any idea as to what is happening, and why? Then how do I fix it? -Adam From briand@deldotd.com Wed Feb 3 12:43:14 1999 Date: Wed Feb 3 12:43:14 1999 From: Brian Denheyer briand@deldotd.com Subject: Problems with LinkSys 10/100 cards >>>>> "Adam" == Adam Crews writes: Adam> I added a Linksys 10/100 card to both machines as eth1 and Adam> have connected them together with a crossover cable. I am Adam> using the tulip.c:v0.90 version of the driver on a 2.0.36 Adam> kernel. I have tried the tulip.c:v0.90h version with the Adam> same results. Adam> Both host's eth1 get the errors: eth1: The transmitter Adam> stopped! CSR5 is 2678016, CSR6 812e2202. eth1: Changing Adam> PNIC configuration to full-duplex, CSR6 812e0200. Seems like everyone gets that "warning" including me. And by the way it is referred to as a warning, not an error, in the source. What I have noticed is that you have to have both machines up and running when you load the driver, or at any rate, that seems to help. I think that the cards do "auto-negotiation" for speed and so when there is nothing else to talk to when the driver activates the card it sort of just stops. In theory, one would think it would "start" again when the other computer fires up and that does seem to happen when I use win. When I use linux I have to ifconfig eth0 down, rmmod and then bring the eth0's back up to get things working... Not exactly convenient. The really bad news is that even when it works under Linux->Linux (2.0.36) the transfer rates stink (< 1 Mbyte/s). Then again they're not very good going from Win->Linux either, and I'm using a 7 ft cable. So I see two problems : A. the warning messages B. the crummy performance (< 1Mb/s) Could someone PLEASE direct me to a datasheet for the LC82C169 so that I can stop whining and get under the hood and fix this... I ain't afraid of device drivers, Donald's already done 100% of the work, that last 0% shouldn't be too bad :-) Also if someone could explain how option interpretation for the modules works that would be helpful. It would be nice for debugging purposes to add options which turned various debugging code on and off. In the meantime, Linksys Etherfast 10/100 cards should probably be avoided. Thanks Brian -- Brian Denheyer briand@deldotd.com Deldot Design, Inc. (503) 788-1607 __ \/.d = Electronic design and development From facanha@insoft.softex.br Wed Feb 3 13:03:07 1999 Date: Wed Feb 3 13:03:07 1999 From: Roberto de Almeida =?iso-8859-1?Q?Fa=E7anha?= facanha@insoft.softex.br Subject: Problems with Adaptec 10/100 cards Hello all, I'm the adm. of a university lab. All the microcomputers in this lab have Adaptec ANA 6911A/TX PCI Fast Ethernet cards based on the DEC 21143 processor. I'm trying to configure the cards in the linux kernel 2.0.35. When the systems start up, the tulip driver (tulip.c:v0.90 10/20/98 becker@cesdis.gsfc.nasa.gov) probes but can't initialize the cards properly. The output of the kernel module is: -------------------------------------------------------------------- tulip.c:v0.90 10/20/98 becker@cesdis.gsfc.nasa.gov eth0: Digital DS21143 Tulip at 0x6500, 00 00 d1 1b 3c bc, IRQ 10. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. eth0: Index #1 - Media 10base2 (#1) described by a 21142 Serial PHY (2) block eth0: MII transceiver #1 config 3100 status 7849 advertising 0101. -------------------------------------------------------------------- and the tulip-diag diagnose program (tulip-diag -f -a -e -e -m -m) shows the following: -------------------------------------------------------------------- tulip-diag.c:v1.06 9/18/98 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0x6500. Digital DS21143 Tulip Tulip chip registers at 0x6500: ffa04800 ffffffff ffffffff 0050d028 0050d228 f0660000 b20e2002 fbfffbff e0000000 fff583ff ffffffff fffe0000 000000c6 ffff0000 fff80000 8ff40008 The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. Transmit started, Receive started, half-duplex. The transmit threshold is 128. Port selection is MII, half-duplex. EEPROM contents: 1109 2b00 0000 0000 0000 0000 0000 0000 00b4 0103 0000 1bd1 bc3c 2800 0000 0000 0000 0000 0000 0000 0800 9702 0003 2102 0008 0300 0821 0001 0000 7800 01e0 5000 1800 8c00 4102 0009 0705 0006 0821 0005 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 042b d721 ID CRC 0xb4 (vs. 0xb4), complete CRC 7b146ea5. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 40, default media type 0800 (Autosense). 2 transceiver description blocks: Media MII, block type 3. MII interface PHY 0 (media type 11). Media 10base2, block type 2. Serial transceiver for 10base2 (media type 65). CSR13 0009 CSR14 0705 CSR15 0006. GP pin direction 0821 GP pin data 0005. MII PHY found at address 1, status 0x7849. MII PHY #1 transceiver registers: 3100 7849 2000 5c01 0101 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 8060 8020 0c61 0000 3000 a3b9 0080 8005 001d. Internal autonegotiation state is 'Autonegotiation disabled'. -------------------------------------------------------------------- What should I do to fix this problem ? Does the actual version of the card suport this card. The cards are jumperless and I can't substitute them (they are not mine). Thank you very much. Roberto de Almeida Facanha From briand@deldotd.com Wed Feb 3 18:16:01 1999 Date: Wed Feb 3 18:16:01 1999 From: Brian Denheyer briand@deldotd.com Subject: Problems with LinkSys 10/100 cards >>>>> "Brian" == Brian Denheyer writes: Brian> Also if someone could explain how option interpretation for the Brian> modules works that would be helpful. It would be nice for debugging Brian> purposes to add options which turned various debugging code on and Brian> off. Yeah, well if I read the web page I'd already know, duh. Brian From briand@deldotd.com Wed Feb 3 18:15:28 1999 Date: Wed Feb 3 18:15:28 1999 From: Brian Denheyer briand@deldotd.com Subject: Problems with Adaptec 10/100 cards I don't actually see why it is you don't think it configured the card properly ? >>>>> "Roberto" == Roberto de Almeida =?iso-8859-1?Q?Fa=E7anha?= writes: Roberto> tulip.c:v0.90 10/20/98 becker@cesdis.gsfc.nasa.gov Roberto> eth0: Digital DS21143 Tulip at 0x6500, 00 00 d1 1b 3c bc, IRQ 10. ^^^^^^^^^^^^^^^^^^^^^ The driver doesn't care what kind of card it is, only what the actual LAN driver IC is, so I think it should work. Brian -- Brian Denheyer briand@deldotd.com Deldot Design, Inc. (503) 788-1607 __ \/.d = Electronic design and development From townsley@physics.ucsb.edu Wed Feb 3 18:34:18 1999 Date: Wed Feb 3 18:34:18 1999 From: Dean Martin Townsley townsley@physics.ucsb.edu Subject: Linksys Cardbus working with 0.90k Hi all, In case anyone is out there watching like I was I'll report my success. I pulled the new 0.90k driver down from the site today, http://cesdis.gsfc.nasa.gov/linux/drivers/test/tulip.c and after upgrading to version 3.0.8 of PCMCIA card services (to fix a Cardbus oddity) it works!! I'm running Redhat 5.1 with a 2.0.35 kernel built from pristine source and (now) using card services 3.0.8 on a Gateway solo 5100. It does give me the error eth0: The transmitter stopped! CSR5 is f0678006, CSR6 b20e6202. once right after I bring up the interface, but after that it works fine, I've been using it most of the afternoon. Much thanks to Donald Becker for his hard work on this, and to him and others for the tulip driver in general, and do Dave Hinds for card services. Regards, -Dean Townsley From steve@ltnlcc.com.tw Wed Feb 3 20:37:05 1999 Date: Wed Feb 3 20:37:05 1999 From: Steve Huang steve@ltnlcc.com.tw Subject: Problems with LinkSys 10/100 cards Many people claimed this problem, as using a PNIC adapter, the system always shows the messag "eth0: The transmitter stopped! CSR5 is 2678016, CSR6 816e2002." when system boot up or media changed. This is coursed by pnic_timer routine. when media changed, pnic_timer STOP transmitter first and then update CSR6, STOP transmit Interrupt occured and show the message. We can remove the Stop Tx code in the pnic_timer routine to reduce the message show. 2058a2059 outl(tp->csr6 | 0x0002, ioaddr + CSR6); /* Restart Tx */ outl(tp->csr6 | 0x2002, ioaddr + CSR6); (orginal) --- outl(tp->csr6 | 0x2002, ioaddr + CSR6); (new) Many people complained that the performance of PNIC adapter has 30% loss then DC21140. I install the latest tulip.c(v0.90f) and found the Linux tulip driver set default Tx threshold to STORE AND FORWARD for PNIC adapter, but set default Tx threshold to 128 bytes for DC21140 adapter. So the performance of PNIC has 30% loss then DC21140. We can change default Tx threshold to 128 bytes for PNIC adapter in the tulip.c . The following is the line number of tulip.c(v0.90f) needed to be modified. Take it for referance. 1372c1372 < tp->csr6 = 0x814C0000 | (tp->full_duplex ? 0x0200 : 0); (new) --- > tp->csr6 = 0x816C0000 | (tp->full_duplex ? 0x0200 : 0); (orginal) 1542c1542 < new_csr6 = 0x810C0000; (new) --- > new_csr6 = 0x812C0000; (orginal) 2004c2004 < new_csr6 |= 0x810C0000; (new) --- > new_csr6 |= 0x812E0000; (orginal) 2006c2006 < new_csr6 |= 0x814C0000; (new) --- > new_csr6 |= 0x816E0000; (orginal) Best regards, Steve Huang, Software Engineer LITE-ON Communictions Corp. > -----Original Message----- > From: Brian Denheyer [mailto:briand@deldotd.com] > Sent: Thursday, February 04, 1999 1:43 AM > To: doo@shroom.com > Cc: linux-tulip@cesdis1.gsfc.nasa.gov > Subject: Re: Problems with LinkSys 10/100 cards > > > >>>>> "Adam" == Adam Crews writes: > > Adam> I added a Linksys 10/100 card to both machines as eth1 and > Adam> have connected them together with a crossover cable. I am > Adam> using the tulip.c:v0.90 version of the driver on a 2.0.36 > Adam> kernel. I have tried the tulip.c:v0.90h version with the > Adam> same results. > > Adam> Both host's eth1 get the errors: eth1: The transmitter > Adam> stopped! CSR5 is 2678016, CSR6 812e2202. eth1: Changing > Adam> PNIC configuration to full-duplex, CSR6 812e0200. > > Seems like everyone gets that "warning" including me. And by the way > it is referred to as a warning, not an error, in the source. > > What I have noticed is that you have to have both machines up and > running when you load the driver, or at any rate, that seems to help. > I think that the cards do "auto-negotiation" for speed and so when > there is nothing else to talk to when the driver activates the card it > sort of just stops. > > In theory, one would think it would "start" again when the other > computer fires up and that does seem to happen when I use win. When I > use linux I have to ifconfig eth0 down, rmmod and then bring the > eth0's back up to get things working... Not exactly convenient. > > The really bad news is that even when it works under Linux->Linux > (2.0.36) the transfer rates stink (< 1 Mbyte/s). Then again they're > not very good going from Win->Linux either, and I'm using a 7 ft > cable. > > So I see two problems : > A. the warning messages > B. the crummy performance (< 1Mb/s) > > Could someone PLEASE direct me to a datasheet for the LC82C169 so that > I can stop whining and get under the hood and fix this... I ain't > afraid of device drivers, Donald's already done 100% of the work, that > last 0% shouldn't be too bad :-) > > Also if someone could explain how option interpretation for the > modules works that would be helpful. It would be nice for debugging > purposes to add options which turned various debugging code on and > off. > > In the meantime, Linksys Etherfast 10/100 cards should probably be > avoided. > > Thanks > > Brian > > -- > > Brian Denheyer briand@deldotd.com > Deldot Design, Inc. (503) 788-1607 > __ > \/.d = Electronic design and development > From briand@deldotd.com Thu Feb 4 00:12:57 1999 Date: Thu Feb 4 00:12:57 1999 From: Brian Denheyer briand@deldotd.com Subject: Problems with LinkSys 10/100 cards >>>>> "Steve" == Steve Huang writes: Steve> Many people claimed this problem, as using a PNIC adapter, the Steve> system Steve> always shows the messag "eth0: The transmitter stopped! CSR5 is 2678016, Steve> CSR6 816e2002." Steve> when system boot up or media changed. This is coursed by pnic_timer Steve> routine. Steve> when media changed, pnic_timer STOP transmitter first and then update Steve> CSR6, I think the confusion is that people think it is an error when, if you look through the source, it is really a warning. If there are situations in which this is useful, like if you are connected to a real network, it's probably worth leaving in. But since my "network" is only two computers it just confuses me, and others, and leads them to believe that there is a problem. Steve> STOP transmit Interrupt occured and show the message. We can remove the Steve> Stop Tx code in the pnic_timer routine to reduce the message show. Steve> 2058a2059 Steve> outl(tp->csr6 | 0x0002, ioaddr + CSR6); /* Restart Tx Steve> */ Steve> outl(tp->csr6 | 0x2002, ioaddr + CSR6); (orginal) Steve> --- Steve> outl(tp->csr6 | 0x2002, ioaddr + CSR6); (new) Steve> Many people complained that the performance of PNIC adapter has 30% Steve> loss then DC21140. I install the latest tulip.c(v0.90f) and found the Steve> Linux tulip Steve> driver set default Tx threshold to STORE AND FORWARD for PNIC adapter, Steve> but set default Tx threshold to 128 bytes for DC21140 adapter. So the Steve> performance of PNIC has 30% loss then DC21140. Steve> We can change default Tx threshold to 128 bytes for PNIC adapter in Steve> the tulip.c . The following is the line number of tulip.c(v0.90f) needed Steve> to Steve> be modified. Take it for referance. Well the BEST transfer rates I have seen are on the order of 1.5Mbytes/s, about 12Mbit/s. The throughput should be on the order of 70Mbit/s so there is still a problem. I have tried to use the options setting to force a 100Mb/s mode and I still don't see results much better than 1Mbyte/s. In addition, when first starting the network the card will take several seconds to begin transmissions, I've seen it take as long as 5 seconds. Once it does everything is fine. I am running an unpatched 2.0.36 kernel with the 0.90f driver. I noticed that a 0.90k driver has been released. I will try the new driver and your patches and see if this improves performance. In the meantime I have downloaded some DC2xxxx data sheets so that I can make sense out of the register values. It is entirely possible that the performance issue is related to kernel version. If this is true, please let me know what kernel seems to give the best performance and I will upgrade. Steve> Best regards, Steve> Steve Huang, Software Engineer Steve> LITE-ON Communictions Corp. Thanks very much for responding. I will post my test results. The driver is not too complicated and I am quickly finding my way around it. Brian From briand@deldotd.com Thu Feb 4 02:28:45 1999 Date: Thu Feb 4 02:28:45 1999 From: Brian Denheyer briand@deldotd.com Subject: Problems with LinkSys 10/100 cards >>>>> "Steve" == Steve Huang writes: Steve> STOP transmit Interrupt occured and show the message. We can remove the Steve> Stop Tx code in the pnic_timer routine to reduce the message show. Steve> 2058a2059 Steve> outl(tp->csr6 | 0x0002, ioaddr + CSR6); /* Restart Tx Steve> */ Steve> outl(tp->csr6 | 0x2002, ioaddr + CSR6); (orginal) Steve> --- Steve> outl(tp->csr6 | 0x2002, ioaddr + CSR6); (new) This patch was a little confusing, here is what I used for the code : tp->csr6 = new_csr6; outl(tp->csr6 | 0x2002, ioaddr + CSR6); dev->trans_start = jiffies; Is this what you intended ? I installed the rest of the patches for the different registers. There is no performance improvement. I STILL see performance of about 1Mbyte/s. I just can't seem to do any better, it's almost as if the chip keeps configuring for 10base instead of 100base. I also tried running one of my boxes under win98 so that I was using the "official" linksys driver and still do NOT see anything better than 1.5Mbyte/s. ?? Brian From steve@ltnlcc.com.tw Thu Feb 4 03:54:32 1999 Date: Thu Feb 4 03:54:32 1999 From: Steve Huang steve@ltnlcc.com.tw Subject: Problems with LinkSys 10/100 cards > -----Original Message----- > From: Brian Denheyer [mailto:briand@deldotd.com] > Sent: Thursday, February 04, 1999 3:28 PM > To: steve@ltnlcc.com.tw > Cc: doo@shroom.com; linux-tulip@cesdis1.gsfc.nasa.gov > Subject: Re: Problems with LinkSys 10/100 cards > > > >>>>> "Steve" == Steve Huang writes: > > Steve> STOP transmit Interrupt occured and show the > message. We can remove the > Steve> Stop Tx code in the pnic_timer routine to reduce > the message show. > > Steve> 2058a2059 > Steve> outl(tp->csr6 | 0x0002, ioaddr + > CSR6); /* Restart Tx > Steve> */ > Steve> outl(tp->csr6 | 0x2002, ioaddr + > CSR6); (orginal) > Steve> --- > Steve> outl(tp->csr6 | 0x2002, ioaddr + > CSR6); (new) > > > This patch was a little confusing, here is what I used for the code : > > tp->csr6 = new_csr6; > outl(tp->csr6 | 0x2002, ioaddr + CSR6); > dev->trans_start = jiffies; > > Is this what you intended ? > YES. The system will never display the warning message while system boot up or media changed. > I installed the rest of the patches for the different registers. > There is no performance improvement. I STILL see performance of about > 1Mbyte/s. I just can't seem to do any better, it's almost as if the > chip keeps configuring for 10base instead of 100base. Do you modified the following lines in tulip.c(v.90f)? 1372c1372 < tp->csr6 = 0x814C0000 | (tp->full_duplex ? 0x0200 : 0); (new) --- > tp->csr6 = 0x816C0000 | (tp->full_duplex ? 0x0200 : 0); (original) 1542c1542 < new_csr6 = 0x810C0000; (new) --- > new_csr6 = 0x812C0000; (original) 2004c2004 < new_csr6 |= 0x810C0000; (new) --- > new_csr6 |= 0x812E0000; (original) 2006c2006 < new_csr6 |= 0x814C0000; (new) --- > new_csr6 |= 0x816E0000; (original) Could you tell me how do you measure the performance and your testing environment ? I would like to simulate it. Thanks. Steve > > I also tried running one of my boxes under win98 so that I was using > the "official" linksys driver and still do NOT see anything better > than 1.5Mbyte/s. > > ?? > > > Brian > From briand@deldotd.com Thu Feb 4 14:14:18 1999 Date: Thu Feb 4 14:14:18 1999 From: Brian Denheyer briand@deldotd.com Subject: Problems with LinkSys 10/100 cards >>>>> "Steve" == Steve Huang writes: >> >>>>> "Steve" == Steve Huang writes: >> Steve> YES. The system will never display the warning message while system Steve> boot up or Steve> media changed. Yes that seems to work. Steve> Do you modified the following lines in tulip.c(v.90f)? Yes I did. I did the modifications in the v.90k tulip.c, but it was very easy to check and make sure that the new code went to the right place. I will double-check again. I am going to work on the "register-explanation" program today starting with registers csr5 and csr6 since they seem to give the most useful information. On the 168/169 do the csr5 and csr6 registers have the same bits meanings as the dec21041 ? Steve> Could you tell me how do you measure the performance and your testing Steve> environment ? Steve> I would like to simulate it. Thanks. Can you tell me how _you_ measure performance and I will try it on my machines. I think it would be very heplful. I am running : Linux soggy 2.0.36 #2 Sun Jan 31 09:45:18 PST 1999 i586 unknown I load the tulip driver as a module. I have not tried compiling it into the kernel. I am NOT using any options on the cards. I have two machines using a crossover cat5 cable (2 meters). I ncftp from one machine to the other and transfer a 30Mbyte file. ^^^^^^^ Potential blunder alert. I did not take into account the disk transfer times. They should be small compared to the ethernet times but not when transferring @ 1-5 Mbyte/s since that is as fast as a disk drive. If I take into account disk transfer times the speed goes up to ~2.5Mbyte/s, at least this lets me know that the 100base modes are working. In order to make the test more reliable I have started using a smaller test file of about 6.6 Mbytes to make disk access time smaller. The total transfer time is now smaller and therefore more unreliable, so I use many trials. Here is the performance of the disk drives : disk 1, scsi-2 : 3.5 s for a cp (i.e. cp test test2) disk 2, scsi-uw : 0.6s ! for a cp Total disk access time is 4.1s, however since we are only reading from one disk and only writing on the other the transfer time is /2 or ~2s. Also running the test repeatedly, which I do, takes OUT the disk transfer times since the file will end up being cached on the machine being read from. The way to REALLY handle this issue is to transfer files using a ram-disk and I am trying to figure out how to set one up. My first attempt failed. After running many trials using the 6.6mbyte file I see total transfer times of 4.5 - 6.7 s. The transfer rate is then 1Mbyte -> 1.5Mbyte/s. If you assume /2 transfer times for the read and write disk accesses, which is very conservative, and then subtract 2 s from the transfer times, then these transfer rates become : 1.4 Mbyte/s to 2.6Mbyte/s. Brian From deadline@plogic.com Thu Feb 4 18:26:56 1999 Date: Thu Feb 4 18:26:56 1999 From: Douglas Eadline deadline@plogic.com Subject: Problems with LinkSys 10/100 cards Brian, The way to really test these things is to use: (I cut this froma document I am preparing) 11.1 Network performance: netperf --------------------------------- Source: http://www.netperf.org/netperf/NetperfPage.html Run Script: ./netperf -t UDP_STREAM -p 12865 -n 2 -l 60 -H NODE -- -s 65535 -m 1472 ./netperf -t TCP_STREAM -p 12865 -n 2 -l 60 -H NODE NODE is the remote node name. 11.2: Network Performance: netpipe ---------------------------------- Source: http://www.scl.ameslab.gov/Projects/Netpipe/ Read the documentation and run the tests and you will have a very good measurement of your performance. I have a box of these Lite-on cards. I may test this tomorrow. I have one question: Are these patches specific to the Lite-On chip set (do they break the driver for other chipsets?) Doug ------------------------------------------------------------------- Paralogic, Inc. | PEAK | Voice:+610.861.6960 115 Research Drive | PARALLEL | Fax:+610.861.8247 Bethlehem, PA 18017 USA | PERFORMANCE | http://www.plogic.com ------------------------------------------------------------------- From briand@deldotd.com Thu Feb 4 18:47:42 1999 Date: Thu Feb 4 18:47:42 1999 From: Brian Denheyer briand@deldotd.com Subject: Problems with LinkSys 10/100 cards >>>>> "Douglas" == Douglas Eadline writes: Douglas> I have a box of these Lite-on cards. I may test this tomorrow. Douglas> I have one question: Are these patches specific to the Douglas> Lite-On chip set (do they break the driver for other chipsets?) Thanks for the info Douglas. I will give it a try ASAP. I'm not sure if the patches would break anything, I was planning on investigating their exact nature as I become more familiar with the register sets. I've built up a tool that I'm going to bolt onto tulip-diag to give register readouts with actual explanations from the data-sheets. So far it only works for csr5 and csr6, but I can add the text for the other registers very easily. Brian -- Brian Denheyer briand@deldotd.com Deldot Design, Inc. (503) 788-1607 __ \/.d = Electronic design and development From briand@deldotd.com Fri Feb 5 00:45:53 1999 Date: Fri Feb 5 00:45:53 1999 From: Brian Denheyer briand@deldotd.com Subject: Problems with LinkSys 10/100 cards >>>>> "Douglas" == Douglas Eadline writes: This driver is not happy. netperf and netpipe can both cause strange error messages from the driver : 1. eth0: too much work during an interrupt, csr5=0x026980d0 2. eth0: Oversized Ethernet frame spanned multiple buffers, status 26cca300! I see message 2 A LOT especially when running netpipe. Aaaargh ! I seem to get different results all the time. On numerous occasions I have seen the driver stop working properly after running netpipe. Sometimes netpipe won't even run correctly, I get message #2 and then that's all folks, remove tulip and reload it. I have seen this behavior under windoze, transfers via samba die and windows says it can't complete the transfer. Netperf seems to be much more reliable but I have seen dependency on what I run and when, i.e. netperf first or netpipe first, etc... Anyway I managed to find a copy of the datasheet for the PNIC part, so maybe I can make more headway. I have seen transfer rates as high as 67Mbit/s, when things are working, so I guess the cards are working properly ?? Anyway I need to try again tomorrow and see if I can get consistent results. Brian From jrc@art.co.uk Fri Feb 5 05:31:52 1999 Date: Fri Feb 5 05:31:52 1999 From: John Connett jrc@art.co.uk Subject: The NEW Kingston KNE100TX? Reliable? We have just received a batch of Kingston KNE100TX cards and on inspection we found that the design (but not the name) has changed from a Digital 21140-AF / Intel S82555 combination to an Intel 21143-PD / SEEQ NQ80220/G combination. The old KNE100TX cards proved rock solid in operation. In fact we used them as a work around for a motherboard mounted Digital 21143-PB which had proved unreliable with earlier versions of the tulip driver (mainly auto-negotiation problems with different flavours of hub and switch). Is this new KNE100TX likely to be reliable with the current stable version (v0.90) of the tulip driver? Would the motherboard mounted Digital 21143-PB be more (or less) reliable than the new KNE100TX cards with the v0.90 tulip driver? We really need a solution that is as reliable as the old KNE100TX and if the new version isn't it we will need to identify an alternative pretty quickly! In a message to this mailing list on Tue, 12 Jan 1999 Tue, Steve Morvai (morvai@synerworks.com) mentioned an Intel document that "mentions the register level differences between the 21143xC and 21143xD chip revisions" and implies that a fix will be required to the driver to support the new chip. An initial test of the new KNE100TX with a 2.0.36 Alpha kernel and a built-in (non-module) driver appears to work and gives the following output during boot: tulip.c:v0.90 10/20/98 becker@cesdis.gsfc.nasa.gov [eth0 text removed] eth1: Digital DS21143 Tulip at 0xa800, 00 c0 f0 3b 39 94, IRQ 27. eth1: EEPROM default media type Autosense. eth1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. eth1: MII transceiver #1 config 3000 status 7829 advertising 01e1. The relevant portion of /proc/pci contains the following: Bus 1, device 10, function 0: Ethernet controller: DEC DC21142 (rev 65). Medium devsel. Fast back-to-back capable. IRQ 27. Master Capable. Latency=32. Min Gnt=20.Max Lat=40. I/O at 0xa800. Non-prefetchable 32 bit memory at 0x9300000. If any other information would be useful, please let men know and I will try to obtain it. Thanks in anticipation -- John Connett (jrc@art.co.uk) From deadline@plogic.com Fri Feb 5 07:11:34 1999 Date: Fri Feb 5 07:11:34 1999 From: Douglas Eadline deadline@plogic.com Subject: Problems with LinkSys 10/100 cards On Thu, 4 Feb 1999, Brian Denheyer wrote: > >>>>> "Douglas" == Douglas Eadline writes: > > This driver is not happy. > > netperf and netpipe can both cause strange error messages from the > driver : > > 1. eth0: too much work during an interrupt, csr5=0x026980d0 > 2. eth0: Oversized Ethernet frame spanned multiple buffers, status 26cca300! > > I see message 2 A LOT especially when running netpipe. I assume this is with the patched driver. > > Aaaargh ! I seem to get different results all the time. On numerous > occasions I have seen the driver stop working properly after running > netpipe. Sometimes netpipe won't even run correctly, I get message #2 > and then that's all folks, remove tulip and reload it. I have seen > this behavior under windoze, transfers via samba die and windows says > it can't complete the transfer. > > Netperf seems to be much more reliable but I have seen dependency on > what I run and when, i.e. netperf first or netpipe first, etc... > > Anyway I managed to find a copy of the datasheet for the PNIC part, so > maybe I can make more headway. > > I have seen transfer rates as high as 67Mbit/s, when things are > working, so I guess the cards are working properly ?? With netperf I get 95-96 Mbit/sec with both UDP and TCP. With netpipe it seems to top about at about 91 Mbit/s Doug ------------------------------------------------------------------- Paralogic, Inc. | PEAK | Voice:+610.861.6960 115 Research Drive | PARALLEL | Fax:+610.861.8247 Bethlehem, PA 18017 USA | PERFORMANCE | http://www.plogic.com ------------------------------------------------------------------- From marko@iprg.nokia.com Fri Feb 5 12:04:28 1999 Date: Fri Feb 5 12:04:28 1999 From: Marko Kiiskila marko@iprg.nokia.com Subject: Problems with LinkSys 10/100 cards > > Netperf seems to be much more reliable but I have seen dependency on > > what I run and when, i.e. netperf first or netpipe first, etc... > > > > Anyway I managed to find a copy of the datasheet for the PNIC part, so > > maybe I can make more headway. > > > > I have seen transfer rates as high as 67Mbit/s, when things are > > working, so I guess the cards are working properly ?? > With netperf I get 95-96 Mbit/sec with both UDP and TCP. > With netpipe it seems to top about at about 91 Mbit/s And what was the packet size in these tests? Not small packets, I assume? I'd be very interested in seeing the measurements done with 64byte, 128 byte, 256, 512, 1024 and 1476 packet sizes. -- Marko Kiiskila marko@iprg.nokia.com +1 408 990 2023 From briand@deldotd.com Fri Feb 5 12:11:26 1999 Date: Fri Feb 5 12:11:26 1999 From: Brian Denheyer briand@deldotd.com Subject: Problems with LinkSys 10/100 cards >>>>> "Douglas" == Douglas Eadline writes: Douglas> I assume this is with the patched driver. Negative - I'm using "stock" 0.90k. Which version did you test with ? Douglas> With netperf I get 95-96 Mbit/sec with both UDP and TCP. Douglas> With netpipe it seems to top about at about 91 Mbit/s Oh great.... I'm seeing about 66 for UDP and *30* for TCP. netpipe can cause problems, as I've said, but when it works all the way through I see about 66. You don't see any of the oversized ethernet frame erros ? What did you use for an upper limit on netpipe ? Can you give me more info about system configuration ? Compared to the performance you are seeing something's definitely wrong in my system here, so I need to get to the bottom of it. Thanks a lot for running the test. Brian From briand@deldotd.com Fri Feb 5 14:03:02 1999 Date: Fri Feb 5 14:03:02 1999 From: Brian Denheyer briand@deldotd.com Subject: Problems with LinkSys 10/100 cards >>>>> "Marko" == Marko Kiiskila writes: >> > I have seen transfer rates as high as 67Mbit/s, when things are >> > working, so I guess the cards are working properly ?? >> With netperf I get 95-96 Mbit/sec with both UDP and TCP. >> With netpipe it seems to top about at about 91 Mbit/s Marko> And what was the packet size in these tests? Not small packets, I assume? Marko> I'd be very interested in seeing the measurements done with 64byte, 128 byte, Marko> 256, 512, 1024 and 1476 packet sizes. That's the really great thing about netpipe it starts at 1 byte transfers and increments the size to a define upper limit, which I have been setting to 1048576, i.e. 1Mbyte. I think I am finally making some progress. My problems only seem to occur in one direction. I'm going to swap cards. Of course, I won't be swapping motherboards, so i'm not sure how to figure out if a MB setting is causing the trouble. Something is definitely flaky. At this point a comment from Donald, or anyone else in the know, on what an "ethernet packet being to big and spanning multiple frames" is would be really helpful. :-) What would be even more helpful is a comment on why such an error would then cause subsequent problems with transfers. Anyway I'll post (numeric) results before too much longer. Brian From schroer@bnl.gov Fri Feb 5 14:32:49 1999 Date: Fri Feb 5 14:32:49 1999 From: Klaus Schroer schroer@bnl.gov Subject: MII media trouble with ANA 6911A/TX Hi We are using the ANA 6911A/TX on several Alpha machines running Linux 2.0.36 with tulip 0.90f. We ordered a bunch of them at the same time and noticed that they look different and have different chipsets (DS21140 and DS21143). We are also using a quad port ANA 6944A (DS21140). First I noticed that I had to force the tulip driver to use the same IRQ for all 4 ports of the ANA 6944A as was already reported. Does this have any impact on the performance when using all ports at the same time e.g. running a router or firewall ? I had some difficulties getting all of them running in 100baseTX-FD mode. I finally found that I couldn't use the DS21143 cards when connecting to a 3Com switch but I could use them when I connected the DS21143 to the ANA 6944A ports. The problem is that if you let it autonegotiate it will end up in half duplex mode and if you try to force it using FD (option=14) it just tells you that the MII transceiver was not found. Here is the log message when including the module: kernel: tulip.c:v0.90f 12/17/98 becker@cesdis.gsfc.nasa.gov kernel: eth0: Digital DS21143 Tulip at 0x9000, 00 00 d1 1a 6f ec, IRQ 16. kernel: eth0: EEPROM default media type Autosense. kernel: eth0: MII interface PHY 0, setup/reset sequences 2/0 long, capabilities 00 00. kernel: eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. kernel: eth0: MII transceiver #1 config 3100 status 7849 advertising 0101. kernel: eth1: Digital DS21140 Tulip at 0x9800, 00 00 92 96 99 20, IRQ 18. kernel: eth1: EEPROM default media type Autosense. kernel: eth1: Index #0 - Media 100baseTx-FD (#5) described by a 21140 non-MII (0) block. kernel: eth1: Index #1 - Media 100baseTx (#3) described by a 21140 non-MII (0) block. kernel: eth1: Index #2 - Media 10baseT-FD (#4) described by a 21140 non-MII (0) block. kernel: eth1: Index #3 - Media 10baseT (#0) described by a 21140 non-MII (0) block. When using no option connecting to the 3Com switch I get a large number of kernel: eth0: Using MII transceiver 1, status ffff. kernel: eth0: 21143 negotiation status 000000c6, MII. kernel: eth0: MII status 786b, Link partner report 0081, CSR6 320e2202. and the connection is very slow (netperf shows about 5 Mb/s) so the autonegotiation didn't work. When using option 14 connecting to the 3Com switch I get kernel: eth0: Using user-specified media MII 100baseTx-FD. kernel: eth0: 21143 negotiation status 000000c6, MII. kernel: eth0: MII status 7849, Link partner report 0000, CSR6 320e2202. kernel: eth0: No link beat on the MII interface, status then 7849 now 7849. and I get no connectionat all. When using option 11 connecting to the 3Com switch I get kernel: eth0: Using user-specified media MII. but get poor performance again (like with no options) so the MII autonegotiation didn't work either. Finally I solved the problem for my case by switching connections. When using option 14 and connecting to one port of the ANA 6944A I get: kernel: eth0: Using user-specified media MII 100baseTx-FD. and it works (netperf shows about 87 Mb/s). So I have to use the DS21140 based cards to connect to the 3Com switch and the DS21143 based cards to connect to the ANA 6944A. Can someone explain that behaviour or did some make the same experience ? Live long and prosperous Klaus From rgb@phy.duke.edu Fri Feb 5 14:45:12 1999 Date: Fri Feb 5 14:45:12 1999 From: Robert G. Brown rgb@phy.duke.edu Subject: Problems with LinkSys 10/100 cards On Fri, 5 Feb 1999, Marko Kiiskila wrote: > > > > Netperf seems to be much more reliable but I have seen dependency on > > > what I run and when, i.e. netperf first or netpipe first, etc... > > > > > > Anyway I managed to find a copy of the datasheet for the PNIC part, so > > > maybe I can make more headway. > > > > > > I have seen transfer rates as high as 67Mbit/s, when things are > > > working, so I guess the cards are working properly ?? > > With netperf I get 95-96 Mbit/sec with both UDP and TCP. > > With netpipe it seems to top about at about 91 Mbit/s > > And what was the packet size in these tests? Not small packets, I assume? > I'd be very interested in seeing the measurements done with 64byte, 128 byte, > 256, 512, 1024 and 1476 packet sizes. Yes, note well that measured transfer rates depend strongly on CPU speed and packet size for packets less than around 1K in size. There is a graph, and set of instructions for measuring performance with netperf, on www.phy.duke.edu/brahma (the graph is even for a tulip card, although not a linksys). Measured throughput will also depend strongly on the CPU load on the receiver (and other things, but these three are the primary determinants). rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu From rgb@phy.duke.edu Fri Feb 5 14:56:26 1999 Date: Fri Feb 5 14:56:26 1999 From: Robert G. Brown rgb@phy.duke.edu Subject: Problems with LinkSys 10/100 cards On Fri, 5 Feb 1999, Brian Denheyer wrote: > At this point a comment from Donald, or anyone else in the know, on > what an "ethernet packet being to big and spanning multiple frames" is > would be really helpful. :-) What would be even more helpful is a > comment on why such an error would then cause subsequent problems with > transfers. One place this is known to occur (as I recall) is if you are running IPX. It also used to occur regularly on networks with a VMS system speaking DECnet on it. As I recall, it is rare to see this on a TCP/IP only network unless something is wrong. Note that I could be wrong about this -- I'm shooting from memory here -- but this is a fairly common error reported in the student dorms here and I'm pretty sure that I recall correctly that it is connected with Novell traffic on the same line. I think that turning off IPX if you are running it usually solves the problem. I believe that Red Hat systems tend to come with IPX turned on by default (even though there is usually no Novell network to join), which accounts for the relative frequency with which the problem is seen. rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu From lowekamp@poconos.cmcl.cs.cmu.edu Fri Feb 5 15:12:06 1999 Date: Fri Feb 5 15:12:06 1999 From: Bruce Lowekamp lowekamp@poconos.cmcl.cs.cmu.edu Subject: linksys cardbus 10/100 still not working I tried today to see if my linksys cardbus card would work with 0.90k/3.0.8, as someone else had reported. Basically, it appears to be receiving packets, but can't transmit them. I've tried on a half-duplex 10baseT and a 100baseT (I'm uncertain of whether the switch supports full duplex---my other workstation only does half) ifconfig eth0 reports that packets are being received, but no packets are being transmitted. The routing and other setttings that I could think of look correct (compared to other linux machines). I also tried the old tricks of setting TULIP_DEFAULT_MEDIA to 4 and trying options=9 to lock the transciever into MII 10bT. Neither helped. occasionally, messages pop up on my screen like: eth0: Tx hung 19 vs 15 (also with 23, 21, and 22 instead of 19) Any help would be appreciated. I can email further diagnostics if it will help. Thanks, Bruce ---------- Here is the syslog output while connected to 10bT with debug cranked up: Feb 5 14:23:38 localhost cardmgr[202]: initializing socket 1 Feb 5 14:23:38 localhost cardmgr[202]: socket 1: Linksys EtherFast 10/100 Feb 5 14:23:38 localhost cardmgr[202]: executing: 'insmod /lib/modules/2.0.36/pcmcia/cb_enabler.o' Feb 5 14:23:38 localhost cardmgr[202]: executing: 'insmod /lib/modules/2.0.36/pcmcia/tulip_cb.o debug=10' Feb 5 14:23:38 localhost kernel: cs: cb_config(bus 4): vendor 0x1011, device 0x0019 Feb 5 14:23:38 localhost kernel: fn 0 bar 1: io 0x300-0x37f Feb 5 14:23:38 localhost kernel: fn 0 bar 2: mem 0xa00c0000-0xa00c03ff Feb 5 14:23:38 localhost kernel: fn 0 rom: mem 0xa0080000-0xa00bffff Feb 5 14:23:38 localhost kernel: tulip_attach(bus 4, function 0) Feb 5 14:23:38 localhost kernel: tulip.c:v0.90k 2/1/99 becker@cesdis.gsfc.nasa.gov Feb 5 14:23:38 localhost kernel: eth0: Digital DS21143 Tulip rev 65 at 0x300, 00 e0 98 04 8b 4a, IRQ 9. Feb 5 14:23:38 localhost kernel: eth0: EEPROM default media type Autosense. Feb 5 14:23:38 localhost kernel: eth0: MII interface PHY 0, setup/reset sequences 0/0 long, capabilities e0 78. Feb 5 14:23:38 localhost kernel: eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Feb 5 14:23:38 localhost kernel: eth0: MII transceiver #0 config 3000 status 7809 advertising 01e1. Feb 5 14:23:38 localhost cardmgr[202]: executing: './network start eth0' Feb 5 14:23:38 localhost kernel: Swansea University Computer Society IPX 0.34 for NET3.035 Feb 5 14:23:38 localhost kernel: IPX Portions Copyright (c) 1995 Caldera, Inc. Feb 5 14:23:38 localhost kernel: Appletalk 0.17 for Linux NET3.035 Feb 5 14:23:38 localhost kernel: eth0: Using MII transceiver 0, status 7809. Feb 5 14:23:43 localhost kernel: eth0: 21143 negotiation status 000000c6, MII. Feb 5 14:23:43 localhost kernel: eth0: MII status 7829, Link partner report 0021, CSR6 b20e2002. Feb 5 14:24:43 localhost kernel: eth0: 21143 negotiation status 000000c6, MII. Feb 5 14:24:43 localhost kernel: eth0: MII status 782d, Link partner report 0021, CSR6 b20e2002. Feb 5 14:25:43 localhost kernel: eth0: 21143 negotiation status 000000c6, MII. Feb 5 14:25:43 localhost kernel: eth0: MII status 782d, Link partner report 0021, CSR6 b20e2002. Feb 5 14:26:13 localhost kernel: 00 00 00 80 02 de 70 de 70 de 70 de 70 de 70 de 70 de 70 de 70 de 70 de 70 46 e9 db 61 20 37 40 80 ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 78 f5 01 j=1600. Feb 5 14:26:13 localhost kernel: ff ff ff ff ff ff 08 00 20 0c 22 d5 08 06 00 01 08 00 06 04 00 01 08 00 20 0c 22 d5 80 02 d1 52 ff ff ff ff ff ff 80 02 fa 21 ff ff ff ff ff ff 08 06 00 60 08 2d eb 87 08 06 fc 0d 34 e5 6c 7e 20 37 40 80 ff ff ff ff ff ff ff ff ff ff ff ff 41 43 41 43 41 43 41 41 41 00 20 46 44 45 44 46 44 43 41 43 j=1600. Feb 5 14:26:13 localhost kernel: ff ff ff ff ff ff 00 10 5a 13 4a 23 08 06 00 01 08 00 06 04 00 01 00 10 5a 13 4a 23 80 02 dc 38 00 00 00 00 00 00 80 02 cb 3d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c3 a7 f9 ea 20 37 40 80 ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 j=1600. ... lines like these repeat for a while, and in the middle of them, this line was present: Feb 5 14:26:13 localhost kernel: ff ff ff ff<7>eth0: interrupt csr5=0xf0270040 new csr5=0xf0260000. ... From briand@deldotd.com Fri Feb 5 15:45:20 1999 Date: Fri Feb 5 15:45:20 1999 From: Brian Denheyer briand@deldotd.com Subject: Problems with LinkSys 10/100 cards >>>>> "Robert" == Robert G Brown writes: Robert> One place this is known to occur (as I recall) is if you Robert> are running IPX. It also used to occur regularly on Robert> networks with a VMS system speaking DECnet on it. As I Robert> recall, it is rare to see this on a TCP/IP only network Robert> unless something is wrong. IPX is turned off in the kernel. I am assuming there is no other way for it to be "secretly" active. Brian From becker@cesdis1.gsfc.nasa.gov Fri Feb 5 15:46:58 1999 Date: Fri Feb 5 15:46:58 1999 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: MII media trouble with ANA 6911A/TX On Fri, 5 Feb 1999, Klaus Schroer wrote: > We are using the ANA 6911A/TX on several Alpha machines running Linux > 2.0.36 with tulip 0.90f. We ordered a bunch of them at the same time and > noticed that they look different and have different chipsets (DS21140 and > DS21143). We are also using a quad port ANA 6944A (DS21140). Grrr, that's why the Tulip driver is a real bitch to support. I get reports for the "ANA6911", when that could mean any one of several very different designs. > First I noticed that I had to force the tulip driver to use the same IRQ > for all 4 ports of the ANA 6944A as was already reported. Does this have > any impact on the performance when using all ports at the same time e.g. > running a router or firewall ? This is a BIOS issue: the BIOS configures the bus bridge on the multiport board. Most x86 BIOSes have a bug that with IRQ assignment and reporting that the driver must work around. > I had some difficulties getting all of them running in 100baseTX-FD > mode. I finally found that I couldn't use the DS21143 cards when > connecting to a 3Com switch but I could use them when I connected the > DS21143 to the ANA 6944A ports. The problem is that if you let it > autonegotiate it will end up in half duplex mode and if you try to force > it using FD (option=14) it just tells you that the MII transceiver was not > found. Here is the log message when including the module: The issue is NWay autonegotiation -- read http://cesdis.gsfc.nasa.gov/linux/misc/NWay.html Most Cisco switches do not autonegotiate -- Cisco has been way behind on this. Many older 3Com switches have broken autonegotiation timing. Some swithes have firmware updates that fixes the worst of the problem. Old Bay Networks switches (e.g. the 28115) don't have autonegotation, but all new ones do. > When using no option connecting to the 3Com switch I get a large number of > kernel: eth0: MII status 786b, Link partner report 0081, CSR6 320e2202. The link partner isn't doing autonegotiation.. > and the connection is very slow (netperf shows about 5 Mb/s) so the > autonegotiation didn't work. > When using option 14 connecting to the 3Com switch I get > kernel: eth0: Using user-specified media MII 100baseTx-FD. > kernel: eth0: 21143 negotiation status 000000c6, MII. > kernel: eth0: MII status 7849, Link partner report 0000, CSR6 320e2202. > kernel: eth0: No link beat on the MII interface, status then 7849 now 7849. > and I get no connectionat all. The status is reporting no link beat. Try running 'mii-diag' to confirm. http://cesdis.gsfc.nasa.gov/linux/diag/index.html > When using option 11 connecting to the 3Com switch I get > kernel: eth0: Using user-specified media MII. > but get poor performance again (like with no options) so the MII > autonegotiation didn't work either. Correct. The default media type when an MII transceiver is found is '11'. > Finally I solved the problem for my case by switching connections. When > using option 14 and connecting to one port of the ANA 6944A I get: > kernel: eth0: Using user-specified media MII 100baseTx-FD. > and it works (netperf shows about 87 Mb/s). Try using "option tulip full_duplex=1" (or e.g. "full_duplex=1,1,0,0" w/multiple ports) This should work on either MII or SYM transceivers. Note that a *negotiated* full duplex connection will always override the duplex setting. 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 briand@deldotd.com Fri Feb 5 15:59:29 1999 Date: Fri Feb 5 15:59:29 1999 From: Brian Denheyer briand@deldotd.com Subject: Problems with LinkSys 10/100 cards >>>>> "Robert" == Robert G Brown writes: Robert> Yes, note well that measured transfer rates depend Robert> strongly on CPU speed and packet size for packets less Robert> than around 1K in size. There is a graph, and set of Robert> instructions for measuring performance with netperf, on Robert> www.phy.duke.edu/brahma (the graph is even for a tulip Robert> card, although not a linksys). Measured throughput will Robert> also depend strongly on the CPU load on the receiver (and Robert> other things, but these three are the primary Robert> determinants). I looked at the graph and let me tell you I am getting nothing like that performance. Now supposedly the hacks which Steve posted should help, but since I can't get 0.90k to behave reliably, I haven't rolled those back in. I am also trying to figure out what they do, and so far the hacks do NOT make sense in relation to the datasheet. Pretty normal for hardware... I am running these tests with very low CPU load, i.e., nothing else of significance is going on. I'm in the process now of trying to track down the differences between the PNIC and the 21143 and see if there is something obvious going on. But as of right now both netperf and netpipe break the drivers quite repeatably. The problem does seem worse in "one direction". Of course the PNIC datasheet is *1994*, so I think I'm pretty much not going to be able to figure out what's going on. *sigh* It'd be a heck of a lot easier to go out and buy two new network cards. Brian From briand@deldotd.com Fri Feb 5 16:12:29 1999 Date: Fri Feb 5 16:12:29 1999 From: Brian Denheyer briand@deldotd.com Subject: Problems with LinkSys 10/100 cards >>>>> "Donald" == Donald Becker writes: Thanks very much for the info.. Donald> ____!!!!!!!!!!!!____ Note 3: Some or all Digital chips Donald> have a buglet/undocumented-behavior: when the other end is Donald> actually in full duplex mode and thus ignoring Donald> "collisions", the receiver sometimes fails to reset the Donald> buffer pointer after a collision resulting in multiple Donald> appended packets in a single buffer. Ouch. Couple of more questions while I have your attention :-) Did you actually have an actual datasheet for the PNIC part when you put in the mods for it ? If you did, did you notice that CSR6/bit 31 (special capture effect) is allegedly "reserved" in the PNIC part vs. the 21143 ? In general, the PNIC and 21143 registers track pretty poorly. Do you expect that I might find other inconsistencies and would you want to know about them, or should I just try changing the code and maybe sometime next week I'll figure something out and let you know. Given the fact that at least one person has reported good performance with these cards, am I wasting my time ? The PNIC datasheet I obtained from a kind soul in the FreeBSD camp is dated Dec 1994, so I am wondering if I should basically throw it away along with the Linksys cards and go out and buy myself a couple of REAL Tulip-based cards. Thanks again Brian -- Brian Denheyer briand@deldotd.com Deldot Design, Inc. (503) 788-1607 __ \/.d = Electronic design and development From deadline@plogic.com Fri Feb 5 16:57:28 1999 Date: Fri Feb 5 16:57:28 1999 From: Douglas Eadline deadline@plogic.com Subject: tulip V90k I tried tulip version 90k today with the following results: 1. Using a Lite On (netGear) Boots OK, but bad performance 2. Using KTI 221TX (DEC 21143) NIC Feb 5 11:34:28 coyote4 kernel: tulip.c:v0.90k 2/1/99 becker@cesdis.gsfc.nasa.gov Feb 5 11:34:28 coyote4 kernel: eth0: Digital DS21143 Tulip rev 65 at 0xec00, EEPROM not present, 00 4c 69 6e 75 79, IRQ 0. Previously .90f worked with this card 3. Using 21140 Netgear NIC It recognized the NIC at boot, but would not work. If I did an "ifdown, rmmod tulip, insmod tulip, ifup", it works OK. Previoulsy with 90f everything worked OK. Using, 90f, I upgraded to 2.0.36 and now find that both the KTI (21143) and the Netgear (21140) need the "ifdown, rmmod tulip, insmod tulip, ifup" after the system is booted to work (perhaps 2.0.36 needs something upgraded I'm using a Rh 5.1 distribution) The lite On comes up OK and works as good as it can with 2.0.36 Doug ------------------------------------------------------------------- Paralogic, Inc. | PEAK | Voice:+610.861.6960 115 Research Drive | PARALLEL | Fax:+610.861.8247 Bethlehem, PA 18017 USA | PERFORMANCE | http://www.plogic.com ------------------------------------------------------------------- From deadline@plogic.com Fri Feb 5 17:09:31 1999 Date: Fri Feb 5 17:09:31 1999 From: Douglas Eadline deadline@plogic.com Subject: Problems with LinkSys 10/100 cards On Fri, 5 Feb 1999, Brian Denheyer wrote: Brian, here aare soem results (all very reproducible) I just posted some of my boot problems with .90f and .90k I also put some netgear Lite-On Nics in our cluster to check some things: NETPERF: 21140 NIC (.90f driver) ---> LITE-ON (.90k driver) --------------------------------------------------------------- UDP UNIDIRECTIONAL SEND TEST to coyote2 Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 65535 1472 59.99 487436 0 95.69 65535 59.99 487436 95.69 TCP STREAM TEST to coyote2 Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65535 65535 65535 59.99 94.76 NETPERF: LITE-ON (.90k driver) ----> 21140 NIC (.90f driver) ---------------------------------------------------------------- UDP UNIDIRECTIONAL SEND TEST to coyote4 Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 65535 1472 59.99 264167 0 51.85 65535 59.99 264167 51.85 TCP STREAM TEST to coyote4 Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65535 65535 65535 60.00 51.73 Using the other NICs in my cluster I get between 94-95 Mbits/sec I may try patching .90f as suggested and see if it works better with the Lite-On card. My test script: ./netperf -t UDP_STREAM -p 12865 -n 2 -l 60 -H coyote$1 -- -s 65535 -m 1472 ./netperf -t TCP_STREAM -p 12865 -n 2 -l 60 -H coyote$1 Doug ------------------------------------------------------------------- Paralogic, Inc. | PEAK | Voice:+610.861.6960 115 Research Drive | PARALLEL | Fax:+610.861.8247 Bethlehem, PA 18017 USA | PERFORMANCE | http://www.plogic.com ------------------------------------------------------------------- From massimo.lambertini@everex.it Fri Feb 5 21:17:38 1999 Date: Fri Feb 5 21:17:38 1999 From: Massimo Lambertini massimo.lambertini@everex.it Subject: 21143 and Fulduplex Hi I have a problem . If i set Fullduplex in my Planet enw9501+ that is a DC21143 the network work very slow. . I use a 3com 10/100 Autosensing Nway Switch , and i've tryed with 10/100 switch of Planet , but the problem remain . I use linux 2.0.36 and tulip driver 0.90 . In Half duplex I archive about 5 Mbyte / s but in fullduplex less then 100 Kbyte /sec. I have setup options=0 , options=16 and Options=14 but in Full Duplex ( I watch this from switch led ) does't work well . Any Suggestion is welcome . Thank you in advance . Please if you send a reply send also email to me . Massimo Lambertini Webmaster of www.everex.it massimo.lambertini@everex.it From briand@deldotd.com Sat Feb 6 14:37:49 1999 Date: Sat Feb 6 14:37:49 1999 From: Brian Denheyer briand@deldotd.com Subject: More definitive results as to the Linksys 10/100 problems OK. I _think_ it's official, there is a bug hiding in the driver or the 82C169. Here's why I think so : When running netpipe or netperf the system does one of two things : 1. the transfers STOP in the middle of the test. That's right, complete with warnings about "the transmitter stopped". Gotta reload the driver. 2. The box sending the packets gets an "ethernet frame too large" error and the ethernet interface becomes very flaky and pretty much unusable. Gotta reload the driver. My set-up : I have two machines (FIC and ASUS motherboards). Both are runnning 2.0.36 kernels. I have swapped cards between the systems. I have swapped (the crossover) cables. The nail in the coffin : My friend brought over 2 Samsung 1200TX cards which use the real DEC21141 controller. We put them in the system, used the exact same 0.90k driver which I have been using with the linksys cards, ran netpipe and netperf in both directions without a single problem and with transfer rates of 90-95Mbits/s. *** The linksys cards do NOT work properly with the 0.90k (or 0.90f) *** driver ! To be more specific, a linksys etherfast 10/100 cards with *** an LC82C169, datecode 9836 does not not work properly with the *** 0.90k(0.90f) drivers. The only possibility now is that one of the cards is bad, highly doubtful since they will work for a while before dying. At the end of the e-mail I have provided some additional debugging information with regards to the frame-size problem. It doesn't seem to point me in any particular direction, I was hoping someone could take a look and provide additional interpretation, and maybe let me know in what direction to proceed. Here is my plan. I'm going to order a couple of samsung cards and toss these linksys cards in the junk-heap (I can't find my damn receipt). However, until I get the new cards, I can keep working on the problem if I can continue to get guidance on things to try. I know hardware but I don't know ethernet. I figure by Thursday I'll have the new cards and then that's the end of this annoying experience. Donald, you've got a lot of patience to have gotten all this sh*t working with buggy docs and buggy chips ! Of course, Lite-On could pay me to figure out what's wrong :-) Brian Here's a data dump of the descriptors from one of the many failed attempts to get these things to work. As Bill Paul pointed out the status for entry 16 is almost totally meaningless, something has really broken : Feb 6 02:39:07 soggy kernel: eth0: Oversized Ethernet frame spanned multiple buffers, status 26cca300! Feb 6 02:39:07 soggy kernel: cur_rx = 166960 entry = 16. Feb 6 02:39:07 soggy kernel: csr5 = 02660010 csr6 = 812e2202. Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:0 status = 80000000 length = 00000600 bufffer1 = 01e16820 buffer2 = 00082830 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:1 status = 80000000 length = 00000600 bufffer1 = 03d8c028 buffer2 = 00082840 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:2 status = 80000000 length = 00000600 bufffer1 = 03d8c820 buffer2 = 00082850 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:3 status = 80000000 length = 00000600 bufffer1 = 00f46028 buffer2 = 00082860 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:4 status = 80000000 length = 00000600 bufffer1 = 00f46820 buffer2 = 00082870 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:5 status = 80000000 length = 00000600 bufffer1 = 016e1028 buffer2 = 00082880 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:6 status = 80000000 length = 00000600 bufffer1 = 016e1820 buffer2 = 00082890 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:7 status = 80000000 length = 00000600 bufffer1 = 01d6f028 buffer2 = 000828a0 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:8 status = 80000000 length = 00000600 bufffer1 = 01d6f820 buffer2 = 000828b0 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:9 status = 80000000 length = 00000600 bufffer1 = 01f09028 buffer2 = 000828c0 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:10 status = 80000000 length = 00000600 bufffer1 = 01f09820 buffer2 = 000828d0 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:11 status = 80000000 length = 00000600 bufffer1 = 02e4f028 buffer2 = 000828e0 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:12 status = 80000000 length = 00000600 bufffer1 = 02e4f820 buffer2 = 000828f0 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:13 status = 80000000 length = 00000600 bufffer1 = 006bc028 buffer2 = 00082900 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:14 status = 80000000 length = 00000600 bufffer1 = 006bc820 buffer2 = 00082910 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:15 status = 80000000 length = 00000600 bufffer1 = 033a2028 buffer2 = 00082920 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:16 status = 26cca300 length = 00000600 bufffer1 = 033a2820 buffer2 = 00082930 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:17 status = 00400300 length = 00000600 bufffer1 = 018dd028 buffer2 = 00082940 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:18 status = 80000000 length = 00000600 bufffer1 = 018dd820 buffer2 = 00082950 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:19 status = 80000000 length = 00000600 bufffer1 = 0336f028 buffer2 = 00082960 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:20 status = 80000000 length = 00000600 bufffer1 = 0336f820 buffer2 = 00082970 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:21 status = 80000000 length = 00000600 bufffer1 = 01802028 buffer2 = 00082980 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:22 status = 80000000 length = 00000600 bufffer1 = 01802820 buffer2 = 00082990 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:23 status = 80000000 length = 00000600 bufffer1 = 0256d028 buffer2 = 000829a0 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:24 status = 80000000 length = 00000600 bufffer1 = 0256d820 buffer2 = 000829b0 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:25 status = 80000000 length = 00000600 bufffer1 = 02de3028 buffer2 = 000829c0 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:26 status = 80000000 length = 00000600 bufffer1 = 02de3820 buffer2 = 000829d0 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:27 status = 80000000 length = 00000600 bufffer1 = 01cb9028 buffer2 = 000829e0 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:28 status = 80000000 length = 00000600 bufffer1 = 01cb9820 buffer2 = 000829f0 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:29 status = 80000000 length = 00000600 bufffer1 = 02d29028 buffer2 = 00082a00 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:30 status = 80000000 length = 00000600 bufffer1 = 02d29820 buffer2 = 00082a10 Feb 6 02:39:07 soggy kernel: Dump of rx_ring descriptors. Feb 6 02:39:07 soggy kernel: entry:31 status = 80000000 length = 02000600 bufffer1 = 02967028 buffer2 = 00082820 From rgb@phy.duke.edu Sun Feb 7 07:10:58 1999 Date: Sun Feb 7 07:10:58 1999 From: Robert G. Brown rgb@phy.duke.edu Subject: Problems with LinkSys 10/100 cards On Fri, 5 Feb 1999, Brian Denheyer wrote: > >>>>> "Robert" == Robert G Brown writes: > > Robert> Yes, note well that measured transfer rates depend > Robert> strongly on CPU speed and packet size for packets less > Robert> than around 1K in size. There is a graph, and set of > Robert> instructions for measuring performance with netperf, on > Robert> www.phy.duke.edu/brahma (the graph is even for a tulip > Robert> card, although not a linksys). Measured throughput will > Robert> also depend strongly on the CPU load on the receiver (and > Robert> other things, but these three are the primary > Robert> determinants). > > I looked at the graph and let me tell you I am getting nothing like > that performance. Now supposedly the hacks which Steve posted should > help, but since I can't get 0.90k to behave reliably, I haven't rolled > those back in. I am also trying to figure out what they do, and so > far the hacks do NOT make sense in relation to the datasheet. Pretty > normal for hardware... I am running these tests with very low CPU > load, i.e., nothing else of significance is going on. I'm curious. I may have asked these questions before (a couple of months ago) but for those of us with brains damaged by a hard youth the world is always new, so bear with me. Do you still get the same general KIND of performance as is indicated in the graph? That is, a region of linear growth in speed where the NIC is sending its maximum packet rate (so speed is varying linearly with the size of the packet payload), followed by a saturation region where the number of packets per second decreases as the size of the packets increases? Where, in the case of a normal card, the saturation occurs where the local transmission requirements hit wirespeed and in the case of the lite-on they are being bottlenecked by something else? > I'm in the process now of trying to track down the differences between > the PNIC and the 21143 and see if there is something obvious going on. > But as of right now both netperf and netpipe break the drivers quite > repeatably. The problem does seem worse in "one direction". > > Of course the PNIC datasheet is *1994*, so I think I'm pretty much not > going to be able to figure out what's going on. I thought that the guy who posted one of the patches (Steven Huang?) worked for Linksys. He ought to be able to send you a current datasheet (or provide even more substantial help). There are a lot of linux users out there -- my newspaper (in the article that trumpeted the fact that Dell now officially supports linux) pointed out that linux owns 18% of the server market and has the fastest growth rate by far of any of the major operating systems in all markets. Linksys appears to be wise enough to recognize this and to maybe be making an effort to ensure that their cards work with linux. > > *sigh* > > It'd be a heck of a lot easier to go out and buy two new network > cards. At $30/each, this is MY favorite solution;-). But , with 21140's getting scarce, I suppose that one day having the lite-on chip work properly would be very useful. I can't help much with the actual debugging, though -- I do have one remote box with a lite-on chip in it, but it is on a 10-base hub. rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu From rgb@phy.duke.edu Sun Feb 7 08:16:36 1999 Date: Sun Feb 7 08:16:36 1999 From: Robert G. Brown rgb@phy.duke.edu Subject: tulip V90k This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --60306615-1062255700-918393388=:27370 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 5 Feb 1999, Douglas Eadline wrote: > I tried tulip version 90k today with the following results: > > 1. Using a Lite On (netGear) > > Boots OK, but bad performance > > 2. Using KTI 221TX (DEC 21143) NIC > > > Feb 5 11:34:28 coyote4 kernel: tulip.c:v0.90k 2/1/99 > becker@cesdis.gsfc.nasa.gov > Feb 5 11:34:28 coyote4 kernel: eth0: Digital DS21143 Tulip rev 65 at > 0xec00, EEPROM not present, 00 4c 69 6e 75 79, IRQ 0. > > Previously .90f worked with this card > > 3. Using 21140 Netgear NIC > > It recognized the NIC at boot, but would not work. If I > did an "ifdown, rmmod tulip, insmod tulip, ifup", it works OK. Doug, try my infamous "probe the PCI_BASE_ADDRESS" patch (attached for 0.89H) to see if it fixes this. I recently noted (the hard way, of course) that as of 0.89H it is still necessary for a number of our systems here with genuine 21140's (the old KNE-100's) in dual PPros. Don swears that probing the ioport to ensure writability should not be necessary and of course he is right, but this patch has worked for everyone who has tried it and at the very least makes the insmod/rmmod/insmod ritual unnecessary by basically incorporating it into the driver. rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu --60306615-1062255700-918393388=:27370 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="tulip.ioport.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: patch to probe ioport for writability LS0tIHR1bGlwLmMtMC44OUgJTW9uIEphbiAxMSAwNzo1OToyMSAxOTk5DQor KysgdHVsaXAuYy0wLjg5SC5pb3BvcnQJTW9uIEphbiAxMSAwODoyODo0OCAx OTk5DQpAQCAtMTgsNyArMTgsNyBAQA0KICovDQogDQogI2RlZmluZSBTTVBf Q0hFQ0sNCi1zdGF0aWMgY29uc3QgY2hhciB2ZXJzaW9uW10gPSAidHVsaXAu Yzp2MC44OUggNS8yMy85OCBiZWNrZXJAY2VzZGlzLmdzZmMubmFzYS5nb3Zc biI7DQorc3RhdGljIGNvbnN0IGNoYXIgdmVyc2lvbltdID0gInR1bGlwLmM6 djAuODlILmlvcG9ydCA1LzIzLzk4IGJlY2tlckBjZXNkaXMuZ3NmYy5uYXNh LmdvdlxuIjsNCiANCiAvKiBBIGZldyB1c2VyLWNvbmZpZ3VyYWJsZSB2YWx1 ZXMuICovDQogDQpAQCAtNTIzLDE1ICs1MjMsNTMgQEANCiAJCXBjaWJpb3Nf cmVhZF9jb25maWdfZHdvcmQocGNpX2J1cywgcGNpX2RldmljZV9mbiwgUENJ X0JBU0VfQUREUkVTU18wLA0KIAkJCQkJCQkJICAmcGNpX2lvYWRkcik7DQog I2VuZGlmDQorIC8qIA0KKyAgKiBQYXRjaCB0byAobWF5YmUpIGZpeCBpb3Bv cnQgYnVnLiAgVGhpcyBmcmFnbWVudCBpcyBmcm9tIHRoZSBib29rDQorICAq IExpbnV4IERldmljZSBEcml2ZXJzLCBwYWdlIDM1MywgYW5kIHBvbGxzIGVh Y2ggcG9zc2libGUgaW9wb3J0DQorICAqIHVudGlsIG9uZSBpcyBmb3VuZCB0 aGF0IGlzIHdyaXRlYWJsZS4gIEkgdGhpbmsgdGhhdCB0aGlzIGlzIHRoZQ0K KyAgKiBjb3JyZWN0IGFuZCByb2J1c3QgYXBwcm9hY2ggdG8gcGNpIGluaXRp YWxpemF0aW9uLg0KKyAgKi8NCiAJCXsNCi0JCXUzMiBwY2lfaW9hZGRyX2No ZWNrOw0KLQkJcGNpYmlvc19yZWFkX2NvbmZpZ19kd29yZChwY2lfYnVzLCBw Y2lfZGV2aWNlX2ZuLA0KLQkJCQkgIFBDSV9CQVNFX0FERFJFU1NfMCwgJnBj aV9pb2FkZHJfY2hlY2spOw0KLQkJaWYgKHBjaV9pb2FkZHIgIT0gcGNpX2lv YWRkcl9jaGVjaykNCi0JCQlwcmludGsoIkJ1Z2d5IFBDSSBCSU9TIC0gcGNp Ymlvc19yZWFkX2NvbmZpZ19kd29yZCgiDQotCQkJICAgICAgICIlZCwlZCwl I3gpID0gJSN4IC8gJSN4LlxuIiwNCi0JCQkgICAgICAgcGNpX2J1cywgcGNp X2RldmljZV9mbiwgUENJX0JBU0VfQUREUkVTU18wLA0KLQkJCSAgICAgICBw Y2lfaW9hZGRyLCBwY2lfaW9hZGRyX2NoZWNrKTsNCisJCSAgaW50IGlpbzsN CisJCSAgdTMyIHBjaV9pb2FkZHJfY2hlY2sscGNpX2lvYWRkcl9tYXNrOw0K KwkJICB1MzIgYWRkcmVzc2VzW10gPSB7DQorCQkJUENJX0JBU0VfQUREUkVT U18wLA0KKwkJCVBDSV9CQVNFX0FERFJFU1NfMSwNCisJCQlQQ0lfQkFTRV9B RERSRVNTXzIsDQorCQkJUENJX0JBU0VfQUREUkVTU18zLA0KKwkJCVBDSV9C QVNFX0FERFJFU1NfNCwNCisJCQlQQ0lfQkFTRV9BRERSRVNTXzUsDQorCQkJ MA0KKwkJICB9Ow0KKyAgICAgICAgICAgICAgICAgIGZvcihpaW89MDthZGRy ZXNzZXNbaWlvXTtpaW8rKyl7DQorCQkgICAgcGNpYmlvc19yZWFkX2NvbmZp Z19kd29yZChwY2lfYnVzLCBwY2lfZGV2aWNlX2ZuLA0KKwkJCWFkZHJlc3Nl c1tpaW9dLCAmcGNpX2lvYWRkcl9jaGVjayk7DQorCQkgICAgcGNpYmlvc193 cml0ZV9jb25maWdfZHdvcmQocGNpX2J1cywgcGNpX2RldmljZV9mbiwNCisJ CQlhZGRyZXNzZXNbaWlvXSwgfjApOw0KKwkJICAgIHBjaWJpb3NfcmVhZF9j b25maWdfZHdvcmQocGNpX2J1cywgcGNpX2RldmljZV9mbiwNCisJCQlhZGRy ZXNzZXNbaWlvXSwgJnBjaV9pb2FkZHJfbWFzayk7DQorCQkgICAgcGNpYmlv c193cml0ZV9jb25maWdfZHdvcmQocGNpX2J1cywgcGNpX2RldmljZV9mbiwN CisJCQlhZGRyZXNzZXNbaWlvXSwgcGNpX2lvYWRkcl9jaGVjayk7DQorCQkg ICAgaWYgKCFwY2lfaW9hZGRyX21hc2spew0KKwkJICAgICAgcHJpbnRrKCJC dWdneSBQQ0kgQklPUyAtIHBjaWJpb3NfcmVhZF9jb25maWdfZHdvcmQoIg0K KwkJICAgICAgICAgIiVkLCVkLCUjeCkgPSAlI3ggLyAlI3guXG4iLA0KKwkJ ICAgICAgICAgcGNpX2J1cywgcGNpX2RldmljZV9mbiwgUENJX0JBU0VfQURE UkVTU18wLA0KKwkJICAgICAgICAgcGNpX2lvYWRkciwgcGNpX2lvYWRkcl9j aGVjayk7DQorCQkgICAgICBwcmludGsoImlvcG9ydCAleCBwcm9iYWJseSB1 bnVzYWJsZS4gIENvbnRpbnVpbmcgc2Nhbi4uLlxuIiwNCisJCSAgICAgICBw Y2lfaW9hZGRyX2NoZWNrKTsNCisJCSAgICB9IGVsc2Ugew0KKwkJICAgICAg cGNpX2lvYWRkciA9IHBjaV9pb2FkZHJfY2hlY2s7CS8qIEdvb2Qgb25lPyAq Lw0KKyAgICAgICAgICAgICAgICAgICAgICBpZih0dWxpcF9kZWJ1ZykgcHJp bnRrKEtFUk5fSU5GTyAidHVsaXBfcHJvYmU6IGlvcG9ydCBmb3VuZCBhdCAl eFxuIixwY2lfaW9hZGRyKTsNCisJCSAgICAgIGJyZWFrOw0KKwkJICAgIH0N CisJCSAgICBpZiAocGNpX2lvYWRkciAhPSBwY2lfaW9hZGRyX2NoZWNrKQ0K KwkJICB9DQorCQkgIGlmICghcGNpX2lvYWRkcil7DQorCQkgICAgcGNpYmlv c19yZWFkX2NvbmZpZ19kd29yZChwY2lfYnVzLCBwY2lfZGV2aWNlX2ZuLA0K KwkJCSAgUENJX0JBU0VfQUREUkVTU18wLCAmcGNpX2lvYWRkcl9jaGVjayk7 DQorICAgICAgICAgICAgICAgICAgICBwcmludGsoIk5vIHZhbGlkIGlvcG9y dCBmb3VuZC4gIEZhbGxpbmcgYmFjayBvbiAoZmFpbGVkKSBpb3BvcnQgJWRc biIscGNpX2lvYWRkcl9jaGVjayk7DQorICAgICAgICAgICAgICAgICAgICBw Y2lfaW9hZGRyID0gcGNpX2lvYWRkcl9jaGVjazsNCisJCSAgfQ0KIAkJfQ0K IAkJLyogUmVtb3ZlIEkvTyBzcGFjZSBtYXJrZXIgaW4gYml0IDAuICovDQog CQlwY2lfaW9hZGRyICY9IH4zOw0K --60306615-1062255700-918393388=:27370-- From briand@deldotd.com Sun Feb 7 13:49:36 1999 Date: Sun Feb 7 13:49:36 1999 From: Brian Denheyer briand@deldotd.com Subject: Problems with LinkSys 10/100 cards >>>>> "rgb" == Robert G Brown writes: rgb> I'm curious. I may have asked these questions before (a couple of rgb> months ago) but for those of us with brains damaged by a hard youth the rgb> world is always new, so bear with me. Do you still get the same general rgb> KIND of performance as is indicated in the graph? That is, a region of rgb> linear growth in speed where the NIC is sending its maximum packet rate rgb> (so speed is varying linearly with the size of the packet payload), rgb> followed by a saturation region where the number of packets per second rgb> decreases as the size of the packets increases? Where, in the case of a rgb> normal card, the saturation occurs where the local transmission rgb> requirements hit wirespeed and in the case of the lite-on they are being rgb> bottlenecked by something else? I didn't explain myself too well. The card tracks the "shape" of the graph, including those interesting drop-outs, but its' "top-end" is 60-70Mbits/s. This is not very useful since 2/3 of the time it can't make it through the test(s). rgb> I thought that the guy who posted one of the patches (Steven Huang?) rgb> worked for Linksys. He ought to be able to send you a current datasheet rgb> (or provide even more substantial help). There are a lot of linux users rgb> out there -- my newspaper (in the article that trumpeted the fact that rgb> Dell now officially supports linux) pointed out that linux owns 18% of rgb> the server market and has the fastest growth rate by far of any of the rgb> major operating systems in all markets. Linksys appears to be wise rgb> enough to recognize this and to maybe be making an effort to ensure that rgb> their cards work with linux. I agree. One would think an official datasheet is not a high price to pay for free work to give a product a broader market. rgb> At $30/each, this is MY favorite solution;-). But , with 21140's rgb> getting scarce, I suppose that one day having the lite-on chip work rgb> properly would be very useful. I can't help much with the actual rgb> debugging, though -- I do have one remote box with a lite-on chip in it, rgb> but it is on a 10-base hub. Well, as I'm sure you saw on a subsequent post, there are genuine 21140's to be found at a good price. My e-mail was mistaken, the 1200TX uses a 21140 not a 21141. Re the lite-on chip, I think it is the 169 version which makes the difference. My guess is that cards with 168's work. And you're right, it would be useful to have the 169 version work. Of course, there is always that small possibility that there is something in my partcular hardware set-up causing the problem, but I sure would think that my tx1200 experiment proved otherwise. Brian -- Brian Denheyer briand@deldotd.com Deldot Design, Inc. (503) 788-1607 __ \/.d = Electronic design and development From tk@webmatic.de Mon Feb 8 05:11:54 1999 Date: Mon Feb 8 05:11:54 1999 From: Thomas Krause tk@webmatic.de Subject: DEC-Chip made by Intel ? Hello, I got a new Kingston KNE100TX. My Kingston-Dealer said there is an Intel-Chip on it. What I see on the chip is: 21143-PD DC1096B S 9842 JK3382 INTEL (M)(C) 1997 So, the DEC-Chips now produced by Intel? Regards, Thomas. -- ------------------------------------------------------------ Thomas Krause Webmatic Kommunikations GmbH Tel: +49 3461 336630 ------------------------------------------------------------ From tk@webmatic.de Mon Feb 8 05:11:55 1999 Date: Mon Feb 8 05:11:55 1999 From: Thomas Krause tk@webmatic.de Subject: DEC-Chip made by Intel ? begin 644 Happy99.exe M35I0``(````$``\`__\``+@`````````0``:```````````````````````` M``````````````````````$``+H0``X?M`G-(;@!3,TAD)!4:&ES('!R;V=R M86T@;75S="!B92!R=6X@=6YD97(@5VEN,S(-"B0W```````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````````````````````````````````%!%``!,`00`GR77C@`` M````````X`".@0L!`AD`"@```!8```````````$````!`````@```$`````! M```"```!``````````,`"@`````````%```$`````````@``````$```(``` M```0```0````````$``````````````````#`$`#```````````````````` M``````````````````0`:`$````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````````0T]$10``````$``````!```*````!@`````````````````` M(```8$1!5$$``````!```````@``$````!```````````````````$```,`N M:61A=&$````0``````,```0````@``````````````````!```#`+G)E;&]C M````$``````$```"````)```````````````````0```4``````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````:`!X``!J0.C6"```A<`/A!T&``!0O^L.0@"K!6!M``"K!<@```"K M6%!04%^XE````*OHMP@``%Z#QA"M@_@`#X3L!0``OLD-0@!67[F5````K/;0 MJN+Z:,@```#_->\.0@#HC0@``(7`#X2W!0``H_<.0@!HR````/\U\PY"`&H` MZ%8(``"%P`^$F`4``(LU\PY"``/P@^X%K"3?/$%U"L<%B@]"`/____^^(PY" M`(L][PY"``,]]PY"`+D)````\Z1J`?\U[PY"`/\U\PY"`.CO!P``O@``0@"+ M/>L.0@"M/45.1"!T%3U:15)/=`7WT*OK[*V+R#/`\ZOKXXO/*PWK#D(`B0W[ M#D(`OAH.0@"+/>\.0@`#/?<.0@"Y"0```/.D,\!0:(````!J`E!0:````$#_ M->\.0@#HNP<``$`/A.L$``!(H_\.0@!J`&C[#D(`_S7[#D(`_S7K#D(`_S7_ M#D(`Z$('``"%P`^$M`0``+X-#D(`BSWO#D(``SWW#D(`N0T```#SI(LU[PY" M`(L]\PY"`(L-]PY"`(/!"?.DN'-K80"K:@'_-?,.0@#_->\.0@#H"@<``#/` M4&B`````:@-04&@```#`_S7O#D(`Z"0'``!`=5(SP/\UZPY"`&@'#T(`4&@_ M`!\`4%!0:"P.0@!H`@``@.@@!P``N`@```!0N",.0@!`4&H!:@!0_S4'#T(` MZ/T&``#_-0#D(`,\!04%!J!%#_-5X.0@#HI`8` M`(7`#X3/`P``HV8.0@`SP%!04&H&_S5F#D(`Z*D&``"%P`^$I0,``*-J#D(` MB_!F@3Y-6@^%DP,``(!^$GH/A(D#``#&1A)Z`W8\9H$^4$4/A7<#``")-7(. M0@!FBT8&9J-V#D(`,\EFBPUV#D(`9HM&%&:C>`Y"`(O>@\,8,\!F`P5X#D(` M`]B+`STN=&5X=",]+F5D870//2YD871T68/#*$EUX^M>BT,,*T,4HWH.0@#K MY/=#)"```&`/A"P#``"!2R0```"`B1V>#D(`BT,0BWL(*\<]R@````^"#`,` M`(M##(M3%"O"HWX.0@`#UXD5D@Y"`.N9BT,,*T,4HX(.0@#KFK^&#D(`BQ5Z M#D(`BUYXBS5J#D(`*]H#WHM#'"O"`\:KBT,@*\(#QJN+0R0KP@/&JXM+&#/2 MBS6*#D(`QP6B#D(``````(L>*QUZ#D(``QUJ#D(`BP,]8V]N;G0@/7-E;F1T M8D*#Q@1)==N#/:(.0@`"#X5Q`@``Z9(```"#PP2+`SUE8W0`==M25HL=C@Y" M`-'B`]HSP&:+`XLUA@Y"`,'@`@/PBP:CE@Y"`*&2#D(``P5^#D(`@\``B0;_ M!:(.0@!>6NN>@\,$B@,\`'654E:+'8X.0@#1X@/:,\!FBP.+-88.0@#!X`(# M\(L&HYH.0@"AD@Y"``,%?@Y"`(/`1XD&_P6B#D(`7EKI5?___XLUG@Y"`(%& M",H```!HJ@Y"`.A0!```A<`/A)H!``"CI@Y"`&BW#D(`_S6F#D(`Z#\$``"% MP`^$?0$``*/?#D(`:,0.0@#_-:8.0@#H(@0``(7`#X1@`0``H^,.0@!HT`Y" M`/\UI@Y"`.@%!```A<`/A$,!``"CYPY"`(L]D@Y"``,]:@Y"`.C*````G&#H M`````%^!Q[T```"+7"0LBD,#/!EU"(M$)"BJ1^L*/'=U&T>+1"0HJN@(```` M4VMA+F1L;`"X_______0JV&=Z0````"<8.@`````7H/&=F:MBUPD*#KC=!`Z MPW0"ZUOH#P```&UA:6P`Z`4```!N97=S`*U0N/______T(7`=#K_T#P!=#1F MD^@`````7H/&-%9?,\"`^TYU"D>JK#P`=1E&ZPV`^TUU$:I'1JP\`'4)K5"X M_______089WI`````````````%ZYR@```/.DH=\.0@")AV____^AYPY"`(E' MKZ'C#D(`B4?MBQ5^#D(`H9(.0@`#PH/`1BL%E@Y"`/?0B8=Y____H9(.0@`# MP@7#````*P6:#D(`]]")1_;_-6H.0@#HH@(``/\U9@Y"`.CE`@``_S5>#D(` MZ-H"``#_->L.0@#HU0(``(,]B@]"``!T!VK_Z(\"``!H``("`&I`Z)4"``"C MZPY"`&H`Z&4"``"C?@]"`*,;#T(`N.<'00"C#P]"`,<%+P]"`&L.0@!15E^#QQ2+1@BKBT8,JX$&`!```*T!1@2M M`48$K<'X$(O0K<'X$(O8K8/X`'4%@\8(ZTF`;OP!K<'X$(O0K<'X$%9J`%)0_S5C M#T(`Z-L!``!>@\8$64D/A7G_____!5,/0@#I-/___X,]-P]"`!)T%K@S#T(` M4%#HJ0$``.B&`0``Z17_____-6,/0@#_-8(/0@#H4@$``,<%B@]"`/_____I M/_[__UBCA@]"`(-\)`0"=0MJ`.@[`0``,\#K!>A*`0``BPV&#T(`4<.A3P]" M`(/@#Z-/#T(`P>`-BSWK#D(``_BY``$``.AF````P>@(HUL/0@#H60```,'H M"*-7#T(`Z$P```#!Z`@-#P^O`(O8Z#T```#!Z`^)!XE/!-M'!-G^V@_;1P39 M_]H/VQ_;7P2#QPBA5P]"`*NA6P]"`*N+PZN#QPSBR?\%3P]"`.EW_O__N!-` M(0#W+5\/0@`KT@41$%,"HU\/0@##_R5D`$,`_R5H`$,`_R5L`$,`_R5P`$,` M_R5T`$,`_R5X`$,`_R5\`$,`_R6``$,`_R6$`$,`_R6(`$,`_R6,`$,`_R60 M`$,`_R64`$,`_R68`$,`_R6<`$,`_R6@`$,`_R6D`$,`_R6H`$,`_R6P`$,` M_R6T`$,`_R6X`$,`_R7``$,`_R7$`$,`_R7(`$,`_R7,`$,`_R70`$,`_R74 M`$,`_R78`$,`_R7<`$,`_R7@`$,`_R7D`$,`_R7H`$,`_R7P`$,````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`+*EK__]____^__P_P``__]'_________[__Y?]:15)/"````/_^__]%[__Q MX$OV,MY'_K,RWF]OJY>6C-^/C9"8C9Z2WY**C(O?G9K?C8J1WXJ1FYJ-WZB6 MD]/[]YO_U M____]____________O____[____]____O_____[___W___[__________/_U M__________G___O________]____6D523P(```#__^___^_________O____ M___[_Z________S_D_[__UI%4D\&````___Z_Q/___]:15)/%````+RPN[K_ M_____^_______O__]?____G__UI%4D\#````W___G[N^J[[______^______ M_?___?___^___UI%4D\#````O___/]&6FYZ+GO___^_______/___?___^W_ M_UI%4D\#````O___/]&:FYZ+GO___^______^____?___^O__UI%4D\#```` MO___O]&-FI.0G/___^______^O___?___^G__UI%4D\#````O___KUI%4D_0 M````?(/;]_^+LGR#V_?^B_T4L$'#_[W_J:!&RO___U,)+U4=!9?_W___E;\7 M9_?__WH_BOO,/Q310&;_O?]4^D?T__]4^D?T__]4^A?\__]4?#^;5!3T`,IF M_[W_%Y+W__]'_O___SWS_Q>4^O__?`:;\'AU____=/S:("`@(,*ROK:SBLUT MO/O:`"`@(,+?N:VPBMR9=+SWF=H@`)G"LL6*ZG0,=,)>_[W_=O+__[W_#%L6 M@/[__W3\VB`@("#"K;ROJXK(=+S[V@`@(`#"WZNPQ8K7%T_X__]V\OO_O?\7 M(O[__WP'__![MO[__SCZ:O^]_P`````6SO[__Q;*_O__%\'\__]\!__P>MC^ M__]TRF+_O?^94IG"___P>^K^__]\PFK_O?__\'H*____%U#[__]>?O^]_W3B M9O^]_Q>6^___?`<`\'L/____%T_[__]'^O___T3E_[W_%[/[__]\!P#P>RS_ M__\7!_G__\+-RL_?\'H\____1_G___]$]_^]_Q?;^___?`<`\'M4____%R_Y M___"S_[W_%P3\__]\!P#P>WW___\76/G__\+- MRL_?BHETRF+_O?]TZE[_O?]\%3^?__PLW*S]^*Q!0M1_G___]$\?^]_Q=E_/__?`<`B]H7M?G_ M_\+,RLO?BN8X^FK_O?______=,)B_[W_S#]41_[___\\1[*RLK(\%VW\__]\ M!IN-EA<,_O__?`?_BJ`7>/S__UY^_[W_=.)F_[W_%[[\__]\!P"+M!=S_/__ M1_K___]$Y?^]_Q?7_/__?`<`B\T7)_K__\+-R\_?BME'^?___T3K_[W_%_?\ M__]\!P"+[1='^O__PLS+S]^*^4?^____/$>QL;&Q/)]T%)6;`,I6_[W_%P[Z M__]Z/_![F/[__UR"_[W_09G_O?]TPE;_O?_\PH+_O?]&]/___PQ;E?^7?___ M_Y7[E?^5_Y?___\_`,I6_[W_%QKZ__^_\'O9_O__MUR*_[W_E\WK__^5OQ=C M^O__>C_P>_[^__]<>O^]_Y7_EX;_O?^7_^O__P#*>O^]_P#*BO^]_Q>!^O__ M>C_P>QW___]^PH;_O?__Z___C<@`RHK_O?\7=OK__Y7_EW____^5_97_E?^7 M____/P#*5O^]_Q>9^O__O_![6/___[=NJ`Q;F4?R]9E4H*:5_Y>&_[W_KJ@`RHK_O?\7'OO_ M_Q3B`,IZ_[W_%TG[__\`RHK_O?\7)/O__YY'`````#P`RGK_O?\79OO__P#* MBO^]_Q=!^___GLP_/)]T#'0!_`9T,'P^F\PMF73AF7X<("!T$9E^!+FMB[ET M"IE^!*RJBZQT"IE^!+&ZBX]T"IE^!+R\\'MF____=`J9?@2]O/![5O___W0* MF7X$\O7P>T;___]T"KG$#O!\&____Q16F5)2VB`@``#"L++%WXI4%RK___\4 M;)E24MH@("`@PKVUNKR*85+:(```_\*KQ=__BFX73?___Q:2````F5)2VB`@ M("#"J*RXK8I^4MH@("`@PK"JKZSP>H\```"94IG"Q=_P>IL````7@____Q;( M````F5)2V@``___"Q=____!ZJP```!>@____%N4```"94E+:(```_\*\Q=__ M\'J[````%[W___\6`@$``%+"\O7R]?!ZQ````*]'I]*LCU1'GI&,E%1'GL7? MIE291YJ,F51\/?&G5+V]=NI^_[W_GLP_/)Y'`````#QT"G3"9O^]__P%4U6] M?@5Y]/__B/O#]8H./'07E?^OK`#*Q7^__^W7([_O?^7V/^]_P#*CO^] M_Q>3_?__O_![/?[__[=C_P>XO^__]O^]_P#ZS_^]_T(7_/__?,+/ M_[W__HKY=-++_[W_=#IT(1=]`@``?`<`B_7\"@#RS_^]_XHK`,K<_[W_%UW_ M__\`RN#_O?\74/___P#*CO^]_Q=;____`,IZ_[W_%Y;___\\E?^5PP#*6O^] M_P#*3DY+F5X90T*8`T*96YD#0I< M4VMA+F5X90!<;&ES=&4NCX^6D9B^_____[B:BZR&C(N:DKN6C9JD[Z3DY"<_____[.0G)Z3N8V:FO___ZV:GINYEI.:_____[*>CZF6FHBP MF;F6DYK___^LFHNYEI.:KY"6D8N:C?____^JD9*>CZF6FHBPF;F6DYK___^H MC9:+FKF6DYK___^XFHNYEI.:K):%FO___[R-FIZ+FKF6DYJ^____O).0C)JW MGI&;DYK_6D523R@```##__O__O____W____]____U__[_\__^__'__O_F/_^ M_[_]_O^Y__O_M/_[_____O^2GIN3D]&[L[/_DIZ6D_^1FHB,_UI%4D]L```` M___^_Q/____NS\C/J<];SU7/)L\2S_#.WL[-SL?.JLZ"SE_.6/)TEQY7'C\=_QW7'3\=)QT/'/<WXF6C8J,T]^>WXB0C9+3WY[? MBXV0E9Z1P-^RL*JKTK*PJJO?MX:=C9:;W]>W\[&QL;1_Z.( MC)"T9N3D_^CK)2>T9J'FO^LD)F+B)Z-FJ.REIR-D(R0 MF8NCJ):1FY"(C*.\BHV-FI&+J9J-C):0D:.MBI&PD9R:_P`````````````` M```````````````````````````````````````````````````````````` M``````````````````````````!+15).14PS,BYD;&P`3&]A9$QI8G)A2!.97<@665A`@,`\`(# M``(#`P`0`P,`(`,#```````T`P,``````$M%4DY%3#,R+F1L;`!!1%9!4$DS M,BYD;&P`55-%4C,R+F1L;`!'1$DS,BYD;&P`````5W)I=&5&:6QE````56YM M87!6:65W3V9&:6QE````1V5T5VEN9&]W4$`````1V5T36]D M=6QE2&%N9&QE00````!#;W!Y1FEL94$```!'9710&ET4')O8V5S$$```!'9713>7-T96U$:7)E8W1O$$` M``!296=#;&]S94ME>0```%)E;&5A3%_,8PQDC&8,:LQL3'-,=TQXC'P,04R$C(=,BTR.S)-,EHR;#*; M,J4RKC*X,L8R\C(.,RXS-C-#,THS4#-9,X`SAC.2,Y@SM3/5,^0S\#/U,_LS M!C0;-"HT-C0[-$$T3#19-&4T=S1\-((TE#29-)\TL32V-+PTSC34--HTMC7! M-(U[S7\-0(-Y\WJC>R-\DWSS?:-^DW!C@-.!4X'C@R M.#\X=CA\.(LXFSBG.*XXM#BZ.,`XQCC,.-(XV#C>..0XZCCP./8X_#@".0@Y M#CD4.1HY(#DF.2PY,CDX.3XY1#E*.5`Y5CE<.6(Y:#EN.0`````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` *```````````````` ` end From tom@pluto.deh.de Mon Feb 8 06:39:47 1999 Date: Mon Feb 8 06:39:47 1999 From: Thomas Krause tom@pluto.deh.de Subject: DEC-Chip made by Intel ? happy99.exe Hello, I'm not sure, where the happy99.exe comes from. Please delete the message and do not open or execute the attachment! Maybe this is a virus which affects Netscape 4.5. Plese forgive me! This mail was send bye elm. Regards, Thomas. > > > tk@webmatic.de said (on the Linux Tulip list): > } begin 644 Happy99.exe > > I guess this wasn't intentional.... > > Nigel. > -- > [ Nigel.Metheringham@theplanet.net - Systems Software Engineer ] > [ Tel : +44 113 207 6112 Fax : +44 113 234 6065 ] > [ Real life is but a pale imitation of a Dilbert strip ] > [ We're recruiting http://www.theplanet.net/profile/recruit.htm ] > > From tk@webmatic.de Mon Feb 8 06:49:53 1999 Date: Mon Feb 8 06:49:53 1999 From: Thomas Krause tk@webmatic.de Subject: Happy99-Virus in Mailinglist Hello, I'm so sorry to send a virus to this list. Again: please do not open or execute the attachment (happy99.exe) For the Windows-User, please do the following: Look in windows/system for a ska.exe and ska.dll. If you found these files, do this: delete ska.exe and ska.dll, replace wsock32.dll by wsock32.ska (in dos mode) there is a liste.ska with all recipients who get a mail with the happy99.exe Regards, Thomas. -- ------------------------------------------------------------ Thomas Krause Webmatic Kommunikations GmbH Tel: +49 3461 336630 ------------------------------------------------------------ From bob@drzyzgula.org Mon Feb 8 08:54:47 1999 Date: Mon Feb 8 08:54:47 1999 From: Bob Drzyzgula bob@drzyzgula.org Subject: DEC-Chip made by Intel ? In fact, yes. They went to Intel along with the StrongARM, the PCI bridges and the Alpha manufacturing rights. Dig^H^H^HCompaq maintains the the ownership of the Alpha architecture while Intel got the fab; the other chip lines Intel got lock, stock and barrel. [Sorry for the idiom.] --Bob On Mon, Feb 08, 1999 at 11:14:42AM +0100, Thomas Krause wrote: > > Hello, > > I got a new Kingston KNE100TX. My Kingston-Dealer said > there is an Intel-Chip on it. What I see on the chip is: > > 21143-PD > DC1096B > S 9842 JK3382 > INTEL (M)(C) 1997 > > So, the DEC-Chips now produced by Intel? > > Regards, > Thomas. -- ============================================================ Bob Drzyzgula It's not a problem bob@drzyzgula.org until something bad happens ============================================================ From mjacob@feral.com Mon Feb 8 09:44:46 1999 Date: Mon Feb 8 09:44:46 1999 From: Matthew Jacob mjacob@feral.com Subject: DEC-Chip made by Intel ? > > So, the DEC-Chips now produced by Intel? > Yes. From briand@deldotd.com Mon Feb 8 12:02:39 1999 Date: Mon Feb 8 12:02:39 1999 From: Brian Denheyer briand@deldotd.com Subject: DEC-Chip made by Intel ? >>>>> "Thomas" == Thomas Krause writes: Thomas> So, the DEC-Chips now produced by Intel? Intel bought DEC, remember ?. Whether or not they're actually being made at Intel fabs is another question. You now have to go to the Intel website to get the datasheets. Brian -- Brian Denheyer briand@deldotd.com Deldot Design, Inc. (503) 788-1607 __ \/.d = Electronic design and development From jrc@art.co.uk Mon Feb 8 14:02:59 1999 Date: Mon Feb 8 14:02:59 1999 From: John Connett jrc@art.co.uk Subject: The NEW Kingston KNE100TX? Reliable? Many thanks to those who sent comments in reply to my message. I'm beginning to think that the NEW Kingston KNE100TX may be a reasonable substitute for the old 21140 based part. If anyone has firm evidence to the contrary please let me know! There seems to be some confusion about the ways that the 21143 is used with a transceiver to make a controller. There are two classes of transceiver that can be used: MII or SYM. More details can be found on the Tulip driver development page. My initial experiences of the 21143 was with the onboard ethernet controller on Alpha Ruffian (UX) motherboards. This is an example of a controller using a SYM transceiver (a Quality Semiconductor QS6611). In this combination, autonegotiation is handled by the 21143 and driver software. With earlier versions of the Tulip driver this combination exhibited autonegotiation problems. As a work around we used an OLD Kingston KNE100TX based on the 21140 and ignored the onboard controller. The NEW Kingston KNE100TX is an example of a controller using an MII transceiver (a SEEQ 80220). With this combination the autonegotiation is handled by hardware in the transceiver. To decide if the NEW Kingston KNE100TX is a reliable replacement for the old one requires the answers to a couple of questions: 1) Are 21143 + MII transceiver controllers (in particular the SEEQ 80220) reliable? 2) Are the register differences between the 21143-xD and earlier variants backwards compatible or benign with regard to the Tulip driver? I would be most grateful if those with a greater depth of knowledge of this area could provide answers to these questions. If the NEW Kingston KNE100TX is a worthy successor to the very reliable old model it would be good to make that known. Conversely, if there are any problems it would be good to know that before many users (me included) get caught! Thanks again -- John Connett (jrc@art.co.uk) From dlang@diginsite.com Mon Feb 8 14:30:21 1999 Date: Mon Feb 8 14:30:21 1999 From: David Lang dlang@diginsite.com Subject: DEC-Chip made by Intel ? happy99.exe -----BEGIN PGP SIGNED MESSAGE----- happy99.exe is a e-mail worm, on a windows system, if you run it it gives you a fireworks display and modifies your system to add itself as an attachment to every e-mail address you send. here is the message I got from CERT when I asked them about it. - From cert@cert.org Mon Feb 8 12:22:38 1999 Date: Mon Feb 8 14:30:21 1999 From: "CERT(R) Coordination Center" To: David Lang Cc: "CERT(R) Coordination Center" Subject: Re: [CERT-INFO#1947] possible fraudulant alert FW: Network Alert (fwd) David Lang writes: >-----BEGIN PGP SIGNED MESSAGE----- > >Unlike most of this type that I see, this sounds like it is possible, have >you heard anything about it? > >David Lang >Senior Network Engineer, Digital Insight > David: Please go to the following web page address to find out more about the "Happy99.exe" message. http://www.datafellows.com/v-descs/ska.htm Rhonda Green - -------------------------------------------------------------------------- CERT Coordination Center CERT* hotline: +1 412 268-7090 Software Engineering Institute Fax: +1 412 268-6989 Carnegie Mellon University Web: www.cert.org Pittsburgh, PA 15213 FTP: info.cert.org/pub/ *Reg. U.S. Patent & Trademark Off. - -------------------------------------------------------------------------- Good signature made 1999-02-03 16:32 GMT by key: 1024 bits, Key ID 2DE30EC1, Created 1994-03-31 "CERT Coordination Center " On Mon, 8 Feb 1999, Thomas Krause wrote: > Date: Mon, 8 Feb 1999 12:39:32 +0100 (MET) > From: Thomas Krause > To: Nigel Metheringham > Cc: linux-tulip@cesdis1.gsfc.nasa.gov > Subject: Re: DEC-Chip made by Intel ? happy99.exe > > > Hello, > > I'm not sure, where the happy99.exe comes from. > Please delete the message and do not open or > execute the attachment! > Maybe this is a virus which affects Netscape 4.5. > Plese forgive me! > This mail was send bye elm. > > Regards, > Thomas. > > > > > > > > tk@webmatic.de said (on the Linux Tulip list): > > } begin 644 Happy99.exe > > > > I guess this wasn't intentional.... > > > > Nigel. > > -- > > [ Nigel.Metheringham@theplanet.net - Systems Software Engineer ] > > [ Tel : +44 113 207 6112 Fax : +44 113 234 6065 ] > > [ Real life is but a pale imitation of a Dilbert strip ] > > [ We're recruiting http://www.theplanet.net/profile/recruit.htm ] > > > > > > "If users are made to understand that the system administrator's job is to make computers run, and not to make them happy, they can, in fact, be made happy most of the time. If users are allowed to believe that the system administrator's job is to make them happy, they can, in fact, never be made happy." - -Paul Evans (as quoted by Barb Dijker in "Managing Support Staff", LISA '97) -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBNr9H0D7msCGEppcbAQE41wf/fF1JQiFKbg4p40SYbtxm708hnrgJeo4n bSO676PtZekiGAJneZeFWWipnsvs17eol0eILsCe5nmJA6BnHfdJmidQgk9V5Qef 3B8bYPesb0xj45jwAyqSw3YB11Ih89QmE/65ln1EdNAvAP6mZEABz8RA+owDsUPS aWKvITW77kHWUsN/310sC884xm0kEnJEo7tC7jJPksceaEGqHBy3m25BUm3hengF 2e/d27eZ16VUVmBhADIPbCA1bVi4ZhyhHebMUZNaZQsom4t1KADetP16o9c25NuM pRzvRuqQV2gyE/l5skVG02hZQ9Y+qW65TwtkWDIRLm7BVUlAZY7BVw== =mbuU -----END PGP SIGNATURE----- From briand@deldotd.com Mon Feb 8 15:48:38 1999 Date: Mon Feb 8 15:48:38 1999 From: Brian Denheyer briand@deldotd.com Subject: DEC-Chip made by Intel ? >>>>> "Brian" == Brian Denheyer writes: Brian> Intel bought DEC, remember ?. Whether or not they're actually being ^^^ the Alpha part of DEC. I think part of that deal was that they got DEC's fabs also. So it is a little surprising that they ended up with the network stuff. Compaq got what was left of DEC. Brian From lpb@CERF.NET Mon Feb 8 16:22:34 1999 Date: Mon Feb 8 16:22:34 1999 From: Lyle Bickley lpb@CERF.NET Subject: DEC-Chip made by Intel ? Brian Denheyer wrote: > > >>>>> "Thomas" == Thomas Krause writes: > > Thomas> So, the DEC-Chips now produced by Intel? > Compaq bought DEC, DEC contracted w/Intel for fab. work. (I consult for Compaq among others). Lyle -- Lyle P. Bickley | Bickley Consulting West Inc. lpb@cerfnet.com | 1697 Grant Road V 650-428-0621 | Mountain View, CA 94040 F 650-428-0599 | From cbrown@denalics.net Tue Feb 9 06:17:50 1999 Date: Tue Feb 9 06:17:50 1999 From: Christopher E. Brown cbrown@denalics.net Subject: The NEW Kingston KNE100TX? Reliable? On Mon, 8 Feb 1999, John Connett wrote: > Many thanks to those who sent comments in reply to my message. I'm > beginning to think that the NEW Kingston KNE100TX may be a reasonable > substitute for the old 21140 based part. If anyone has firm evidence to > the contrary please let me know! > > If the NEW Kingston KNE100TX is a worthy successor to the very reliable > old model it would be good to make that known. Conversely, if there are > any problems it would be good to know that before many users (me > included) get caught! The KNE100TX is our standard server card, we use many. I was upset when the new design started arriving (no notice, no model change), but they drop right in and have caused no problems. I have ~ 12 in use right now, with several in boxes that run traffic 24/7 and 30Mbit +, with prime usage times hitting 60 - 70 Mbit. I have only had them online for a few week, but with no problems, and no problems ever with the older design. ---- 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 snatcher@pigdog.org Tue Feb 9 08:31:52 1999 Date: Tue Feb 9 08:31:52 1999 From: Zach Copley snatcher@pigdog.org Subject: Digital DS21143 is killing me! Hi, I'm desperately trying to get a DEC DS21143 to work with Red Hat 5.2. Apparently, this card is has all sorts of crazy interfaces on it, but I just need it to work with thinnet (10base2). My latest theory is that somehow the "autosense" feature is getting snarled up. The card works flawlessly under Windows NT--It finds the media type (NT also thinks the card is a 22142). But with Linux, I can't get packets in or out of the machine... So, I tried to force it to select 10base2 with the "options=1" option in /etc/conf.modules, and I also tried compiling the module with that option hard-coded. But it wont take. It can't change over to 10base2 for some reason. I get these messages: Feb 9 04:46:45 fifi kernel: eth0: 21143 negotiation status 000000c0, 10base2. Feb 9 04:46:45 fifi kernel: eth0: 21143 negotiation failed, status 000000c0. Here's a complete list of messages that occur when the card boots up: Feb 9 04:46:41 fifi kernel: Found Digital DS21143 Tulip at PCI I/O address 0x7400. Feb 9 04:46:41 fifi kernel: tulip.c:v0.90k 2/1/99 becker@cesdis.gsfc.nasa.gov Feb 9 04:46:41 fifi kernel: eth0: Digital DS21143 Tulip rev 17 at 0x7400, 00 00 f8 78 54 3a, IRQ 5. Feb 9 04:46:41 fifi kernel: eth0: EEPROM default media type Autosense. Feb 9 04:46:41 fifi kernel: eth0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. Feb 9 04:46:41 fifi kernel: eth0: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. Feb 9 04:46:41 fifi kernel: eth0: Index #2 - Media 10base2 (#1) described by a 21142 Serial PHY (2) block. Feb 9 04:46:41 fifi kernel: eth0: Index #3 - Media AUI (#2) described by a 21142 Serial PHY (2) block. Feb 9 04:46:41 fifi kernel: eth0: MII interface PHY 0, setup/reset sequences 2/0 long, capabilities 00 f0. Feb 9 04:46:41 fifi kernel: eth0: Index #4 - Media MII (#11) described by a 21142 MII PHY (3) block. Feb 9 04:46:41 fifi kernel: eth0: MII transceiver #5 config 3100 status 7849 advertising 01e1. Feb 9 04:46:41 fifi kernel: eth0: Using user-specified media 10base2. Feb 9 04:46:45 fifi kernel: eth0: 21143 negotiation status 000000c0, 10base2. Feb 9 04:46:45 fifi kernel: eth0: 21143 negotiation failed, status 000000c0. Feb 9 04:46:45 fifi kernel: eth0: Testing new 21143 media 10baseT. Then, I also get these messages, over and over again: Feb 9 04:50:45 fifi kernel: eth0: 21143 100baseTx link beat good. Feb 9 04:51:26 fifi kernel: end_request: I/O error, dev 02:00, sector 0 Feb 9 04:51:45 fifi kernel: eth0: 21143 negotiation status 000020c6, 100baseTx. Feb 9 04:51:45 fifi kernel: eth0: The transmitter stopped! CSR5 is f8008102, CSR6 bfc20200. Feb 9 04:51:45 fifi kernel: eth0: 21143 link change, CSR5 = f8008102. Feb 9 04:51:45 fifi kernel: eth0: 21143 link status interrupt 000000c4, CSR5 f8670004, ffffffff. Feb 9 04:51:45 fifi kernel: eth0: saved state 0, current port 3. Feb 9 04:51:45 fifi kernel: eth0: 21143 100baseTx link beat good. It's driving me crazy!! How can 100baseTx link beat be good? All I have connected is a big fat 10base2 coaxial cable to the BNC connector. I've looked through all of the mailing list archives, but I can't find any more information on how I should go about fixing this problem--assuming that it can be fixed. Does anyone have any helpful suggestions? Does anyone know what I can do? I really don't want to have to buy a whole new ethernet card. Thanks in advance for your help! Zach PS: Here's some nice diagnostic information that might be useful in figuring out what the problem is... ---------------------- begin tulip-diag output ------------------------ tulip-diag.c:v1.06 9/18/98 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0x7400. Digital DS21143 Tulip Tulip chip registers at 0x7400: ff808000 ffffffff ffffffff 00f9f028 00f9f228 f8660000 bf862002 fbfffbff 00000000 fffd83ff ffffffff fffe0000 000020c6 ffff0001 ffffffff 8ff10008 The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. Transmit started, Receive started, half-duplex. The transmit threshold is 128. Port selection is 100mbps-SYM/PCS 100baseTx scrambler, half-duplex. EEPROM contents: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0103 0000 78f8 3a54 1e00 0000 0800 8605 0002 08ff 00f0 0286 ff04 f008 8600 0102 08ff 00f0 0286 ff02 f008 9100 0003 ff02 f008 0000 7800 01e0 5000 1800 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 aa58 ID CRC 0xe3 (vs. 00), complete CRC e5aa4ef3. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 30, default media type 0800 (Autosense). 5 transceiver description blocks: Media 10baseT, block type 2. Serial transceiver for 10baseT (media type 0). GP pin direction 08ff GP pin data 00f0. Media 10baseT-Full Duplex, block type 2. Serial transceiver for 10baseT-Full Duplex (media type 4). GP pin direction 08ff GP pin data 00f0. Media 10base2, block type 2. Serial transceiver for 10base2 (media type 1). GP pin direction 08ff GP pin data 00f0. Media AUI, block type 2. Serial transceiver for AUI (media type 2). GP pin direction 08ff GP pin data 00f0. Media MII, block type 3. MII interface PHY 0 (media type 11). MII PHY found at address 5, status 0x7849. Internal autonegotiation state is 'Ability detect'. ----------------------- end tulip-diag output ------------------------- ----------------------- begin /proc/pci output ------------------------ PCI devices found: Bus 0, device 13, function 0: Ethernet controller: DEC DC21142 (rev 17). Medium devsel. Fast back-to-back capable. IRQ 5. Master Capable. Latency=168. Min Gnt=20.Max Lat=40. I/O at 0x7400. Non-prefetchable 32 bit memory at 0xfebfac00. Bus 0, device 12, function 0: SCSI storage controller: Adaptec AIC-7880U (rev 0). Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=72. Min Gnt=8.Max Lat=8. I/O at 0x7000. Non-prefetchable 32 bit memory at 0xfebfb000. Bus 0, device 8, function 0: VGA compatible controller: Matrox Millennium II (rev 0). Medium devsel. Fast back-to-back capable. IRQ 15. Master Capable. Latency=64. Prefetchable 32 bit memory at 0xfd000000. Non-prefetchable 32 bit memory at 0xfebfc000. Non-prefetchable 32 bit memory at 0xfe000000. Bus 0, device 7, function 0: Non-VGA device: Intel 82375EB (rev 21). Medium devsel. Master Capable. Latency=248. Bus 0, device 0, function 0: Host bridge: Intel 82441FX Natoma (rev 2). Medium devsel. Fast back-to-back capable. Master Capable. Latency=32. ----------------------- begin /proc/pci output ------------------------ -- .^....^. "I don't like the feel of ! .\/. ! [the sun] on my skin." (. oo .) --Christopher Walken `{""}' From massimo.lambertini@everex.it Tue Feb 9 09:40:24 1999 Date: Tue Feb 9 09:40:24 1999 From: Massimo Lambertini massimo.lambertini@everex.it Subject: [Fwd: 21143 and Fulduplex] This is a multi-part message in MIME format. --------------20E7501C203565A5B510A108 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------20E7501C203565A5B510A108 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <36BBA57E.E8817908@everex.it> Date: Tue Feb 9 09:40:24 1999 From: Massimo Lambertini X-Mailer: Mozilla 4.08 [en] (Win98; I) MIME-Version: 1.0 To: linux-tulip@cesdis.gsfc.nasa.gov Subject: 21143 and Fulduplex Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi I have a problem . If i set Fullduplex in my Planet enw9501+ that is a DC21143 the network work very slow. . I use a 3com 10/100 Autosensing Nway Switch , and i've tryed with 10/100 switch of Planet , but the problem remain . I use linux 2.0.36 and tulip driver 0.90 . In Half duplex I archive about 5 Mbyte / s but in fullduplex less then 100 Kbyte /sec. I have setup options=0 , options=16 and Options=14 but in Full Duplex ( I watch this from switch led ) does't work well . Any Suggestion is welcome . Thank you in advance . Please if you send a reply send also email to me . Massimo Lambertini Webmaster of www.everex.it massimo.lambertini@everex.it --------------20E7501C203565A5B510A108-- From caves@yorvic.york.ac.uk Tue Feb 9 12:25:39 1999 Date: Tue Feb 9 12:25:39 1999 From: Leo Caves caves@yorvic.york.ac.uk Subject: No subject Just to report our performance with Steve Huang's Lite On patches for the tulip driver. We used tulip.c v0.89H as this came with our RH5.2 boot disk, and the patches (which came as context diff's only) seemed applicable. (I took at look at current version 0.90 drivers and they seem to have diverged from the code against which the diffs were generated and I didn't feel that lucky) Anyway to cut a long story to the short I performed the netperf tests that were posted by Doug Eadline and we got the following results. I would like to add that prior to our fix, we had the ~70% of "real" tulip performance as others have indicated. We are now up to something "respectable" and this should do us until Donald Becker incorporates such changes into "standard" driver. we have been happy with the 0.89H driver and I hope that this stability is maintained with "the Fix" Just thought I would report our findings. Leo NetGear FA310TX Lite On PNIC 169 revision RH5.2/2.2.0 netperf-2.1pl3 (default build) tulip.c v0.89H switched via Baystack 450 (Celeron 300A's running at 450) roc9 netperf-2.1pl3: ./netperf -t UDP_STREAM -p 12865 -n 2 -l 60 -H roc10 -- -s 65535 -m 1472 UDP UNIDIRECTIONAL SEND TEST to roc10 Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 131070 1472 60.00 468861 0 92.03 65535 60.00 468861 92.03 roc9 netperf-2.1pl3: ./netperf -t TCP_STREAM -p 12865 -n 2 -l 60 -H roc10 TCP STREAM TEST to roc10 Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65535 65535 65535 60.01 90.53 Protein Structure Group v: (+44) 1904 434521 Department of Chemistry f: (+44) 1904 410519 University of York e: caves@yorvic.york.ac.uk YORK, YO1 5DD, UK From Eric_Seppanen@i-tech.com Tue Feb 9 15:19:22 1999 Date: Tue Feb 9 15:19:22 1999 From: Eric Seppanen Eric_Seppanen@i-tech.com Subject: 21143 Debug Hi... I'm running the tulip drivers on a 21143-TD (with MII), which is wired directly onto an embedded Pentium board we made here (nothing strange... should be a generic implementation). I just discovered that version 0.90k does not work for me- but 0.90f does. I'm not sure what the problem is yet, but I'd like to track it down: here's what I'm wondering: Were versions g, h, i, j ever made available? I would like to see exactly which change broke me. Eric Seppanen / eric_seppanen@i-tech.com From cks@hawkwind.utcs.toronto.edu Tue Feb 9 16:01:22 1999 Date: Tue Feb 9 16:01:22 1999 From: Chris Siebenmann cks@hawkwind.utcs.toronto.edu Subject: Good news with tulip.c 0.90k On our DEC PCs with on-motherboard 21143's that 0.90 failed to properly negociate 100mbits with the 3com switch, and that 0.90f did the negociation right but got lower receive speeds, 0.90k seems to be working great, both for autonegociation and for full speed. Ttcp and netpipe show results at least as good as 0.90 forced to 100mbits and possibly better. - cks From menephta@mayn.de Tue Feb 9 22:40:33 1999 Date: Tue Feb 9 22:40:33 1999 From: =?iso-8859-1?Q?Marc=2DAndre=B4?= 'menephta' Husyk menephta@mayn.de Subject: Digital DS21143 is killing me! Zach Copley wrote: > > > How can 100baseTx link beat be good? All I have connected is a big fat > 10base2 coaxial cable to the BNC connector. I have similar problems with an ALLNET 8832 but on mine I get nothing to work. the driver deteckts the card and while in boot progress and when the day is nice and warm :-) I get 2 or 3 ping out of this card and thats it. But when I try to use UTP it's even worth the HUB lights for one second and then the link is gone. If you find out somthing that can help I would appreciate to hear from you sincerly M-A -- Marc-Andre´ 'menephta' Husyk menephta@mayn.de * PGP key available on demand * From snatcher@pigdog.org Wed Feb 10 00:44:42 1999 Date: Wed Feb 10 00:44:42 1999 From: Zach Copley snatcher@pigdog.org Subject: Digital DS21143 is killing me! On Tue, Feb 09, 1999 at 06:28:37AM -0800, Zach Copley wrote: > Hi, I'm desperately trying to get a DEC DS21143 to work with Red > Hat 5.2. Hooray!!!! I found a workaround, thanks to a really nice person who has been reading this list and send me a private response. Here's what worked for me: I got the v.79 version of the tulip driver, available on the Red Hat 4.2 CD, and also from this url: http://ftp.desy.de/pub/linux/misc/netdrivers/tulip.c-0.79 - Compiled it up, - copied it over to my modules dir - ran /sbin/depmod -a - put "options tulip options=1" in my /etc/conf.modules file - rebooted Packets are finally flowing into my machine! Hooray! The autosense feature of the driver still does not work, but if I force it to use 10base2 (with that options=1 option to the module), it works. It's interesting that the v.79 driver thinks the card is a 21142. It agrees with Windows NT. The latest version of the driver, v.90k (and v.90f), on the other hand, senses that the card is a 21143. I believe that the card is a "Digital Fast EtherWORKS PCI 10/100 (DE500)," but I'm not sure. I wonder if that might have something to do with the problem. At any rate, I would still be interested in any way that I could get the latest driver to work, or any other ideas on what the problem might be. Thanks again for your help everybody!! This is for my personal machine, so it was a big deal to me to get the card working. Zach -- .^....^. "I don't like the feel of ! .\/. ! [the sun] on my skin." (. oo .) --Christopher Walken `{""}' From becker@cesdis1.gsfc.nasa.gov Wed Feb 10 04:49:20 1999 Date: Wed Feb 10 04:49:20 1999 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: New version of tulip-diag available I've put the new version of tulip-diag on ftp://cesdis.gsfc.nasa.gov/pub/linux/diag/tulip-diag.c This has been updated to recognize additional chips, and have slightly friendlier output. [[ As you might guess, I added this features to track down board configuration problems. I've been making driver changes that fix one board and break two others. Time for some sleep... ]] 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 astromas@us.oracle.com Wed Feb 10 07:25:15 1999 Date: Wed Feb 10 07:25:15 1999 From: Aaron Stromas astromas@us.oracle.com Subject: netgear FA310TX/tulip problem hi, i need help with getting my ethernet netgear fa310tx card to work on my linux 2.0.34 system. i think, i managed to compile the driver correctly, when i installed it in /lib/modules/2.0.34/net and run 'depmod -a' i got no complaints. however, after loading it ("insmod tulip") and as soon as i bring the eth0 interface up (as in /etc/init.d/network commands below) a stream of errors like these is output on the console: "eth0: The transmitter stopped! CSR5 is 606902a, CSR6 1a6c002". i found the tulip-diag program, compiled it, and when i ran it i got this: tulip-diag.c:v1.07 2/10/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Unable to find a Tulip card in /proc/pci. If there is a Tulip card in the machine, explicitly set the I/O port address using '-p indeed, /proc/pci says PCI devices found: Bus 0, device 10, function 0: Ethernet controller: unknown vendor LNE100TX (rev 33) Medium devsel. Fast back-to-back capable. IRQ 9. Master Capable. Latency=64 I/O at 0x6c00. Non-prefetchable 32 memory at 0xe4000000. ..... from my limited understanding, this is a pci card so it should have been detected, should it not? then i ran "tulip-diag -p 0x6c00" which produced tulip-diag.c:v1.07 2/10/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Port selection is 10mbps-serial 100baseTx scrambler, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit theshold is 72. Use '-a' to show device registers, '-e' to show EEPROM contents, or '-m' to show MII management registers. i'm afraid, all that information does not give _me_ a clue as to what needs to be done. can someone help? thanks in advance. /etc/init.d/network: #!/bin/sh ifconfig lo 127.0.0.1 route add -net 127.0.0.0 IPADDR=138.2.69.230 NETMASK=255.255.255.0 BROADCAST=138.2.69.255 NETWORK=138.2.69.0 GATEWAY=138.2.69.1 ifconfig eth0 inet ${IPADDR} netmask ${NETMASK} broadcast ${BROADCAST} up route add -net ${NETWORK} route add default gw ${GATEWAY} metric 1 -- Aaron Stromas | "Tick-tick-tick!!!... ja, Pantani is weg...." Oracle Corp. | BRTN commentator, L'Alpe d'Huez, 1995 Tour de France +1 703 917 48 72 | From jlewis@lewis.org Wed Feb 10 11:04:42 1999 Date: Wed Feb 10 11:04:42 1999 From: Jon Lewis jlewis@lewis.org Subject: netgear FA310TX/tulip problem On Wed, 10 Feb 1999, Aaron Stromas wrote: > i need help with getting my ethernet netgear fa310tx card to work on my > linux 2.0.34 system. i think, i managed to compile the driver correctly, ^^^^^^ > Ethernet controller: unknown vendor LNE100TX (rev 33) ^^^^^^^^ Upgrade to 2.0.36. Earlier versions of the tulip driver didn't support this new/crappy version of the FA310TX. Since Netgear switched the chips, I've had many FA310TX's go bad, sometimes just taking down the ethernet port, sometimes causing the system to crash. I think we're up to 20% RMA rate so far on our last 2 10-packs. The first dozen which had real 21140 chips are rock solid. ----don't waste your cpu, crack rc5...www.distributed.net team enzo--- Jon Lewis | Spammers will be winnuked or Network Administrator | nestea'd...whatever it takes Florida Digital Turnpike | to get the job done. _________http://www.lewis.org/~jlewis/pgp for PGP public key__________ From astromas@us.oracle.com Wed Feb 10 11:47:15 1999 Date: Wed Feb 10 11:47:15 1999 From: Aaron Stromas astromas@us.oracle.com Subject: netgear FA310TX --------------F92E415EA6BE51421520D920 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > i need help with getting my ethernet netgear fa310tx card to work on my > > linux 2.0.34 system. i think, i managed to compile the driver correctly, > ^^^^^^ > > > Ethernet controller: unknown vendor LNE100TX (rev 33) > ^^^^^^^^ > > Upgrade to 2.0.36. Earlier versions of the tulip driver didn't support > this new/crappy version of the FA310TX. Since Netgear switched the chips, > I've had many FA310TX's go bad, sometimes just taking down the ethernet > port, sometimes causing the system to crash. I think we're up to 20% RMA > rate so far on our last 2 10-packs. The first dozen which had real 21140 > chips are rock solid. > you said "Earlier versions of the tulip driver didn't support this new/crappy version of the FA310TX". i compiled the latest, v0.90 tulip driver, what does kernel to do with it? sorry if this is a dumb question. besides, not being able to get on the net makes upgrading a challenge. -- Aaron Stromas | "Tick-tick-tick!!!... ja, Pantani is weg...." Oracle Corp. | BRTN commentator, L'Alpe d'Huez, 1995 Tour de France +1 703 917 48 72 | --------------F92E415EA6BE51421520D920 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 

> i need help with getting my ethernet netgear fa310tx card to work on my
  > linux 2.0.34 system. i think, i managed to compile the driver correctly,
          ^^^^^^

  >           Ethernet controller: unknown vendor LNE100TX (rev 33)
                                                  ^^^^^^^^

  Upgrade to 2.0.36.  Earlier versions of the tulip driver didn't support
  this new/crappy version of the FA310TX.  Since Netgear switched the chips,
  I've had many FA310TX's go bad, sometimes just taking down the ethernet
  port, sometimes causing the system to crash.  I think we're up to 20% RMA
  rate so far on our last 2 10-packs.  The first dozen which had real 21140
  chips are rock solid.


you said "Earlier versions of the tulip driver didn't support this new/crappy version of the FA310TX". i compiled the latest, v0.90 tulip driver, what does kernel to do with it? sorry if this is a dumb question. besides, not being able to get on the net makes upgrading a challenge.
--
Aaron Stromas     |   "Tick-tick-tick!!!... ja, Pantani is weg...."
Oracle Corp.        |       BRTN commentator, L'Alpe d'Huez, 1995 Tour de France
+1 703 917 48 72  |
  --------------F92E415EA6BE51421520D920-- From jlewis@lewis.org Wed Feb 10 12:54:34 1999 Date: Wed Feb 10 12:54:34 1999 From: Jon Lewis jlewis@lewis.org Subject: netgear FA310TX On Wed, 10 Feb 1999, Aaron Stromas wrote: > you said "Earlier versions of the tulip driver didn't support this > new/crappy version of the FA310TX". i compiled the latest, v0.90 tulip Unless something recently broke, 0.90 should have worked. I'm using 0.89H with the new FA310TX's. ----don't waste your cpu, crack rc5...www.distributed.net team enzo--- Jon Lewis | Spammers will be winnuked or Network Administrator | nestea'd...whatever it takes Florida Digital Turnpike | to get the job done. _________http://www.lewis.org/~jlewis/pgp for PGP public key__________ From fess@idealab.com Wed Feb 10 15:19:10 1999 Date: Wed Feb 10 15:19:10 1999 From: John Fessenden fess@idealab.com Subject: No subject We just got (out of habit) about 60 Kingston KNE100TX cards which of course now have the 21143 intel chip on them, and now we are having far less luck than previously. This time we have very little time to deploy this equipment. Could someone give us the quick start on which version of which driver is the optimal for using this card? or should we start all over and get a different card? Thank you all in advance for your help. From deadline@plogic.com Wed Feb 10 17:52:07 1999 Date: Wed Feb 10 17:52:07 1999 From: Douglas Eadline deadline@plogic.com Subject: .90f patch for lite-on chip set This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --868617915-979911619-918684856=:25074 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: I have included a patch for tulip .90f (as suggested by Steve Huang ) Here are the netperf results (see my previous posts for test scripts): BEFORE PATCH: ============ UDP UNIDIRECTIONAL SEND TEST to coyote1 Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 65535 1472 60.00 371769 0 72.97 65535 60.00 371769 72.97 TCP STREAM TEST to coyote1 Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65535 65535 65535 60.00 72.78 AFTER PATCH: ============ UDP UNIDIRECTIONAL SEND TEST to coyote1 Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 65535 1472 59.99 470422 0 92.34 65535 59.99 470422 92.34 TCP STREAM TEST to coyote1 Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65535 65535 65535 59.99 91.68 So the Lite-On is now just about as good at the 2114X. Doug ------------------------------------------------------------------- Paralogic, Inc. | PEAK | Voice:+610.861.6960 115 Research Drive | PARALLEL | Fax:+610.861.8247 Bethlehem, PA 18017 USA | PERFORMANCE | http://www.plogic.com ------------------------------------------------------------------- --868617915-979911619-918684856=:25074 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="tulip.90f-lite-on-patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Patch for Lite-On (Netgear) NIC Content-Disposition: ATTACHMENT; FILENAME="tulip.90f-lite-on-patch" LS0tIC91c3Ivc3JjL2xpbnV4L2RyaXZlcnMvbmV0L3R1bGlwLmMuOTBmCUZy aSBGZWIgIDUgMTE6NDA6MTEgMTk5OQ0KKysrIC91c3Ivc3JjL2xpbnV4L2Ry aXZlcnMvbmV0L3R1bGlwLmMubGl0ZS1vbi1maXhlZAlXZWQgRmViIDEwIDE0 OjAzOjA3IDE5OTkNCkBAIC0xMzY5LDcgKzEzNjksNyBAQA0KIAkJfQ0KIAl9 IGVsc2UgaWYgKHRwLT5jaGlwX2lkID09IExDODJDMTY4ICAmJiAgdHAtPm1p aV9jbnQgJiYgISB0cC0+bWVkaWFsb2NrKSB7DQogCQlkZXYtPmlmX3BvcnQg PSAxMTsNCi0JCXRwLT5jc3I2ID0gMHg4MTZDMDAwMCB8ICh0cC0+ZnVsbF9k dXBsZXggPyAweDAyMDAgOiAwKTsNCisJCXRwLT5jc3I2ID0gMHg4MTRDMDAw MCB8ICh0cC0+ZnVsbF9kdXBsZXggPyAweDAyMDAgOiAwKTsNCiAJCW91dGwo MHgwMDAxLCBpb2FkZHIgKyBDU1IxNSk7DQogCX0gZWxzZSBpZiAodHAtPmNo aXBfaWQgPT0gTVg5ODcxMyAmJiAhIHRwLT5tZWRpYWxvY2spIHsNCiAJCWRl di0+aWZfcG9ydCA9IDA7DQpAQCAtMTUzOSw3ICsxNTM5LDcgQEANCiAJCQkJ ICAgZGV2LT5uYW1lLCBpbmwoaW9hZGRyICsgMHhCOCksIGlubChpb2FkZHIg KyBDU1IxMiksDQogCQkJCSAgIG1lZGlhbmFtZVtkZXYtPmlmX3BvcnRdKTsN CiAJCWlmICh0cC0+bWlpX2NudCkgew0KLQkJCW5ld19jc3I2ID0gMHg4MTJD MDAwMDsNCisJCQluZXdfY3NyNiA9IDB4ODEwQzAwMDA7DQogCQkJb3V0bCgw eDAwMDEsIGlvYWRkciArIENTUjE1KTsNCiAJCQlvdXRsKDB4MDIwMUIwN0Es IGlvYWRkciArIDB4QjgpOw0KIAkJfSBlbHNlIGlmIChzdGFydHVwKSB7DQpA QCAtMjAwMSw5ICsyMDAxLDkgQEANCiAJCQkJICAgZGV2LT5uYW1lLCBuZWdv dGlhdGVkLCBpbmwoaW9hZGRyICsgQ1NSNSkpOw0KIA0KIAkJaWYgKG5lZ290 aWF0ZWQgJiAweDAzODApIAkJCQkvKiAxMCB2cyAxMDBtYnBzICovDQotCQkJ bmV3X2NzcjYgfD0gMHg4MTJFMDAwMDsNCisJCQluZXdfY3NyNiB8PSAweDgx MEMwMDAwOw0KIAkJZWxzZQ0KLQkJCW5ld19jc3I2IHw9IDB4ODE2RTAwMDA7 DQorCQkJbmV3X2NzcjYgfD0gMHg4MTRDMDAwMDsNCiAJCWlmICgoKG5lZ290 aWF0ZWQgJiAweDAzMDApID09IDB4MDEwMCkJCQkvKiBEdXBsZXggKi8NCiAJ CQl8fCAobmVnb3RpYXRlZCAmIDB4MDBDMCkgPT0gMHgwMDQwDQogCQkJfHwg dHAtPmZ1bGxfZHVwbGV4X2xvY2spIHsNCg== --868617915-979911619-918684856=:25074-- From deadline@plogic.com Wed Feb 10 18:14:29 1999 Date: Wed Feb 10 18:14:29 1999 From: Douglas Eadline deadline@plogic.com Subject: tulip.90 k results This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --868617915-518858603-918688293=:25074 Content-Type: TEXT/PLAIN; charset=US-ASCII Don (and anyone else interested) I have attached the NEW diagnostic output for the KTI KF-221TX/2 (21143) NIC. Here is what is reported (dmesg) Found Digital DS21143 Tulip at PCI I/O address 0xec00. tulip.c:v0.90k 2/1/99 becker@cesdis.gsfc.nasa.gov eth0: Digital DS21143 Tulip rev 65 at 0xec00, EEPROM not present, 00 4c 69 6e 75 79, IRQ 0. eth0: Old style EEPROM -- no media selection information. Found Digital DS21143 Tulip at PCI I/O address 0xec00. Here is the funny thing, there are two idential NICs (KTI) in this machine. When I use the .90k I can not get eth0 to come up (ifup eth0), but I can get the second interface to come up (ifup eth1). Here is what is in /var/log/messages when I tried this (ifup eth0, then ifup eth1)): Feb 10 14:15:40 coyote4 kernel: Found Digital DS21143 Tulip at PCI I/O address 0xec80. Feb 10 14:15:40 coyote4 kernel: tulip.c:v0.90k 2/1/99 becker@cesdis.gsfc.nasa.gov Feb 10 14:15:40 coyote4 kernel: eth0: Digital DS21143 Tulip rev 65 at 0xec80, EEPROM not present, 00 4c 69 6e 75 79, IRQ 0. Feb 10 14:15:40 coyote4 kernel: eth0: Old style EEPROM -- no media selection information. Feb 10 14:15:40 coyote4 kernel: Found Digital DS21143 Tulip at PCI I/O address 0xec00. Feb 10 14:15:40 coyote4 kernel: eth1: Digital DS21143 Tulip rev 33 at 0xec00, 00 40 f6 74 3c 4b, IRQ 9. Feb 10 14:15:40 coyote4 kernel: eth1: EEPROM default media type Autosense. Feb 10 14:15:40 coyote4 kernel: eth1: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. Feb 10 14:15:40 coyote4 kernel: eth1: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. Feb 10 14:15:40 coyote4 kernel: eth1: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. Feb 10 14:15:40 coyote4 kernel: eth1: Index #3 - Media 100baseTx-FD (#5) described by a 21143 SYM PHY (4) block. The NICs work fine with .90f (except for the fact that as a module they will not load correclty at boot, I have to "ifdown eth0, rmmod tulip, insmod tulip, ifup eth0" and then they work great. If I compile the module into the kernel, then the NICs come up at boot. Bob Brown sent me a patch to try, but it is for .89h and I did not have time to integrate into .90f(k).) Hope this helps Doug ------------------------------------------------------------------- Paralogic, Inc. | PEAK | Voice:+610.861.6960 115 Research Drive | PARALLEL | Fax:+610.861.8247 Bethlehem, PA 18017 USA | PERFORMANCE | http://www.plogic.com ------------------------------------------------------------------- --868617915-518858603-918688293=:25074 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="tulip-diag.out.90k" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: tulip-diag for tulip.90k Content-Disposition: attachment; filename="tulip-diag.out.90k" dHVsaXAtZGlhZy5jOnYxLjA3IDIvMTAvOTkgRG9uYWxkIEJlY2tlciAoYmVj a2VyQGNlc2Rpcy5nc2ZjLm5hc2EuZ292KQ0KSW5kZXggIzE6IEZvdW5kIGEg RGlnaXRhbCBEUzIxMTQzIFR1bGlwIGFkYXB0ZXIgYXQgMHhlYzgwLg0KRGln aXRhbCBEUzIxMTQzIFR1bGlwIFR1bGlwIGNoaXAgcmVnaXN0ZXJzIGF0IDB4 ZWM4MDoNCiAgZjlhMDQ4MDAgZmZmZmZmZmYgZmZmZmZmZmYgMDBmZGY4MjAg MDBmZGZhMjAgZjAwMDAxMDIgYjM4NjAyMDAgZjNmZTAwMDANCiAgZTAwMDAw MDAgZmZmNTgzZmYgZmZmZmZmZmYgMDAwMDAwMDAgMDAwMDAwYzQgZmZmZjAw MDAgZmZmYTAwMDAgOGZmMDAwMDgNCiBQb3J0IHNlbGVjdGlvbiBpcyAxMDBt YnBzLVNZTS9QQ1MgMTAwYmFzZVR4IHNjcmFtYmxlciwgZnVsbC1kdXBsZXgu DQogVHJhbnNtaXQgc3RvcHBlZCwgUmVjZWl2ZSBzdG9wcGVkLCBmdWxsLWR1 cGxleC4NCiAgVGhlIFJ4IHByb2Nlc3Mgc3RhdGUgaXMgJ1N0b3BwZWQnLg0K ICBUaGUgVHggcHJvY2VzcyBzdGF0ZSBpcyAnU3RvcHBlZCcuDQogIFRoZSB0 cmFuc21pdCB0aHJlc2hvbGQgaXMgMTI4Lg0KRUVQUk9NIGNvbnRlbnRzOg0K ICAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDANCiAg MDAwMCAwMTAzIDQwMDAgNzRmNiAwZTNjIDFlMDAgMDAwMCAwODAwDQogIDg2 MDQgMDAwMiAwOGFmIDAwYTUgMDI4NiBhZjA0IGE1MDggODgwMA0KICAwMzA0 IDA4YWYgMDBhNSA4MDYxIDA0ODggYWYwNSBhNTA4IDYxMDANCiAgMDA4MCAw MDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwDQogIDAwMDAgMDAw MCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMA0KICAwMDAwIDAwMDAg MDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDANCiAgMDAwMCAwMDAwIDAw MDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAyYzc5DQogSUQgQ1JDIDB4ZTMgKHZz LiAwMCksIGNvbXBsZXRlIENSQyA2MWNiOGRiNS4NCkVFUFJPTSB0cmFuc2Nl aXZlci9tZWRpYSBkZXNjcmlwdGlvbiBmb3IgdGhlIERpZ2l0YWwgRFMyMTE0 MyBUdWxpcCBjaGlwLg0KDQpMZWFmIG5vZGUgYXQgb2Zmc2V0IDMwLCBkZWZh dWx0IG1lZGlhIHR5cGUgMDgwMCAoQXV0b3NlbnNlKS4NCiA0IHRyYW5zY2Vp dmVyIGRlc2NyaXB0aW9uIGJsb2NrczoNCiAgTWVkaWEgMTBiYXNlVCwgYmxv Y2sgdHlwZSAyLg0KICAgU2VyaWFsIHRyYW5zY2VpdmVyIGZvciAxMGJhc2VU IChtZWRpYSB0eXBlIDApLg0KICAgIEdQIHBpbiBkaXJlY3Rpb24gMDhhZiAg R1AgcGluIGRhdGEgMDBhNS4NCiAgTWVkaWEgMTBiYXNlVC1GdWxsIER1cGxl eCwgYmxvY2sgdHlwZSAyLg0KICAgU2VyaWFsIHRyYW5zY2VpdmVyIGZvciAx MGJhc2VULUZ1bGwgRHVwbGV4IChtZWRpYSB0eXBlIDQpLg0KICAgIEdQIHBp biBkaXJlY3Rpb24gMDhhZiAgR1AgcGluIGRhdGEgMDBhNS4NCiAgTWVkaWEg MTAwYmFzZVR4LCBibG9jayB0eXBlIDQuDQogICBTWU0gdHJhbnNjZWl2ZXIg Zm9yIDEwMGJhc2VUeCAobWVkaWEgdHlwZSAzKS4NCiAgICBHUCBwaW4gZGly ZWN0aW9uIDA4YWYgIEdQIHBpbiBkYXRhIDAwYTUuDQogICAgTm8gbWVkaWEg ZGV0ZWN0aW9uIGluZGljYXRpb24gKGNvbW1hbmQgODAgNjEpLg0KICBNZWRp YSAxMDBiYXNlVHggRnVsbCBEdXBsZXgsIGJsb2NrIHR5cGUgNC4NCiAgIFNZ TSB0cmFuc2NlaXZlciBmb3IgMTAwYmFzZVR4IEZ1bGwgRHVwbGV4IChtZWRp YSB0eXBlIDUpLg0KICAgIEdQIHBpbiBkaXJlY3Rpb24gMDhhZiAgR1AgcGlu IGRhdGEgMDBhNS4NCiAgICBObyBtZWRpYSBkZXRlY3Rpb24gaW5kaWNhdGlv biAoY29tbWFuZCA4MCA2MSkuDQogKioqV0FSTklORyoqKjogTm8gTUlJIHRy YW5zY2VpdmVycyBmb3VuZCENCiAgSW50ZXJuYWwgYXV0b25lZ290aWF0aW9u IHN0YXRlIGlzICdBdXRvbmVnb3RpYXRpb24gZGlzYWJsZWQnLg0KSW5kZXgg IzI6IEZvdW5kIGEgRGlnaXRhbCBEUzIxMTQzIFR1bGlwIGFkYXB0ZXIgYXQg MHhlYzAwLg0KRGlnaXRhbCBEUzIxMTQzIFR1bGlwIFR1bGlwIGNoaXAgcmVn aXN0ZXJzIGF0IDB4ZWMwMDoNCiAgZmUwMDgwMDAgZmZmZmZmZmYgZmZmZmZm ZmYgMDBmZGYwMjggMDBmZGYyMjggZjgwMDAxMTYgYjI0MjAyMDAgZjNmZTAw MDANCiAgZTAwMDAwMDAgZmZmNTgzZmYgZmZmZmZmZmYgZmZmZTAwMDAgNDFl MTkyY2YgZmZmZjAwMDEgZmZmYmZmZmYgOGZmMTAwMDgNCiBQb3J0IHNlbGVj dGlvbiBpcyAxMG1wYnMtc2VyaWFsLCBmdWxsLWR1cGxleC4NCiBUcmFuc21p dCBzdG9wcGVkLCBSZWNlaXZlIHN0b3BwZWQsIGZ1bGwtZHVwbGV4Lg0KICBU aGUgUnggcHJvY2VzcyBzdGF0ZSBpcyAnU3RvcHBlZCcuDQogIFRoZSBUeCBw cm9jZXNzIHN0YXRlIGlzICdTdG9wcGVkJy4NCiAgVGhlIHRyYW5zbWl0IHRo cmVzaG9sZCBpcyA3Mi4NCkVFUFJPTSBjb250ZW50czoNCiAgMDAwMCAwMDAw IDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwDQogIDAwMDAgMDEwMyA0 MDAwIDc0ZjYgNGIzYyAxZTAwIDAwMDAgMDgwMA0KICA4NjA0IDAwMDIgMDhh ZiAwMGE1IDAyODYgYWYwNCBhNTA4IDg4MDANCiAgMDMwNCAwOGFmIDAwYTUg ODA2MSAwNDg4IGFmMDUgYTUwOCA2MTAwDQogIDAwODAgMDAwMCAwMDAwIDAw MDAgMDAwMCAwMDAwIDAwMDAgMDAwMA0KICAwMDAwIDAwMDAgMDAwMCAwMDAw IDAwMDAgMDAwMCAwMDAwIDAwMDANCiAgMDAwMCAwMDAwIDAwMDAgMDAwMCAw MDAwIDAwMDAgMDAwMCAwMDAwDQogIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAw MCAwMDAwIDAwMDAgMjY0ZQ0KIElEIENSQyAweGUzICh2cy4gMDApLCBjb21w bGV0ZSBDUkMgOGQ5YmZlNzguDQpFRVBST00gdHJhbnNjZWl2ZXIvbWVkaWEg ZGVzY3JpcHRpb24gZm9yIHRoZSBEaWdpdGFsIERTMjExNDMgVHVsaXAgY2hp cC4NCg0KTGVhZiBub2RlIGF0IG9mZnNldCAzMCwgZGVmYXVsdCBtZWRpYSB0 eXBlIDA4MDAgKEF1dG9zZW5zZSkuDQogNCB0cmFuc2NlaXZlciBkZXNjcmlw dGlvbiBibG9ja3M6DQogIE1lZGlhIDEwYmFzZVQsIGJsb2NrIHR5cGUgMi4N CiAgIFNlcmlhbCB0cmFuc2NlaXZlciBmb3IgMTBiYXNlVCAobWVkaWEgdHlw ZSAwKS4NCiAgICBHUCBwaW4gZGlyZWN0aW9uIDA4YWYgIEdQIHBpbiBkYXRh IDAwYTUuDQogIE1lZGlhIDEwYmFzZVQtRnVsbCBEdXBsZXgsIGJsb2NrIHR5 cGUgMi4NCiAgIFNlcmlhbCB0cmFuc2NlaXZlciBmb3IgMTBiYXNlVC1GdWxs IER1cGxleCAobWVkaWEgdHlwZSA0KS4NCiAgICBHUCBwaW4gZGlyZWN0aW9u IDA4YWYgIEdQIHBpbiBkYXRhIDAwYTUuDQogIE1lZGlhIDEwMGJhc2VUeCwg YmxvY2sgdHlwZSA0Lg0KICAgU1lNIHRyYW5zY2VpdmVyIGZvciAxMDBiYXNl VHggKG1lZGlhIHR5cGUgMykuDQogICAgR1AgcGluIGRpcmVjdGlvbiAwOGFm ICBHUCBwaW4gZGF0YSAwMGE1Lg0KICAgIE5vIG1lZGlhIGRldGVjdGlvbiBp bmRpY2F0aW9uIChjb21tYW5kIDgwIDYxKS4NCiAgTWVkaWEgMTAwYmFzZVR4 IEZ1bGwgRHVwbGV4LCBibG9jayB0eXBlIDQuDQogICBTWU0gdHJhbnNjZWl2 ZXIgZm9yIDEwMGJhc2VUeCBGdWxsIER1cGxleCAobWVkaWEgdHlwZSA1KS4N CiAgICBHUCBwaW4gZGlyZWN0aW9uIDA4YWYgIEdQIHBpbiBkYXRhIDAwYTUu DQogICAgTm8gbWVkaWEgZGV0ZWN0aW9uIGluZGljYXRpb24gKGNvbW1hbmQg ODAgNjEpLg0KICoqKldBUk5JTkcqKio6IE5vIE1JSSB0cmFuc2NlaXZlcnMg Zm91bmQhDQogIEludGVybmFsIGF1dG9uZWdvdGlhdGlvbiBzdGF0ZSBpcyAn VHJhbnNtaXQgZGlzYWJsZWQnLg0K --868617915-518858603-918688293=:25074 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="tulip-diag.out.90f-ifdown" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: tulip diag for .90f before interface is up Content-Disposition: attachment; filename="tulip-diag.out.90f-ifdown" dHVsaXAtZGlhZy5jOnYxLjA3IDIvMTAvOTkgRG9uYWxkIEJlY2tlciAoYmVj a2VyQGNlc2Rpcy5nc2ZjLm5hc2EuZ292KQ0KSW5kZXggIzE6IEZvdW5kIGEg RGlnaXRhbCBEUzIxMTQzIFR1bGlwIGFkYXB0ZXIgYXQgMHhlYzgwLg0KRGln aXRhbCBEUzIxMTQzIFR1bGlwIFR1bGlwIGNoaXAgcmVnaXN0ZXJzIGF0IDB4 ZWM4MDoNCiAgZjlhMDQ4MDAgZmZmZmZmZmYgZmZmZmZmZmYgMDBmZGY4MjAg MDBmZGZhMjAgZjgwMDAxMTIgYjI0MjAyMDAgZjNmZTAwMDANCiAgZTAwMDAw MDAgZmZmNTgzZmYgZmZmZmZmZmYgMDAwMDAwMDAgNDFlMTkyY2YgZmZmZjAw MDEgZmZmYmZmZmYgOGZmMTAwMDgNCiBQb3J0IHNlbGVjdGlvbiBpcyAxMG1w YnMtc2VyaWFsLCBmdWxsLWR1cGxleC4NCiBUcmFuc21pdCBzdG9wcGVkLCBS ZWNlaXZlIHN0b3BwZWQsIGZ1bGwtZHVwbGV4Lg0KICBUaGUgUnggcHJvY2Vz cyBzdGF0ZSBpcyAnU3RvcHBlZCcuDQogIFRoZSBUeCBwcm9jZXNzIHN0YXRl IGlzICdTdG9wcGVkJy4NCiAgVGhlIHRyYW5zbWl0IHRocmVzaG9sZCBpcyA3 Mi4NCkVFUFJPTSBjb250ZW50czoNCiAgMDAwMCAwMDAwIDAwMDAgMDAwMCAw MDAwIDAwMDAgMDAwMCAwMDAwDQogIDAwMDAgMDEwMyA0MDAwIDc0ZjYgMGUz YyAxZTAwIDAwMDAgMDgwMA0KICA4NjA0IDAwMDIgMDhhZiAwMGE1IDAyODYg YWYwNCBhNTA4IDg4MDANCiAgMDMwNCAwOGFmIDAwYTUgODA2MSAwNDg4IGFm MDUgYTUwOCA2MTAwDQogIDAwODAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAw IDAwMDAgMDAwMA0KICAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAw MDAwIDAwMDANCiAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAw MCAwMDAwDQogIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAg MmM3OQ0KIElEIENSQyAweGUzICh2cy4gMDApLCBjb21wbGV0ZSBDUkMgNjFj YjhkYjUuDQpFRVBST00gdHJhbnNjZWl2ZXIvbWVkaWEgZGVzY3JpcHRpb24g Zm9yIHRoZSBEaWdpdGFsIERTMjExNDMgVHVsaXAgY2hpcC4NCg0KTGVhZiBu b2RlIGF0IG9mZnNldCAzMCwgZGVmYXVsdCBtZWRpYSB0eXBlIDA4MDAgKEF1 dG9zZW5zZSkuDQogNCB0cmFuc2NlaXZlciBkZXNjcmlwdGlvbiBibG9ja3M6 DQogIE1lZGlhIDEwYmFzZVQsIGJsb2NrIHR5cGUgMi4NCiAgIFNlcmlhbCB0 cmFuc2NlaXZlciBmb3IgMTBiYXNlVCAobWVkaWEgdHlwZSAwKS4NCiAgICBH UCBwaW4gZGlyZWN0aW9uIDA4YWYgIEdQIHBpbiBkYXRhIDAwYTUuDQogIE1l ZGlhIDEwYmFzZVQtRnVsbCBEdXBsZXgsIGJsb2NrIHR5cGUgMi4NCiAgIFNl cmlhbCB0cmFuc2NlaXZlciBmb3IgMTBiYXNlVC1GdWxsIER1cGxleCAobWVk aWEgdHlwZSA0KS4NCiAgICBHUCBwaW4gZGlyZWN0aW9uIDA4YWYgIEdQIHBp biBkYXRhIDAwYTUuDQogIE1lZGlhIDEwMGJhc2VUeCwgYmxvY2sgdHlwZSA0 Lg0KICAgU1lNIHRyYW5zY2VpdmVyIGZvciAxMDBiYXNlVHggKG1lZGlhIHR5 cGUgMykuDQogICAgR1AgcGluIGRpcmVjdGlvbiAwOGFmICBHUCBwaW4gZGF0 YSAwMGE1Lg0KICAgIE5vIG1lZGlhIGRldGVjdGlvbiBpbmRpY2F0aW9uIChj b21tYW5kIDgwIDYxKS4NCiAgTWVkaWEgMTAwYmFzZVR4IEZ1bGwgRHVwbGV4 LCBibG9jayB0eXBlIDQuDQogICBTWU0gdHJhbnNjZWl2ZXIgZm9yIDEwMGJh c2VUeCBGdWxsIER1cGxleCAobWVkaWEgdHlwZSA1KS4NCiAgICBHUCBwaW4g ZGlyZWN0aW9uIDA4YWYgIEdQIHBpbiBkYXRhIDAwYTUuDQogICAgTm8gbWVk aWEgZGV0ZWN0aW9uIGluZGljYXRpb24gKGNvbW1hbmQgODAgNjEpLg0KICoq KldBUk5JTkcqKio6IE5vIE1JSSB0cmFuc2NlaXZlcnMgZm91bmQhDQogIElu dGVybmFsIGF1dG9uZWdvdGlhdGlvbiBzdGF0ZSBpcyAnVHJhbnNtaXQgZGlz YWJsZWQnLg0KSW5kZXggIzI6IEZvdW5kIGEgRGlnaXRhbCBEUzIxMTQzIFR1 bGlwIGFkYXB0ZXIgYXQgMHhlYzAwLg0KRGlnaXRhbCBEUzIxMTQzIFR1bGlw IFR1bGlwIGNoaXAgcmVnaXN0ZXJzIGF0IDB4ZWMwMDoNCiAgZmUwMDgwMDAg ZmZmZmZmZmYgZmZmZmZmZmYgMDBmZGYwMjggMDBmZGYyMjggZjgwMDAxMTYg YjI0MjAyMDAgZjNmZTAwMDANCiAgZTAwMDAwMDAgZmZmNTgzZmYgZmZmZmZm ZmYgZmZmZTAwMDAgNDFlMTkyY2UgZmZmZjAwMDEgZmZmYmZmZmYgOGZmMTAw MDgNCiBQb3J0IHNlbGVjdGlvbiBpcyAxMG1wYnMtc2VyaWFsLCBmdWxsLWR1 cGxleC4NCiBUcmFuc21pdCBzdG9wcGVkLCBSZWNlaXZlIHN0b3BwZWQsIGZ1 bGwtZHVwbGV4Lg0KICBUaGUgUnggcHJvY2VzcyBzdGF0ZSBpcyAnU3RvcHBl ZCcuDQogIFRoZSBUeCBwcm9jZXNzIHN0YXRlIGlzICdTdG9wcGVkJy4NCiAg VGhlIHRyYW5zbWl0IHRocmVzaG9sZCBpcyA3Mi4NCkVFUFJPTSBjb250ZW50 czoNCiAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAw DQogIDAwMDAgMDEwMyA0MDAwIDc0ZjYgNGIzYyAxZTAwIDAwMDAgMDgwMA0K ICA4NjA0IDAwMDIgMDhhZiAwMGE1IDAyODYgYWYwNCBhNTA4IDg4MDANCiAg MDMwNCAwOGFmIDAwYTUgODA2MSAwNDg4IGFmMDUgYTUwOCA2MTAwDQogIDAw ODAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMA0KICAwMDAw IDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDANCiAgMDAwMCAw MDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwDQogIDAwMDAgMDAw MCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMjY0ZQ0KIElEIENSQyAweGUz ICh2cy4gMDApLCBjb21wbGV0ZSBDUkMgOGQ5YmZlNzguDQpFRVBST00gdHJh bnNjZWl2ZXIvbWVkaWEgZGVzY3JpcHRpb24gZm9yIHRoZSBEaWdpdGFsIERT MjExNDMgVHVsaXAgY2hpcC4NCg0KTGVhZiBub2RlIGF0IG9mZnNldCAzMCwg ZGVmYXVsdCBtZWRpYSB0eXBlIDA4MDAgKEF1dG9zZW5zZSkuDQogNCB0cmFu c2NlaXZlciBkZXNjcmlwdGlvbiBibG9ja3M6DQogIE1lZGlhIDEwYmFzZVQs IGJsb2NrIHR5cGUgMi4NCiAgIFNlcmlhbCB0cmFuc2NlaXZlciBmb3IgMTBi YXNlVCAobWVkaWEgdHlwZSAwKS4NCiAgICBHUCBwaW4gZGlyZWN0aW9uIDA4 YWYgIEdQIHBpbiBkYXRhIDAwYTUuDQogIE1lZGlhIDEwYmFzZVQtRnVsbCBE dXBsZXgsIGJsb2NrIHR5cGUgMi4NCiAgIFNlcmlhbCB0cmFuc2NlaXZlciBm b3IgMTBiYXNlVC1GdWxsIER1cGxleCAobWVkaWEgdHlwZSA0KS4NCiAgICBH UCBwaW4gZGlyZWN0aW9uIDA4YWYgIEdQIHBpbiBkYXRhIDAwYTUuDQogIE1l ZGlhIDEwMGJhc2VUeCwgYmxvY2sgdHlwZSA0Lg0KICAgU1lNIHRyYW5zY2Vp dmVyIGZvciAxMDBiYXNlVHggKG1lZGlhIHR5cGUgMykuDQogICAgR1AgcGlu IGRpcmVjdGlvbiAwOGFmICBHUCBwaW4gZGF0YSAwMGE1Lg0KICAgIE5vIG1l ZGlhIGRldGVjdGlvbiBpbmRpY2F0aW9uIChjb21tYW5kIDgwIDYxKS4NCiAg TWVkaWEgMTAwYmFzZVR4IEZ1bGwgRHVwbGV4LCBibG9jayB0eXBlIDQuDQog ICBTWU0gdHJhbnNjZWl2ZXIgZm9yIDEwMGJhc2VUeCBGdWxsIER1cGxleCAo bWVkaWEgdHlwZSA1KS4NCiAgICBHUCBwaW4gZGlyZWN0aW9uIDA4YWYgIEdQ IHBpbiBkYXRhIDAwYTUuDQogICAgTm8gbWVkaWEgZGV0ZWN0aW9uIGluZGlj YXRpb24gKGNvbW1hbmQgODAgNjEpLg0KICoqKldBUk5JTkcqKio6IE5vIE1J SSB0cmFuc2NlaXZlcnMgZm91bmQhDQogIEludGVybmFsIGF1dG9uZWdvdGlh dGlvbiBzdGF0ZSBpcyAnVHJhbnNtaXQgZGlzYWJsZWQnLg0K --868617915-518858603-918688293=:25074 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="tulip-diag.out.90f-ifup" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: tulip diag for .90f after interface is up Content-Disposition: attachment; filename="tulip-diag.out.90f-ifup" dHVsaXAtZGlhZy5jOnYxLjA3IDIvMTAvOTkgRG9uYWxkIEJlY2tlciAoYmVj a2VyQGNlc2Rpcy5nc2ZjLm5hc2EuZ292KQ0KSW5kZXggIzE6IEZvdW5kIGEg RGlnaXRhbCBEUzIxMTQzIFR1bGlwIGFkYXB0ZXIgYXQgMHhlYzgwLg0KRGln aXRhbCBEUzIxMTQzIFR1bGlwIFR1bGlwIGNoaXAgcmVnaXN0ZXJzIGF0IDB4 ZWM4MDoNCiAgZjlhMDQ4MDAgZmZmZmZmZmYgZmZmZmZmZmYgMDBmZGI4MjAg MDBmZGJhMjAgZjA2NjAwMDAgYjM4NjIyMDIgZmJmZmZiZmYNCiAgZTAwMDAw MDAgZmZmNDgzZmYgZmZmZmZmZmYgMDAwMDAwMDAgMDAwMDAwYzQgZmZmZjAw MDAgZmZmYTAwMDAgOGZmMDAwMDgNCiBQb3J0IHNlbGVjdGlvbiBpcyAxMDBt YnBzLVNZTS9QQ1MgMTAwYmFzZVR4IHNjcmFtYmxlciwgZnVsbC1kdXBsZXgu DQogVHJhbnNtaXQgc3RhcnRlZCwgUmVjZWl2ZSBzdGFydGVkLCBmdWxsLWR1 cGxleC4NCiAgVGhlIFJ4IHByb2Nlc3Mgc3RhdGUgaXMgJ1dhaXRpbmcgZm9y IHBhY2tldHMnLg0KICBUaGUgVHggcHJvY2VzcyBzdGF0ZSBpcyAnSWRsZScu DQogIFRoZSB0cmFuc21pdCB0aHJlc2hvbGQgaXMgMTI4Lg0KRUVQUk9NIGNv bnRlbnRzOg0KICAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAw IDAwMDANCiAgMDAwMCAwMTAzIDQwMDAgNzRmNiAwZTNjIDFlMDAgMDAwMCAw ODAwDQogIDg2MDQgMDAwMiAwOGFmIDAwYTUgMDI4NiBhZjA0IGE1MDggODgw MA0KICAwMzA0IDA4YWYgMDBhNSA4MDYxIDA0ODggYWYwNSBhNTA4IDYxMDAN CiAgMDA4MCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwDQog IDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMA0KICAw MDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDANCiAgMDAw MCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAyYzc5DQogSUQgQ1JD IDB4ZTMgKHZzLiAwMCksIGNvbXBsZXRlIENSQyA2MWNiOGRiNS4NCkVFUFJP TSB0cmFuc2NlaXZlci9tZWRpYSBkZXNjcmlwdGlvbiBmb3IgdGhlIERpZ2l0 YWwgRFMyMTE0MyBUdWxpcCBjaGlwLg0KDQpMZWFmIG5vZGUgYXQgb2Zmc2V0 IDMwLCBkZWZhdWx0IG1lZGlhIHR5cGUgMDgwMCAoQXV0b3NlbnNlKS4NCiA0 IHRyYW5zY2VpdmVyIGRlc2NyaXB0aW9uIGJsb2NrczoNCiAgTWVkaWEgMTBi YXNlVCwgYmxvY2sgdHlwZSAyLg0KICAgU2VyaWFsIHRyYW5zY2VpdmVyIGZv ciAxMGJhc2VUIChtZWRpYSB0eXBlIDApLg0KICAgIEdQIHBpbiBkaXJlY3Rp b24gMDhhZiAgR1AgcGluIGRhdGEgMDBhNS4NCiAgTWVkaWEgMTBiYXNlVC1G dWxsIER1cGxleCwgYmxvY2sgdHlwZSAyLg0KICAgU2VyaWFsIHRyYW5zY2Vp dmVyIGZvciAxMGJhc2VULUZ1bGwgRHVwbGV4IChtZWRpYSB0eXBlIDQpLg0K ICAgIEdQIHBpbiBkaXJlY3Rpb24gMDhhZiAgR1AgcGluIGRhdGEgMDBhNS4N CiAgTWVkaWEgMTAwYmFzZVR4LCBibG9jayB0eXBlIDQuDQogICBTWU0gdHJh bnNjZWl2ZXIgZm9yIDEwMGJhc2VUeCAobWVkaWEgdHlwZSAzKS4NCiAgICBH UCBwaW4gZGlyZWN0aW9uIDA4YWYgIEdQIHBpbiBkYXRhIDAwYTUuDQogICAg Tm8gbWVkaWEgZGV0ZWN0aW9uIGluZGljYXRpb24gKGNvbW1hbmQgODAgNjEp Lg0KICBNZWRpYSAxMDBiYXNlVHggRnVsbCBEdXBsZXgsIGJsb2NrIHR5cGUg NC4NCiAgIFNZTSB0cmFuc2NlaXZlciBmb3IgMTAwYmFzZVR4IEZ1bGwgRHVw bGV4IChtZWRpYSB0eXBlIDUpLg0KICAgIEdQIHBpbiBkaXJlY3Rpb24gMDhh ZiAgR1AgcGluIGRhdGEgMDBhNS4NCiAgICBObyBtZWRpYSBkZXRlY3Rpb24g aW5kaWNhdGlvbiAoY29tbWFuZCA4MCA2MSkuDQogKioqV0FSTklORyoqKjog Tm8gTUlJIHRyYW5zY2VpdmVycyBmb3VuZCENCiAgSW50ZXJuYWwgYXV0b25l Z290aWF0aW9uIHN0YXRlIGlzICdBdXRvbmVnb3RpYXRpb24gZGlzYWJsZWQn Lg0KSW5kZXggIzI6IEZvdW5kIGEgRGlnaXRhbCBEUzIxMTQzIFR1bGlwIGFk YXB0ZXIgYXQgMHhlYzAwLg0KRGlnaXRhbCBEUzIxMTQzIFR1bGlwIFR1bGlw IGNoaXAgcmVnaXN0ZXJzIGF0IDB4ZWMwMDoNCiAgZmUwMDgwMDAgZmZmZmZm ZmYgZmZmZmZmZmYgMDBmZGYwMjggMDBmZGYyMjggZjgwMDAxMTYgYjI0MjAy MDAgZjNmZTAwMDANCiAgZTAwMDAwMDAgZmZmNTgzZmYgZmZmZmZmZmYgZmZm ZTAwMDAgNDFlMTkyY2UgZmZmZjAwMDEgZmZmYmZmZmYgOGZmMTAwMDgNCiBQ b3J0IHNlbGVjdGlvbiBpcyAxMG1wYnMtc2VyaWFsLCBmdWxsLWR1cGxleC4N CiBUcmFuc21pdCBzdG9wcGVkLCBSZWNlaXZlIHN0b3BwZWQsIGZ1bGwtZHVw bGV4Lg0KICBUaGUgUnggcHJvY2VzcyBzdGF0ZSBpcyAnU3RvcHBlZCcuDQog IFRoZSBUeCBwcm9jZXNzIHN0YXRlIGlzICdTdG9wcGVkJy4NCiAgVGhlIHRy YW5zbWl0IHRocmVzaG9sZCBpcyA3Mi4NCkVFUFJPTSBjb250ZW50czoNCiAg MDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwDQogIDAw MDAgMDEwMyA0MDAwIDc0ZjYgNGIzYyAxZTAwIDAwMDAgMDgwMA0KICA4NjA0 IDAwMDIgMDhhZiAwMGE1IDAyODYgYWYwNCBhNTA4IDg4MDANCiAgMDMwNCAw OGFmIDAwYTUgODA2MSAwNDg4IGFmMDUgYTUwOCA2MTAwDQogIDAwODAgMDAw MCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMA0KICAwMDAwIDAwMDAg MDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDANCiAgMDAwMCAwMDAwIDAw MDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwDQogIDAwMDAgMDAwMCAwMDAw IDAwMDAgMDAwMCAwMDAwIDAwMDAgMjY0ZQ0KIElEIENSQyAweGUzICh2cy4g MDApLCBjb21wbGV0ZSBDUkMgOGQ5YmZlNzguDQpFRVBST00gdHJhbnNjZWl2 ZXIvbWVkaWEgZGVzY3JpcHRpb24gZm9yIHRoZSBEaWdpdGFsIERTMjExNDMg VHVsaXAgY2hpcC4NCg0KTGVhZiBub2RlIGF0IG9mZnNldCAzMCwgZGVmYXVs dCBtZWRpYSB0eXBlIDA4MDAgKEF1dG9zZW5zZSkuDQogNCB0cmFuc2NlaXZl ciBkZXNjcmlwdGlvbiBibG9ja3M6DQogIE1lZGlhIDEwYmFzZVQsIGJsb2Nr IHR5cGUgMi4NCiAgIFNlcmlhbCB0cmFuc2NlaXZlciBmb3IgMTBiYXNlVCAo bWVkaWEgdHlwZSAwKS4NCiAgICBHUCBwaW4gZGlyZWN0aW9uIDA4YWYgIEdQ IHBpbiBkYXRhIDAwYTUuDQogIE1lZGlhIDEwYmFzZVQtRnVsbCBEdXBsZXgs IGJsb2NrIHR5cGUgMi4NCiAgIFNlcmlhbCB0cmFuc2NlaXZlciBmb3IgMTBi YXNlVC1GdWxsIER1cGxleCAobWVkaWEgdHlwZSA0KS4NCiAgICBHUCBwaW4g ZGlyZWN0aW9uIDA4YWYgIEdQIHBpbiBkYXRhIDAwYTUuDQogIE1lZGlhIDEw MGJhc2VUeCwgYmxvY2sgdHlwZSA0Lg0KICAgU1lNIHRyYW5zY2VpdmVyIGZv ciAxMDBiYXNlVHggKG1lZGlhIHR5cGUgMykuDQogICAgR1AgcGluIGRpcmVj dGlvbiAwOGFmICBHUCBwaW4gZGF0YSAwMGE1Lg0KICAgIE5vIG1lZGlhIGRl dGVjdGlvbiBpbmRpY2F0aW9uIChjb21tYW5kIDgwIDYxKS4NCiAgTWVkaWEg MTAwYmFzZVR4IEZ1bGwgRHVwbGV4LCBibG9jayB0eXBlIDQuDQogICBTWU0g dHJhbnNjZWl2ZXIgZm9yIDEwMGJhc2VUeCBGdWxsIER1cGxleCAobWVkaWEg dHlwZSA1KS4NCiAgICBHUCBwaW4gZGlyZWN0aW9uIDA4YWYgIEdQIHBpbiBk YXRhIDAwYTUuDQogICAgTm8gbWVkaWEgZGV0ZWN0aW9uIGluZGljYXRpb24g KGNvbW1hbmQgODAgNjEpLg0KICoqKldBUk5JTkcqKio6IE5vIE1JSSB0cmFu c2NlaXZlcnMgZm91bmQhDQogIEludGVybmFsIGF1dG9uZWdvdGlhdGlvbiBz dGF0ZSBpcyAnVHJhbnNtaXQgZGlzYWJsZWQnLg0K --868617915-518858603-918688293=:25074-- From deadline@plogic.com Wed Feb 10 18:24:54 1999 Date: Wed Feb 10 18:24:54 1999 From: Douglas Eadline deadline@plogic.com Subject: your mail On Wed, 10 Feb 1999, John Fessenden wrote: > > > We just got (out of habit) about 60 Kingston KNE100TX cards which of > course now have the 21143 intel chip on them, and now we are having far > less luck than previously. This time we have very little time to deploy > this equipment. > > Could someone give us the quick start on which version of which driver > is the optimal for using this card? or should we start all over and get a > different card? > > Thank you all in advance for your help. try .90f or .90k If they do not work, run the new tulip-diag and post the results for Don to see. Doug ------------------------------------------------------------------- Paralogic, Inc. | PEAK | Voice:+610.861.6960 115 Research Drive | PARALLEL | Fax:+610.861.8247 Bethlehem, PA 18017 USA | PERFORMANCE | http://www.plogic.com ------------------------------------------------------------------- From pcg@gospelcom.net Wed Feb 10 20:04:53 1999 Date: Wed Feb 10 20:04:53 1999 From: Peter Green pcg@gospelcom.net Subject: new Kingston KNE100TX > Could someone give us the quick start on which version of which driver > is the optimal for using this card? or should we start all over and get a > different card? As per recent postings by Christopher E. Brown and John Connett those cards seem to be okay. I have one, but haven't installed it yet. Which drivers have you tried it with? I'm assuming the gentlemen listed above were using either the stable or test 0.90 driver...I'd give it a shot! /pg -- Peter Green Gospel Communications Network, SysAdmin pcg@gospelcom.net From maurice@harddata.com Thu Feb 11 01:19:48 1999 Date: Thu Feb 11 01:19:48 1999 From: Maurice Hilarius maurice@harddata.com Subject: some patches We had a problem running tulip-diag v1.07 as was recently posted. We are trying to use it on an Alpha. Following is the patch needed to fix it: --- ./tulip-diag.c~ Wed Feb 10 01:56:19 1999 +++ ./tulip-diag.c Wed Feb 10 20:07:48 1999 @@ -865,7 +865,9 @@ printf("EEPROM transceiver/media description for the %s chip.\n", pcidev_tbl[part_idx].part_name); p = (void *)ee_data + ee_data[27]; - media = *((short *)p)++; + /* media = *((short *)p)++; */ + media = *p++; + media += (*p++ * 0x100); printf("\nLeaf node at offset %d, default media type %4.4x (%s).\n", ee_data[27], media, media & 0x0800 ? "Autosense" : medianame[media & 15]); Best regards, Maurice W. Hilarius NEW! Telephone: 01-780-456-9771 Hard Data Ltd. NEW! FAX: 01-780-456-9772 11060 - 166 Avenue email:maurice@harddata.com Edmonton, AB, Canada - T5X 1Y3 http://www.harddata.com From rgb@phy.duke.edu Thu Feb 11 09:03:35 1999 Date: Thu Feb 11 09:03:35 1999 From: Robert G. Brown rgb@phy.duke.edu Subject: tulip.90 k results On Wed, 10 Feb 1999, Douglas Eadline wrote: > Here is the funny thing, there are two idential NICs (KTI) > in this machine. When I use the .90k I can not > get eth0 to come up (ifup eth0), but I can get > the second interface to come up (ifup eth1). Oooo, this really sounds like the bloody bios bug, too, that the patch fixes. I just found (the hard way, of course) that even with 2.0.36 and 0.89H in spanking new dual PII's, my old REAL (21141) KNE-100's still barf on the old ioport bug. Things are a bit better, perhaps. The symptom now is that the FIRST boot from a hard reset, the KNE-100 comes up on 0xec00, ifconfigs "normally", and then just doesn't work. The second (warm) boot, it comes up on 0xec80 and works fine. The third (warm) boot, it comes up on 0xec00 and hangs. And so it continues... The patch in 0.89H does seem to shift the ioport on the first (cold) boot to 0xec80 and the system works fine. This alternating behavior, though, as I recall, is new -- I think that in the old days a warm boot would put you back at the original ioport and it would hang every time unless you did the insmod/rmmod/insmod fix thingie kludge. I personally, with my animistic projections on inanimate hardware, think that the real problem is that my older tulip cards just don't "like" ioport 0xec00. Perhaps it dropped one of the cards on its electronic head when it was a baby or something. The proper solution is to put the cards in therapy -- if they have a chance to talk it all out with an understanding CPU, perhaps they'll get over this mindless animosity. rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu From briand@deldotd.com Thu Feb 11 12:40:11 1999 Date: Thu Feb 11 12:40:11 1999 From: Brian Denheyer briand@deldotd.com Subject: .90f patch for lite-on chip set I'd really like to kwno exactly which chip is on the card you tested... Obviously, from all of my ranting, I can't post netperf performance because the card can't get through the test is any sort of consistent fashion. Posting a tulip-diag output would be helpful too. Thanks Brian From maurice@harddata.com Thu Feb 11 17:42:03 1999 Date: Thu Feb 11 17:42:03 1999 From: Maurice Hilarius maurice@harddata.com Subject: fun with tulip We recently got stuck with some of the new Netgear 310 cards which came with "non-Digital" chips on them. They DO work, to a degree, but slowly. For interests sake we ran the latest tulip-daig on them, to see what we could find out. Not being a God of this stuff, I can not tell too much from it. Here is the output, with a (few) comments: tulip.c:v0.89H 5/23/98 becker@cesdis.gsfc.nasa.gov eth0: Lite-On 82c168 PNIC at 0x8800, 00 a0 cc 39 90 4f, IRQ 17. eth0: MII transceiver found at MDIO address 1, config 1000 status 782d. eth0: Advertising 01e1 on PHY 1, previously advertising 01e1. eth0: Changing PNIC configuration to half-duplex, CSR6 816e0000. Ok, lets try 'tulip-diag' # ./tulip-diag tulip-diag.c:v1.07 2/10/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Unable to find a Tulip card in /proc/pci. If there is a Tulip card in the machine, explicitly set the I/O port address using '-p Hm, ok. 'cat /proc/pci' gives indeed something like that: ..... Bus 0, device 7, function 0: Ethernet controller: LiteOn LNE100TX (rev 33). Medium devsel. Fast back-to-back capable. IRQ 17. Master Capable. Latency=32. I/O at 0x8800 [0x8801]. Non-prefetchable 32 bit memory at 0x6001000 [0x6001000]. ..... # ./tulip-diag -p 0x8800 tulip-diag.c:v1.07 2/10/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Port selection is MII 100baseTx scrambler, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. Use '-a' to show device registers, '-e' to show EEPROM contents, or '-m' to show MII management registers. # ./tulip-diag -p 0x8800 -m tulip-diag.c:v1.07 2/10/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Port selection is MII 100baseTx scrambler, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. ***WARNING***: No MII transceivers found! Oh, really?? The driver itself claims otherwise. # ./tulip-diag -p 0x8800 -a -f tulip-diag.c:v1.07 2/10/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Digital Tulip, unknown type Tulip chip registers at 0x8800: 0000e000 01ff0000 00000000 47885818 47885a18 02660010 816e2002 0001ebef 00000000 00004800 47885a38 47109068 00000025 00000000 00000000 10000001 Port selection is MII 100baseTx scrambler, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. # ./tulip-diag -p 0x8800 -e tulip-diag.c:v1.07 2/10/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Port selection is MII 100baseTx scrambler, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. * An old-style EEPROM layout was found. * The old-style layout does not contain transceiver control information. * This board may not work, or may work only with a subset of transceiver * options or data rates. Not that I am a tiny bit wiser after that (except that this board does work, at least here, as I am connected through it when typing these words :-). If this is of any use to Donald, or others, great! BTW, this was run on an Alpha: Cabriolet - 21064A / 275MHz machine. Linux 2.0.36. Best regards, Maurice W. Hilarius NEW! Telephone: 01-780-456-9771 Hard Data Ltd. NEW! FAX: 01-780-456-9772 11060 - 166 Avenue email:maurice@harddata.com Edmonton, AB, Canada - T5X 1Y3 http://www.harddata.com From maurice@harddata.com Thu Feb 11 19:59:45 1999 Date: Thu Feb 11 19:59:45 1999 From: Maurice Hilarius maurice@harddata.com Subject: fun with tulip With regards to your message at 07:09 PM 02-11-99 -0500, Mark Hahn. Where you stated: >> We recently got stuck with some of the new Netgear 310 cards which came >> with "non-Digital" chips on them. They DO work, to a degree, but slowly. > >this is a well-know bug in the driver. the patch, which fixes >lite-on tulip clone performance, was posted to this list this week. > You mean .90k? And Doug Eadlines posted patch? YEs, saw that, thanks. However, it doesn't work on the Alpha, hence the diag posting, in the hope that Donald or someone can see what the problem is. Please note the entertaining part where the diag says: ***WARNING***: No MII transceivers found! And yet the driver says: eth0: MII transceiver found at MDIO address 1, config 1000 status 782d So, we are scratching our heads a bit.. BTW, just to get the diag to run we had to patch a bit, see yesterdays posting on this topic.. Best regards, Maurice W. Hilarius NEW! Telephone: 01-780-456-9771 Hard Data Ltd. NEW! FAX: 01-780-456-9772 11060 - 166 Avenue email:maurice@harddata.com Edmonton, AB, Canada - T5X 1Y3 http://www.harddata.com From davids@webmaster.com Thu Feb 11 20:31:00 1999 Date: Thu Feb 11 20:31:00 1999 From: David Schwartz davids@webmaster.com Subject: Weird tulip-diag results tulip-diag says: tulip-diag.c:v1.07 2/10/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Macronix 98713 PMAC adapter at 0x6100. Port selection is 10mpbs-serial 100baseTx scrambler, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. dmesg says: tulip.c:v0.90 10/20/98 becker@cesdis.gsfc.nasa.gov eth0: Macronix 98713 PMAC at 0x6100, 00 40 33 a5 0f 9e, IRQ 11. eth0: EEPROM default media type 100baseTx. eth0: Index #0 - Media 10baseT (#0) described by a 21140 non-MII (0) block. eth0: Index #1 - Media 100baseTx (#3) described by a 21140 non-MII (0) block. eth0: Index #2 - Media 10baseT-FD (#4) described by a 21140 non-MII (0) block. eth0: Index #3 - Media 100baseTx-FD (#5) described by a 21140 non-MII (0) block It should be running (and is) 100baseTx, half duplex. So what is a "10mpbs-serial"? DS From deadline@plogic.com Thu Feb 11 20:31:32 1999 Date: Thu Feb 11 20:31:32 1999 From: Douglas Eadline deadline@plogic.com Subject: tulip.90 k results On Wed, 10 Feb 1999, Douglas Eadline wrote: > Don (and anyone else interested) > > > Here is the funny thing, there are two idential NICs (KTI) > in this machine. When I use the .90k I can not > get eth0 to come up (ifup eth0), but I can get > the second interface to come up (ifup eth1). Ah umm, I just realized the the two NICs are different. >From memory, one is a 21143PA and the other is 21143PD I'm not sure which is which. I'll check next week. Sorry about the confusion. Doug ------------------------------------------------------------------- Paralogic, Inc. | PEAK | Voice:+610.861.6960 115 Research Drive | PARALLEL | Fax:+610.861.8247 Bethlehem, PA 18017 USA | PERFORMANCE | http://www.plogic.com ------------------------------------------------------------------- From ironwolf@lightside.com Fri Feb 12 00:32:51 1999 Date: Fri Feb 12 00:32:51 1999 From: Robert McNally ironwolf@lightside.com Subject: Please Help: Can't get Macronix 98713 to Work I am a new Linux user, but have a good deal of computer experience, including programming. I recently acquired Linux and so far the only snag is getting it to work with my Ethernet adapter, which is a NDC Communications Sohoware Fast Auto 10/100 PCI adapter. The manufacturer tells me it uses Tulip-compatible chips. My attempts to use the tulip driver included with Red Hat 5.2 have so far been unsuccessful, however. I have downloaded and installed the most recent test version of tulip.c (v0.90k), but also with no success. I have been unable to compile tulip-diag.c, as it appears to call for "cc", a compiler I don't have (Red Hat seems to only come with gcc, please correct me if I'm wrong.) However, I have included as much information as I know how below. The one external sign that the driver is doing anything at all is as follows: when I restart my computer, the link light on my 10base-T hub is lit. However, when tulip.c loads, it goes out and stays out until the system is again restarted. I have no problem using my adapter under Windows 98. I also attempted to use the de4x5 with similar results (except the link light does not go out), so I think tulip.c may not be at fault. However, at this time I have no idea what the problem might be. Just on the chance it might help, I also compiled and tested the driver with REVERSE_PROBE_ORDER defined, but with the same effect. Thanks in advance, Robert ------------------------------------------------------------------- BIOS: PhoenixBIOS 4.0 Release 6.0.A Copyright 1985-1997 Phoenix Technologies Ltd. All Rights Reserved Copyright Hewlett Packard, Inc. Rev 1.08 CPU = Pentium II 450 MHz (128MB RAM) ------------------------------------------------------------------- >From /etc/conf.modules: alias sound es1371 alias eth0 tulip options tulip options=0 debug=1 (also tried options=9) ------------------------------------------------------------------- >From the Linux boot sequence: ... IPX Portions Copyright (c) 1995 Caldera, Inc. Appletalk 0.17 for Linux NET3.035 The PCI BIOS has not enable the device at 0/72! Updating PCI command 0084->0085. tulip.c:v0.90k 2/1/99 becker@cesdis.gsfc.nasa.gov eth0: Macronix 98713 PMAC rev 17 at 0xd800, 00 80 c6 f7 6f 0c, IRQ 255. SIOCSIFFLAGS: Resource temporarily unavailable Starting portmapper: portmap Mounting remote filesystems ... ------------------------------------------------------------------- My Linux login screen: Red Hat Linux release 5.2 (Apollo) Kernel 2.0.36 on an i686 ------------------------------------------------------------------- Attempting to use the de4x5 driver produces the following during Linux startup: ... IPX Portions Copyright (c) 1995 Caldera, Inc. Appletalk 0.17 for Linux NET3.035 insmod: /lib/modules/preferred/net/de4x5.o: init_module: Device or resource busy Delaying eth0 initialization. Starting portmapper: portmap Mounting remote filesystems ... ------------------------------------------------------------------- cat proc/pci produces: PCI devices found: Bus 0, device 12, function 0: Multimedia audio controller: Ensoniq Unknown device (rev 2). Vendor id=1274. Device id=1371. Slow devsel. IRQ 9. Master Capable. Latency=96. Min Gnt=12.Max Lat=128. I/O at 0xdcc0. Bus 0, device 10, function 0: Communication controller: Unknown vendor L56xMF (rev 1). Medium devsel. Fast back-to-back capable. IRQ 255. Master Capable. No bursts. Min Gnt=252.Max Lat=14. Non-prefetchable 32 bit memory at 0xfedff800. I/O at 0xdca8. I/O at 0xd400. Bus 0, device 9, function 0: Ethernet controller: Unknown vendor MX98713 (rev 17). Medium devsel. Fast back-to-back capable. IRQ 255. Master Capable. Latency=66. Min Gnt=8.Max Lat=56. I/O at 0xd800. Non-prefetchable 32 bit memory at 0xfedffc00. Bus 0, device 7, function 3: Bridge: Intel 82371AB PIIX4 ACPI (rev 2). Medium devsel. Fast back-to-back capable. Bus 0, device 7, function 2: USB Controller: Intel 82371AB PIIX4 USB (rev 1). Medium devsel. Fast back-to-back capable. IRQ 255. Master Capable. Latency=32. I/O at 0xdc60. Bus 0, device 7, function 1: IDE interface: Intel 82371AB PIIX4 IDE (rev 1). Medium devsel. Fast back-to-back capable. Master Capable. Latency=32. I/O at 0xdcb0. Bus 0, device 7, function 0: ISA bridge: Intel 82371AB PIIX4 ISA (rev 2). Medium devsel. Fast back-to-back capable. Master Capable. No bursts. Bus 1, device 0, function 0: VGA compatible controller: ATI Mach64 GB (rev 92). Medium devsel. Fast back-to-back capable. IRQ 9. Master Capable. Latency=66. Min Gnt=8. Non-prefetchable 32 bit memory at 0xfd000000. I/O at 0x7800. Non-prefetchable 32 bit memory at 0xfecfe000. Bus 0, device 1, function 0: PCI bridge: Intel 440BX - 82443BX AGP (rev 2). Medium devsel. Master Capable. Latency=128. Min Gnt=140. Bus 0, device 0, function 0: Host bridge: Intel 440BX - 82443BX Host (rev 2). Medium devsel. Master Capable. Latency=32. Prefetchable 32 bit memory at 0xf8000000. From becker@cesdis1.gsfc.nasa.gov Fri Feb 12 00:59:59 1999 Date: Fri Feb 12 00:59:59 1999 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: Please Help: Can't get Macronix 98713 to Work On Thu, 11 Feb 1999, Robert McNally wrote: > Subject: Please Help: Can't get Macronix 98713 to Work .. > is a NDC Communications Sohoware Fast Auto 10/100 PCI adapter. > > The manufacturer tells me it uses Tulip-compatible chips. My attempts The Macronix chip is a Tulip work-alike, with some changes in the media selection registers. The first 12 registers are very similar to the 21140. > to use the tulip driver included with Red Hat 5.2 have so far been > unsuccessful, however. I have downloaded and installed the most recent > test version of tulip.c (v0.90k), but also with no success. > > I have been unable to compile tulip-diag.c, as it appears to call for > "cc", a compiler I don't have (Red Hat seems to only come with gcc, Usually 'cc' is a link to gcc beta$ ls -atlr /usr/bin/cc lrwxrwxrwx 1 root root 3 Oct 3 11:38 /usr/bin/cc -> gcc* > The PCI BIOS has not enable the device at 0/72! Updating PCI command 0084->0085. > tulip.c:v0.90k 2/1/99 becker@cesdis.gsfc.nasa.gov > eth0: Macronix 98713 PMAC rev 17 at 0xd800, 00 80 c6 f7 6f 0c, IRQ 255. > SIOCSIFFLAGS: Resource temporarily unavailable ... > Ethernet controller: Unknown vendor MX98713 (rev 17). > Medium devsel. Fast back-to-back capable. IRQ 255. Master Capable. Latency=66. Min Gnt=8.Max Lat=56. > I/O at 0xd800. Your BIOS isn't assigning an IRQ. Change the "PnP OS" (a misnomer) field, or a field that relates to IRQ assignment, in the BIOS setup. It's curious that your PCI BIOS uses IRQ255 to mean no IRQ assignment. This is the correct value, but most x86 BIOSes use IRQ0. 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 ironwolf@lightside.com Fri Feb 12 02:31:25 1999 Date: Fri Feb 12 02:31:25 1999 From: Robert McNally ironwolf@lightside.com Subject: Please Help: Can't get Macronix 98713 to Work At 10:00 PM -0800 2/11/99, Donald Becker wrote: >On Thu, 11 Feb 1999, Robert McNally wrote: > >> Subject: Please Help: Can't get Macronix 98713 to Work >.. >> is a NDC Communications Sohoware Fast Auto 10/100 PCI adapter. >> >> The manufacturer tells me it uses Tulip-compatible chips. My attempts > >The Macronix chip is a Tulip work-alike, with some changes in the media >selection registers. The first 12 registers are very similar to the 21140. > >> to use the tulip driver included with Red Hat 5.2 have so far been >> unsuccessful, however. I have downloaded and installed the most recent >> test version of tulip.c (v0.90k), but also with no success. >> >> I have been unable to compile tulip-diag.c, as it appears to call for >> "cc", a compiler I don't have (Red Hat seems to only come with gcc, > >Usually 'cc' is a link to gcc >beta$ ls -atlr /usr/bin/cc >lrwxrwxrwx 1 root root 3 Oct 3 11:38 /usr/bin/cc -> gcc* OK, I see that. Now, unfortunately, I'm getting a large number of compiler errors that look like I may have something misconfigured. Whether I try cc -O -Wall -o tulip-diag tulip-diag.c or cc -O -Wall -o tulip-diag tulip-diag.c -DLIBMII libmii.c I get a stream of errors which starts: tulip-diag.c:1: parse error before `#' tulip-diag.c:1: parse error before `#' tulip-diag.c:1: elements of array `longopts' have incomplete type tulip-diag.c:1: warning: excess elements in struct initializer afer `longopts[0]' tulip-diag.c:1: warning: excess elements in struct initializer afer `longopts[0]' tulip-diag.c:1: warning: excess elements in struct initializer afer `longopts[0]' ... BTW, I'm also not sure which version I should be attempting to build for my card. >> The PCI BIOS has not enable the device at 0/72! Updating PCI command >>0084->0085. >> tulip.c:v0.90k 2/1/99 becker@cesdis.gsfc.nasa.gov >> eth0: Macronix 98713 PMAC rev 17 at 0xd800, 00 80 c6 f7 6f 0c, IRQ 255. >> SIOCSIFFLAGS: Resource temporarily unavailable >... >> Ethernet controller: Unknown vendor MX98713 (rev 17). >> Medium devsel. Fast back-to-back capable. IRQ 255. Master >>Capable. Latency=66. Min Gnt=8.Max Lat=56. >> I/O at 0xd800. > >Your BIOS isn't assigning an IRQ. Change the "PnP OS" (a misnomer) field, >or a field that relates to IRQ assignment, in the BIOS setup. > >It's curious that your PCI BIOS uses IRQ255 to mean no IRQ assignment. This >is the correct value, but most x86 BIOSes use IRQ0. OK, I found the setting in the BIOS setup and changed it. Now the Linux boot sequence reads: tulip.c:v0.90k 2/1/99 becker@cesdis.gsfc.nasa.gov eth0: Macronix 98713 PMAC rev 17 at 0xd800, 00 80 c6 f7 6f 0c, IRQ 11. It is also no longer saying "SIOCSIFFLAGS: Resource temporarily unavailable". But the same thing happens-- the link light goes out and stays out. BTW, can you think of any reason I need to switch the PnP OS BIOS setting each time I switch between Windows 98 and Linux? Thanks for your continued help. Robert From becker@cesdis1.gsfc.nasa.gov Fri Feb 12 02:47:39 1999 Date: Fri Feb 12 02:47:39 1999 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: Please Help: Can't get Macronix 98713 to Work On Thu, 11 Feb 1999, Robert McNally wrote: > >> I have been unable to compile tulip-diag.c, as it appears to call for > >> "cc", a compiler I don't have (Red Hat seems to only come with gcc, > > OK, I see that. Now, unfortunately, I'm getting a large number of compiler > errors that look like I may have something misconfigured. Whether I try > > cc -O -Wall -o tulip-diag tulip-diag.c .. > tulip-diag.c:1: parse error before `#' Try transferring the file using FTP rather than a web browser: ftp://cesdis.gsfc.nasa.gov/pub/linux/diag/tulip-diag.c > tulip.c:v0.90k 2/1/99 becker@cesdis.gsfc.nasa.gov > eth0: Macronix 98713 PMAC rev 17 at 0xd800, 00 80 c6 f7 6f 0c, IRQ 11. I broke things with a change in v0.90k. Try changing the csr0 initialization on line 83 from #elif defined(__i386__) - static int csr0 = 0x0A000000 | 0x8000; + static int csr0 = 0x01A00000 | 0x8000; #else > BTW, can you think of any reason I need to switch the PnP OS BIOS setting > each time I switch between Windows 98 and Linux? The field really means "allow Windows to use 16-bit real-mode drivers". It provides BIOS hooks to emulate an MS-DOS environment, but only works with Windows. 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 travis.johnson@mci.com Fri Feb 12 03:37:26 1999 Date: Fri Feb 12 03:37:26 1999 From: Travis Johnson travis.johnson@mci.com Subject: cardbus support w/ kernel 2.2.x Is this being worked on? I am guessing there may be difficulties getting it to work with the comment from the source code: /* Grrrr, the PCI code changed, but did not consider CardBus... */ #include Just curious if I should look into porting it myself... Thanks, Travis From MaxFreedom@free-market.net Fri Feb 12 11:01:16 1999 Date: Fri Feb 12 11:01:16 1999 From: Max Freedom MaxFreedom@free-market.net Subject: tulip.90 k results Douglas Eadline wrote: > > Here is the funny thing, there are two idential NICs (KTI) > in this machine. When I use the .90k I can not > get eth0 to come up (ifup eth0), but I can get > the second interface to come up (ifup eth1). > >[cut] > > Feb 10 14:15:40 coyote4 kernel: eth0: Digital DS21143 Tulip rev 65 at > 0xec80, EEPROM not present, 00 4c 69 6e 75 79, IRQ 0. > >[cut] > > Feb 10 14:15:40 coyote4 kernel: eth1: Digital DS21143 Tulip rev 33 at > 0xec00, 00 40 f6 74 3c 4b, IRQ 9. The IRQ for eth0 looks wrong. I had the same problem with my LinkSys board. At Mark Hahn's suggestion, I diddled with some of the BIOS settings relating to plug-n-play. I believe turning *off* automatic configuration of PCI devices by the BIOS fixed my problem. That may not work for you, though, since eth1 is working OK. Mark also suggested moving the board to a different slot or possibly upgrading the BIOS. From christian@hamburg.gay-web.de Fri Feb 12 13:08:52 1999 Date: Fri Feb 12 13:08:52 1999 From: Christian Kuehn (Hostmaster) christian@hamburg.gay-web.de Subject: Patch-File for PRO110(B) & Linux 2.2.1 Hi ! I made a kernel-patch (based on Linux 2.2.1) for people who wants to use a PRO110(B)- Fast-Ethernet-card with the new Linux-kernel 2.2. You can find it on my homepage http://hamburg.gay-web.de/~tks/patch_ax88140_for_linux-2.2.1.gz Please unzip it in /usr/src and patch your kernel-source (normally in /usr/src/linux) with cat patch_ax88140_for_linux.2.2.1 | patch -p0 Now you can select the PRO110(B)-driver via "make config/menuconfig/xconfig" Good luck! Christian -- Christian Kuehn, 20257 Hamburg Tel. (040) 40 19 72 32 / Fax. (040) 40 19 72 30 eMail: christian@hamburg.gay-web.de http://hamburg.gay-web.de/~tks Und immer einen Besuch wert: http://hamburg.gay-web.de ****************************************************** From ironwolf@lightside.com Fri Feb 12 21:39:09 1999 Date: Fri Feb 12 21:39:09 1999 From: Robert McNally ironwolf@lightside.com Subject: Please Help: Can't get Macronix 98713 to Work At 11:48 PM -0800 2/11/99, Donald Becker wrote: >On Thu, 11 Feb 1999, Robert McNally wrote: > >> >> I have been unable to compile tulip-diag.c, as it appears to call for >> >> "cc", a compiler I don't have (Red Hat seems to only come with gcc, >> >> OK, I see that. Now, unfortunately, I'm getting a large number of compiler >> errors that look like I may have something misconfigured. Whether I try >> >> cc -O -Wall -o tulip-diag tulip-diag.c >.. >> tulip-diag.c:1: parse error before `#' > >Try transferring the file using FTP rather than a web browser: > ftp://cesdis.gsfc.nasa.gov/pub/linux/diag/tulip-diag.c OK, I have successfully figured out how to get tulip-diag.c to compile. >> tulip.c:v0.90k 2/1/99 becker@cesdis.gsfc.nasa.gov >> eth0: Macronix 98713 PMAC rev 17 at 0xd800, 00 80 c6 f7 6f 0c, IRQ 11. > >I broke things with a change in v0.90k. >Try changing the csr0 initialization on line 83 from > #elif defined(__i386__) >- static int csr0 = 0x0A000000 | 0x8000; >+ static int csr0 = 0x01A00000 | 0x8000; > #else I tried this change to no effect, but kept it in because you say it's a fix. Now that I have tulip-diag (I built the MII version, since my adapter has 100Base-T capability as well as 10Base-T), below is a transcript of my session with it: # tulip-diag-mii -f -e -e -a -m -m -p d800 tulip-diag.c:v1.07 2/10/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Digital Tulip, unknown type Tulip chip registers at 0xd800: fff88000 ffffffff ffffffff 00fff028 00fff228 f4661000 01a82002 f7ffebef fffe0000 fff583ff fffd7b37 fffe0000 000020ce ffff0001 fffffff9 fff00000 Port selection is 10mpbs-serial 100baseTx scrambler, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. EEPROM contents: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 8000 f7c6 0c6f 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0014 0000 0000 0000 0000 0512 10d9 ca0c ID CRC 0xe3 (vs. 00), complete CRC cfac2f47. A simplifed EEPROM data table was found. The EEPROM does not contain transceiver control information. ***WARNING***: No MII transceivers found! Thanks for the help so far! Robert From Nicholas.S.Jenkins@cdc.com Thu Feb 18 14:44:38 1999 Date: Thu Feb 18 14:44:38 1999 From: Nicholas Jenkins Nicholas.S.Jenkins@cdc.com Subject: Linksys Cardbus and .90k This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BE5B4D.0C5A3380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Good Day, My name is Nicholas Jenkins. This is my first post to this list. I have been reading for about the last month, and I have perused through several prior months' notes. First my questions: Who, if anyone, at this point is working on updates to the .90K version of tulip.c to resolve its issues with the latest linksys card(s)? Any luck? My offer: I know nothing about Linux driver development, or the specifics of this technology, but I am a proficient programmer, and I am willing to help in whatever way I can to this cause. Just point me in the right direction. Uniqueness: I have a Dell Inspiron 7000 and a Linksys Cardbus 10/100 card (chip rev d) that I can develop on. Notes about current tulip.c: I started trying to compile version .89L (pointed to by the Linksys web page) under RH 5.2. when this failed, I found the linksys dev page (one of them :) and I got .90F. When this failed, I upgraded to kernel 2.2.1. When this failed, I found the other page and downloaded .90K. This failed for a long time. At the same time, I was trying to resolve some XFree86 problems. As it turns out, at home, I'm running 100BT, Full Duplex. At work, I am running 10BT. At home, afer recompiling the kernel 2.2.1 (to resolve my XFree86 problem), I got the network card to work once - although I did also have to do: ifconfig eth0 down; ifconfig eth0 up <--saw this in some of the postings - and it did work. Now then, I went into work the next day, and I recompiled the kernel again, after which I tried to start the network, and I got nothing. In fact, I recompiled the kernel 10 different ways, none of which would allow me to resolve the problem - regardless of any ifconfig or /etc/pcmcia settings. Since then, I have been moving between houses, and I broke my ankle, so I haven't been able to transport my notebook between the 2 environments, but I believe that based on these experiences, as some others that I have not documented, that any driver prior to .90K is worthless for the Linksys, and that even then it will ONLY work in 100BT environments - in spite of the fact that even in 10BT environments it "sees" that the link is only 10BT, and it would otherwise appear that it is responding appropriately to that environment (I say this based upon the MII LEDs). -NICK ------=_NextPart_000_0005_01BE5B4D.0C5A3380 Content-Type: text/x-vcard; name="Nicholas S Jenkins.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: ATTACHMENT; filename="Nicholas S Jenkins.vcf" BEGIN:VCARD VERSION:2.1 N:Jenkins;Nicholas;S FN:Nicholas S Jenkins ORG:Control Data Systems, Inc. TITLE:Systems Administrator NOTE;ENCODING=QUOTED-PRINTABLE:Always question authority.=0D=0AMoreover, always question. TEL;WORK;VOICE:(937)427-6380 TEL;WORK;FAX:(937)427-6301 ADR;WORK:;(937)427-6300;2970 Presidential Drive, Suite 200;Fairborn;Ohio;45324;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:(937)427-6300=0D=0A2970 Presidential Drive, Suite 200=0D=0AFairborn, Ohio 45= 324=0D=0AUSA URL: URL:http://wrtfac.day.cdc.com:17080/~Nicholas.S.Jenkins EMAIL;PREF;INTERNET:Nicholas.S.Jenkins@cdc.com REV:19981204T155059Z END:VCARD ------=_NextPart_000_0005_01BE5B4D.0C5A3380-- From becker@cesdis1.gsfc.nasa.gov Thu Feb 18 15:16:57 1999 Date: Thu Feb 18 15:16:57 1999 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: Linksys Cardbus and .90k On Thu, 18 Feb 1999, Nicholas Jenkins wrote: > Subject: Linksys Cardbus and .90k > Who, if anyone, at this point is working on updates > to the .90K version of tulip.c to resolve its issues > with the latest linksys card(s)? Any luck? I am actively working on the Tulip driver. I've been spending about three hours a day over the past week on it, and I've sent out various private snapshots to individuals to test. AFAIK, the current public test release, 90K, should work with both versions of the Linksys CardBus card (at the expense of breaking PCI 21143-TD/PD boards:-<). [[ My latest snapshot now works with the PNIC-II, but I just borrowed an AmbiCom CardBus w/SYM transceiver and an ASIX88140 PCI card last night that reportedly fail with the current driver. Just when I thought I was ready for a release... ]] > Notes about current tulip.c: > When this failed, I found the other page and downloaded > .90K. This failed for a long time. At the same time, > I was trying to resolve some XFree86 problems. As it > turns out, at home, I'm running 100BT, Full Duplex. With Autonegotiation? > At work, I am running 10BT. Without Autonegotiation e.g. a simple old-technology repeater? > At home, afer recompiling > the kernel 2.2.1 (to resolve my XFree86 problem), I got > the network card to work once - although I did also have > to do: ifconfig eth0 down; ifconfig eth0 up <--saw this > in some of the postings - and it did work. .. > between the 2 environments, but I believe that based on > these experiences, as some others that I have not documented, > that any driver prior to .90K is worthless for the Linksys, It depends on the version. The older card works fine, as long as snooze mode is never enabled. The new 21143-TD chip has a different EEPROM size and must have burst mode disabled to work. 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 Nicholas.S.Jenkins@cdc.com Thu Feb 18 15:39:26 1999 Date: Thu Feb 18 15:39:26 1999 From: Nicholas Jenkins Nicholas.S.Jenkins@cdc.com Subject: Linksys Cardbus and .90k WOW!!!!Thanks for the fast response... My comments are strewn w/in, as yours were... > -----Original Message----- > From: Donald Becker [mailto:becker@cesdis1.gsfc.nasa.gov] > Sent: Thursday, February 18, 1999 3:18 PM > To: Nicholas Jenkins > Cc: linux-tulip@beowulf.gsfc.nasa.gov > Subject: Re: Linksys Cardbus and .90k > > > On Thu, 18 Feb 1999, Nicholas Jenkins wrote: > > Subject: Linksys Cardbus and .90k > > Who, if anyone, at this point is working on updates > > to the .90K version of tulip.c to resolve its issues > > with the latest linksys card(s)? Any luck? > > I am actively working on the Tulip driver. > I've been spending about three hours a day over the past week on it, and > I've sent out various private snapshots to individuals to test. > > AFAIK, the current public test release, 90K, should work with both > versions of the Linksys CardBus card (at the expense of breaking PCI > 21143-TD/PD boards:-<). Sorry, don't know what AFAIK means...but I get the point. However, it didn't work, except once, but probably due to items discussed below. > > [[ My latest snapshot now works with the PNIC-II, but I just borrowed an > AmbiCom CardBus w/SYM transceiver and an ASIX88140 PCI card last > night that > reportedly fail with the current driver. Just when I thought I was ready > for a release... ]] > > > Notes about current tulip.c: > > When this failed, I found the other page and downloaded > > .90K. This failed for a long time. At the same time, > > I was trying to resolve some XFree86 problems. As it > > turns out, at home, I'm running 100BT, Full Duplex. > > With Autonegotiation? Yep...At home I have a Linksys 5 port 10/100 N-Way, Auto-Negotiation hub. If you need the exact model, I can give you that info. > > > At work, I am running 10BT. > > Without Autonegotiation e.g. a simple old-technology repeater? Yep...a simple 24-port 10BT unmanaged hub. How'd you know?!!! Seems like you've seen this before, eh?! > > > At home, afer recompiling > > the kernel 2.2.1 (to resolve my XFree86 problem), I got > > the network card to work once - although I did also have > > to do: ifconfig eth0 down; ifconfig eth0 up <--saw this > > in some of the postings - and it did work. > .. > > between the 2 environments, but I believe that based on > > these experiences, as some others that I have not documented, > > that any driver prior to .90K is worthless for the Linksys, > > It depends on the version. The older card works fine, as long as > snooze mode > is never enabled. > The new 21143-TD chip has a different EEPROM size and must have burst mode > disabled to work. Couple of notes on this... I thought it interesting that you didn't put in some code like: #ifdef CARDBUS #define EEPROM_ADDRLEN 8 #define EEPROM_SIZE 512 /* 2 << EEPROM_ADDRLEN */ #else #define EEPROM_ADDRLEN 6 #define EEPROM_SIZE 128 /* 2 << EEPROM_ADDRLEN */ #endif I say this, because I have seen many times in the postings, where you note that the new length should be 8. Also, I have never seen the posting say that the EEPROM_SIZE should be increased to 512...but...based on your source-code notes, it would seem logical? As for the burst-mode...what's the fix there? I assume that it's a value in csr0, but what - 0? Let me know, and I'll try it, as my notebook is currently here at work. -NICK P.S. why don't I/the archives see any postings since the 12th? From lowekamp@poconos.cmcl.cs.cmu.edu Fri Feb 19 12:08:42 1999 Date: Fri Feb 19 12:08:42 1999 From: Bruce Lowekamp lowekamp@poconos.cmcl.cs.cmu.edu Subject: Linksys Cardbus and .90k I also haven't yet managed to get my LinkSys Cardbus going. I've spent most of my time trying to get it working at 10bT, although the couple times I've plugged it into 100bTX, it hasn't worked either. This is with .90k and 3.0.8 on 2.0.36 (redhat 5.2). I also tried .90p today. The basic result was the same---it appeared to be receiving but not transmitting. However, .90p didn't read my HW address right, either. It produced 00:80:00:80:00:80. I also tried locking the transceiver with options=9, but this didn't help, either. The only interesting thing I could tell from the output was that the tulip-diag I ran before trying to ping listed the Tx process state as "stopped," and after I tried to ping and ran tulip-diag again, it says "Waiting for Tx to finish." Here are the debug messages from syslog and the reports from the new tulip-diag with libmii. If anything else would be of help, just let me know. Bruce ---------------- syslog from .90k on 10baseT: Feb 19 11:23:38 localhost cardmgr[202]: initializing socket 1 Feb 19 11:23:38 localhost cardmgr[202]: socket 1: Linksys EtherFast 10/100 Feb 19 11:23:38 localhost cardmgr[202]: executing: 'insmod /lib/modules/2.0.36/pcmcia/cb_enabler.o' Feb 19 11:23:38 localhost cardmgr[202]: executing: 'insmod /lib/modules/2.0.36/pcmcia/tulip_cb.o debug=10' Feb 19 11:23:38 localhost kernel: cs: cb_config(bus 4): vendor 0x1011, device 0x0019 Feb 19 11:23:38 localhost kernel: fn 0 bar 1: io 0x400-0x47f Feb 19 11:23:38 localhost kernel: fn 0 bar 2: mem 0xa00c0000-0xa00c03ff Feb 19 11:23:38 localhost kernel: fn 0 rom: mem 0xa0080000-0xa00bffff Feb 19 11:23:38 localhost kernel: tulip_attach(bus 4, function 0) Feb 19 11:23:38 localhost kernel: tulip.c:v0.90k 2/1/99 becker@cesdis.gsfc.nasa.gov Feb 19 11:23:38 localhost kernel: eth0: Digital DS21143 Tulip rev 65 at 0x400, 00 e0 98 04 8b 4a, IRQ 9. Feb 19 11:23:38 localhost kernel: eth0: EEPROM default media type Autosense. Feb 19 11:23:38 localhost kernel: eth0: MII interface PHY 0, setup/reset sequences 0/0 long, capabilities e0 78. Feb 19 11:23:38 localhost kernel: eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Feb 19 11:23:38 localhost kernel: eth0: MII transceiver #0 config 3000 status 7809 advertising 01e1. Feb 19 11:23:38 localhost cardmgr[202]: executing: './network start eth0' Feb 19 11:23:39 localhost kernel: eth0: Using MII transceiver 0, status 7809. Feb 19 11:23:44 localhost kernel: eth0: 21143 negotiation status 000000c6, MII. Feb 19 11:23:44 localhost kernel: eth0: MII status 7829, Link partner report 0021, CSR6 b20e2002. Feb 19 11:23:57 localhost kernel: eth0: Using MII transceiver 0, status 782d. Feb 19 11:24:02 localhost kernel: eth0: 21143 negotiation status 000000c6, MII. Feb 19 11:24:02 localhost kernel: eth0: MII status 782d, Link partner report 0021, CSR6 b20e2002. lots of binary stuff as I reported in a message a few weeks ago tulip-diag before trying to ping: tulip-diag.c:v1.07 2/10/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Digital Tulip, unknown type Tulip chip registers at 0x400: fa008000 ffffffff ffffffff 00fdd028 00fdd228 f0000102 b20e0000 f3fe0000 e0000000 fffd83ff ffffffff 00000000 000000c6 ffff0000 fff80000 8ff90008 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. EEPROM transceiver/media description for the Digital Tulip, unknown type chip. Leaf node at offset 128, default media type 0000 (10baseT). 0 transceiver description blocks: MII PHY found at address 0, status 0x782d. tulip-diage after trying to ping: tulip-diag.c:v1.07 2/10/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Digital Tulip, unknown type Tulip chip registers at 0x400: fa008000 ffffffff ffffffff 00fdf820 00fdfa20 f0200100 b20e0000 f3fe0000 e0000000 fffd83ff ffffffff 00000000 000000c6 ffff0000 fff80000 8ff90008 Port selection is MII, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Waiting for Tx to finish'. The transmit threshold is 128. EEPROM transceiver/media description for the Digital Tulip, unknown type chip. Leaf node at offset 128, default media type 0000 (10baseT). 0 transceiver description blocks: MII PHY found at address 0, status 0x782d. syslog from .90p on 10baseT: Feb 19 10:55:31 localhost cardmgr[202]: initializing socket 1 Feb 19 10:55:31 localhost cardmgr[202]: socket 1: Linksys EtherFast 10/100 Feb 19 10:55:31 localhost cardmgr[202]: executing: 'insmod /lib/modules/2.0.36/pcmcia/cb_enabler.o' Feb 19 10:55:31 localhost cardmgr[202]: executing: 'insmod /lib/modules/2.0.36/pcmcia/tulip_cb.o debug=10' Feb 19 10:55:31 localhost kernel: cs: cb_config(bus 4): vendor 0x1011, device 0x0019 Feb 19 10:55:31 localhost kernel: fn 0 bar 1: io 0x400-0x47f Feb 19 10:55:31 localhost kernel: fn 0 bar 2: mem 0xa00c0000-0xa00c03ff Feb 19 10:55:31 localhost kernel: fn 0 rom: mem 0xa0080000-0xa00bffff Feb 19 10:55:31 localhost kernel: tulip_attach(bus 4, function 0) Feb 19 10:55:31 localhost kernel: tulip.c:v0.90p 2/18/99 becker@cesdis.gsfc.nasa.gov Feb 19 10:55:31 localhost kernel: eth0: Digital DS21143 Tulip rev 65 at 0x400, 00:80:00:80:00:80, IRQ 9. Feb 19 10:55:31 localhost kernel: eth0: EEPROM default media type Autosense. Feb 19 10:55:31 localhost kernel: eth0: MII interface PHY 0, setup/reset sequences 0/0 long, capabilities e0 78. Feb 19 10:55:31 localhost kernel: eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Feb 19 10:55:31 localhost kernel: eth0: MII transceiver #0 config 3000 status 7809 advertising 01e1. Feb 19 10:55:31 localhost cardmgr[202]: executing: './network start eth0' Feb 19 10:55:31 localhost kernel: Swansea University Computer Society IPX 0.34 for NET3.035 Feb 19 10:55:31 localhost kernel: IPX Portions Copyright (c) 1995 Caldera, Inc. Feb 19 10:55:31 localhost kernel: Appletalk 0.17 for Linux NET3.035 Feb 19 10:55:31 localhost kernel: eth0: Using MII transceiver 0, status 7809. Feb 19 10:55:36 localhost kernel: eth0: 21143 negotiation status 000000c6, MII. Feb 19 10:55:36 localhost kernel: eth0: MII status 7829, Link partner report 0021, CSR6 b20e2002. Feb 19 10:56:36 localhost kernel: eth0: 21143 negotiation status 000000c6, MII. Feb 19 10:56:36 localhost kernel: eth0: MII status 782d, Link partner report 0021, CSR6 b20e2002. Feb 19 10:57:36 localhost kernel: eth0: 21143 negotiation status 000000c6, MII. Feb 19 10:57:36 localhost kernel: eth0: MII status 782d, Link partner report 0021, CSR6 b20e2002. Feb 19 10:58:36 localhost kernel: eth0: 21143 negotiation status 000000c6, MII. Feb 19 10:58:36 localhost kernel: eth0: MII status 782d, Link partner report 0021, CSR6 b20e2002. Feb 19 10:59:36 localhost kernel: eth0: 21143 negotiation status 000000c6, MII. Feb 19 10:59:36 localhost kernel: eth0: MII status 782d, Link partner report 0021, CSR6 b20e2002. Feb 19 11:00:36 localhost kernel: eth0: 21143 negotiation status 000000c6, MII. Feb 19 11:00:36 localhost kernel: eth0: MII status 782d, Link partner report 0021, CSR6 b20e2002. Feb 19 11:01:29 localhost kernel: Swansea University Computer Society IPX 0.34 for NET3.035 Feb 19 11:01:29 localhost kernel: IPX Portions Copyright (c) 1995 Caldera, Inc. Feb 19 11:01:29 localhost kernel: Appletalk 0.17 for Linux NET3.035 Feb 19 11:01:36 localhost kernel: eth0: 21143 negotiation status 000000c6, MII. Feb 19 11:01:36 localhost kernel: eth0: MII status 782d, Link partner report 0021, CSR6 b20e2002. Feb 19 11:02:36 localhost kernel: eth0: 21143 negotiation status 000000c6, MII. Feb 19 11:02:36 localhost kernel: eth0: MII status 782d, Link partner report 0021, CSR6 b20e2002. Feb 19 11:03:25 localhost cardmgr[202]: executing: './network check eth0' Feb 19 11:03:25 localhost cardmgr[202]: shutting down socket 1 Feb 19 11:03:25 localhost cardmgr[202]: executing: './network stop eth0' Feb 19 11:03:25 localhost kernel: tulip_detach(eth0) Feb 19 11:03:25 localhost cardmgr[202]: executing: 'rmmod tulip_cb' Feb 19 11:03:25 localhost cardmgr[202]: executing: 'rmmod cb_enabler' tulip-diag.c:v1.07 2/10/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Digital Tulip, unknown type Tulip chip registers at 0x400: f9a08000 ffffffff ffffffff 00fdf028 00fdf228 f0000102 b20e0000 f3fe0000 e0000000 fffd83ff ffffffff 00000000 000000c6 ffff0000 fff80000 8ff90008 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. EEPROM transceiver/media description for the Digital Tulip, unknown type chip. Leaf node at offset 128, default media type 0000 (10baseT). 0 transceiver description blocks: MII PHY found at address 0, status 0x782d. From ericding@MIT.EDU Fri Feb 19 13:18:44 1999 Date: Fri Feb 19 13:18:44 1999 From: Eric Ding ericding@MIT.EDU Subject: Linksys Lite-On and 0.90 vs. 0.90f (patched) vs. 0.90p Hi all, I've got several of the Linksys 82c169 NIC's on my intranet, and have observed some inexplicably (at least by me) poor performance. Machine 10.0.0.1 is a 486DX4-100 that serves as our router to our cable modem network, 4 MB RAM, running the 0.90f patched driver. Machine 10.0.0.3 is a 5x86-133 on a VIP motherboard, 32 MB RAM. When I run netperf from 10.0.0.1 to 10.0.0.3, I get these results: TCP STREAM TEST to 10.0.0.3 Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65535 65535 65535 10.39 17.78 I *think* this is really low because of the motherboard and such, as doing a test to 10.0.0.1 gives similar numbers. Is this a good assumption? The really bad performance comes when I run netperf to go from 10.0.0.3 (with the 0.90 driver) back to 10.0.0.1: TCP STREAM TEST to 10.0.0.1 Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65535 65535 65535 10.39 1.96 You think that's bad? If I upgrade to the patched 0.90f or the 0.90p driver, I get absolutely abominable results: 65535 65535 65535 11.05 0.24 By the way, pinging to 10.0.0.3 from itself yields the following: 65535 65535 65535 10.00 80.47 Can anyone help me figure out what's going on? Thanks, Eric From Nicholas.S.Jenkins@cdc.com Fri Feb 19 14:31:52 1999 Date: Fri Feb 19 14:31:52 1999 From: Nicholas Jenkins Nicholas.S.Jenkins@cdc.com Subject: .90P driver and Linksys Cardbus This is a multi-part message in MIME format. ------=_NextPart_000_0001_01BE5C14.822C5F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Good Day, I just tried out the .90P driver, and it WORKS GREAT!!!!! Kudos, Mr. Becker! I did not have 1 single problem, while using the driver (on the 10BT unmanaged hub, non-auto-sensing). This is on the latest rev of the Linksys 10/100 Cardbus card. One note regarding the code, however; initially, I got an error while trying to run it "as-is", something about "dereferencing a NULL kernel pointer". After looking at the code, it turns out that the change you made at my request doesn't quite work, as it references a struct not yet allocated at compile time. See below: #ifdef CARDBUS #define EEPROM_ADDRLEN (tp->revision == 65 ? 8 : 6) #else #define EEPROM_ADDRLEN 6 #endif tp is an unassigned pointer at this point in the code, so this is a bad test. I merely changed it to the following, for the moment: #ifdef CARDBUS #define EEPROM_ADDRLEN 8 #else #define EEPROM_ADDRLEN 6 #endif Which worked for me, although, admittedly, it's not really the same test at all. However, I thank you for the new driver. It's great!!!!! -NICK ------=_NextPart_000_0001_01BE5C14.822C5F80 Content-Type: image/gif; name="Judge's Chambers.gif" Content-Transfer-Encoding: Base64 Content-Disposition: ATTACHMENT; filename="Judge's Chambers.gif" Content-ID: <860552119@19021999-0425> R0lGODlhIAM7ANX/ACEhISEYGCEQEGs5GGMxEHs5EEohCJRCEKVKEDkhEJxKEK1SEFopCGsxCEop EIQ5AJxCAK1KAGs5ELVaEHM5CK1SCJRCAKVKAIxCAL1aAM5jADkpGEIpEDkpEGuUjEpaWoytrWN7 e4SlpTlKSmOEhDFCQsDAwFp7eyk5OVJzczlSUkJjYzFSUiE5OSFCQnuUnEpjaxApMYSUnAAQGCk5 QggYIRghKSkxOSEpMUpKUjExORAQGAAAAAAAAAAAAAAAACH5BAEAACYALAAAAAAgAzsAQAb/wEsl MiFmjpNJZaFcDDYcgK5UstloJRSWhsPaarialWViuUawsrlmWpVapVwJZ7sBcLfSSGXq+/+AgYKD hIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6CZGRUZSqMTCxUVFhUKCgcCAbJ0dDQjMTAufS1l KSQuMS01NzU0MGspKyknMS4vIi8swSwkdXl7odna29zd3t/g4eLj5OXm54AWTAsLCBcKCK4Q8K4J sgAlOjUxwR8tVjA8sBhRY4aLFTl0tKDRjCEMGMpshNGhokqNYSNw4JiCDZ3HjyBDihxJsqTJkygb QbiQCsJKBRYwyMRg4QGFWAIAoGjBggaJ/2QwRpjgEcODhxQxyhBcAeLEjBkxUMTosmPHDRxzNIKp cQeFHj4pw4odS7as2bNo01qCwA6BWwTs2sFt68AegBUefrm4GKPGDqw4cthBEebNihEzuDJNgSLH Px06tH6ZgUPnV7WYM2vezLmz58+IMkTQoIFUhSQVXEJodeDJhgA2YlTN8+VvjciJAaggEaLFDGGV N1oBcAfwCJ62WAC4cQ0s6OfQo0ufTr26JHWo5NJTMC+eAtcBtH7IUYfGbxwhPmj8cmNEZBs7Lhav bIX5iBvWaOH56ty6//8ABijggCCNdoQGGWgwAYIKkpZgAQ5sAIBQWX1x0QgoXPSFVmDgsP8DhgTV UEIMNuTwwRd1YHWfRpbtAdYHiMBI4Iw01mjjjQMqIAQr7Kyiyo9KUABFADtIBEZfNKSgQgyJpWBC DFfhEAMNC6WQAhm6OBmbGMGU8MELJyzXXH84lmnmmWimidlcqRCRhBJLFHEBAR28FkZgwVA5ggu+ nLBnCkeZ8IEOI9AgogoCJflkHffZkNEM5DHHn5qUVmrppZh+s9IQF3QawaedhnoBA68FcEczJ6RB 4gjJnJACDM2soMJCMaCRxgxftLCeFRLpYIdE+7nYh4yZFmvsscgm+8dKokbQ6UqfRktAAhKGAEML HoywwgksoFDirCyc4AIZcIRAQ7gfqMD/hzR4FIlVCyhU1EJXkypr77345jsgjKehNoFo/r45gT2x xCcHcTbooNNFV8awzAq6wBBCCsLgCsBFLQhzA5QY17DCHWPqK/LIJJe85lyqCKwKO85SwMFrxOHg Hh4qYLjCxCbA0FSHVelRAhg2wAbGCDnskbHHXLRIpslMN+300+Js2mwEFYjaqQQvAwBjCy5AhUIy L8yaccL0aSQlc1zZQBhhVkCp0c/ANucHsVDXbffdeEMihCpWrywEOwVsALNE3n4QTA0LYQHWVVqM MBANLuhCRs7H+Hk4ky6AfFnenHfuuecyFvDAAzI9cMABGIw+kwUXYP1aZCKmMMIHI+5T/wML17rQ Qkb8lEDDURCtwIIvZEjEhQ0BzaC5ukt/7vzz0OdbQAGuWGABTNa74oo7DdgDmxVY3SD2uR70kQYL sn4gQwk8SBPDCn1EfkbGU/We+X7qRq///vwXq4qbAgtgEiQgOFPhQ1K6k19eABWQK7VABwmjgp6E gQITDINELUhKzpaXv/558IMgnNE8YDIPllzAHe7QnuvuEgIRBG8FLThMUjI4Ag9ATAUbMwMv+rCn FVSlbTILjg2Ik4cOhvCISEwiaP6VICIg6Aif+heCIOSAAPhOh82gGAtaQAIPiOsET9JDGbiogsTQ 4AMwgODFNIIfPAxxOSVgnhLnSMc6kv9FYHFpCwIqsMfVkOo17VlBUkjAPhzIAAQgcF8MWIBIcyUF BupyQ5fWEwYwoEBiYopj8+zIyU56Uhw/ChUE3NGpVlgAAhYQwA5yUoJwiaB8T4lPBpUhPJ4UJDZU gtdTyOCBEMjsAzfIGNcyB0c5fvKYyEwmKBTwo2Y201mqCBwHBADBD6EABe7CgQx50hPf1IBVM1DB K2mXqxbcwFfvwQEKRkBETSrznfCMpyROQ5ok1FOAFRDS4MQAGR0kJCM3QAFUtuQMEtAARRqaA7C8 tKcqxSCTxpSnRCdK0T8U4ADXs948sqe9PbrOVJUMzxD9so+F5CwEVmDbEOkQNIncgAv/G4sXDcRW mSIasaI4zSky/5eEUgjwTRCCmRictJMS9GaLKoChxYIpkeHwbkpwuAqJDnMME7TzpjrNqlbnOMJT vqNqKByhAgj4mhEUqgYZ4tLNPgCVOzQ1MCqgQ5SARYcZ5GEYYvDWVbG61b76dX9MZNCCpDjYB0Uo PCZIaghu8Y8lteAD19TrOd8GgBnEa0RY8dKIVHAitFYGjh35q2hH6zzSmNZBDDqtBh7gAAcIIB/D eZvarFACO+SDDlP45grWs7s7LYQObqPDXjcZI9Ia97jFWlCCjsBcBH2qX0EV6UttUAU4mGBEWGCB Cnw1FRr4IXI5M58JktEHG5ggg8oL/xZfkcve9t7LdKjDwAFeUYEHrCJ7FiDAy0Cqq6m8IQ0560kX rpK4yEGMDFjCRS7EsI8ZjIAEHHSvhCesLOtZ2ML3pQmzJHBYABgJT8fZhw14ssjYqBNyLggIDF4F sT7U6rris0EIPEAcr4SWwjjOsZqYOwpSMHcITMxAXeyEhxsUzRa5PNcWbbUqOKSKBVA+hg2AMd6e QKRWmruxjrfMZRqtJBUXeElMaFI6l8VCFhdRiM+41ocUGAqMwbBgDlKgAxaM2ErAuyE/ZgWoGter y4AOtH/wmAo98rGUZA1AZHzlO4Y47hmIRLAJXEACEFBGB/yAMsRgIAOU0gI+cc0ycf8FTepSa4ZZ oXJWmC8QrU8RoIAXG4aUbDGuRR5EBMlwUgxgi+maTSmutN1VL/ysZVMb+9hoCWWoSNkpElrAAAlI gBQwzY8YqEAwL33BQZKxp+vSAHJ5GpfuwjA7XuHgNyuVG7LXze6xsEUu8I53O15tp91x7TjCpAEM C6KLxE06hlOytiBHAD7IZEQMJRD1qNvN8IaTYwjOXEIz91ZFaZsIeK86Di62mAIwmcC7Oai2Cz5g JfcVyQa4Mhtz7CCpYjv85TAHR7/6RbWAvSnRjmoxDAPeAmjoArzBECacDdUCOluBBvi5ihiCw5GF x/zpUN+EaEohGon/aIQHIOuEwO3/sZzVDBgeAMELhDfea3FRBDOIzwoQQnD2mLsgmXR51OdOd0tc NKOntLD2mImABJw5DzEkwdphpzM48yIZMpDBCp6CVhPcYhi1peQNlJe0pju97pjP/CHc0iMANmEJ znq1tB0Xg2eQKARdzFBDd+PLYqwdBNaa1eGscJE4wKCLL6jp5jTP+94nAkg9/WkShjwhKFvJT1fA hSBTYK7hEQZxJ6CB6nmSjCqsJ088ifvlfc/9zGMnLggYpTy2I4AzH8SGIjDBU2KNAjTiNpgZG0gY UM6UbGnkQ/gRQzC13/3++98E84BKL8FHOvIOKvQy6IEUGeQXyoNGSzIrLpBLYhAU/zXgAh7QabJH Ikg3B2DwF9q3ff8Xgg23KarGapwiBKESIaWyA5GxEXYFHyMQAlDBC2vHECaAAiswdgd1f1fAWf9A IjgAEfwngkRYd8pVWIPVIExUF7LQKzoQH1kRHzJjAunBLUnRFGm1A1PhLUETA531bbszB1Kwe0VY hjGHBHDyJqXgJqRBRaayFY0BGecmHABQFTPwOyHAJHXIFfgxHLExJTAwU+oyL6AFgmZ4iIG2EnCx aqh0YalDAX8UAHbAFWJQWX9RVziAPiHAAj9zMWvUdjUVGbWCC5M2EKKGiKjIcIQGfnvURxGQaPQR axexD/zgAS8wXilgVzdwciQCLP8S8QYZggXHcQIxNISpeIzGhmqesmqs1mocZid1AFlppwJUggIs cDvlYxW7VlselgM5sBwZ1AW8szEOZkEfiIzoSGrK1inM9g4uYQGJ5mEooAMfQEjHoScgMAI8gAe7 difCIRHLsR56gB/j4VLGmI4IuWXvxnlswnltMQARMiFZkEEj1hdFtwJ8kTbwkSKT1VRTcSdz8JGx 1XQJWZI6BnE/QjWpEEqq8IwAoBT/gCsmAEZlFBVLohUBuRy8Ugdx82ko0IcHaZJCyV798iZApgQq E10l8HEZdF606Dha8A/00UZhEB/dJSXUxStVcBVD1HLrNZRg6VeqgAQ/VpZT1FpTVtQHtxVQaOU7 UkgLSqdNGaEC3lIojcEFQXgFzIECEGWIYfmX8nRaCaJaqaUBBeAaGLIhGiGHAEk0XwA7UjIriMM2 cfQFHsaTMtOV6gaYnLlVQQAAOw== ------=_NextPart_000_0001_01BE5C14.822C5F80-- From Nicholas.S.Jenkins@cdc.com Fri Feb 19 15:36:11 1999 Date: Fri Feb 19 15:36:11 1999 From: Nicholas Jenkins Nicholas.S.Jenkins@cdc.com Subject: Linksys Cardbus and .90k Comments are below.... -NICK > -----Original Message----- > From: owner-linux-tulip@beowulf.gsfc.nasa.gov > [mailto:owner-linux-tulip@beowulf.gsfc.nasa.gov]On Behalf Of Bruce > Lowekamp > Sent: Friday, February 19, 1999 12:08 PM > To: linux-tulip@beowulf.gsfc.nasa.gov > Subject: Re: Linksys Cardbus and .90k > > > > I also haven't yet managed to get my LinkSys Cardbus going. I've > spent most of my time trying to get it working at 10bT, although the > couple times I've plugged it into 100bTX, it hasn't worked either. > > This is with .90k and 3.0.8 on 2.0.36 (redhat 5.2). I upgraded to kernel 2.2.1 - which works a lot better (at least for me) in several ways. Since doing so, I haven't had a reason to return to 2.0.36, so I don't really know if the newest tulip driver will work there. However, the newest driver does seem to work under 2.2.1 with the Linksys card. > I also tried .90p > today. The basic result was the same---it appeared to be receiving > but not transmitting. However, .90p didn't read my HW address right, > either. It produced 00:80:00:80:00:80. As per some prior messages on this list, 00:80:00:80:00:80 is caused by the EEPROM_SIZE pre-processor macro being set to "6" instead of "8". I can only assume that either you forgot the "-DCARDBUS" option when compiling, or you noticed the error regarding the dereferenced NULL kernel pointer, and you erased the offending preprocessor ifdef macros - only you kept the "6" part instead of the "8" part you need. See my prior message regarding this. Also note - until this is fixed, and the driver is getting the correct MAC address, this driver will NEVER work correctly. So, this MUST be fixed first! > I also tried locking the > transceiver with options=9, but this didn't help, either. After today's release, I have mine set to option 11 - which should be the default, and it worked just fine on 10BT, plugged into a hub which is not n-way auto-negotiating. I hope these comments help. > > The only interesting thing I could tell from the output was that the > tulip-diag I ran before trying to ping listed the Tx process state as > "stopped," and after I tried to ping and ran tulip-diag again, it says > "Waiting for Tx to finish." > > Here are the debug messages from syslog and the reports from the new > tulip-diag with libmii. > > If anything else would be of help, just let me know. > > Bruce > > ---------------- > > syslog from .90k on 10baseT: > Feb 19 11:23:38 localhost cardmgr[202]: initializing socket 1 > Feb 19 11:23:38 localhost cardmgr[202]: socket 1: Linksys EtherFast 10/100 > Feb 19 11:23:38 localhost cardmgr[202]: executing: 'insmod > /lib/modules/2.0.36/pcmcia/cb_enabler.o' > Feb 19 11:23:38 localhost cardmgr[202]: executing: 'insmod > /lib/modules/2.0.36/pcmcia/tulip_cb.o debug=10' > Feb 19 11:23:38 localhost kernel: cs: cb_config(bus 4): vendor > 0x1011, device 0x0019 > Feb 19 11:23:38 localhost kernel: fn 0 bar 1: io 0x400-0x47f > Feb 19 11:23:38 localhost kernel: fn 0 bar 2: mem 0xa00c0000-0xa00c03ff > Feb 19 11:23:38 localhost kernel: fn 0 rom: mem 0xa0080000-0xa00bffff > Feb 19 11:23:38 localhost kernel: tulip_attach(bus 4, function 0) > Feb 19 11:23:38 localhost kernel: tulip.c:v0.90k 2/1/99 > becker@cesdis.gsfc.nasa.gov > Feb 19 11:23:38 localhost kernel: eth0: Digital DS21143 Tulip rev > 65 at 0x400, 00 e0 98 04 8b 4a, IRQ 9. > Feb 19 11:23:38 localhost kernel: eth0: EEPROM default media > type Autosense. > Feb 19 11:23:38 localhost kernel: eth0: MII interface PHY 0, > setup/reset sequences 0/0 long, capabilities e0 78. > Feb 19 11:23:38 localhost kernel: eth0: Index #0 - Media MII > (#11) described by a 21142 MII PHY (3) block. > Feb 19 11:23:38 localhost kernel: eth0: MII transceiver #0 > config 3000 status 7809 advertising 01e1. > Feb 19 11:23:38 localhost cardmgr[202]: executing: './network start eth0' > Feb 19 11:23:39 localhost kernel: eth0: Using MII transceiver 0, > status 7809. > Feb 19 11:23:44 localhost kernel: eth0: 21143 negotiation status > 000000c6, MII. > Feb 19 11:23:44 localhost kernel: eth0: MII status 7829, Link > partner report 0021, CSR6 b20e2002. > Feb 19 11:23:57 localhost kernel: eth0: Using MII transceiver 0, > status 782d. > Feb 19 11:24:02 localhost kernel: eth0: 21143 negotiation status > 000000c6, MII. > Feb 19 11:24:02 localhost kernel: eth0: MII status 782d, Link > partner report 0021, CSR6 b20e2002. > > lots of binary stuff as I reported in a message a few weeks ago > > > tulip-diag before trying to ping: > > tulip-diag.c:v1.07 2/10/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > Digital Tulip, unknown type Tulip chip registers at 0x400: > fa008000 ffffffff ffffffff 00fdd028 00fdd228 f0000102 b20e0000 f3fe0000 > e0000000 fffd83ff ffffffff 00000000 000000c6 ffff0000 fff80000 8ff90008 > 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. > EEPROM transceiver/media description for the Digital Tulip, > unknown type chip. > > Leaf node at offset 128, default media type 0000 (10baseT). > 0 transceiver description blocks: > MII PHY found at address 0, status 0x782d. > > > tulip-diage after trying to ping: > > tulip-diag.c:v1.07 2/10/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > Digital Tulip, unknown type Tulip chip registers at 0x400: > fa008000 ffffffff ffffffff 00fdf820 00fdfa20 f0200100 b20e0000 f3fe0000 > e0000000 fffd83ff ffffffff 00000000 000000c6 ffff0000 fff80000 8ff90008 > Port selection is MII, half-duplex. > Transmit stopped, Receive stopped, half-duplex. > The Rx process state is 'Stopped'. > The Tx process state is 'Waiting for Tx to finish'. > The transmit threshold is 128. > EEPROM transceiver/media description for the Digital Tulip, > unknown type chip. > > Leaf node at offset 128, default media type 0000 (10baseT). > 0 transceiver description blocks: > MII PHY found at address 0, status 0x782d. > > > > syslog from .90p on 10baseT: > > Feb 19 10:55:31 localhost cardmgr[202]: initializing socket 1 > Feb 19 10:55:31 localhost cardmgr[202]: socket 1: Linksys EtherFast 10/100 > Feb 19 10:55:31 localhost cardmgr[202]: executing: 'insmod > /lib/modules/2.0.36/pcmcia/cb_enabler.o' > Feb 19 10:55:31 localhost cardmgr[202]: executing: 'insmod > /lib/modules/2.0.36/pcmcia/tulip_cb.o debug=10' > Feb 19 10:55:31 localhost kernel: cs: cb_config(bus 4): vendor > 0x1011, device 0x0019 > Feb 19 10:55:31 localhost kernel: fn 0 bar 1: io 0x400-0x47f > Feb 19 10:55:31 localhost kernel: fn 0 bar 2: mem 0xa00c0000-0xa00c03ff > Feb 19 10:55:31 localhost kernel: fn 0 rom: mem 0xa0080000-0xa00bffff > Feb 19 10:55:31 localhost kernel: tulip_attach(bus 4, function 0) > Feb 19 10:55:31 localhost kernel: tulip.c:v0.90p 2/18/99 > becker@cesdis.gsfc.nasa.gov > Feb 19 10:55:31 localhost kernel: eth0: Digital DS21143 Tulip rev > 65 at 0x400, 00:80:00:80:00:80, IRQ 9. > Feb 19 10:55:31 localhost kernel: eth0: EEPROM default media > type Autosense. > Feb 19 10:55:31 localhost kernel: eth0: MII interface PHY 0, > setup/reset sequences 0/0 long, capabilities e0 78. > Feb 19 10:55:31 localhost kernel: eth0: Index #0 - Media MII > (#11) described by a 21142 MII PHY (3) block. > Feb 19 10:55:31 localhost kernel: eth0: MII transceiver #0 > config 3000 status 7809 advertising 01e1. > Feb 19 10:55:31 localhost cardmgr[202]: executing: './network start eth0' > Feb 19 10:55:31 localhost kernel: Swansea University Computer > Society IPX 0.34 for NET3.035 > Feb 19 10:55:31 localhost kernel: IPX Portions Copyright (c) 1995 > Caldera, Inc. > Feb 19 10:55:31 localhost kernel: Appletalk 0.17 for Linux NET3.035 > Feb 19 10:55:31 localhost kernel: eth0: Using MII transceiver 0, > status 7809. > Feb 19 10:55:36 localhost kernel: eth0: 21143 negotiation status > 000000c6, MII. > Feb 19 10:55:36 localhost kernel: eth0: MII status 7829, Link > partner report 0021, CSR6 b20e2002. > Feb 19 10:56:36 localhost kernel: eth0: 21143 negotiation status > 000000c6, MII. > Feb 19 10:56:36 localhost kernel: eth0: MII status 782d, Link > partner report 0021, CSR6 b20e2002. > Feb 19 10:57:36 localhost kernel: eth0: 21143 negotiation status > 000000c6, MII. > Feb 19 10:57:36 localhost kernel: eth0: MII status 782d, Link > partner report 0021, CSR6 b20e2002. > Feb 19 10:58:36 localhost kernel: eth0: 21143 negotiation status > 000000c6, MII. > Feb 19 10:58:36 localhost kernel: eth0: MII status 782d, Link > partner report 0021, CSR6 b20e2002. > Feb 19 10:59:36 localhost kernel: eth0: 21143 negotiation status > 000000c6, MII. > Feb 19 10:59:36 localhost kernel: eth0: MII status 782d, Link > partner report 0021, CSR6 b20e2002. > Feb 19 11:00:36 localhost kernel: eth0: 21143 negotiation status > 000000c6, MII. > Feb 19 11:00:36 localhost kernel: eth0: MII status 782d, Link > partner report 0021, CSR6 b20e2002. > Feb 19 11:01:29 localhost kernel: Swansea University Computer > Society IPX 0.34 for NET3.035 > Feb 19 11:01:29 localhost kernel: IPX Portions Copyright (c) 1995 > Caldera, Inc. > Feb 19 11:01:29 localhost kernel: Appletalk 0.17 for Linux NET3.035 > Feb 19 11:01:36 localhost kernel: eth0: 21143 negotiation status > 000000c6, MII. > Feb 19 11:01:36 localhost kernel: eth0: MII status 782d, Link > partner report 0021, CSR6 b20e2002. > Feb 19 11:02:36 localhost kernel: eth0: 21143 negotiation status > 000000c6, MII. > Feb 19 11:02:36 localhost kernel: eth0: MII status 782d, Link > partner report 0021, CSR6 b20e2002. > Feb 19 11:03:25 localhost cardmgr[202]: executing: './network check eth0' > Feb 19 11:03:25 localhost cardmgr[202]: shutting down socket 1 > Feb 19 11:03:25 localhost cardmgr[202]: executing: './network stop eth0' > Feb 19 11:03:25 localhost kernel: tulip_detach(eth0) > Feb 19 11:03:25 localhost cardmgr[202]: executing: 'rmmod tulip_cb' > Feb 19 11:03:25 localhost cardmgr[202]: executing: 'rmmod cb_enabler' > > > > tulip-diag.c:v1.07 2/10/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > Digital Tulip, unknown type Tulip chip registers at 0x400: > f9a08000 ffffffff ffffffff 00fdf028 00fdf228 f0000102 b20e0000 f3fe0000 > e0000000 fffd83ff ffffffff 00000000 000000c6 ffff0000 fff80000 8ff90008 > 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. > EEPROM transceiver/media description for the Digital Tulip, > unknown type chip. > > Leaf node at offset 128, default media type 0000 (10baseT). > 0 transceiver description blocks: > MII PHY found at address 0, status 0x782d. > From lowekamp@poconos.cmcl.cs.cmu.edu Fri Feb 19 16:55:16 1999 Date: Fri Feb 19 16:55:16 1999 From: Bruce Lowekamp lowekamp@poconos.cmcl.cs.cmu.edu Subject: Linksys Cardbus and .90k > As per some prior messages on this list, 00:80:00:80:00:80 is caused by > the EEPROM_SIZE pre-processor macro being set to "6" instead of "8". > I can only assume that either you forgot the "-DCARDBUS" option when > compiling, I mistakenly assumed that the "unintialized reference" messages were ignorable. (as I've sometimes seen in beta drivers, but not this time). Once I fixed the EEPROM_SIZE and ADDRLEN problems, it started working. But, I don't get any performance at all. I can only pull 15-20Kbps through an ftp. By contrast, DOS can pull 400Kbps on the same link and another linux machine on the same hub can pull 500Kbps. So I suspect there's still a problem here somewhere, although I'm not sure where. Following is a patch I made to the code that I suspect may allow the same code to work with both types of cardbus as well as with regular PCI cards, but I haven't tested it with anything other than mine, of course. I hope that Donald has an idea how to fix the problem more elegantly, but this takes care of it. If anyone has any ideas about the performance, please let me know. Thanks, Bruce -- Bruce Lowekamp lowekamp@cs.cmu.edu http://www.cs.cmu.edu/People/lowekamp/home.html ------------- *** tulip.c.90p Fri Feb 19 10:54:14 1999 --- tulip.c Fri Feb 19 16:38:44 1999 *************** *** 418,428 **** #define DESC_RING_WRAP 0x02000000 #ifdef CARDBUS ! #define EEPROM_ADDRLEN (tp->revision == 65 ? 8 : 6) #else #define EEPROM_ADDRLEN 6 - #endif #define EEPROM_SIZE 128 /* 2 << EEPROM_ADDRLEN */ struct medialeaf { u8 type; --- 418,431 ---- #define DESC_RING_WRAP 0x02000000 #ifdef CARDBUS ! #define EEPROM_ADDRLEN (chip_rev == 65 ? 8 : 6) ! #define EEPROM_SIZE (2 << EEPROM_ADDRLEN) ! #define EEPROM_MAX 512 #else #define EEPROM_ADDRLEN 6 #define EEPROM_SIZE 128 /* 2 << EEPROM_ADDRLEN */ + #define EEPROM_MAX 128 + #endif struct medialeaf { u8 type; *************** *** 477,483 **** unsigned int nway:1; /* 21143 internal NWay. */ unsigned int csr0; /* CSR0 setting. */ unsigned int csr6; /* Current CSR6 control settings. */ ! unsigned char eeprom[EEPROM_SIZE]; /* Serial EEPROM contents. */ u16 to_advertise; /* NWay capabilities advertised. */ u16 advertising[4]; signed char phys[4], mii_cnt; /* MII device addresses. */ --- 480,486 ---- unsigned int nway:1; /* 21143 internal NWay. */ unsigned int csr0; /* CSR0 setting. */ unsigned int csr6; /* Current CSR6 control settings. */ ! unsigned char eeprom[EEPROM_MAX]; /* Serial EEPROM contents. */ u16 to_advertise; /* NWay capabilities advertised. */ u16 advertising[4]; signed char phys[4], mii_cnt; /* MII device addresses. */ *************** *** 488,494 **** int pad0, pad1; /* Used for 8-byte alignment */ }; ! static void parse_eeprom(struct device *dev); static int read_eeprom(long ioaddr, int location, int addr_len); static int mdio_read(struct device *dev, int phy_id, int location); static void mdio_write(struct device *dev, int phy_id, int location, int value); --- 491,497 ---- int pad0, pad1; /* Used for 8-byte alignment */ }; ! static void parse_eeprom(struct device *dev, u8 chip_rev); static int read_eeprom(long ioaddr, int location, int addr_len); static int mdio_read(struct device *dev, int phy_id, int location); static void mdio_write(struct device *dev, int phy_id, int location, int value); *************** *** 779,785 **** /* This is logically part of probe1(), but too complex to write inline. */ if (tulip_tbl[chip_idx].flags & HAS_MEDIA_TABLE) ! parse_eeprom(dev); if (media_cap[tp->default_port] & MediaIsMII) { u16 media2advert[] = { 0x20, 0x40, 0x03e0, 0x60, 0x80, 0x100, 0x200 }; --- 782,788 ---- /* This is logically part of probe1(), but too complex to write inline. */ if (tulip_tbl[chip_idx].flags & HAS_MEDIA_TABLE) ! parse_eeprom(dev, chip_rev); if (media_cap[tp->default_port] & MediaIsMII) { u16 media2advert[] = { 0x20, 0x40, 0x03e0, 0x60, 0x80, 0x100, 0x200 }; *************** *** 941,947 **** #define get_u16(ptr) (((u8*)(ptr))[0] + (((u8*)(ptr))[1]<<8)) #endif ! static void parse_eeprom(struct device *dev) { /* The last media info list parsed, for multiport boards. */ static struct mediatable *last_mediatable = NULL; --- 944,950 ---- #define get_u16(ptr) (((u8*)(ptr))[0] + (((u8*)(ptr))[1]<<8)) #endif ! static void parse_eeprom(struct device *dev, u8 chip_rev) { /* The last media info list parsed, for multiport boards. */ static struct mediatable *last_mediatable = NULL; From briand@deldotd.com Fri Feb 19 17:30:18 1999 Date: Fri Feb 19 17:30:18 1999 From: Brian Denheyer briand@deldotd.com Subject: Linksys Lite-On and 0.90 vs. 0.90f (patched) vs. 0.90p >>>>> "Eric" == Eric Ding writes: Eric> Hi all, Eric> I've got several of the Linksys 82c169 NIC's on my intranet, and have Eric> observed some inexplicably (at least by me) poor performance. It's not inexplicable. I spent several days with the two $#%@ cards I bought. Something's broke in the operation of the 169. There are some performance speed-up patches which do help, but a fundamental problem remains. Turn on a verbose level of debugging in conf.modules and you will see "ethernet frame too large" messages show up in the logs. Once that happens the card still works, but performance becomes abysmal, just as you see in your test results. Try using the NPtcp test and that'll really screw it up. Brian From ericding@MIT.EDU Sat Feb 20 00:27:10 1999 Date: Sat Feb 20 00:27:10 1999 From: Eric Ding ericding@MIT.EDU Subject: Linksys Lite-On and 0.90 vs. 0.90f (patched) vs. 0.90p >>>>> Brian Denheyer writes: > It's not inexplicable. I spent several days with the two $#%@ cards I > bought. Something's broke in the operation of the 169. Sigh. I don't yet have the means to test the 169 under DOS or Win95; do these performance problems exist there as well? And why would it happen in one direction but not in the other? Urgh. BTW, trying the UDP test with netperf in the "slow" direction doesn't just go slowly, it actually hangs up the connection while the test is going on. Sheesh. :( Is there any hope of these issues being resolved, or is this a hopeless hardware issue? =( Eric From briand@deldotd.com Sat Feb 20 13:57:35 1999 Date: Sat Feb 20 13:57:35 1999 From: Brian Denheyer briand@deldotd.com Subject: Linksys Lite-On and 0.90 vs. 0.90f (patched) vs. 0.90p >>>>> "Eric" == Eric Ding writes: >>>>> Brian Denheyer writes: Eric> Sigh. I don't yet have the means to test the 169 under DOS Eric> or Win95; do these performance problems exist there as well? Eric> And why would it happen in one direction but not in the Eric> other? Urgh. I have win98 and I am using samba, every once in a while the transfer dies. Doesn't happen too often. Transfer speed is very erratic. Eric> BTW, trying the UDP test with netperf in the "slow" Eric> direction doesn't just go slowly, it actually hangs up the Eric> connection while the test is going on. That's what NPtcp does... Eric> Sheesh. :( Yep. Eric> Is there any hope of these issues being resolved, or is this Eric> a hopeless hardware issue? =( I am waiting on some samsung cards with "genuine" dec21140's. Everybody is out of stock on them. A friend lent me two and I tried out them out in the same machines that are having problems with the 169's. They worked great ( same kernel, driver, etc..) - NPtcp said better than 90Mbits/s. Eric> Eric Brian From roessler@guug.de Mon Feb 22 13:50:40 1999 Date: Mon Feb 22 13:50:40 1999 From: Thomas Roessler roessler@guug.de Subject: 0.90p and DFE-500TX After having struggled quite a bit with older tulip drivers (stock 2.0.34), 0.90f finally got our DFE-500TX working. Thanks for the driver, I should have tried it earlier. :) Anyway, ifconfig reports rather strange interface statistics. Note that the interface actually works. eth1 Link encap:Ethernet HWaddr 00:80:C8:93:EC:E7 inet addr:131.220.223.83 Bcast:131.220.223.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5545 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2 errors:1433 dropped:0 overruns:0 carrier:1433 Collisions:0 Interrupt:11 Base address:0x6000 tlr From Nicholas.S.Jenkins@cdc.com Mon Feb 22 15:04:29 1999 Date: Mon Feb 22 15:04:29 1999 From: Nicholas Jenkins Nicholas.S.Jenkins@cdc.com Subject: Linksys Cardbus and .90k In short, you're right about performance! > Once I fixed the EEPROM_SIZE and ADDRLEN problems, it started > working. But, I don't get any performance at all. I can only pull > 15-20Kbps through an ftp. By contrast, DOS can pull 400Kbps on the > same link and another linux machine on the same hub can pull 500Kbps. > So I suspect there's still a problem here somewhere, although I'm not > sure where. > After reading your response, I started up my favorite tulip driver :), and ran some ftp tests to get an idea of performance. On a lightly-used 10BT segment with approximately 20 machines connected via an unmanaged hub, over 2 15 minute periods, I got the following responses: ftp from linux to machines - between 40kBytes and 90Kbytes/sec. = 3.2% - 7.2% of theoretical maximum on the segment. ftp from DOS box in Win98 to machines - between 295 kBytes and 667 Kbytes/sec. = 23.7% - 53.4% of theoretical maximum on the segment. Since this was not on a switched segment, even if we assume the 667 was ~= to 100% of theoretical maximum - given available bandwidth of the shared segment, it would still mean that the linux version of the driver was only operating at 13.5% efficiency. Any thoughts on improving this? BTW - I'm just happy to have the driver working each and every time I start up the machine - something of a rarety until the .90p driver. Performance is a secondary issue to reliability - a least with me. -NICK From pcg@gospelcom.net Mon Feb 22 16:42:10 1999 Date: Mon Feb 22 16:42:10 1999 From: Peter Green pcg@gospelcom.net Subject: 0.90p and DFE-500TX > Anyway, ifconfig reports rather strange interface statistics. Note that the > interface actually works. > > eth1 Link encap:Ethernet HWaddr 00:80:C8:93:EC:E7 > inet addr:131.220.223.83 Bcast:131.220.223.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:5545 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:2 errors:1433 dropped:0 overruns:0 carrier:1433 I've noticed this as well, regardless of the tulip/epic100/3c59x/whatever driver being used. It's an old version of net-tools that's causing the confusion. Upgrade to the latest version and the stats magically right themselves. :) /pg -- Peter Green Gospel Communications Network, SysAdmin pcg@gospelcom.net From roessler@guug.de Mon Feb 22 16:52:49 1999 Date: Mon Feb 22 16:52:49 1999 From: Thomas Roessler roessler@guug.de Subject: 0.90p and DFE-500TX On 1999-02-22 16:34:14 -0500, Peter Green wrote: > I've noticed this as well, regardless of the > tulip/epic100/3c59x/whatever driver being used. It's an old version > of net-tools that's causing the confusion. Upgrade to the latest > version and the stats magically right themselves. :) That's fascinating. Should I also upgrade cat(1)? ;-)) [roessler@riemann roessler]$ cat /proc/net/dev Inter-| Receive | Transmit face |packets errs drop fifo frame|packets errs drop fifo colls carrier lo: 85688 0 0 0 0 85688 0 0 0 0 0 eth0: 297 0 0 0 0 73 0 0 0 0 0 eth1: 153789 0 0 0 0 16 71910 0 0 0 71910 ppp0: 991 0 0 0 0 1232 0 0 0 0 0 tlr -- http://home.pages.de/~roessler/ From pcg@gospelcom.net Mon Feb 22 17:04:12 1999 Date: Mon Feb 22 17:04:12 1999 From: Peter Green pcg@gospelcom.net Subject: 0.90p and DFE-500TX On Mon, 22 Feb 1999, Thomas Roessler wrote: > On 1999-02-22 16:34:14 -0500, Peter Green wrote: > > I've noticed this as well, regardless of the > > tulip/epic100/3c59x/whatever driver being used. It's an old version > > of net-tools that's causing the confusion. Upgrade to the latest > > version and the stats magically right themselves. :) > That's fascinating. Should I also upgrade cat(1)? ;-)) Sure, upgrade that...in fact you might be better off rebuilding your kernel, upgrading your CPU, chanting softly in some long-forgotten pagan language, and calling down the power of the /proc gods to try to get the right results. My bad. :) /pg -- Peter Green Gospel Communications Network, SysAdmin pcg@gospelcom.net From griffon@snurgle.org Mon Feb 22 17:44:59 1999 Date: Mon Feb 22 17:44:59 1999 From: Chris Chiappa griffon@snurgle.org Subject: Success - Linksys Cardbus / Toshiba Tecra 8000 Excellent news - the 0.90p driver (with the hardcoded EEPROM_ADDRLEN that was discussed on this list) + PCMCIA 3.0.9 fixes the problems I was having without even having to hardcode the media type. The PCMCIA drivers were indeed the problem and it was a late term fix...I was using a 3.0.9 snapshot and that didn't work, while the released 3.0.9 does. I suspect it has something to do with this changelog entry: -- Added fix for buggy PCI bus enumeration on some Toshiba laptops. But I don't have anything to back that up with. Thanks of course to Donald for his awe-inspiring work, and thanks too to the people who suggested various other short term fixes (which unfortunately didn't work). -- +------- --- -- -- - |My opinions are those of snurgle.org, not Oracle / griffon@snurgle.org| !http://www.snurgle.org/~griffon/ / cchiappa@us.oracle.com| - -- -- --- -------+ From Nicholas.S.Jenkins@cdc.com Tue Feb 23 13:47:45 1999 Date: Tue Feb 23 13:47:45 1999 From: Nicholas Jenkins Nicholas.S.Jenkins@cdc.com Subject: Linksys Cardbus 10/100 performance note Good Day, ALL: I recompiled the tulip.c driver today, using various values for the "performance" register setting (static int csr0 = 0x01A00000 | 0x8000; - line 82). After installing the latest version of the PCMCIA drivers - 3.0.9, here's what I found: tulip.c w/csr0 = 0x01A00000 | 0x8000 yielded 40-90Kbytes/sec. tulip.c w/csr0 = 0x01A00000 | 0x9000 yielded 90-130Kbytes/sec. tulip.c w/csr0 = 0x01A00000 | 0xE000 yielded 890-1100Kbytes/sec. This was on a 10BT hubbed network, using FTP. Thus, it would appear that the Linksys Cardbus 10/100 card prefers a defined "burst limit" (0x8000 vs 0x9000), and that it works better with 32 longwords for cache than 16. -NICK From deirdre@deirdre.net Tue Feb 23 15:52:21 1999 Date: Tue Feb 23 15:52:21 1999 From: Deirdre Saoirse deirdre@deirdre.net Subject: Linksys Cardbus 10/100 performance note Whee! Thanks! I have one of these very cards. :)))) On Tue, 23 Feb 1999, Nicholas Jenkins wrote: > Good Day, ALL: > > I recompiled the tulip.c driver today, using > various values for the "performance" register > setting (static int csr0 = 0x01A00000 | 0x8000; - line 82). > > After installing the latest version of the PCMCIA > drivers - 3.0.9, here's what I found: > > tulip.c w/csr0 = 0x01A00000 | 0x8000 yielded 40-90Kbytes/sec. > tulip.c w/csr0 = 0x01A00000 | 0x9000 yielded 90-130Kbytes/sec. > tulip.c w/csr0 = 0x01A00000 | 0xE000 yielded 890-1100Kbytes/sec. > > This was on a 10BT hubbed network, using FTP. > > Thus, it would appear that the Linksys Cardbus 10/100 > card prefers a defined "burst limit" (0x8000 vs 0x9000), and > that it works better with 32 longwords for cache than 16. > > -NICK > _Deirdre * http://disclaimer.deirdre.org * http://www.deirdre.net "I would rather choose to have my leg bitten off than to buy NT" Rob Narberes, Information Systems Manager, DNA Plant Technologies Corp as quoted in (!) Computerworld From griffon@snurgle.org Tue Feb 23 16:57:17 1999 Date: Tue Feb 23 16:57:17 1999 From: Chris Chiappa griffon@snurgle.org Subject: Linksys Cardbus 10/100 performance note FYI, the Linksys 10/100 Cardbus (on a 10BT network) that I've been working with gets 900KB/sec in the default configuration here. (It's the late-model Linksys with the new Tulip chip) -- +------- --- -- -- - |My opinions are those of snurgle.org, not Oracle / griffon@snurgle.org| !http://www.snurgle.org/~griffon/ / cchiappa@us.oracle.com| - -- -- --- -------+ From becker@cesdis1.gsfc.nasa.gov Wed Feb 24 03:00:16 1999 Date: Wed Feb 24 03:00:16 1999 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: New tulip.c test release v0.90q As usual, ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/test/tulip.c This release Fixes the tp->chip_revision dereference bug in v0.90p (urk). Both -TC and -TD CardBus cards should work, without breaking 21143-TD PCI cards with normal-sized 93c46 EEPROMs. Correctly sets the Ax88140 address register. Works with the PNIC-II, mostly correctly. CSR0 is now settable as a module option e.g. csr0=0x01a0e000 This may be set to improve performance or to avoid PCI bugs (e.g. '486 chipsets that cannot handle bursts). This release does not fix CSR0 performance improvements as per recent list messages. (Good work -- the new module parameter should make it easier to report on this. I'll put in a more agressive default when we get enough reports.) Failure to initialize 21143 registers when the media type is overridden. Untested ASIX Ax88140 multicast filter. 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 lowekamp@poconos.cmcl.cs.cmu.edu Wed Feb 24 10:32:05 1999 Date: Wed Feb 24 10:32:05 1999 From: Bruce Lowekamp lowekamp@poconos.cmcl.cs.cmu.edu Subject: Linksys Cardbus 10/100 on .90q I tested 0.90q with pcmcia 3.0.9 on my Linksys Cardbus 21143TD today, running on a TP600 with 2.0.36. Complete success. Not only did everything work without any modifications, but whatever performance problems there were went away without trying any of the CSR mods that were suggested yesterday. I was able to pull 1000Kbps through an ftp over a 10bT hub, which is about the maximum. I couldn't test a direct connection through a 100bT network, since I don't have accounts on two machines that are directly connected. I did some transfers that are purely 100bT, but go through a router, and got similar performance numbers to what my alpha gets on that network, so I'm pretty happy with that behavior. If I can get hold of another machine on the same 100bT network, I'll do some more tests and see if any of the CSR modifications help. Thanks, Donald. Bruce From nathana@premier1.net Wed Feb 24 15:27:17 1999 Date: Wed Feb 24 15:27:17 1999 From: Nathan Anderson nathana@premier1.net Subject: Linksys Cardbus 10/100 performance note On Tue, 23 Feb 1999, Nicholas Jenkins wrote: > Good Day, ALL: > > I recompiled the tulip.c driver today, using > various values for the "performance" register > setting (static int csr0 = 0x01A00000 | 0x8000; - line 82). > > After installing the latest version of the PCMCIA > drivers - 3.0.9, here's what I found: > > tulip.c w/csr0 = 0x01A00000 | 0x8000 yielded 40-90Kbytes/sec. > tulip.c w/csr0 = 0x01A00000 | 0x9000 yielded 90-130Kbytes/sec. > tulip.c w/csr0 = 0x01A00000 | 0xE000 yielded 890-1100Kbytes/sec. > > This was on a 10BT hubbed network, using FTP. > > Thus, it would appear that the Linksys Cardbus 10/100 > card prefers a defined "burst limit" (0x8000 vs 0x9000), and > that it works better with 32 longwords for cache than 16. Nick, Are you using a 21143-TD based LinkSys Cardbus adapter, or do you have the original LinkSys card? TIA, -- Nathan Anderson From Nicholas.S.Jenkins@cdc.com Wed Feb 24 16:53:13 1999 Date: Wed Feb 24 16:53:13 1999 From: Nicholas Jenkins Nicholas.S.Jenkins@cdc.com Subject: Linksys Cardbus 10/100 performance note In short, I'll have to check tonight. I purchased the card only about 1 month ago - from buycomp.com - which I believe does enough volume to turn over their stock quickly??? At any rate, after purchasing, I went to the Linksys site, and I noticed a statement saying that they had recently changed from rev C of the chip, to rev D, and that if the supplied Linux driver did not work, that you probably had a rev D, and that you should look to this list for upcoming drivers. Needless to say, my card did not work with the supplied driver, or any other up until rev .90p. Actually, I got it to work with .90K for about 5 minutes - once. Additionally, I thought that only the "rev D" chips required the EEPROM_SIZE set to "8"? I think that primarily based on these 2 criteria, I assume that I have a rev D chip. However, when I get home tonight, I will verify for a fact which card I have (I assume with the diag tool I can download?) -NICK > -----Original Message----- > From: Nathan Anderson [mailto:nathana@premier1.net] > Sent: Wednesday, February 24, 1999 3:20 PM > To: Nicholas Jenkins > Cc: linux-tulip@beowulf.gsfc.nasa.gov > Subject: Re: Linksys Cardbus 10/100 performance note > > > On Tue, 23 Feb 1999, Nicholas Jenkins wrote: > > > Good Day, ALL: > > > > I recompiled the tulip.c driver today, using > > various values for the "performance" register > > setting (static int csr0 = 0x01A00000 | 0x8000; - line 82). > > > > After installing the latest version of the PCMCIA > > drivers - 3.0.9, here's what I found: > > > > tulip.c w/csr0 = 0x01A00000 | 0x8000 yielded 40-90Kbytes/sec. > > tulip.c w/csr0 = 0x01A00000 | 0x9000 yielded 90-130Kbytes/sec. > > tulip.c w/csr0 = 0x01A00000 | 0xE000 yielded 890-1100Kbytes/sec. > > > > This was on a 10BT hubbed network, using FTP. > > > > Thus, it would appear that the Linksys Cardbus 10/100 > > card prefers a defined "burst limit" (0x8000 vs 0x9000), and > > that it works better with 32 longwords for cache than 16. > > Nick, > > Are you using a 21143-TD based LinkSys Cardbus adapter, or do you have the > original LinkSys card? > > TIA, > > -- Nathan Anderson > > > > From beidson@polymail.cpunix.calpoly.edu Thu Feb 25 00:58:01 1999 Date: Thu Feb 25 00:58:01 1999 From: Brady Eidson beidson@polymail.cpunix.calpoly.edu Subject: Problem with the whole tulip idea I have direct access to the internet via an ethernet connection, and my card is a card which falls under the Tulip driver category. I've tried a number of different distributions and have got the startup floppies for most of the major releases. The problem is that, unless I totally am missing something very obviously, I can't install Linux without my ethernet working because I'm going to it FTP direct, but I can't get the ethernet without a tulip driver, and I can't get the tulip driver installed till I have the Linux kernal running. How can I do this all? -Brady From deirdre@deirdre.net Thu Feb 25 02:33:13 1999 Date: Thu Feb 25 02:33:13 1999 From: Deirdre Saoirse deirdre@deirdre.net Subject: Problem with the whole tulip idea Are you using RedHat? Some of their kernels don't support Tulip for ftp installs. I don't know if the later ones do. You might check specific distributions to see if they have tulip-friendly ftp installs. Or, because you're at Cal Poly, are you at Pomona? Or SLO? If the former, you might be able to buzz down to one of the install fests at OCLUG in Fullerton (just down the 57). If you're transport-impaired, several people come from that area. On Wed, 24 Feb 1999, Brady Eidson wrote: > I have direct access to the internet via an ethernet connection, and my > card is a card which falls under the Tulip driver category. I've tried > a number of different distributions and have got the startup floppies > for most of the major releases. The problem is that, unless I totally > am missing something very obviously, I can't install Linux without my > ethernet working because I'm going to it FTP direct, but I can't get the > ethernet without a tulip driver, and I can't get the tulip driver > installed till I have the Linux kernal running. > > How can I do this all? > > -Brady > > _Deirdre * http://disclaimer.deirdre.org * http://www.deirdre.net "I would rather choose to have my leg bitten off than to buy NT" Rob Narberes, Information Systems Manager, DNA Plant Technologies Corp as quoted in (!) Computerworld From rgb@phy.duke.edu Thu Feb 25 03:03:59 1999 Date: Thu Feb 25 03:03:59 1999 From: Robert G. Brown rgb@phy.duke.edu Subject: Problem with the whole tulip idea On Wed, 24 Feb 1999, Brady Eidson wrote: > I have direct access to the internet via an ethernet connection, and my > card is a card which falls under the Tulip driver category. I've tried > a number of different distributions and have got the startup floppies > for most of the major releases. The problem is that, unless I totally > am missing something very obviously, I can't install Linux without my > ethernet working because I'm going to it FTP direct, but I can't get the > ethernet without a tulip driver, and I can't get the tulip driver > installed till I have the Linux kernal running. > > How can I do this all? Ahh, a vicious circle. The very simplest way is to buy a linux CD -- I've seen Red Hat 5.2 for sale in stores around here for only $30 or so, and lots of linux books these days come with a CD with all of Slackware and/or Debian and/or RH and/or... stuck in the back. Install from CD, build a kernel if necessary, upgrade if necessary. Will it be necessary? Don't know. You say your card is "in the tulip category", but is it a genuine tulip (Digital 21141)? A Linksys (lite-on tulip clone)? An Intel tulip (21143)? If it isn't a genuine tulip (of the sort that says Digital 21140 on the chip in the middle of the card) it is quite possible that it needs a very recent release of the driver to work. In that case, you'll need to put a very recent version of the driver code on a floppy and make a kernel (or module) that uses the new driver revision. You could also try to get somebody to build you a boot/root floppy set with a kernel that will run your network card. How that works, however, depends on what distribution you plan to install over the network. I could easily enough put a kernel that ought to boot your system where you can find it and download it, but that won't necessarily get your install root floppy to work with the boot floppy. rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu From Nicholas.S.Jenkins@cdc.com Thu Feb 25 10:58:22 1999 Date: Thu Feb 25 10:58:22 1999 From: Nicholas Jenkins Nicholas.S.Jenkins@cdc.com Subject: 21143TD determination (and my card, in particular) This is a multi-part message in MIME format. ------=_NextPart_000_0003_01BE60AD.AECC8400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Good Day, ALL: Over the past few days, my Linksys Cardbus 10/100 ethernet card has had slightly different responses to the various versions of the tulip driver than some others'. I beleve this prompted Mr. Anderson to ask yesterday if, in fact, I had a "late-model" linksys card with the 21143-TD chip on it. I thought so, but was uncertain. Therefore, I investigated last night. It is. The following are the criteria upon which one can assume that they have a -TD card, as opposed to the earlier -TC (?) card: In the November 1998 linux-tulip list archives, it would seem to state that the following are all equivalent proof: 1) If your card is labelled PCMPC200. 2) If your card has a revision level of 65, instead of 48. 3) If the required EEPROM_SIZE is 8, not 6 in order to get the tulip driver to work at all, and to get a good value for the MAC address. In fact, in the December 1998 list archives, it is suggested that a non-TD card will NOT work with EEPROM_SIZE set to 8. Hopefully, this concise format will help others also determine quickly whether or not their card is a "-TD". ------=_NextPart_000_0003_01BE60AD.AECC8400 Content-Type: image/gif; name="Judge's Chambers.gif" Content-Transfer-Encoding: Base64 Content-Disposition: ATTACHMENT; filename="Judge's Chambers.gif" Content-ID: <180254915@25021999-2fab> R0lGODlhIAM7ANX/ACEhISEYGCEQEGs5GGMxEHs5EEohCJRCEKVKEDkhEJxKEK1SEFopCGsxCEop EIQ5AJxCAK1KAGs5ELVaEHM5CK1SCJRCAKVKAIxCAL1aAM5jADkpGEIpEDkpEGuUjEpaWoytrWN7 e4SlpTlKSmOEhDFCQsDAwFp7eyk5OVJzczlSUkJjYzFSUiE5OSFCQnuUnEpjaxApMYSUnAAQGCk5 QggYIRghKSkxOSEpMUpKUjExORAQGAAAAAAAAAAAAAAAACH5BAEAACYALAAAAAAgAzsAQAb/wEsl MiFmjpNJZaFcDDYcgK5UstloJRSWhsPaarialWViuUawsrlmWpVapVwJZ7sBcLfSSGXq+/+AgYKD hIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6CZGRUZSqMTCxUVFhUKCgcCAbJ0dDQjMTAufS1l KSQuMS01NzU0MGspKyknMS4vIi8swSwkdXl7odna29zd3t/g4eLj5OXm54AWTAsLCBcKCK4Q8K4J sgAlOjUxwR8tVjA8sBhRY4aLFTl0tKDRjCEMGMpshNGhokqNYSNw4JiCDZ3HjyBDihxJsqTJkygb QbiQCsJKBRYwyMRg4QGFWAIAoGjBggaJ/2QwRpjgEcODhxQxyhBcAeLEjBkxUMTosmPHDRxzNIKp cQeFHj4pw4odS7as2bNo01qCwA6BWwTs2sFt68AegBUefrm4GKPGDqw4cthBEebNihEzuDJNgSLH Px06tH6ZgUPnV7WYM2vezLmz58+IMkTQoIFUhSQVXEJodeDJhgA2YlTN8+VvjciJAaggEaLFDGGV N1oBcAfwCJ62WAC4cQ0s6OfQo0ufTr26JHWo5NJTMC+eAtcBtH7IUYfGbxwhPmj8cmNEZBs7Lhav bIX5iBvWaOH56ty6//8ABijggCCNdoQGGWgwAYIKkpZgAQ5sAIBQWX1x0QgoXPSFVmDgsP8DhgTV UEIMNuTwwRd1YHWfRpbtAdYHiMBI4Iw01mjjjQMqIAQr7Kyiyo9KUABFADtIBEZfNKSgQgyJpWBC DFfhEAMNC6WQAhm6OBmbGMGU8MELJyzXXH84lmnmmWimidlcqRCRhBJLFHEBAR28FkZgwVA5ggu+ nLBnCkeZ8IEOI9AgogoCJflkHffZkNEM5DHHn5qUVmrppZh+s9IQF3QawaedhnoBA68FcEczJ6RB 4gjJnJACDM2soMJCMaCRxgxftLCeFRLpYIdE+7nYh4yZFmvsscgm+8dKokbQ6UqfRktAAhKGAEML HoywwgksoFDirCyc4AIZcIRAQ7gfqMD/hzR4FIlVCyhU1EJXkypr77345jsgjKehNoFo/r45gT2x xCcHcTbooNNFV8awzAq6wBBCCsLgCsBFLQhzA5QY17DCHWPqK/LIJJe85lyqCKwKO85SwMFrxOHg Hh4qYLjCxCbA0FSHVelRAhg2wAbGCDnskbHHXLRIpslMN+300+Js2mwEFYjaqQQvAwBjCy5AhUIy L8yaccL0aSQlc1zZQBhhVkCp0c/ANucHsVDXbffdeEMihCpWrywEOwVsALNE3n4QTA0LYQHWVVqM MBANLuhCRs7H+Hk4ky6AfFnenHfuuecyFvDAAzI9cMABGIw+kwUXYP1aZCKmMMIHI+5T/wML17rQ Qkb8lEDDURCtwIIvZEjEhQ0BzaC5ukt/7vzz0OdbQAGuWGABTNa74oo7DdgDmxVY3SD2uR70kQYL sn4gQwk8SBPDCn1EfkbGU/We+X7qRq///vwXq4qbAgtgEiQgOFPhQ1K6k19eABWQK7VABwmjgp6E gQITDINELUhKzpaXv/558IMgnNE8YDIPllzAHe7QnuvuEgIRBG8FLThMUjI4Ag9ATAUbMwMv+rCn FVSlbTILjg2Ik4cOhvCISEwiaP6VICIg6Aif+heCIOSAAPhOh82gGAtaQAIPiOsET9JDGbiogsTQ 4AMwgODFNIIfPAxxOSVgnhLnSMc6kv9FYHFpCwIqsMfVkOo17VlBUkjAPhzIAAQgcF8MWIBIcyUF BupyQ5fWEwYwoEBiYopj8+zIyU56Uhw/ChUE3NGpVlgAAhYQwA5yUoJwiaB8T4lPBpUhPJ4UJDZU gtdTyOCBEMjsAzfIGNcyB0c5fvKYyEwmKBTwo2Y201mqCBwHBADBD6EABe7CgQx50hPf1IBVM1DB K2mXqxbcwFfvwQEKRkBETSrznfCMpyROQ5ok1FOAFRDS4MQAGR0kJCM3QAFUtuQMEtAARRqaA7C8 tKcqxSCTxpSnRCdK0T8U4ADXs948sqe9PbrOVJUMzxD9so+F5CwEVmDbEOkQNIncgAv/G4sXDcRW mSIasaI4zSky/5eEUgjwTRCCmRictJMS9GaLKoChxYIpkeHwbkpwuAqJDnMME7TzpjrNqlbnOMJT vqNqKByhAgj4mhEUqgYZ4tLNPgCVOzQ1MCqgQ5SARYcZ5GEYYvDWVbG61b76dX9MZNCCpDjYB0Uo PCZIaghu8Y8lteAD19TrOd8GgBnEa0RY8dKIVHAitFYGjh35q2hH6zzSmNZBDDqtBh7gAAcIIB/D eZvarFACO+SDDlP45grWs7s7LYQObqPDXjcZI9Ia97jFWlCCjsBcBH2qX0EV6UttUAU4mGBEWGCB Cnw1FRr4IXI5M58JktEHG5ggg8oL/xZfkcve9t7LdKjDwAFeUYEHrCJ7FiDAy0Cqq6m8IQ0560kX rpK4yEGMDFjCRS7EsI8ZjIAEHHSvhCesLOtZ2ML3pQmzJHBYABgJT8fZhw14ssjYqBNyLggIDF4F sT7U6rris0EIPEAcr4SWwjjOsZqYOwpSMHcITMxAXeyEhxsUzRa5PNcWbbUqOKSKBVA+hg2AMd6e QKRWmruxjrfMZRqtJBUXeElMaFI6l8VCFhdRiM+41ocUGAqMwbBgDlKgAxaM2ErAuyE/ZgWoGter y4AOtH/wmAo98rGUZA1AZHzlO4Y47hmIRLAJXEACEFBGB/yAMsRgIAOU0gI+cc0ycf8FTepSa4ZZ oXJWmC8QrU8RoIAXG4aUbDGuRR5EBMlwUgxgi+maTSmutN1VL/ysZVMb+9hoCWWoSNkpElrAAAlI gBQwzY8YqEAwL33BQZKxp+vSAHJ5GpfuwjA7XuHgNyuVG7LXze6xsEUu8I53O15tp91x7TjCpAEM C6KLxE06hlOytiBHAD7IZEQMJRD1qNvN8IaTYwjOXEIz91ZFaZsIeK86Di62mAIwmcC7Oai2Cz5g JfcVyQa4Mhtz7CCpYjv85TAHR7/6RbWAvSnRjmoxDAPeAmjoArzBECacDdUCOluBBvi5ihiCw5GF x/zpUN+EaEohGon/aIQHIOuEwO3/sZzVDBgeAMELhDfea3FRBDOIzwoQQnD2mLsgmXR51OdOd0tc NKOntLD2mImABJw5DzEkwdphpzM48yIZMpDBCp6CVhPcYhi1peQNlJe0pju97pjP/CHc0iMANmEJ znq1tB0Xg2eQKARdzFBDd+PLYqwdBNaa1eGscJE4wKCLL6jp5jTP+94nAkg9/WkShjwhKFvJT1fA hSBTYK7hEQZxJ6CB6nmSjCqsJ088ifvlfc/9zGMnLggYpTy2I4AzH8SGIjDBU2KNAjTiNpgZG0gY UM6UbGnkQ/gRQzC13/3++98E84BKL8FHOvIOKvQy6IEUGeQXyoNGSzIrLpBLYhAU/zXgAh7QabJH Ikg3B2DwF9q3ff8Xgg23KarGapwiBKESIaWyA5GxEXYFHyMQAlDBC2vHECaAAiswdgd1f1fAWf9A IjgAEfwngkRYd8pVWIPVIExUF7LQKzoQH1kRHzJjAunBLUnRFGm1A1PhLUETA531bbszB1Kwe0VY hjGHBHDyJqXgJqRBRaayFY0BGecmHABQFTPwOyHAJHXIFfgxHLExJTAwU+oyL6AFgmZ4iIG2EnCx aqh0YalDAX8UAHbAFWJQWX9RVziAPiHAAj9zMWvUdjUVGbWCC5M2EKKGiKjIcIQGfnvURxGQaPQR axexD/zgAS8wXilgVzdwciQCLP8S8QYZggXHcQIxNISpeIzGhmqesmqs1mocZid1AFlppwJUggIs cDvlYxW7VlselgM5sBwZ1AW8szEOZkEfiIzoSGrK1inM9g4uYQGJ5mEooAMfQEjHoScgMAI8gAe7 difCIRHLsR56gB/j4VLGmI4IuWXvxnlswnltMQARMiFZkEEj1hdFtwJ8kTbwkSKT1VRTcSdz8JGx 1XQJWZI6BnE/QjWpEEqq8IwAoBT/gCsmAEZlFBVLohUBuRy8Ugdx82ko0IcHaZJCyV798iZApgQq E10l8HEZdF606Dha8A/00UZhEB/dJSXUxStVcBVD1HLrNZRg6VeqgAQ/VpZT1FpTVtQHtxVQaOU7 UkgLSqdNGaEC3lIojcEFQXgFzIECEGWIYfmX8nRaCaJaqaUBBeAaGLIhGiGHAEk0XwA7UjIriMM2 cfQFHsaTMtOV6gaYnLlVQQAAOw== ------=_NextPart_000_0003_01BE60AD.AECC8400-- From Nicholas.S.Jenkins@cdc.com Thu Feb 25 14:52:33 1999 Date: Thu Feb 25 14:52:33 1999 From: Nicholas Jenkins Nicholas.S.Jenkins@cdc.com Subject: Linksys Cardbus performance (new) This is a multi-part message in MIME format. ------=_NextPart_000_0002_01BE60CE.64D40AA0 Content-Type: multipart/related; boundary="----=_NextPart_001_0003_01BE60CE.64D40AA0" ------=_NextPart_001_0003_01BE60CE.64D40AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Good Day, ALL: Today, I put Mr. Becker's latest csr0 option to the test. I found that using .90q instead of .90p today brought my performance values more in line with what other people have been finding. (Also of note is that I discoverd yesterday some router problems we were having for the last few days - which may also have had an effect on my prior statistics.) At any rate, I ran multitudinous FTPs over the last hour, and the following are my results: *) In general it would appear (as Mr. Becker had noted in a prior posting) that at least for the Linksys, bit 24 being set to "1" hurts - at least for settings below "C000" - except "0000" - which is an odd case. *) In general, it would not appear (based on my new numbers) that adding the "burst limit" particularly helps (or hurts) *) In general I found that my best setting is roughly "00A0C000", although it was very little different from any of the following: 00A04000 00A04800 00A08000 00A09000 00A0E000 00A00000 01A0C000 01A0E000 01A00000 Here are my numbers, in kilobytes/sec. (for the large numbers, I would say that any difference of <= ~100K is not significant, since our hubbed network traffic is "bursty".): 00A04000 moon - 970-1000 wrtfac - 790 00A04800 moon - 970-1000 wrtfac - 860 00A08000 - 1st time moon - 980-1000 wrtfac - 930 00A08000 - 2nd time moon - 930-940 wrtfac - 900 00A09000 - 1st time moon 920-1000 wrtfac - 910 00A09000 - 2nd time moon - 900-940 wrtfac - 870 00A0C000 - 1st time moon - 840-1000 wrtfac - 920 00A0C000 - 2nd time moon - 880-930 wrtfac - 830 00A0E000 - 1st time moon - 850-890 wrtfac - 860 00A0E000 - 2nd time moon - 900-950 wrtfac - 930 00A00000 - 1st time moon - 850-960 wrtfac - 950 00A00000 - 2nd time moon 830-850 wrtfac - 820 01A04000 moon - 44-45 wrtfac - 40 01A04800 moon 13-21 wrtfac - 21 01A08000 - 1st time moon - 68-90 wrtfac - 92 01A08000 - 2nd time moon - 87-91 wrtfac - 87 01A09000 - 1st time moon - 58-180 wrtfac - 96 01A09000 - 2nd time moon - 65-190 wrtfac - 140 01A0C000 - 1st time moon - 800-1000 wrtfac - 880 01A0C000 - 2nd time moon - 880-950 wrtfac - 880 01A0E000 - 1st time moon - 740, 820 wrtfac - 860 01A0E000 - 2nd time moon - 770-870 wrtfac - 830 01A00000 - 1st time moon - 830-970 wrtfac - 910 01A00000 - 2nd time moon - 900-1000 wrtfac - 900 -NICK ------=_NextPart_001_0003_01BE60CE.64D40AA0 Content-Type: image/gif; name="Judge's Chambers.gif" Content-Transfer-Encoding: Base64 Content-Disposition: ATTACHMENT; filename="Judge's Chambers.gif" Content-ID: <190282319@25021999-02c4> R0lGODlhIAM7ANX/ACEhISEYGCEQEGs5GGMxEHs5EEohCJRCEKVKEDkhEJxKEK1SEFopCGsxCEop EIQ5AJxCAK1KAGs5ELVaEHM5CK1SCJRCAKVKAIxCAL1aAM5jADkpGEIpEDkpEGuUjEpaWoytrWN7 e4SlpTlKSmOEhDFCQsDAwFp7eyk5OVJzczlSUkJjYzFSUiE5OSFCQnuUnEpjaxApMYSUnAAQGCk5 QggYIRghKSkxOSEpMUpKUjExORAQGAAAAAAAAAAAAAAAACH5BAEAACYALAAAAAAgAzsAQAb/wEsl MiFmjpNJZaFcDDYcgK5UstloJRSWhsPaarialWViuUawsrlmWpVapVwJZ7sBcLfSSGXq+/+AgYKD hIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6CZGRUZSqMTCxUVFhUKCgcCAbJ0dDQjMTAufS1l KSQuMS01NzU0MGspKyknMS4vIi8swSwkdXl7odna29zd3t/g4eLj5OXm54AWTAsLCBcKCK4Q8K4J sgAlOjUxwR8tVjA8sBhRY4aLFTl0tKDRjCEMGMpshNGhokqNYSNw4JiCDZ3HjyBDihxJsqTJkygb QbiQCsJKBRYwyMRg4QGFWAIAoGjBggaJ/2QwRpjgEcODhxQxyhBcAeLEjBkxUMTosmPHDRxzNIKp cQeFHj4pw4odS7as2bNo01qCwA6BWwTs2sFt68AegBUefrm4GKPGDqw4cthBEebNihEzuDJNgSLH Px06tH6ZgUPnV7WYM2vezLmz58+IMkTQoIFUhSQVXEJodeDJhgA2YlTN8+VvjciJAaggEaLFDGGV N1oBcAfwCJ62WAC4cQ0s6OfQo0ufTr26JHWo5NJTMC+eAtcBtH7IUYfGbxwhPmj8cmNEZBs7Lhav bIX5iBvWaOH56ty6//8ABijggCCNdoQGGWgwAYIKkpZgAQ5sAIBQWX1x0QgoXPSFVmDgsP8DhgTV UEIMNuTwwRd1YHWfRpbtAdYHiMBI4Iw01mjjjQMqIAQr7Kyiyo9KUABFADtIBEZfNKSgQgyJpWBC DFfhEAMNC6WQAhm6OBmbGMGU8MELJyzXXH84lmnmmWimidlcqRCRhBJLFHEBAR28FkZgwVA5ggu+ nLBnCkeZ8IEOI9AgogoCJflkHffZkNEM5DHHn5qUVmrppZh+s9IQF3QawaedhnoBA68FcEczJ6RB 4gjJnJACDM2soMJCMaCRxgxftLCeFRLpYIdE+7nYh4yZFmvsscgm+8dKokbQ6UqfRktAAhKGAEML HoywwgksoFDirCyc4AIZcIRAQ7gfqMD/hzR4FIlVCyhU1EJXkypr77345jsgjKehNoFo/r45gT2x xCcHcTbooNNFV8awzAq6wBBCCsLgCsBFLQhzA5QY17DCHWPqK/LIJJe85lyqCKwKO85SwMFrxOHg Hh4qYLjCxCbA0FSHVelRAhg2wAbGCDnskbHHXLRIpslMN+300+Js2mwEFYjaqQQvAwBjCy5AhUIy L8yaccL0aSQlc1zZQBhhVkCp0c/ANucHsVDXbffdeEMihCpWrywEOwVsALNE3n4QTA0LYQHWVVqM MBANLuhCRs7H+Hk4ky6AfFnenHfuuecyFvDAAzI9cMABGIw+kwUXYP1aZCKmMMIHI+5T/wML17rQ Qkb8lEDDURCtwIIvZEjEhQ0BzaC5ukt/7vzz0OdbQAGuWGABTNa74oo7DdgDmxVY3SD2uR70kQYL sn4gQwk8SBPDCn1EfkbGU/We+X7qRq///vwXq4qbAgtgEiQgOFPhQ1K6k19eABWQK7VABwmjgp6E gQITDINELUhKzpaXv/558IMgnNE8YDIPllzAHe7QnuvuEgIRBG8FLThMUjI4Ag9ATAUbMwMv+rCn FVSlbTILjg2Ik4cOhvCISEwiaP6VICIg6Aif+heCIOSAAPhOh82gGAtaQAIPiOsET9JDGbiogsTQ 4AMwgODFNIIfPAxxOSVgnhLnSMc6kv9FYHFpCwIqsMfVkOo17VlBUkjAPhzIAAQgcF8MWIBIcyUF BupyQ5fWEwYwoEBiYopj8+zIyU56Uhw/ChUE3NGpVlgAAhYQwA5yUoJwiaB8T4lPBpUhPJ4UJDZU gtdTyOCBEMjsAzfIGNcyB0c5fvKYyEwmKBTwo2Y201mqCBwHBADBD6EABe7CgQx50hPf1IBVM1DB K2mXqxbcwFfvwQEKRkBETSrznfCMpyROQ5ok1FOAFRDS4MQAGR0kJCM3QAFUtuQMEtAARRqaA7C8 tKcqxSCTxpSnRCdK0T8U4ADXs948sqe9PbrOVJUMzxD9so+F5CwEVmDbEOkQNIncgAv/G4sXDcRW mSIasaI4zSky/5eEUgjwTRCCmRictJMS9GaLKoChxYIpkeHwbkpwuAqJDnMME7TzpjrNqlbnOMJT vqNqKByhAgj4mhEUqgYZ4tLNPgCVOzQ1MCqgQ5SARYcZ5GEYYvDWVbG61b76dX9MZNCCpDjYB0Uo PCZIaghu8Y8lteAD19TrOd8GgBnEa0RY8dKIVHAitFYGjh35q2hH6zzSmNZBDDqtBh7gAAcIIB/D eZvarFACO+SDDlP45grWs7s7LYQObqPDXjcZI9Ia97jFWlCCjsBcBH2qX0EV6UttUAU4mGBEWGCB Cnw1FRr4IXI5M58JktEHG5ggg8oL/xZfkcve9t7LdKjDwAFeUYEHrCJ7FiDAy0Cqq6m8IQ0560kX rpK4yEGMDFjCRS7EsI8ZjIAEHHSvhCesLOtZ2ML3pQmzJHBYABgJT8fZhw14ssjYqBNyLggIDF4F sT7U6rris0EIPEAcr4SWwjjOsZqYOwpSMHcITMxAXeyEhxsUzRa5PNcWbbUqOKSKBVA+hg2AMd6e QKRWmruxjrfMZRqtJBUXeElMaFI6l8VCFhdRiM+41ocUGAqMwbBgDlKgAxaM2ErAuyE/ZgWoGter y4AOtH/wmAo98rGUZA1AZHzlO4Y47hmIRLAJXEACEFBGB/yAMsRgIAOU0gI+cc0ycf8FTepSa4ZZ oXJWmC8QrU8RoIAXG4aUbDGuRR5EBMlwUgxgi+maTSmutN1VL/ysZVMb+9hoCWWoSNkpElrAAAlI gBQwzY8YqEAwL33BQZKxp+vSAHJ5GpfuwjA7XuHgNyuVG7LXze6xsEUu8I53O15tp91x7TjCpAEM C6KLxE06hlOytiBHAD7IZEQMJRD1qNvN8IaTYwjOXEIz91ZFaZsIeK86Di62mAIwmcC7Oai2Cz5g JfcVyQa4Mhtz7CCpYjv85TAHR7/6RbWAvSnRjmoxDAPeAmjoArzBECacDdUCOluBBvi5ihiCw5GF x/zpUN+EaEohGon/aIQHIOuEwO3/sZzVDBgeAMELhDfea3FRBDOIzwoQQnD2mLsgmXR51OdOd0tc NKOntLD2mImABJw5DzEkwdphpzM48yIZMpDBCp6CVhPcYhi1peQNlJe0pju97pjP/CHc0iMANmEJ znq1tB0Xg2eQKARdzFBDd+PLYqwdBNaa1eGscJE4wKCLL6jp5jTP+94nAkg9/WkShjwhKFvJT1fA hSBTYK7hEQZxJ6CB6nmSjCqsJ088ifvlfc/9zGMnLggYpTy2I4AzH8SGIjDBU2KNAjTiNpgZG0gY UM6UbGnkQ/gRQzC13/3++98E84BKL8FHOvIOKvQy6IEUGeQXyoNGSzIrLpBLYhAU/zXgAh7QabJH Ikg3B2DwF9q3ff8Xgg23KarGapwiBKESIaWyA5GxEXYFHyMQAlDBC2vHECaAAiswdgd1f1fAWf9A IjgAEfwngkRYd8pVWIPVIExUF7LQKzoQH1kRHzJjAunBLUnRFGm1A1PhLUETA531bbszB1Kwe0VY hjGHBHDyJqXgJqRBRaayFY0BGecmHABQFTPwOyHAJHXIFfgxHLExJTAwU+oyL6AFgmZ4iIG2EnCx aqh0YalDAX8UAHbAFWJQWX9RVziAPiHAAj9zMWvUdjUVGbWCC5M2EKKGiKjIcIQGfnvURxGQaPQR axexD/zgAS8wXilgVzdwciQCLP8S8QYZggXHcQIxNISpeIzGhmqesmqs1mocZid1AFlppwJUggIs cDvlYxW7VlselgM5sBwZ1AW8szEOZkEfiIzoSGrK1inM9g4uYQGJ5mEooAMfQEjHoScgMAI8gAe7 difCIRHLsR56gB/j4VLGmI4IuWXvxnlswnltMQARMiFZkEEj1hdFtwJ8kTbwkSKT1VRTcSdz8JGx 1XQJWZI6BnE/QjWpEEqq8IwAoBT/gCsmAEZlFBVLohUBuRy8Ugdx82ko0IcHaZJCyV798iZApgQq E10l8HEZdF606Dha8A/00UZhEB/dJSXUxStVcBVD1HLrNZRg6VeqgAQ/VpZT1FpTVtQHtxVQaOU7 UkgLSqdNGaEC3lIojcEFQXgFzIECEGWIYfmX8nRaCaJaqaUBBeAaGLIhGiGHAEk0XwA7UjIriMM2 cfQFHsaTMtOV6gaYnLlVQQAAOw== ------=_NextPart_001_0003_01BE60CE.64D40AA0-- ------=_NextPart_000_0002_01BE60CE.64D40AA0 Content-Type: text/x-vcard; name="Nicholas S Jenkins.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Nicholas S Jenkins.vcf" BEGIN:VCARD VERSION:2.1 N:Jenkins;Nicholas;S FN:Nicholas S Jenkins ORG:Control Data Systems, Inc. TITLE:Systems Administrator NOTE;ENCODING=QUOTED-PRINTABLE:Always question authority.=0D=0AMoreover, always question. TEL;WORK;VOICE:(937)427-6380 TEL;WORK;FAX:(937)427-6301 ADR;WORK:;(937)427-6300;2970 Presidential Drive, Suite 200;Fairborn;Ohio;45324;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:(937)427-6300=0D=0A2970 Presidential Drive, Suite 200=0D=0AFairborn, Ohio 45= 324=0D=0AUSA URL: URL:http://wrtfac.day.cdc.com:17080/~Nicholas.S.Jenkins EMAIL;PREF;INTERNET:Nicholas.S.Jenkins@cdc.com REV:19981204T155059Z END:VCARD ------=_NextPart_000_0002_01BE60CE.64D40AA0-- From deadline@plogic.com Thu Feb 25 18:03:02 1999 Date: Thu Feb 25 18:03:02 1999 From: Douglas Eadline deadline@plogic.com Subject: Linksys Cardbus performance (new) On Thu, 25 Feb 1999, Nicholas Jenkins wrote: > Good Day, ALL: > > Today, I put Mr. Becker's latest csr0 option to the test. > I found that using .90q instead of .90p today brought > my performance values more in line with what other > people have been finding. (Also of note is that I discoverd > yesterday some router problems we were having for the > last few days - which may also have had an effect on my > prior statistics.) > > At any rate, I ran multitudinous FTPs over the last hour, > and the following are my results: You may want to use something designed to measure network performance like netperf of netpipe. (see previous postings for sources). -Doug > > *) In general it would appear (as Mr. Becker had noted in a prior > posting) that at least for the Linksys, bit 24 being set to "1" > hurts - at least for settings below "C000" - except "0000" - > which is an odd case. > *) In general, it would not appear (based on my new numbers) > that adding the "burst limit" particularly helps (or hurts) > *) In general I found that my best setting is roughly "00A0C000", > although it was very little different from any of the following: > 00A04000 > 00A04800 > 00A08000 > 00A09000 > 00A0E000 > 00A00000 > 01A0C000 > 01A0E000 > 01A00000 > > Here are my numbers, in kilobytes/sec. (for the large numbers, > I would say that any difference of <= ~100K is not significant, since > our hubbed network traffic is "bursty".): > > 00A04000 > moon - 970-1000 > wrtfac - 790 > > 00A04800 > moon - 970-1000 > wrtfac - 860 > > 00A08000 - 1st time > moon - 980-1000 > wrtfac - 930 > > 00A08000 - 2nd time > moon - 930-940 > wrtfac - 900 > > 00A09000 - 1st time > moon 920-1000 > wrtfac - 910 > > 00A09000 - 2nd time > moon - 900-940 > wrtfac - 870 > > 00A0C000 - 1st time > moon - 840-1000 > wrtfac - 920 > > 00A0C000 - 2nd time > moon - 880-930 > wrtfac - 830 > > 00A0E000 - 1st time > moon - 850-890 > wrtfac - 860 > > 00A0E000 - 2nd time > moon - 900-950 > wrtfac - 930 > > 00A00000 - 1st time > moon - 850-960 > wrtfac - 950 > > 00A00000 - 2nd time > moon 830-850 > wrtfac - 820 > > 01A04000 > moon - 44-45 > wrtfac - 40 > > 01A04800 > moon 13-21 > wrtfac - 21 > > 01A08000 - 1st time > moon - 68-90 > wrtfac - 92 > > 01A08000 - 2nd time > moon - 87-91 > wrtfac - 87 > > 01A09000 - 1st time > moon - 58-180 > wrtfac - 96 > > 01A09000 - 2nd time > moon - 65-190 > wrtfac - 140 > > 01A0C000 - 1st time > moon - 800-1000 > wrtfac - 880 > > 01A0C000 - 2nd time > moon - 880-950 > wrtfac - 880 > > 01A0E000 - 1st time > moon - 740, 820 > wrtfac - 860 > > 01A0E000 - 2nd time > moon - 770-870 > wrtfac - 830 > > 01A00000 - 1st time > moon - 830-970 > wrtfac - 910 > > 01A00000 - 2nd time > moon - 900-1000 > wrtfac - 900 > > -NICK ------------------------------------------------------------------- Paralogic, Inc. | PEAK | Voice:+610.861.6960 115 Research Drive | PARALLEL | Fax:+610.861.8247 Bethlehem, PA 18017 USA | PERFORMANCE | http://www.plogic.com ------------------------------------------------------------------- From ericding@MIT.EDU Thu Feb 25 18:50:05 1999 Date: Thu Feb 25 18:50:05 1999 From: Eric Ding ericding@MIT.EDU Subject: Linksys Lite-On and 0.90q: much improved! Hi all, things have much improved, I'm glad to see, with the latest tulip driver 0.90q. Where before I was seeing throughput in the area of .22 Mb/s, I now see from 10-16 Mb/s, a huge boost. Not great, but much, much better. >From what I can see, it has everything to do with the CSR0 setting, but I've not yet played around to find the optimal setting. All I know is that under the old setting (0x00A04800), I was getting *tons* of frame overflow messages: eth0: Oversized Ethernet frame spanned multiple buffers, status 7fff8301! but now I'm seeing far fewer with csr0=0x01A08000. Still some, and hence, it would seem, the less than optimal performance, but far fewer. Thanks, Donald! Any further suggestions on how to get rid of the remaining frame buffer messages? Eric -- 1105 Lexington St. Apt. 2-10 [H] (781) 647-3411 Waltham, MA 02452-7200 <>< [O] (508) 870-0300 x284 http://www.mit.edu/~ericding/ [cellular] (781) 910-DING **** Proverbs 18:22 **** Isaiah 64:4 **** 2 Chron. 16:9 **** Titus 3:5 **** From jeffrey.hundstad@mankato.msus.edu Fri Feb 26 16:43:13 1999 Date: Fri Feb 26 16:43:13 1999 From: Jeffrey Hundstad jeffrey.hundstad@mankato.msus.edu Subject: forced 100mbs full duplex. I'm having problem with a DECchip 21140 auto detecting the duplex correctly with a cicso switch. I'd like to force duplex 100mbs with full duplex. On: http://cesdis.gsfc.nasa.gov/linux/drivers/tulip.html there is a chart that describes each mode (and I'm sure it's one of): 13 MII 100baseTx 14 MII 100baseTx-FD 15 MII 100baseT4 But later in the document it says: An example of loading the Tulip module is insmod tulip.o tulip_debug=1 options=0,16 This sets the debug message level to minimal messages, sets the first card to the auto-sense the media type, and the second to forced-full-duplex. Which mode do I want is 100 mbs full duplex? Please mail directly to me at: jeffrey.hundstad@mankato.msus.edu Thanks in advance! -- Jeffrey Hundstad From jeffrey.hundstad@mankato.msus.edu Fri Feb 26 17:13:09 1999 Date: Fri Feb 26 17:13:09 1999 From: Jeffrey Hundstad jeffrey.hundstad@mankato.msus.edu Subject: Let's try that full duplex question again... I want to force my DECchip 21140 into 100 mbs - full duplex. I want to use a LILO "append" line to accomplish this. What should the append line look like? Example to make this happen on an Intel EEPro100 it looks like: append = "ether=0,0,0x30,eth0" From shrike@il.fontys.nl Fri Feb 26 21:32:11 1999 Date: Fri Feb 26 21:32:11 1999 From: M.Brands shrike@il.fontys.nl Subject: forced 100mbs full duplex. On Fri, 26 Feb 1999, Jeffrey Hundstad wrote: > 14 MII 100baseTx-FD This should be the one... Mathijs From danci@kibla.org Sat Feb 27 03:30:59 1999 Date: Sat Feb 27 03:30:59 1999 From: Danilo Godec danci@kibla.org Subject: Net booting? I have a Micronet SP2500K - a 21443 based card. It works very nice (they even provide Linux drivers - source code - on the company web & ftp sites). However, when trying to use netboot or etherboot packages to build a boot ROM, things get stuck. Usually the boot ROM (erhm, EPROM actually, but that shouldn't matter) is simply not detected so nothing happens. Sometimes we get a complete lockup just when it should start booting (ie. right after the computer BIOS is done). I also tried this with a Compex RL2000-PCI (NE2000 PCI compatible) and a Compex RL2000A (the ISA variant), with same success (that is no success). I'm asking for clues now... Are boot ROMs anyway 'standard' (ie. if one designed for a 21134 based card should work in all other 21134 based cards - even from different manufacturer)? Is it likely that card manufacturers include some propriarity specifications so cool people like netboot and etherboot developers couldn't support them ? Anyone successfully using boot ROMs in TCP/IP networks (bootp)? Especially with cheap cards (Tulip or not-Tulip)? Anyone using netboot (or etherboot) with other-than 3c5x9 cards (this one worked even for me)? Thanks, D. PS.: References: http://www.han.de/~gero/netboot/ http://www.slug.org.au/etherboot/ From ehowser@ottertech.com Sun Feb 28 05:21:11 1999 Date: Sun Feb 28 05:21:11 1999 From: Edmond Howser ehowser@ottertech.com Subject: Problem w/ 2 Netgear NICs Single netgear cards work on a number of different OSes on my system. With a single card, eth0 & de0 is fine at 10 & 0xFC00 in their respective OSes.. Everything works greats. When I insert a second, neither works under FreeBSD 2.2.7, Slackware 3.6, or Red Hat 5.2. The IO ports are the same (per /proc/pci) as under Windows (0xFC00 & 0xF480) but the IRQs come in at 255 under Linux vs. 10 & 9. IRQ 9 was previously free on my system - it doesn't appear that I have IRQ or port conflicts. Does anyone has suggestions? -Edmond Howser