From udk@swbell.net Sun, 31 Dec 2000 15:24:36 -0600 Date: Sun, 31 Dec 2000 15:24:36 -0600 From: Uday Kallianpur udk@swbell.net Subject: [tulip] tulip,mandrake 7.1 and linksys 10/100 ver 4.0 This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C0733D.C89CEA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i did what you told me to do /sbin/insmod ./tulip.o and it says = ./tulip.o: unresolved symbol pci-drv.unregistered and ./tulip.o: unresolved symbol pci-drv.register how do I solve this I am a newbie of the highest = degree. I understand it is a problem concerning libraries how can I update them? Thankyou Uday Kallianpur ----- Original Message ----- From: "Donald Becker" To: "Uday Kallianpur" Cc: Sent: Friday, December 29, 2000 8:12 AM Subject: Re: [tulip] mandrake 7.1 > On Fri, 29 Dec 2000, Uday Kallianpur wrote: > > > I am having trouble with the card. i followed these instructions. > > What card are you using? > Where did you get the instructions? > > > > Linux kernel version 2.2.x > > > Log in as root, admin, or superuser and type this at a terminal = prompt: > > mount -t msdos /dev/fd0 /mnt/floppy > > Hmmm, they should have used 'mcopy a:/linux/tulip.c ...' > > > cp tulip.c /usr/src/linux/net/inet > > Wow, that's pretty bogus. > That directory was in the include path only to support the old v1.0 = kernel > series. I still get 1.2.13 bug reports, but it's been years since = anyone > has run even 1.2.13, and certainly v1.0 with a PCI driver is unlikely. > > You can put the source file in any directory that you choose, = preferably in > something obvious such as /usr/src/drivers/ > > > Compile the tulip.c file with the compile command: > ... > > You should now have a file called tulip.o in the same inet = directory, you > > must copy the tulip.o file to the proper directory within Linux so = it can be > > loaded, and then activated. > > cp tulip.o /lib/modules/kernel_version/net > > Before doing this, you should test the driver with > /sbin/insmod ./tulip.o > > > When I did depmod -a i get > > depmod: *** unresolved symbols in = /lib/modules/2.2.15-4mdk/net/tulip.o > > Try doing > /sbin/insmod tulip > to find the names of the unresolved symbols. > > > I am sure i compiled it okay i did not get any errors also I used = the > > latest drivers from scyld.com. I do not know what else to do?? This = is > > driving me crazy > > Read > http://www.scyld.com/network/updates.html > > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters > Annapolis MD 21403 410-990-9993 > ------=_NextPart_000_0014_01C0733D.C89CEA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
i did what you=20 told me to do /sbin/insmod ./tulip.o and it says = ./tulip.o:
unresolved symbol=20 pci-drv.unregistered and  ./tulip.o: unresolved = symbol
pci-drv.register=20 how do I solve this I am a newbie of the highest degree.  = I
understand=20 it is a problem concerning libraries how can I update=20 them?

Thankyou
Uday Kallianpur
----- Original Message=20 -----
From: "Donald Becker" <becker@scyld.com>
To: "Uday Kallianpur" <udk@swbell.net>
Cc:=20 <tulip@scyld.com>
Sent: Friday, December 29, 2000 8:12 AM
Subject: Re: = [tulip]=20 mandrake 7.1


> On Fri, 29 Dec 2000, Uday Kallianpur=20 wrote:
>
> > I am having trouble with the card. i = followed these=20 instructions.
>
> What card are you using?
> Where did = you get=20 the instructions?
>
>
> > Linux kernel version=20 2.2.x
>
> > Log in as root, admin, or superuser and type = this at=20 a terminal prompt:
> > mount -t msdos /dev/fd0=20 /mnt/floppy
>
> Hmmm, they should have used 'mcopy = a:/linux/tulip.c=20 ...'
>
> > cp tulip.c = /usr/src/linux/net/inet
>
>=20 Wow, that's pretty bogus.
> That directory was in the include path = only to=20 support the old v1.0 kernel
> series.  I still get 1.2.13 bug = reports, but it's been years since anyone
> has run even 1.2.13, = and=20 certainly v1.0 with a PCI driver is unlikely.
>
> You can = put the=20 source file in any directory that you choose, preferably
in
> = something=20 obvious such as /usr/src/drivers/
>
> > Compile the = tulip.c file=20 with the compile command:
> ...
> > You should now have a = file=20 called tulip.o in the same inet directory,
you
> > must copy = the=20 tulip.o file to the proper directory within Linux so it
can = be
> >=20 loaded, and then activated.
> > cp tulip.o=20 /lib/modules/kernel_version/net
>
> Before doing this, you = should=20 test the driver with
>   /sbin/insmod = ./tulip.o
>
>=20 > When I did depmod -a i get
> > depmod: *** unresolved = symbols in=20 /lib/modules/2.2.15-4mdk/net/tulip.o
>
> Try = doing
> =20 /sbin/insmod tulip
> to find the names of the unresolved=20 symbols.
>
> > I am sure i compiled it okay i did not get = any=20 errors also I used the
> > latest drivers from scyld.com. I do = not know=20 what else to do?? This is
> > driving me crazy
>
>=20 Read
>   http://www.scyld.com/network/updates.html
>
> Donald Becker becker@scyld.com
>=20 Scyld Computing Corporation http://www.scyld.com
> 410 Severn Ave. Suite 210 Second = Generation=20 Beowulf Clusters
> Annapolis MD 21403=20 410-990-9993
>
------=_NextPart_000_0014_01C0733D.C89CEA60-- From kfbarry@bellatlantic.net Sun, 31 Dec 2000 21:00:19 -0500 Date: Sun, 31 Dec 2000 21:00:19 -0500 From: Kevin Barry kfbarry@bellatlantic.net Subject: [tulip] Linksys 10/100 Card I'm using the latest Linksys 10/100 NIC with Red Hat 6.2, kernel 2.2.14. I d/led the latest drivers in package form from scyld.com and installed the package using GnomeRPM. I get the following error when I run insmod tulip. Using /lib/modules/2.2.14-5.0/net/tulip.o /lib/modules/2.2.14-5.0/net/tulip.o: init_module:device or resource busy On a system reboot the initialization of eth0 fails. Any help or direction would be appreciated. Thanks. Kevin From scrapmetaldevil@home.com Sun, 31 Dec 2000 22:46:22 +0000 (/etc/localtime) Date: Sun, 31 Dec 2000 22:46:22 +0000 (/etc/localtime) From: scrapmetaldevil@home.com scrapmetaldevil@home.com Subject: [tulip] LinkSys LNE100TX v4.1 cards! Okay here is the deal...I have gotten pci-scan and tulip to compile wonderfully under slakware 7.1. No problem...the kernel sources carry modversions.h and it takes seconds to install. However, using Debian I get the error, pci-scan and tulip will not compile with the 2.2.16 kernel sources installed. I get the error messages: pci-scan.c:56: linux/modversions.h: No such file or directory In file included from pci-scan.c:67: kern_compat.h:42: linux/modversions.h: No such file for directory So I check my /usr/src/linux/include/linux dir and yes, we have no modversions.h Now, I didn't think this would be a problem if I installed current sources for the 2.2.16 kernel, but this is not the case. The help file on the site says to remove the -DMODVERSIONS flag from the compile command, but the funny thing is the compile command at the end of the pci-scan.c file does not use that flag! So, here I am floppy copying from one machine to another bits here and there and nothing seems to be the cure. I also had this problem when compilling under redhat and mandrake. I just used the simple command : gcc -DMODULE -O6 -c pci-scan.c and that is all slakware needed(also for tulip.c), but this thing will NOT compile for debian. What am I missing here? I copied the modversions.h file from a 2.2.17 system just to see if it would at least find the file in /usr/src/linux/include/linux but nope, the same error messages. I am currently using Storm Linux Open Ed., which is a debian child of sorts. But it won't compile under the main debian distro either...with full development installs and also the header packages...I can't seem to locate the header packages anywhere for 2.2.16 like Mandrake has...any insight would be appreciated...I'd like to get a look at debian on the box I have before I have to say that slak is the only thing that will ever owrk on this box. From becker@scyld.com Sun, 31 Dec 2000 23:12:51 -0500 (EST) Date: Sun, 31 Dec 2000 23:12:51 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Linksys 10/100 Card On Sun, 31 Dec 2000, Kevin Barry wrote: > I'm using the latest Linksys 10/100 NIC with Red Hat 6.2, kernel 2.2.14. I > d/led the latest drivers in package form from scyld.com and installed the > package using GnomeRPM. > > I get the following error when I run insmod tulip. > > Using /lib/modules/2.2.14-5.0/net/tulip.o > /lib/modules/2.2.14-5.0/net/tulip.o: init_module:device or resource busy Are you actually running the updated driver? You can check by reading the log with 'dmesg'. The driver puts the version number into the log even if it doesn't find a supported card. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Sun, 31 Dec 2000 23:25:03 -0500 (EST) Date: Sun, 31 Dec 2000 23:25:03 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] LinkSys LNE100TX v4.1 cards! On Sun, 31 Dec 2000 scrapmetaldevil@home.com wrote: > Okay here is the deal...I have gotten pci-scan and tulip to compile > wonderfully under slakware 7.1. No problem...the kernel sources carry > modversions.h and it takes seconds to install. However, using Debian I get > the error, pci-scan and tulip will not compile with the 2.2.16 kernel > sources installed. I get the error messages: pci-scan.c:56: > linux/modversions.h: No such file or directory In file included from > pci-scan.c:67: kern_compat.h:42: linux/modversions.h: No such file for > directory The modversions.h file is specific to the exact kernel you are running. Not just the kernel version, but also the options that it is compiled with. > for debian. What am I missing here? I copied the modversions.h file from a > 2.2.17 system just to see if it would at least find the file in Copying the modversions.h file from another system will not work. >.... The help file on the site says to > remove the -DMODVERSIONS flag from the compile command, but the funny > thing is the compile command at the end of the pci-scan.c file does not > use that flag! The drivers and "pci-scan.c" support file now use the following construct: ________________ #include #if defined(MODULE) && defined(CONFIG_MODVERSIONS) && ! defined(MODVERSIONS) #define MODVERSIONS #endif .... #if LINUX_VERSION_CODE < 0x20300 && defined(MODVERSIONS) #include #endif ________________ If CONFIG_MODVERSIONS is defined in your kernel configuration file, the modversions.h file is automatically included. This relies on both config.h and modversions.h matching the kernel that you are compiling for. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From kfbarry@bellatlantic.net Mon, 1 Jan 2001 00:17:34 -0500 Date: Mon, 1 Jan 2001 00:17:34 -0500 From: Kevin Barry kfbarry@bellatlantic.net Subject: [tulip] Linksys 10/100 Card I just d/led the package driver file this evening and loaded it. I used the dmesg command and got what looks like a copy of a bootup seq but I don't see anything that refers to the NIC or any associated drivers. The information covers CPU, hard and floppy drives, CD etc. -----Original Message----- From: Donald Becker [mailto:becker@scyld.com] Sent: Sunday, December 31, 2000 11:13 PM To: Kevin Barry Cc: tulip@scyld.com Subject: Re: [tulip] Linksys 10/100 Card On Sun, 31 Dec 2000, Kevin Barry wrote: > I'm using the latest Linksys 10/100 NIC with Red Hat 6.2, kernel 2.2.14. I > d/led the latest drivers in package form from scyld.com and installed the > package using GnomeRPM. > > I get the following error when I run insmod tulip. > > Using /lib/modules/2.2.14-5.0/net/tulip.o > /lib/modules/2.2.14-5.0/net/tulip.o: init_module:device or resource busy Are you actually running the updated driver? You can check by reading the log with 'dmesg'. The driver puts the version number into the log even if it doesn't find a supported card. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Mon, 1 Jan 2001 00:39:58 -0500 (EST) Date: Mon, 1 Jan 2001 00:39:58 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Linksys 10/100 Card On Mon, 1 Jan 2001, Kevin Barry wrote: >> Are you actually running the updated driver? >> You can check by reading the log with 'dmesg'. The driver puts the version >> number into the log even if it doesn't find a supported card. > I just d/led the package driver file this evening and loaded it. I used the > dmesg command and got what looks like a copy of a bootup seq but I don't see > anything that refers to the NIC or any associated drivers. The information > covers CPU, hard and floppy drives, CD etc. You should look just after trying to load the driver. You should also verify that you have a ADMtek AN985 chip by looking in /proc/pci. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From kfbarry@bellatlantic.net Mon, 1 Jan 2001 00:34:25 -0500 Date: Mon, 1 Jan 2001 00:34:25 -0500 From: Kevin Barry kfbarry@bellatlantic.net Subject: [tulip] Linksys 10/100 Card Please bear in mind that I'm relatively new to Linux thus some of my questions may reflect this. Do I need to compile the kernel after loading the driver package? If I try to use the 'make xconfig', 'make menuconfig' or 'make config' I get the error: make: *** No rule to make target 'xconfig'. Stop. -----Original Message----- From: Donald Becker [mailto:becker@scyld.com] Sent: Sunday, December 31, 2000 11:13 PM To: Kevin Barry Cc: tulip@scyld.com Subject: Re: [tulip] Linksys 10/100 Card On Sun, 31 Dec 2000, Kevin Barry wrote: > I'm using the latest Linksys 10/100 NIC with Red Hat 6.2, kernel 2.2.14. I > d/led the latest drivers in package form from scyld.com and installed the > package using GnomeRPM. > > I get the following error when I run insmod tulip. > > Using /lib/modules/2.2.14-5.0/net/tulip.o > /lib/modules/2.2.14-5.0/net/tulip.o: init_module:device or resource busy Are you actually running the updated driver? You can check by reading the log with 'dmesg'. The driver puts the version number into the log even if it doesn't find a supported card. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From kfbarry@bellatlantic.net Mon, 1 Jan 2001 00:43:45 -0500 Date: Mon, 1 Jan 2001 00:43:45 -0500 From: Kevin Barry kfbarry@bellatlantic.net Subject: [tulip] Linksys 10/100 Card Although the failure to load the tulip driver is evident on screen during bootup it is not referenced in the dmesg file. I checked for the /proc/pci directory and could only find /proc/bus/pci. in this directory is a 0 byte file named devices and a folder 00. Kevin -----Original Message----- From: Donald Becker [mailto:becker@scyld.com] Sent: Monday, January 01, 2001 12:40 AM To: Kevin Barry Cc: tulip@scyld.com Subject: RE: [tulip] Linksys 10/100 Card On Mon, 1 Jan 2001, Kevin Barry wrote: >> Are you actually running the updated driver? >> You can check by reading the log with 'dmesg'. The driver puts the version >> number into the log even if it doesn't find a supported card. > I just d/led the package driver file this evening and loaded it. I used the > dmesg command and got what looks like a copy of a bootup seq but I don't see > anything that refers to the NIC or any associated drivers. The information > covers CPU, hard and floppy drives, CD etc. You should look just after trying to load the driver. You should also verify that you have a ADMtek AN985 chip by looking in /proc/pci. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From jzwolak@vt.edu Mon, 1 Jan 2001 17:45:40 -0500 Date: Mon, 1 Jan 2001 17:45:40 -0500 From: Jason Zwolak jzwolak@vt.edu Subject: [tulip] Cannot force media type on Netgear FA310TX I am running Debian 2.2, kernel 2.2.17, AMD Duron 600, Biostar MB (M7VKB) w/ the Via chipset. I'm trying to force the media type for my Netgear FA310TX with the following command: tulip-diag -f -F 10baseT And it does not work. The output of the command is: -------------------------------------------------------------------------------- tulip-diag.c:v2.04 9/26/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Lite-On 82c168 PNIC adapter at 0xdc00. Port selection is 100mbps-SYM/PCS 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' or '-aa' to show device registers, '-e' to show EEPROM contents, -ee for parsed contents, or '-m' or '-mm' to show MII management registers. -------------------------------------------------------------------------------- If I down the network then do the following... Type tulip-diag -a and get: -------------------------------------------------------------------------------- tulip-diag.c:v2.04 9/26/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Lite-On 82c168 PNIC adapter at 0xdc00. Lite-On 82c168 PNIC chip registers at 0xdc00: 00008000 01ff0000 62df5975 00319810 00319a10 06000132 01a6c000 00000000 00000000 00000000 00319ae0 00319ae0 0000003d 00000000 00000000 10000000 00000000 f0000000 f0041385 000000bf 40020000 00319810 03d0d010 0201f868 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Port selection is 100mbps-SYM/PCS 100baseTx scrambler, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit unit is set to store-and-forward. -------------------------------------------------------------------------------- Type ifconfig eth0 netmask 255.255.255.0 192.168.1.100 Then tulip-diag -a and get: -------------------------------------------------------------------------------- tulip-diag.c:v2.04 9/26/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Lite-On 82c168 PNIC adapter at 0xdc00. * A potential Tulip chip has been found, but it appears to be active. * Either shutdown the network, or use the '-f' flag to see all values. Port selection is 100mbps-SYM/PCS 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. -------------------------------------------------------------------------------- So far so good. But my hub (or network cable) is not very good at transmitting at 100baseT, so all my network cards are set to 10baseT (I have a 10/100 hub). The way I do this (I have all Linux boxes) is I use the mii-diag program to force them all to 10baseT like this: mii-diag -F 10baseT-HD I do that for every card on the network and everything works. So I do that with my Netgear card and get: Using the default interface 'eth0'. SIOCGMIIPHY on eth0 failed: No such device I explicitly aliased eth0 to tulip in my modules.conf file. The Netgear card shows up as eth0 when I do an ifconfig. So I try tulip-diag -f -F 10baseT and get what I have at the top of this message. Also I tried media types of 10baseT-HD and 10baseT-FD and get the same response. Feel free to suggest the obvious... last time I had a problem like this I had typed 10BaseT instead of 10baseT. It took me a whole weekend to not figure that out and it took Donald Becker 20 minutes or 2 hours (I cannot remember which) to figure it out for me, sorry Donald. -- Jason Zwolak http://jason.zwolak.org/ From matti.aarnio@zmailer.org Wed, 3 Jan 2001 12:09:28 +0200 Date: Wed, 3 Jan 2001 12:09:28 +0200 From: Matti Aarnio matti.aarnio@zmailer.org Subject: [tulip] Tulip media types 5 and 6 ? (Allied Telesyn AT-2800TX Cardbus) (This is a story of how AT-2800TX got to work at my IBM ThinkPad T20, plus things to ponder/patch at various instances of the driver.) Hi, I have strange media types 5 and 6 at an Allied Telesyn AT-2800TX CardBus network card, and I tried lots of things before (somehow) realized that "tulip-diag -ee" spoke of "reset sequence" on them both. Then I made following change to Linux 2.4.0-prerelease code, and now using 240prerel builtin cardbus code, and tulip driver (plus small pcmcia config file), it is working just fine. The Scyld driver has type 5 supported, and somehow I thought that 6 is just a variant of that. Below you find: - relevant bit of dmesg during pcmcia and tulip module load - "tulip-diag -ee" output - /etc/pcmcia/at2800tx.conf file - patch for 2.4.0-prerelease (included in post-prerelease diff) Hmm.. I thought I used PCMCIA-CS 3.1.23 code, perhaps it labels itself wrong ? Linux PCMCIA Card Services 3.1.22 options: [pci] [cardbus] [pm] PCI: Found IRQ 9 for device 00:02.0 PCI: The same IRQ used for device 00:05.0 PCI: The same IRQ used for device 01:00.0 PCI: Found IRQ 10 for device 00:02.1 Yenta IRQ list 0098, PCI irq9 Socket status: 30000006 Yenta IRQ list 0098, PCI irq10 Socket status: 30000006 cs: IO port probe 0x0c00-0x0cff: clean. cs: IO port probe 0x0800-0x08ff: clean. cs: IO port probe 0x0100-0x04ff: excluding 0x170-0x177 0x370-0x377 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. inserting the card: cs: cb_alloc(bus 2): vendor 0x1011, device 0x0019 got res[1400:147f] for resource 0 of PCI device 1011:0019 got res[10400000:104003ff] for resource 1 of PCI device 1011:0019 got res[10000000:1003ffff] for resource 6 of PCI device 1011:0019 PCI: Enabling device 02:00.0 (0000 -> 0003) Linux Tulip driver version 0.9.12 (December 17, 2000) divert: allocating divert_blk for eth0 PCI: Setting latency timer of device 02:00.0 to 64 eth0: Digital DS21143 Tulip rev 65 at 0x1400, 00:A0:D2:AF:0C:96, IRQ 9. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. eth0: Index #1 - Media 100baseTx (#3) described by a 21143 reset method (5) block. eth0: Index #2 - Media MII 100baseT4 (#15) described by a UNKNOWN (6) block. eth0: MII transceiver #1 config 3000 status 7809 advertising 00a1. eth0: Advertising 01e1 on PHY 1, previously advertising 00a1. eth0: Advertising 01e1 (to advertise is 01e1). eth0: Setting full-duplex based on MII#1 link partner capability of 41e1. ------- tulip-diag -ee output ------------ tulip-diag.c:v2.04 9/26/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x1400. Port selection is MII, full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. The NWay status register is 000000c6. EEPROM size is 8. PCI Subsystem IDs, vendor 1259, device 2802. CardBus Information Structure at offset 00005002. Ethernet MAC Station Address 00:A0:D2:AF:0C:96. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 30, default media type 0800 (Autosense). 3 transceiver description blocks: Media MII, block type 3, length 19. MII interface PHY 0 (media type 11). 21143 MII initialization sequence is 0 words:. 21143 MII reset sequence is 3 words: 0807 0000 0002. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. No MII interrupt. Media MII, block type 5, length 8. Adapter Reset Sequence, sequence length 3: 0807 0000 0002. Media MII 100baseT4, block type 6, length 11. Adapter Reset Sequence, sequence length 15: 0704 0008 0000 0200 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 4000. EEPROM contents: 1259 2802 5002 0000 0000 0000 0000 0200 d8fd 0104 a000 afd2 960c 1e00 0000 0800 9303 0003 0300 0807 0000 0002 7800 01e0 5000 1800 8800 0305 0807 0000 0002 068b 040f 0807 0000 0000 0002 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 a240 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ID block CRC 0xfd (vs. 0xfd). Full contents CRC 0x070a (read as 0x0000). MII PHY found at address 1, status 0x782d. Internal autonegotiation state is 'Autonegotiation disabled'. --------------------------------------------- --- /etc/pcmcia/at2800tx.conf --- device "tulip" class "network" module "tulip" card "Allied Telesyn AT-2800TX" version "Allied Telesis K.K.", "CentreCOM LA100-CardBus-T V2" # manfid 0x0101, 0x0001 bind "tulip" --------------------------------- diff -u --recursive --new-file v2.4.0-prerelease/linux/drivers/net/tulip/media.c linux/drivers/net/tulip/media.c --- v2.4.0-prerelease/linux/drivers/net/tulip/media.c Mon Jun 19 13:42:39 2000 +++ linux/drivers/net/tulip/media.c Mon Jan 1 09:54:07 2001 @@ -263,6 +263,24 @@ tulip_mdio_write(dev, tp->phys[phy_num], 4, to_advertise); break; } + case 5: case 6: { + u16 setup[5]; + u32 csr13val, csr14val, csr15dir, csr15val; + for (i = 0; i < 5; i++) + setup[i] = get_u16(&p[i*2 + 1]); + + if (startup && mtable->has_reset) { + struct medialeaf *rleaf = &mtable->mleaf[mtable->has_reset]; + unsigned char *rst = rleaf->leafdata; + if (tulip_debug > 1) + printk(KERN_DEBUG "%s: Resetting the transceiver.\n", + dev->name); + for (i = 0; i < rst[0]; i++) + outl(get_u16(rst + 1 + (i<<1)) << 16, ioaddr + CSR15); + } + + break; + } default: printk(KERN_DEBUG "%s: Invalid media table selection %d.\n", dev->name, mleaf->type); From becker@scyld.com Wed, 3 Jan 2001 11:39:04 -0500 (EST) Date: Wed, 3 Jan 2001 11:39:04 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Tulip media types 5 and 6 ? (Allied Telesyn AT-2800TX Cardbus) On Wed, 3 Jan 2001, Matti Aarnio wrote: > (This is a story of how AT-2800TX got to work at my IBM ThinkPad T20, > plus things to ponder/patch at various instances of the driver.) .. > I have strange media types 5 and 6 at an Allied Telesyn AT-2800TX These are new SROM entry types. They are pretty obscure, and I didn't expect to see them. > CardBus network card, and I tried lots of things before (somehow) realized > that "tulip-diag -ee" spoke of "reset sequence" on them both. Then I made > following change to Linux 2.4.0-prerelease code, and now using 240prerel > builtin cardbus code, and tulip driver (plus small pcmcia config file), > it is working just fine. > > The Scyld driver has type 5 supported, and somehow I thought that 6 is > just a variant of that. No, it's a different type of reset. Type 5 was introduced because some SYM transceivers needed to be reset in order to switch back to 10baseT mode so that autonegotiation could take place. It isn't needed for MII transceivers since they retain the autonegotiated capability word, and have their own reset sequence. My driver uses block type 5 only for SYM transceivers. Type 6 appeared to be a hack to work around a bug in a specific piece of hardware. The driver had to shut down the SYM transceiver when the cable was physically removed, but there was circuitry to restart the transceiver when the cable was inserted. It only applied starting at a specific revision of the 21143, and the SROM manual had a note about how the Intel drivers were broken, uhmmm, had unpredictable results for the general case. My driver ignores block type 6. I believe that this is correct. > Linux Tulip driver version 0.9.12 (December 17, 2000) > eth0: Digital DS21143 Tulip rev 65 at 0x1400, 00:A0:D2:AF:0C:96, IRQ 9. > eth0: EEPROM default media type Autosense. > eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. > eth0: Index #1 - Media 100baseTx (#3) described by a 21143 reset method (5) block. > eth0: Index #2 - Media MII 100baseT4 (#15) described by a UNKNOWN (6) block. I just tweaked my driver to emit better messages in the latter two entries. > tulip-diag.c:v2.04 9/26/2000 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html ... > Leaf node at offset 30, default media type 0800 (Autosense). > 3 transceiver description blocks: > Media MII, block type 3, length 19. > MII interface PHY 0 (media type 11). > 21143 MII initialization sequence is 0 words:. > 21143 MII reset sequence is 3 words: 0807 0000 0002. > Media capabilities are 7800, advertising 01e1. > Full-duplex map 5000, Threshold map 1800. > No MII interrupt. > Media MII, block type 5, length 8. > Adapter Reset Sequence, sequence length 3: 0807 0000 0002. OK, so this is bogus. A Type 5 block isn't needed for MII transceivers, since the reset sequence is already in the Type 3 block. Indeed, they are identical here. > Media MII 100baseT4, block type 6, length 11. > Adapter Reset Sequence, sequence length 15: 0704 0008 0000 0200 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 4000. I'm guessing that you added this case to the tulip-diag program. It's not quite right. It should read something like Media Reset, block type 6, length 11. Adapter Reset Sequence, sequence length 4: 0807 0000 0000 0002 I'll add a correct line to 'tulip-diag'. But this is completely bogus. This type of reset only applies to SYM transceivers, not MII transceivers. I suspect that it is harmless to ignore this, since all three reset sequences are exactly the same. > diff -u --recursive --new-file v2.4.0-prerelease/linux/drivers/net/tulip/media.c linux/drivers/net/tulip/media.c > --- v2.4.0-prerelease/linux/drivers/net/tulip/media.c Mon Jun 19 13:42:39 2000 > +++ linux/drivers/net/tulip/media.c Mon Jan 1 09:54:07 2001 > @@ -263,6 +263,24 @@ > tulip_mdio_write(dev, tp->phys[phy_num], 4, to_advertise); > break; > } > + case 5: case 6: { > + u16 setup[5]; > + u32 csr13val, csr14val, csr15dir, csr15val; > + for (i = 0; i < 5; i++) > + setup[i] = get_u16(&p[i*2 + 1]); Errrmmm, this code is pretty bogus. Did it really do anything for you? Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From matti.aarnio@zmailer.org Wed, 3 Jan 2001 21:22:01 +0200 Date: Wed, 3 Jan 2001 21:22:01 +0200 From: Matti Aarnio matti.aarnio@zmailer.org Subject: [tulip] Tulip media types 5 and 6 ? (Allied Telesyn AT-2800TX Cardbus) On Wed, Jan 03, 2001 at 11:39:04AM -0500, Donald Becker wrote: > > I have strange media types 5 and 6 at an Allied Telesyn AT-2800TX > > These are new SROM entry types. > They are pretty obscure, and I didn't expect to see them. Famous last words, or that effect... ... > > The Scyld driver has type 5 supported, and somehow I thought that 6 is > > just a variant of that. > > No, it's a different type of reset. I see. > Type 5 was introduced because some SYM transceivers needed to be reset > in order to switch back to 10baseT mode so that autonegotiation could take > place. It isn't needed for MII transceivers since they retain the > autonegotiated capability word, and have their own reset sequence. > > My driver uses block type 5 only for SYM transceivers. I haven't understood the difference of MII and SYM tranceivers, specifically, can both types of tranceivers exist at some card ? > Type 6 appeared to be a hack to work around a bug in a specific piece of > hardware. The driver had to shut down the SYM transceiver when the cable > was physically removed, but there was circuitry to restart the transceiver > when the cable was inserted. It only applied starting at a specific > revision of the 21143, and the SROM manual had a note about how the Intel > drivers were broken, uhmmm, had unpredictable results for the general case. > > My driver ignores block type 6. I believe that this is correct. I just switched back and forth between 100BaseT-FDX switch, and 10BaseT HUB, one such transition appears to "tulip-diag -mm" as shows below. (I have also one 100BaseT hub somewhere, but couldn't find it now.) So that interface seems to work with MII in both modes. What could be the point with those other media specifications at this card ? --- t.1 Wed Jan 3 20:20:14 2001 +++ t.4 Wed Jan 3 20:29:40 2001 @@ -1,18 +1,18 @@ tulip-diag.c:v2.04 9/26/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x2400. - Port selection is MII, full-duplex. - Transmit started, Receive started, full-duplex. + Port selection is MII, half-duplex. + Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 000000c6. MII PHY found at address 1, status 0x782d. MII PHY #1 transceiver registers: - 3000 782d 0040 6212 01e1 41e1 0003 0000 + 3000 782d 0040 6212 01e1 0021 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 - 5000 0300 0000 0000 0000 017f 0500 0000 - 003f 853e 0f00 ff00 002f 4000 80a0 000b. + 5000 0000 0000 0000 0000 0000 0800 0000 + 003c 8006 0f00 ff00 002c 4000 0080 000b. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x782d ... 782d. Link status: established. @@ -23,6 +23,6 @@ I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. - Link partner capability is 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT. - Negotiation completed. + Link partner capability is 0021: 10baseT. + Negotiation did not complete. Internal autonegotiation state is 'Autonegotiation disabled'. > ... > > Leaf node at offset 30, default media type 0800 (Autosense). > > 3 transceiver description blocks: > > Media MII, block type 3, length 19. > > MII interface PHY 0 (media type 11). > > 21143 MII initialization sequence is 0 words:. > > 21143 MII reset sequence is 3 words: 0807 0000 0002. > > Media capabilities are 7800, advertising 01e1. > > Full-duplex map 5000, Threshold map 1800. > > No MII interrupt. > > Media MII, block type 5, length 8. > > Adapter Reset Sequence, sequence length 3: 0807 0000 0002. > > OK, so this is bogus. A Type 5 block isn't needed for MII transceivers, > since the reset sequence is already in the Type 3 block. Indeed, they are > identical here. > > > Media MII 100baseT4, block type 6, length 11. > > Adapter Reset Sequence, sequence length 15: 0704 0008 0000 0200 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 4000. > > I'm guessing that you added this case to the tulip-diag program. Now that you mention it, yes, very possibly. Downloading your baseline version.... > It's not quite right. It should read something like > > Media Reset, block type 6, length 11. > Adapter Reset Sequence, sequence length 4: 0807 0000 0000 0002 Your tulip-diag + libmii reports actually: Media MII, block type 5, length 8. Adapter Reset Sequence, sequence length 3: 0807 0000 0002. Media MII 100baseT4, block type 6, length 11. UNKNOW MEDIA DESCRIPTION BLOCK TYPE! 06 0f 04 07 08 00 00 00 00 02 00. > I'll add a correct line to 'tulip-diag'. > > But this is completely bogus. This type of reset only applies to SYM > transceivers, not MII transceivers. I suspect that it is harmless to ignore > this, since all three reset sequences are exactly the same. Indeed. > > diff -u --recursive --new-file v2.4.0-prerelease/linux/drivers/net/tulip/media.c linux/drivers/net/tulip/media.c > > --- v2.4.0-prerelease/linux/drivers/net/tulip/media.c Mon Jun 19 13:42:39 2000 > > +++ linux/drivers/net/tulip/media.c Mon Jan 1 09:54:07 2001 > > @@ -263,6 +263,24 @@ > > tulip_mdio_write(dev, tp->phys[phy_num], 4, to_advertise); > > break; > > } > > + case 5: case 6: { > > + u16 setup[5]; > > + u32 csr13val, csr14val, csr15dir, csr15val; > > + for (i = 0; i < 5; i++) > > + setup[i] = get_u16(&p[i*2 + 1]); > > Errrmmm, this code is pretty bogus. Did it really do anything for you? Aside of not complaining and the card works ? Unfortunately that change wasn't the only one which happened in between previous non-functional test, and this new one. (Changes like pcmcia-cs tulip_cb.c vs. Linux 2.4.0-testNN/drivers/net/tulip/, some other details with PCMCIA/CARDBUS support.) > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters > Annapolis MD 21403 410-990-9993 /Matti Aarnio From becker@scyld.com Wed, 3 Jan 2001 17:15:13 -0500 (EST) Date: Wed, 3 Jan 2001 17:15:13 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Tulip media types 5 and 6 ? (Allied Telesyn AT-2800TX Cardbus) On Wed, 3 Jan 2001, Matti Aarnio wrote: > On Wed, Jan 03, 2001 at 11:39:04AM -0500, Donald Becker wrote: > > > I have strange media types 5 and 6 at an Allied Telesyn AT-2800TX > > > > These are new SROM entry types. > > They are pretty obscure, and I didn't expect to see them. > > Famous last words, or that effect... I was being nice. Mostly I was thinking "what kind of low-grade crack were they smoking to come up with _that_ pile..." > > My driver uses block type 5 only for SYM transceivers. > > I haven't understood the difference of MII and SYM tranceivers, > specifically, can both types of tranceivers exist at some card ? In theory, yes, SROM table could list both types. But electrically it's pretty much impossible. The MII interface uses 4 data lines in each direction, while SYM interfaces use 5 "4B/5B" scrambled data lines. Also, due to a design quirk, the whole chip has to be reset to switch between SYM and MII transceivers. Every configuration bit is cleared except for the MII/SYM selection bit! > > Type 6 appeared to be a hack to work around a bug in a specific piece of ... > So that interface seems to work with MII in both modes. > What could be the point with those other media specifications > at this card ? I don't know for certain. This card couldn't use the standard example media table from Intel. It might be that an inexperienced designer had to write a new table, and was just covering all of the bases. Or perhaps the Digital/Intel reference driver didn't handle MII resets correctly, and thus they added this reset as a work-around. An all-too-common bug is using the example SYM media table for a unique design, and then hacking the reference driver to support only that card. At least these guys tried to work with a generic driver. Given that this has a type 6 table entry, and this is a CardBus card, I'm wondering if the transceiver is in the dongle, and a dongle disconnect requires the reset sequence. The type 6 entry might be a sleazy way of indicating this, even though it violates the current SROM specification. > > I'm guessing that you added this case to the tulip-diag program. > > Now that you mention it, yes, very possibly. > Downloading your baseline version.... I'll send you a copy of the beta tulip-diag, which adds 21145, Comet and Conexant support. Please send a report. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From matti.aarnio@zmailer.org Thu, 4 Jan 2001 07:59:56 +0200 Date: Thu, 4 Jan 2001 07:59:56 +0200 From: Matti Aarnio matti.aarnio@zmailer.org Subject: [tulip] Tulip media types 5 and 6 ? (Allied Telesyn AT-2800TX Cardbus) Good morning, On Wed, Jan 03, 2001 at 05:15:13PM -0500, Donald Becker wrote: ... > Given that this has a type 6 table entry, and this is a CardBus card, I'm > wondering if the transceiver is in the dongle, and a dongle disconnect > requires the reset sequence. The type 6 entry might be a sleazy way of > indicating this, even though it violates the current SROM specification. "Dongle" ? Oh, like TP/Coax module at some earlier PCMCIA cards ? No, this is just 4-wire cable from Type-I card form fitting connector to RJ45 female. About one feet long. No active electronics at all at this cable. > Donald Becker becker@scyld.com /Matti Aarnio From rob.torop@verizon.net Thu, 04 Jan 2001 22:44:38 -0500 Date: Thu, 04 Jan 2001 22:44:38 -0500 From: Rob Torop rob.torop@verizon.net Subject: [tulip] Netgear fa310tx rev - D2 The chipset on this one says LC82C169C. Does the current tulip.o support this one? I've seen some posts that imply that one should use 0.89H, but perhaps that doesn't apply to the "rev D2" model. Thanks... - Rob From sunkcost@pobox.com Fri, 5 Jan 01 01:02:49 -0600 Date: Fri, 5 Jan 01 01:02:49 -0600 From: sc sunkcost@pobox.com Subject: [tulip] Slow Linksys Etherfast 10/100 PCMCIA speeds Hi, I'm at my wit's end trying to figure this out; so, this newbie is throwing himself at the feet of the community to see if anybody can toss me a clue. My setup: - Debian 2.2.17 on a ThinkPad T20 with a Linksys 10/100 EtherFast PCMCIA card. Problem: - Slow network speeds 5-10 KB / s on multi megabyte file exchanges. File sizes < 400 K work ok but performance takes a big hit afterwards. I'm guessing that the potential causes are: - tulip.o driver isn't working properly. - the card is improperly set (say to full duplex rather than just half). - hardware-related conflict like an IRQ snafu. - didn't sacrifice enough hamsters. My troubleshooting efforts: - works fine on the Win98 partition - ifconfig is showing a large number of collisions : 10-17% of RX packets - cardctl shows at least recognizes the card as a Linksys Etherfast 10/100 card - cardinfo shows it as an NE2K compatible card. - Tried denying it various IRQs, but that didn't work - Can't do anything with ifport except set it for auto-config - For some reason, at a LAN that I set up at work, the network speeds from the DSL-connected router are excellent. However, at 2 other LANs that I set up similar to the one at work, I get awful network speeds. The networks aren't anything fancy, just a few vanilla 10 Mb hubs connected together. I've spent most of my time trying to unsuccessfully come up with a fresher tulip.o driver, but despite SCYLD's abundance of info, I'm running into snags with the compilation of the module. Keep on getting a modversions.h not found. When I place the modversions.h from my kernel-headers 2.2.17 in a place where the compilation of tulip.c can find it (/usr/include/linux/), I get a ton of misc. files not found that're from modversions.h. I could hunt for those files and copy them over like I did with modversions.h, but I'm concerned that I might be wasting my time on this track if it turns out that the driver already present probably isn't the issue. Like I said earlier, for some reason, the speeds are fine at work. Any suggestions? Thanks, Steve From becker@scyld.com Fri, 5 Jan 2001 03:00:01 -0500 (EST) Date: Fri, 5 Jan 2001 03:00:01 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Slow Linksys Etherfast 10/100 PCMCIA speeds On Fri, 5 Jan 2001, sc wrote: > - Debian 2.2.17 on a ThinkPad T20 with a Linksys 10/100 EtherFast PCMCIA > card. Is this a PCMCIA card, or a CardBus card? What is the part number and the detection message? > Problem: > - Slow network speeds 5-10 KB / s on multi megabyte file exchanges. File > sizes < 400 K work ok but performance takes a big hit afterwards. ... > - ifconfig is showing a large number of collisions : 10-17% of RX packets > - cardctl shows at least recognizes the card as a Linksys Etherfast > 10/100 card > - cardinfo shows it as an NE2K compatible card. If this is correct, you have a PCMCIA NE2000 clone, not a tulip-based card. A PCMCIA card *will* use up a lot of CPU time and be very slow, although not as slow as you report. With a T20 you really should be using a CardBus card. And the Linksys CardBus card will use the Tulip driver, so we can help you here. > - For some reason, at a LAN that I set up at work, the network speeds > from the DSL-connected router are excellent. However, at 2 other LANs > that I set up similar to the one at work, I get awful network speeds. > The networks aren't anything fancy, just a few vanilla 10 Mb hubs > connected together. This points to some sort of media selection problem. > running into snags with the compilation of the module. Keep on getting a > modversions.h not found. This indicates inconsistent header files. BTW, you should no longer need to pass -DMODVERSIONS as a compile option. When I place the modversions.h from my > kernel-headers 2.2.17 in a place where the compilation of tulip.c can > find it (/usr/include/linux/), I get a ton of misc. files not found Bad, bad, bad. The modversions.h file is constructured specifically for your exact kernel version. Copying it from another machine will never work. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From ohdamnthathurts@yahoo.com Fri, 5 Jan 2001 13:08:43 -0500 Date: Fri, 5 Jan 2001 13:08:43 -0500 From: Ed Padin ohdamnthathurts@yahoo.com Subject: [tulip] starfire driver compilation problems Hi, I joined this list because I'm having a problem compiling the starfire.c driver under a 2.0.33 kernel. It keeps complaining the init.h is not found. Is there a specific library I should be installing? BTW: Chances are that this is the wrong list for that driver. So, if that is the case, can someone direct me to the proper list for that driver? Thanks. From becker@scyld.com Fri, 5 Jan 2001 13:32:41 -0500 (EST) Date: Fri, 5 Jan 2001 13:32:41 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] starfire driver compilation problems On Fri, 5 Jan 2001, Ed Padin wrote: > Date: Fri, 5 Jan 2001 13:08:43 -0500 > From: Ed Padin > To: tulip@scyld.com > Subject: [tulip] starfire driver compilation problems > > Hi, > > I joined this list because I'm having a problem compiling the starfire.c > driver under a 2.0.33 kernel. It keeps complaining the init.h is not found. > Is there a specific library I should be installing? This is a generic problem for all of the drivers. The bug is in kern_compat.h, where I added new backward-compatiblity code. Here is the fix: @@ -144,7 +144,7 @@ #endif /* Added at the suggestion of Jes Sorensen. */ -#if LINUX_VERSION_CODE < 0x20153 +#if LINUX_VERSION_CODE > 0x20153 #include #else Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From ohdamnthathurts@yahoo.com Fri, 5 Jan 2001 14:26:19 -0500 Date: Fri, 5 Jan 2001 14:26:19 -0500 From: Ed Padin ohdamnthathurts@yahoo.com Subject: [tulip] starfire driver compilation problems The patch worked and I was able to compile the driver. Now the pci-scan.o module loads okay but I when I try to load the starfire driver I get the following: cpu_to_be16: wrong version or undefined Loading failed! The module symbols (from linux-2.0.33) don't match your linux-2.0.3 BTW: here's a list of my currently loaded modules if that matters: Module: #pages: Used by: pci-scan 1 0 cipcb 6 1 ip_masq_quake 1 0 ip_masq_irc 1 0 ip_masq_ftp 1 0 ip_masq_raudio 1 0 tulip 6 1 3c59x 5 1 ----- Original Message ----- From: "Donald Becker" To: "Ed Padin" Cc: Sent: Friday, January 05, 2001 1:32 PM Subject: Re: [tulip] starfire driver compilation problems > On Fri, 5 Jan 2001, Ed Padin wrote: > > > Date: Fri, 5 Jan 2001 13:08:43 -0500 > > From: Ed Padin > > To: tulip@scyld.com > > Subject: [tulip] starfire driver compilation problems > > > > Hi, > > > > I joined this list because I'm having a problem compiling the starfire.c > > driver under a 2.0.33 kernel. It keeps complaining the init.h is not found. > > Is there a specific library I should be installing? > > This is a generic problem for all of the drivers. > > The bug is in kern_compat.h, where I added new backward-compatiblity code. > > Here is the fix: > @@ -144,7 +144,7 @@ > #endif > > /* Added at the suggestion of Jes Sorensen. */ > -#if LINUX_VERSION_CODE < 0x20153 > +#if LINUX_VERSION_CODE > 0x20153 > #include > #else > > > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters > Annapolis MD 21403 410-990-9993 > > > _______________________________________________ > tulip mailing list > tulip@scyld.com > http://www.scyld.com/mailman/listinfo/tulip From krs@linux-support.net Fri, 05 Jan 2001 13:31:51 -0600 Date: Fri, 05 Jan 2001 13:31:51 -0600 From: Karl Sackett krs@linux-support.net Subject: [tulip] Problems compiling the tulip driver I'm building a new driver for a Linksys EtherPCI card and I'm running into the same compilation problems that others have been having. My target is a Debian 2.2r2 system with the 2.2.18pre21 kernel source. Here's what happens when I try compiling tulip.c (this is after unpacking the netdrivers tarball): miranda$ make tulip gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -I/usr/src/linux/include -pipe -fno-strength-reduce -DMODVERSIONS -c -o tulip.o tulip.c tulip.c:139: linux/modversions.h: No such file or directory In file included from tulip.c:162: kern_compat.h:42: linux/modversions.h: No such file or directory {standard input}: Assembler messages: {standard input}:131: Warning: Ignoring changed section attributes for .modinfo make: *** [tulip.o] Error 1 So I now get rid of the -DMODVERSIONS: miranda$ gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -I/usr/src/linux/include -pipe -fno-strength-reduce -c -o tulip.o tulip.c tulip.c:139: linux/modversions.h: No such file or directory In file included from tulip.c:162: kern_compat.h:42: linux/modversions.h: No such file or directory {standard input}: Assembler messages: {standard input}:131: Warning: Ignoring changed section attributes for .modinfo Huh. Okay, now try what the tulip.c source says: miranda$ gcc -DMODULE -Wall -Wstrict-prototypes -O6 -c tulip.c tulip.c:139: linux/modversions.h: No such file or directory In file included from tulip.c:162: kern_compat.h:42: linux/modversions.h: No such file or directory And this is where I'm stuck. Anyone have any ideas on how to fix this? -- Karl Sackett krs@linux-support.net Linux Support Services, Inc. From sunkcost@pobox.com Fri, 5 Jan 01 16:18:47 -0600 Date: Fri, 5 Jan 01 16:18:47 -0600 From: sc sunkcost@pobox.com Subject: [tulip] Slow Linksys Etherfast 10/100 PCMCIA speeds On 1/5/01 2:00 AM, Donald Becker (becker@scyld.com) wrote: >Is this a PCMCIA card, or a CardBus card? >What is the part number and the detection message? UGH. You're right; my bad. When going through Linksys' support pages, I didn't make the distinction between Cardbus vs. PCMCIA and Linksys has similar Etherfast cards for both. So, I am barking up the wrong tree (wish these revelations wouldn't come after I post publicly... :P Thanks a lot, Steve From becker@scyld.com Fri, 5 Jan 2001 23:08:28 -0500 (EST) Date: Fri, 5 Jan 2001 23:08:28 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] starfire driver compilation problems On Fri, 5 Jan 2001, Ed Padin wrote: > The patch worked and I was able to compile the driver. Now the pci-scan.o > module loads okay but I when I try to load the starfire driver I get the > following: > > cpu_to_be16: wrong version or undefined As Homer would say, Doh! Please try the updated kern_compat.h from ftp://www.scyld.com/pub/network/kern_compat.h That is the only driver using cpu_to_be*() functions. I removed them from natsemi.c. Most PCI hardware is little-endian, but you occasionally get some big-endian infiltrater that puts a B-E element in an otherwise L-E design. > > This is a generic problem for all of the drivers. > > The bug is in kern_compat.h, where I added new backward-compatiblity code. Please send a report. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Fri, 5 Jan 2001 23:13:46 -0500 (EST) Date: Fri, 5 Jan 2001 23:13:46 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Problems compiling the tulip driver On Fri, 5 Jan 2001, Karl Sackett wrote: > ...the same compilation problems that others have been having. My > target is a Debian 2.2r2 system with the 2.2.18pre21 kernel source. > Here's what happens when I try compiling tulip.c (this is after > unpacking > the netdrivers tarball): > > miranda$ make tulip > gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 > -I/usr/src/linux/include -pipe -fno-strength-reduce -DMODVERSIONS -c > -o tulip.o tulip.c > tulip.c:139: linux/modversions.h: No such file or directory This just can't happen. You are have a hallucination. Perhaps it's a mass hallucination, but whatever is going on, it's all just in your imagination. Here is why: The Makefile says: LINUX=/usr/src/linux CFLAGS=-DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -I$(LINUX)/include # If the modversion.h file exists we should pass a flag. # Most of my drivers have been updated to not need this, but not the other # kernel source files. MODVER_H = $(LINUX)/include/linux/modversions.h ifneq ($(wildcard $(MODVER_H)),"") CFLAGS += -DMODVERSIONS endif So this verifies that /usr/src/linux/include/linux/modversions.h exists before adding in the -DMODVERSIONS flag. Your compile line has -DMODVERSIONS Thus you have /usr/src/linux/include/linux/modversions.h And that is the reason you will _never_ see > tulip.c:139: linux/modversions.h: No such file or directory Got it? Now take two of the pink pills, and those voice in your head will go away... Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From ohdamnthathurts@yahoo.com Sat, 6 Jan 2001 11:45:08 -0500 Date: Sat, 6 Jan 2001 11:45:08 -0500 From: Ed Padin ohdamnthathurts@yahoo.com Subject: [tulip] starfire driver compilation problems That did the trick, thanks. I would also like to take this opportunity to thank you for your efforts and contributions. It seems that Linux would not be very ethernet capable without your work. Your name appears in 34 of the 73 *.c files in my /usr/src/linux/drivers/net dir. [root@Client net]# ls *.c | wc -l 73 [root@Client net]# grep becker *.c -L | wc -l 34 ----- Original Message ----- From: "Donald Becker" To: "Ed Padin" Cc: Sent: Friday, January 05, 2001 11:08 PM Subject: Re: [tulip] starfire driver compilation problems > On Fri, 5 Jan 2001, Ed Padin wrote: > > > The patch worked and I was able to compile the driver. Now the pci-scan.o > > module loads okay but I when I try to load the starfire driver I get the > > following: > > > > cpu_to_be16: wrong version or undefined > > As Homer would say, Doh! > > Please try the updated kern_compat.h from > ftp://www.scyld.com/pub/network/kern_compat.h > > That is the only driver using cpu_to_be*() functions. I removed them from > natsemi.c. > > Most PCI hardware is little-endian, but you occasionally get some big-endian > infiltrater that puts a B-E element in an otherwise L-E design. > > > > This is a generic problem for all of the drivers. > > > The bug is in kern_compat.h, where I added new backward-compatiblity code. > > Please send a report. > > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters > Annapolis MD 21403 410-990-9993 From hbarta@enteract.com Sun, 7 Jan 2001 10:28:52 -0600 (CST) Date: Sun, 7 Jan 2001 10:28:52 -0600 (CST) From: Hank Barta hbarta@enteract.com Subject: [tulip] stall on tulip card I finally got my LNE-100TX V4.1 card working weeks ago by putting it in a different PCI slot. Since then, all has been well until I started running 'setiathome' on this box. Since then, I've had three lockups of the tulip card Here is all of the information I can think of that seems to be pertinent: Each time, running the network startup script resumed communications. I could find no indication of problems in the logs. The lockups have occurred only when was running X clients on an NT box (connected first through a 100BaseTx hub and then a 10BaseT hub.) This last time, I recorded the results of 'tulip-diag' before and after I restarted the network: tulip-diag.c:v2.04 9/26/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a ADMtek AL985 Centaur-P adapter at 0xdc00. Port selection is 100mbps full duplex (Link is on) Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 256. The Comet MAC registers are 08782000 ffffba45 filter 8000000000000000. Use '-a' or '-aa' to show device registers, '-e' to show EEPROM contents, -ee for parsed contents, or '-m' or '-mm' to show MII management registers. oak:/var/log# /etc/init.d/networking restart Reconfiguring network interfaces: done. oak:/var/log# /home/hbarta/download/linux/kernel/tulip/x/tulip-diag tulip-diag.c:v2.04 9/26/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a ADMtek AL985 Centaur-P adapter at 0xdc00. Port selection is 100mbps full duplex (Link is on) Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. The Comet MAC registers are 08782000 ffffba45 filter 8000000000000000. Use '-a' or '-aa' to show device registers, '-e' to show EEPROM contents, -ee for parsed contents, or '-m' or '-mm' to show MII management registers. The version of the driver I'm running is: tulip.c:v0.92p 11/28/2000 Written by Donald Becker And this is on a kernel version 2.2.18pre21. I am running on an AMD 800 MHz Thunderbird (at the design clock frequency.) I'm running setiathome with '-nice 19', but it does soak up all available CPU cycles. It does cause the CPU to run warmer too, but other than this problem, the system has been rock solid. When I first set this system up, I ran kernel compiles for several days straight with no Signal 11 problems. Any idea what causes this and how to fix it? -- Hank Barta White Oak Software Inc. hbarta@enteract.com Predictable Systems by Design.(tm) Beautiful Sunny Winfield, Illinois From becker@scyld.com Mon, 8 Jan 2001 03:57:34 -0500 (EST) Date: Mon, 8 Jan 2001 03:57:34 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] stall on tulip card On Sun, 7 Jan 2001, Hank Barta wrote: > well until I started running 'setiathome' on this box. Since > then, I've had three lockups of the tulip card Here is all of > the information I can think of that seems to be pertinent: > I could find no indication of problems in the logs. What was happing with the counts in /proc/net/dev? > This last time, I recorded the results of 'tulip-diag' before > and after I restarted the network: ... > The transmit threshold is 256. .. > The transmit threshold is 128. The only difference is with the transmit threshold, which was increased in the error case. There was a report that manipulating Tx threshold was causing a problem with the Centaur, but I was unable to reproduce the problem. If this really is the problem, we will have to figure out if the hang is caused by the initial underrun, or the attempt to increase the Tx threshold value. See the state with 'tulip-diag -aa' might be useful. Thanks for the good report. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From goemon@anime.net Mon, 8 Jan 2001 01:17:18 -0800 (PST) Date: Mon, 8 Jan 2001 01:17:18 -0800 (PST) From: Dan Hollis goemon@anime.net Subject: [tulip] stall on tulip card On Mon, 8 Jan 2001, Donald Becker wrote: > The only difference is with the transmit threshold, which was increased in > the error case. There was a report that manipulating Tx threshold was > causing a problem with the Centaur, but I was unable to reproduce the > problem. If this really is the problem, we will have to figure out if the > hang is caused by the initial underrun, or the attempt to increase the Tx > threshold value. Donald, I have about 10 data points now from people who have used the CSR18 bit 1 patch. For most of them (9 out of 10) it fixed the problem and for the last it didnt change anything, eg it didnt make things worse. I sent a couple cards to Jeff Garzik at mandrake and he was able to duplicate the problem and confirm the fix as well. I know you cant reproduce the problem but lots of us have the problem and CSR18 bit 1 really does fix it. Please consider adding it to the driver. -Dan From krs@linux-support.net Mon, 08 Jan 2001 14:37:56 -0600 Date: Mon, 08 Jan 2001 14:37:56 -0600 From: Karl Sackett krs@linux-support.net Subject: [tulip] Problems compiling the tulip driver Donald Becker wrote: > > On Fri, 5 Jan 2001, Karl Sackett wrote: > > > miranda$ make tulip > > gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 > > -I/usr/src/linux/include -pipe -fno-strength-reduce -DMODVERSIONS -c > > -o tulip.o tulip.c > > tulip.c:139: linux/modversions.h: No such file or directory > > This just can't happen. You are have a hallucination. Perhaps it's a mass > hallucination, but whatever is going on, it's all just in your imagination. [snip] > And that is the reason you will _never_ see > > tulip.c:139: linux/modversions.h: No such file or directory > > Got it? Now take two of the pink pills, and those voice in your head will > go away... I did find a fix. It's not enough that you download and unpack the kernel source. You actually have to build a kernel. Really. That's how modversions.h gets generated. Imagine that. So now I've hit THIS wall: miranda:/usr/src/modules# insmod pci-scan.o pci-scan.o: unresolved symbol pci_write_config_byte pci-scan.o: unresolved symbol pci_find_class pci-scan.o: unresolved symbol pci_read_config_byte pci-scan.o: unresolved symbol pci_read_config_dword pci-scan.o: unresolved symbol __ioremap pci-scan.o: unresolved symbol pci_read_config_word pci-scan.o: unresolved symbol pci_set_master pci-scan.o: unresolved symbol pci_write_config_dword pci-scan.o: unresolved symbol pci_write_config_word pci-scan.o: unresolved symbol check_region pci-scan.o: unresolved symbol printk miranda:/usr/src/modules# grep pci_write_config_byte /proc/ksyms 801b1804 pci_write_config_byte_R2gig_e84d5397 Still no joy. Any suggestions? -- Karl Sackett krs@linux-support.net Linux Support Services, Inc. From ldperron@colvir.net Mon, 08 Jan 2001 16:03:37 -0500 Date: Mon, 08 Jan 2001 16:03:37 -0500 From: Louis-David Perron ldperron@colvir.net Subject: [tulip] Problems compiling the tulip driver Strange...because here ALL my modules won't work because of unresolved symbols...I recompiled my kernel with make zImage, then make modules then make modules_install and have broken all my modules... Karl Sackett wrote: > > Donald Becker wrote: > > > > On Fri, 5 Jan 2001, Karl Sackett wrote: > > > > > miranda$ make tulip > > > gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 > > > -I/usr/src/linux/include -pipe -fno-strength-reduce -DMODVERSIONS -c > > > -o tulip.o tulip.c > > > tulip.c:139: linux/modversions.h: No such file or directory > > > > This just can't happen. You are have a hallucination. Perhaps it's a mass > > hallucination, but whatever is going on, it's all just in your imagination. > > [snip] > > > And that is the reason you will _never_ see > > > tulip.c:139: linux/modversions.h: No such file or directory > > > > Got it? Now take two of the pink pills, and those voice in your head will > > go away... > > I did find a fix. It's not enough that you download and unpack the > kernel > source. You actually have to build a kernel. Really. That's how > modversions.h gets generated. Imagine that. > > So now I've hit THIS wall: > > miranda:/usr/src/modules# insmod pci-scan.o > pci-scan.o: unresolved symbol pci_write_config_byte > pci-scan.o: unresolved symbol pci_find_class > pci-scan.o: unresolved symbol pci_read_config_byte > pci-scan.o: unresolved symbol pci_read_config_dword > pci-scan.o: unresolved symbol __ioremap > pci-scan.o: unresolved symbol pci_read_config_word > pci-scan.o: unresolved symbol pci_set_master > pci-scan.o: unresolved symbol pci_write_config_dword > pci-scan.o: unresolved symbol pci_write_config_word > pci-scan.o: unresolved symbol check_region > pci-scan.o: unresolved symbol printk > miranda:/usr/src/modules# grep pci_write_config_byte /proc/ksyms > 801b1804 pci_write_config_byte_R2gig_e84d5397 > > Still no joy. Any suggestions? > > -- > Karl Sackett krs@linux-support.net > Linux Support Services, Inc. > > _______________________________________________ > tulip mailing list > tulip@scyld.com > http://www.scyld.com/mailman/listinfo/tulip From clifto@clifto.com Mon, 08 Jan 2001 15:07:59 -0600 Date: Mon, 08 Jan 2001 15:07:59 -0600 From: Clifton T. Sharp Jr. clifto@clifto.com Subject: [tulip] Problems compiling the tulip driver Karl Sackett wrote: > miranda:/usr/src/modules# insmod pci-scan.o > pci-scan.o: unresolved symbol pci_write_config_byte > pci-scan.o: unresolved symbol pci_find_class > pci-scan.o: unresolved symbol pci_read_config_byte > pci-scan.o: unresolved symbol pci_read_config_dword > pci-scan.o: unresolved symbol __ioremap > pci-scan.o: unresolved symbol pci_read_config_word > pci-scan.o: unresolved symbol pci_set_master > pci-scan.o: unresolved symbol pci_write_config_dword > pci-scan.o: unresolved symbol pci_write_config_word > pci-scan.o: unresolved symbol check_region > pci-scan.o: unresolved symbol printk > miranda:/usr/src/modules# grep pci_write_config_byte /proc/ksyms > 801b1804 pci_write_config_byte_R2gig_e84d5397 > > Still no joy. Any suggestions? That reads like a who's-who of symbols in kern_compat.h. -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cliff Sharp | Hate spam? Take the Boulder Pledge! | | WA9PDM | http://www.zdnet.com/yil/content/mag/9612/ebert9612.html | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From goemon@anime.net Mon, 8 Jan 2001 13:18:58 -0800 (PST) Date: Mon, 8 Jan 2001 13:18:58 -0800 (PST) From: Dan Hollis goemon@anime.net Subject: [tulip] Problems compiling the tulip driver On Mon, 8 Jan 2001, Karl Sackett wrote: > miranda:/usr/src/modules# grep pci_write_config_byte /proc/ksyms > 801b1804 pci_write_config_byte_R2gig_e84d5397 > > Still no joy. Any suggestions? Congratulations. You've compiled a versioned-module kernel but neglected to compile a versioned tulip module. -Dan From devdrvr@davis.com Tue, 09 Jan 2001 12:24:58 -0800 Date: Tue, 09 Jan 2001 12:24:58 -0800 From: devdrvr devdrvr@davis.com Subject: [tulip] [tulip]: MAC Address Range Assignment I want to spin my own DEC chip based card for Linux boxes. Who is the standards body or company that controls the dolling out of MAC address ranges nowadays? I used to know this but have forgotten. I looked at RFC 1700 and it is a mess and not clear, or current for that matter. Thanks for any pointers folks can give me, --Lu Device Driver Programmer Davis, CA 01 (530) 400-5692 From becker@scyld.com Tue, 9 Jan 2001 16:33:43 -0500 (EST) Date: Tue, 9 Jan 2001 16:33:43 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] [tulip]: MAC Address Range Assignment On Tue, 9 Jan 2001, devdrvr wrote: > I want to spin my own DEC chip based card for Linux boxes. Who is the > standards body or company that controls the dolling out of MAC address > ranges nowadays? I used to know this but have forgotten. I looked at RFC > 1700 and it is a mess and not clear, or current for that matter. The IEEE. They will assign you a vendor ID which gets you 24 bits of serial number aa:bb:cc:**:**:** It costs a few thousand dollars. You may wish to just use addresses with the "local" bit set in the first address byte. Years ago pacific rim vendors were notorious for making up their own station addresses. Diamond Flower used 'D' 'F' 'E' as their address prefix. Check the ID list on a network sniffer for examples. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Tue, 9 Jan 2001 17:09:47 -0500 (EST) Date: Tue, 9 Jan 2001 17:09:47 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] stall on tulip card On Mon, 8 Jan 2001, Dan Hollis wrote: > On Mon, 8 Jan 2001, Donald Becker wrote: > > The only difference is with the transmit threshold, which was increased in > > the error case. There was a report that manipulating Tx threshold was > > causing a problem with the Centaur, but I was unable to reproduce the > > problem. If this really is the problem, we will have to figure out if the > > hang is caused by the initial underrun, or the attempt to increase the Tx > > threshold value. > > Donald, I have about 10 data points now from people who have used the > CSR18 bit 1 patch. For most of them (9 out of 10) it fixed the problem > and for the last it didnt change anything, eg it didnt make things worse. Does this mask the TxUnderrun event? If so, the Tx threshold will never be increased, and the Tx underruns will continue. > I know you cant reproduce the problem but lots of us have the problem and > CSR18 bit 1 really does fix it. Please consider adding it to the driver. It's in, but I'm fully comfortable with it. Please send reports... I added this code in the TxFIFOUnderrun handler: if (tulip_debug > 1) printk(KERN_WARNING "%s: Tx threshold increased, " "new CSR6 %x.\n", dev->name, tp->csr6); Look for 0.92q in the test directory today. If it passes the tests it will become either 0.93 or 1.00 at the end of the week. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From goemon@anime.net Tue, 9 Jan 2001 14:43:34 -0800 (PST) Date: Tue, 9 Jan 2001 14:43:34 -0800 (PST) From: Dan Hollis goemon@anime.net Subject: [tulip] stall on tulip card On Tue, 9 Jan 2001, Donald Becker wrote: > On Mon, 8 Jan 2001, Dan Hollis wrote: > > Donald, I have about 10 data points now from people who have used the > > CSR18 bit 1 patch. For most of them (9 out of 10) it fixed the problem > > and for the last it didnt change anything, eg it didnt make things worse. > Does this mask the TxUnderrun event? > If so, the Tx threshold will never be increased, and the Tx underruns will > continue. It masks tx underrun totally. Once CSR18 bit 1 is set, the driver never ever sees another tx underrun event (we never ever see TxFIFOUnderflow once CSR18 is set). BTW if we just ignore underrun and restart the transmitter on underflow errors, the centaur will get totally locked up. If we bump up the threshold and restart, it may delay it a while, but we will still eventually get locked up. Whatever magic this CSR18 bit does, it totally compensates at a hardware level for these problems. I wish ADMtek would actually tell us what the hell it is doing. -Dan From becker@scyld.com Wed, 10 Jan 2001 01:35:50 -0500 (EST) Date: Wed, 10 Jan 2001 01:35:50 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] tulip.c v0.92r available for testing In the usual test directory: ftp://www.scyld.com/pub/network/test/tulip.c If there are no reported problems this will become v0.93 or v1.00 at the end of the week. The recent CVS log entries are: ________________ tulip.c:v0.92r 1/10/2001 Correct the multicast filter bits for the Comet/Centaur. ---------------------------- revision 1.54 date: 2001/01/10 05:22:34; author: becker; state: Exp; lines: +47 -27 tulip.c:v0.92q 1/9/2001 Handle new 6 media reset leaf, and change the reported name for type 5 & 6 to "transceiver reset". The reset index for type 5 is stored "+1" since we use non-zero to indicate set. Print a "Set to forced full duplex" message. The duplex lock setting may now be changed with 'mii-diag'. Check for the set-tx-full->instant-empty race. Enable the automatic underrun recovery feature in the Comet. (Dan Hollis ) --------------------------- revision 1.53 date: 2000/12/09 22:10:20; author: becker; state: Exp; lines: +12 -4 tulip.c:v0.92p 11/28/2000 Use I/O space operations for built-in drivers in order to claim the I/O port region exclusively. This avoid detecting repeats (eth0...eth7) of a single card. Added a Conexant LANfinity table entry. The details of the Conexant design are not yet known. Added a PCI table entry for the Accton EN1217/EN2242, which is a renumbered ADMtek Comet chip. Clear the full duplex flag on open(). Otherwise a previous detection of full duplex mode will result in the chip not properly switched to FDX mode. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From chip_rodden@hotmail.com Wed, 10 Jan 2001 15:40:14 -0000 Date: Wed, 10 Jan 2001 15:40:14 -0000 From: Chip Rodden chip_rodden@hotmail.com Subject: [tulip] hamachi,starfire, tulip on Alpha I'm having problems with all three of these drivers on my DS10 Alpha box. Anytime I do a ping with any reasonable frequency, say 1 46 byte packet every 10000 usec, the box crashes. I get messages like: eth4: something wicked happened eth4: Too much work on interrupt, status=0x10000 eth4: Too much work on interrupt, status=0x20000 eth4: Too much work on interrupt, status=0x30000 over and over leading up to the crash. The above even happens with the GigE card where one 46 byte packet every 10000 usec isn't that much bandwidth. This is with the most up-to-date tulip and hamachi drivers. Donald? Thanks Chip chip_rodden@hotmail.com _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From r.geyer@ebe-technologies.com mer., 10 janv. 2001 17:47:29 +000110-1747-29-PART-BREAK Date: mer., 10 janv. 2001 17:47:29 +000110-1747-29-PART-BREAK From: Raphael GEYER r.geyer@ebe-technologies.com Subject: [tulip] Using multiple DFE-570TX Hi, I can't make work my firewalls with 2 DFE-570TX connect to an ASUS CUR-DLS motherboard. First of all DLINK says than each port needs its own IRQ. That make's up to 8 IRQ and I only have 6 free. Can it work with less than 8 IRQs ? How are assigned this IRQs. If I put a card on each end of my pci's slots I get the following: Bus 1 IRQ 11,5,3 and 7 Bus 3 IRQ 15,9,9 and 9 If I put the cards on following pci slots I get the following: Bus 1 IRQ 11,5,3 and 7 Bus 2 IRQ 10,7,5 and 3 If I put the cards on my active raiser card (1 pci connector -> 2 pci slots) I get the following; Bus 1 IRQ 11,5,3 and 7 Bus 2 IRQ 11,5,3 and 7 What are the thinks to do in order to make 2 cards work in one PC? Does I have an hardware pb or a software pb ? What's about IRQ sharing is this not possible ? Thanks in advance Raphael GEYER France From goemon@anime.net Wed, 10 Jan 2001 11:19:32 -0800 (PST) Date: Wed, 10 Jan 2001 11:19:32 -0800 (PST) From: Dan Hollis goemon@anime.net Subject: [tulip] Using multiple DFE-570TX On 10 xxx -1, Raphael GEYER wrote: > I can't make work my firewalls with 2 DFE-570TX connect to an ASUS > CUR-DLS motherboard. > First of all DLINK says than each port needs its own IRQ. > That make's up to 8 IRQ and I only have 6 free. > Can it work with less than 8 IRQs ? Yes. PCI requires cards to be able to share IRQs. So it will work. I've put 4 quad tulip cards in a PC once (16 ethernet ports) and it worked. -Dan From amcintosh@atreus-systems.com Wed, 10 Jan 2001 15:58:33 -0500 (EST) Date: Wed, 10 Jan 2001 15:58:33 -0500 (EST) From: Allan McIntosh amcintosh@atreus-systems.com Subject: [tulip] netgear 310tx Hey, I am using a Cyrix MediaGXtm MMXtm Enhanced 233MHz machine as a router and it appears that the machine can not handle 100Mbits of throughput (The machine comes to a stand still when testing). There is 1 netgear 310tx and an rtl8139. I am trying to set the netgear to 10baseT with options=10 inorder to limit throughput. However when I bring up the interface I can not ping anything. tulip-diag says all is well as does mii-diag. I saw threads in the archives of poeple attemping to force the 310tx's to 100 has anyone successfully locked one of these cards to 10baseT-FD? Thanks Allan -- ------------------------------------------------------------------ Allan McIntosh, Software Technologist Atreus Systems Corp, http://www.atreuscorp.com Phone: (613) 233-1741 ext 217 1800 764-5514 Fax: (613) 233-8204 ------------------------------------------------------------------ From r.geyer@ebe-technologies.com jeu., 11 janv. 2001 08:03:53 +000111-0803-53-PART-BREAK Date: jeu., 11 janv. 2001 08:03:53 +000111-0803-53-PART-BREAK From: Raphael GEYER r.geyer@ebe-technologies.com Subject: [tulip] Using multiple DFE-570TX >I've put 4 quad tulip cards in a PC once (16 ethernet ports) and it >worked. > >-Dan Hi, Could you give more informations about that, what are the used IRQs, how are they shared by the cards ? Can it be a driver problem ? I use 2 cards A and B. If I configure A1 with 192.168.1.101 and A2 with 192.168.1.102, I can ping both IPs. But if I cut one link I have 2 cases no IP can be pinged or both works. Strange isn't it ? Raphael GEYER From goemon@anime.net Wed, 10 Jan 2001 23:20:24 -0800 (PST) Date: Wed, 10 Jan 2001 23:20:24 -0800 (PST) From: Dan Hollis goemon@anime.net Subject: [tulip] Using multiple DFE-570TX On 11 xxx -1, Raphael GEYER wrote: > >I've put 4 quad tulip cards in a PC once (16 ethernet ports) and it > >worked. > Could you give more informations about that, what are the used IRQs, how > are they shared by the cards ? They are shared however BIOS decides it. > Can it be a driver problem ? Unlikely. > I use 2 cards A and B. If I configure A1 with 192.168.1.101 and A2 with > 192.168.1.102, I can ping both IPs. But if I cut one link I have 2 cases > no IP can be pinged or both works. > Strange isn't it ? Nope. Linux only answers ARP for a specific network out one device by default. Try putting each ethernet port on a different network number (eg 192.168.1.101 and 192.168.2.101). -Dan From dave@lake.demon.co.uk Thu, 11 Jan 2001 09:11:46 +0000 Date: Thu, 11 Jan 2001 09:11:46 +0000 From: Dave Anderson dave@lake.demon.co.uk Subject: [tulip] netgear and adaptec problems - status? Hi, On searching the web, I found quite a few references to performance problems with the FA310TX and adaptec SCSI cards. I'm looking to buy some FA310TXs, and I have a Adaptec AIC-7890/1 Ultra2 SCSI host adapter. The references were quite old, so, I'm wondering, do these problems still exist? Many thanks for any info. regards Dave From hbarta@enteract.com Thu, 11 Jan 2001 13:17:17 -0600 (CST) Date: Thu, 11 Jan 2001 13:17:17 -0600 (CST) From: Hank Barta hbarta@enteract.com Subject: [tulip] netgear 310tx On Wed, 10 Jan 2001, Allan McIntosh wrote: > I am using a Cyrix MediaGXtm MMXtm Enhanced 233MHz machine as a router > and it appears that the machine can not handle 100Mbits of > throughput (The machine comes to a stand still when testing). There is 1 > netgear 310tx and an rtl8139. I am surprised to hear that because I asm using an old laptop for my firewall (cable modem) and it seems to have no trouble keeping up. It has: 486/33 (thinkpad TP750Cs) 12MB RAM 1x 3C589 PCMCIA combo Ethernet card (using 10BaseT) 1x Dlink ne2000 10/100 compatible card (connected to a 10/100 cable modem, so it runs at 100 Mb/s) At the highest sustained throughput - about 450 KB/sec. in one direction, 'top' reports a CPU load of about 60%. And I believe Donald has mentioned that the ne2000 takes a lot of CPU cycles. With a 233 MHz processor, you should have in the vicinity of about 10x the processor horsepower, (but perhaps not 10x the I/O bandwidth?) As an aside, I wonder how I would know if my firewall was slowing down my cable modem throughput? Most people people who would seem to know more about this than me recommend a P133 minimum for a firewall, but the 486/33 seems to be doing fine. (But maybe I'd see 700 or 800 KB/sec with a faster machine. ;) -- Hank Barta White Oak Software Inc. hbarta@enteract.com Predictable Systems by Design.(tm) Beautiful Sunny Winfield, Illinois From cro@nca.asu.edu Thu, 11 Jan 2001 12:48:26 -0700 Date: Thu, 11 Jan 2001 12:48:26 -0700 From: C. R. Oldham cro@nca.asu.edu Subject: [tulip] netgear 310tx Hank Barta wrote: > I am surprised to hear that because I asm using an old laptop > for my firewall (cable modem) and it seems to have no trouble > keeping up. [...] > a 10/100 cable modem, so it runs at 100 Mb/s) Yes, but the cablemodem isn't actually doing more than about .5 Mb/sec. Doesn't matter if your net is 10 Mb or 100 Mb, it's the actual traffic that will make the difference. > At the highest sustained throughput - about 450 KB/sec. in > one direction, 'top' reports a CPU load of about 60%. And I > believe Donald has mentioned that the ne2000 takes a lot of > CPU cycles. That's getting there. Plus a laptop with 16 bit PC cards might not even perform near a similarly configured desktop machine--laptop manufacturers often skimp on things like bus performance to get costs down or save power. > With a 233 MHz processor, you should have in the vicinity of > about 10x the processor horsepower, (but perhaps not 10x the > I/O bandwidth?) Nope. Only if the machine in question is using PCI cards. > As an aside, I wonder how I would know if my firewall was > slowing down my cable modem throughput? Watch top like you've been doing. Also check your interface statistics for dropped/corrupt packets. > would seem to know more about this than me recommend a P133 > minimum for a firewall, but the 486/33 seems to be doing fine. They might recommend that because a 486/33 will probably be an ISA machine, and a Pentium 133 would be a PCI machine. > (But maybe I'd see 700 or 800 KB/sec with a faster machine. ;) It's possible. Is the firewall doing anything else? -- / C. R. (Charles) Oldham | NCA Commission on Schools \ / Director of Technology | Arizona State University \ / cro@nca.asu.edu | V:480-965-8703 F:480-965-9423 \ From jzwolak@vt.edu Thu, 11 Jan 2001 18:14:22 -0500 Date: Thu, 11 Jan 2001 18:14:22 -0500 From: Jason Zwolak jzwolak@vt.edu Subject: [tulip] netgear 310tx On Wed, Jan 10, 2001 at 03:58:33PM -0500, Allan McIntosh wrote: > Hey, > > I am using a Cyrix MediaGXtm MMXtm Enhanced 233MHz machine as a router > and it appears that the machine can not handle 100Mbits of > throughput (The machine comes to a stand still when testing). There is 1 > netgear 310tx and an rtl8139. I am trying to set the netgear to 10baseT > with options=10 inorder to limit throughput. However when I bring up the > interface I can not ping anything. tulip-diag says all is well as does > mii-diag. > > I saw threads in the archives of poeple attemping to force the 310tx's to > 100 has anyone successfully locked one of these cards to 10baseT-FD? I have not locked mine to 10baseT-FD, but I did lock it to 10baseT-HD. I had problems with bumping mine down to 10baseT-HD. Turns out there were two problems: - The network cable and card did not have a strong connection to each other. - I had a somewhat old version of the driver, which apparently was causing some problems, but I'm not sure. So I am currently using linux kernel 2.4 and the latest mii-diag and tulip-diag from the web. I am using the tulip driver that came with 2.4. After the tulip module is loaded I execute a command like: mii-diag -F 10baseT-HD This works for me. -- Jason Zwolak http://jason.zwolak.org/ From hbarta@enteract.com Fri, 12 Jan 2001 08:14:10 -0600 (CST) Date: Fri, 12 Jan 2001 08:14:10 -0600 (CST) From: Hank Barta hbarta@enteract.com Subject: [tulip] netgear 310tx On Thu, 11 Jan 2001, C. R. Oldham wrote: > Date: Thu, 11 Jan 2001 12:48:26 -0700 > From: C. R. Oldham > To: tulip@scyld.com > Subject: Re: [tulip] netgear 310tx > > Hank Barta wrote: > > > I am surprised to hear that because I asm using an old laptop > > for my firewall (cable modem) and it seems to have no trouble > > keeping up. > > [...] > > > a 10/100 cable modem, so it runs at 100 Mb/s) > > Yes, but the cablemodem isn't actually doing more than about .5 Mb/sec. > Doesn't matter if your net is 10 Mb or 100 Mb, it's the actual traffic that > will make the difference. At 450 KB/sec, it is about 4.5 Mb/sec I understand what you mean about Ethernet capacity vs cable modem capacity, but at ~5 Mb/sec, I'm not that far away from saturating the 10BaseT ethernet segment. Or is there something I am misunderstanding? (Or should I stop trying to do math in my head? ;) > Watch top like you've been doing. Also check your interface statistics for > dropped/corrupt packets. OK, I'll check for that. > It's possible. Is the firewall doing anything else? No, nothing. -- Hank Barta White Oak Software Inc. hbarta@enteract.com Predictable Systems by Design.(tm) Beautiful Sunny Winfield, Illinois From cro@nca.asu.edu Fri, 12 Jan 2001 07:42:55 -0700 Date: Fri, 12 Jan 2001 07:42:55 -0700 From: C. R. Oldham cro@nca.asu.edu Subject: [tulip] netgear 310tx Hank Barta wrote: > At 450 KB/sec, it is about 4.5 Mb/sec Sorry I missed the capital 'B' in KB; I thought you meant 450 Kb/45 KB. I was confused because most cable providers I know are capping at the very least at 1 Mb/sec. To get 450 KB/sec is *very* unusual. -- / C. R. (Charles) Oldham | NCA Commission on Schools \ / Director of Technology | Arizona State University \ / cro@nca.asu.edu | V:480-965-8703 F:480-965-9423 \ From kenneth.g.lafond@intel.com Fri, 12 Jan 2001 11:35:46 -0800 Date: Fri, 12 Jan 2001 11:35:46 -0800 From: Lafond, Kenneth G kenneth.g.lafond@intel.com Subject: [tulip] Starfire, RH 7.0 and the Adaptec Quartet64 Greetings, list - I'm trying to get an Adaptec Quartet 64 quad port adapter to work in RH 7.0. I'm having no luck. I've gotten pci-scan.c and starfire.c to compile without error (using the instructions for RH7.0 from the website), but although the modules load without error, they don't seem to actually do anything with the card - ie after installation in linuxconf, an /etc/rc.d/init.d/network reload yields no new working ports...they just time out. The network connections I'm using are known good. Has anyone gotten this to work? Am I using the right driver? Thanks in advance, Ken Lafond From ohdamnthathurts@yahoo.com Fri, 12 Jan 2001 17:26:33 -0500 Date: Fri, 12 Jan 2001 17:26:33 -0500 From: Ed Padin ohdamnthathurts@yahoo.com Subject: [tulip] Starfire, RH 7.0 and the Adaptec Quartet64 I aplogize if what I put forth below is trivial, but here goes... > Greetings, list - > I'm trying to get an Adaptec Quartet 64 quad port adapter to work in > RH 7.0. I'm having no luck. I've gotten pci-scan.c and starfire.c to > compile without error (using the instructions for RH7.0 from the website), > but although the modules load without error, they don't seem to actually do > anything with the card - ie after installation in linuxconf, an > /etc/rc.d/init.d/network reload yields no new working ports...they just time > out. On the console, as root, try unloading any and all modules. do lsmod and them rmmod until the list is empty. You may have to do ifconfig eth? down for eth card drivers. Then do: insmod pci-scan insmod starfire ifconfig eth0 If you get a response then try connecting a known good network connection and do: ifconfig eth0 up tcpdump -i eth0 If you see a bunch of net traffic then the driver is probably working and the redhat automated stuff is not. Hope it helps. From busey@grove.ufl.edu Fri, 12 Jan 2001 19:50:10 -0500 Date: Fri, 12 Jan 2001 19:50:10 -0500 From: Jon Busey busey@grove.ufl.edu Subject: [tulip] 9 'unresolved symbol's, module problems I've combed the archives and found this same problem but none of the solutions that worked for others worked for me. The message I keep getting is: tulip.o: unresolved symbol __kfree_skb_R33abe94a tulip.o: unresolved symbol dev_close_R8da92aa7 tulip.o: unresolved symbol eth_type_trans_R96395552 tulip.o: unresolved symbol netif_rx_Rf2799e21 tulip.o: unresolved symbol unregister_netdev_R4d34aaeb tulip.o: unresolved symbol skb_over_panic_R8c41de6b tulip.o: unresolved symbol init_etherdev_Rf393f939 tulip.o: unresolved symbol alloc_skb_R58ff4843 tulip.o: unresolved symbol eth_copy_and_sum_R3579512e This is what I have tried: downloading _all previous versions of netdrivers*_, running depmod -a, running 'make; insmod pci-scan.o ' fine so far, never any errors, then 'insmod tulip.o' gives me the same message each time, and putting tulip.o in the /lib/modules tree results in an 'depmod: *** Unresolved symbols in /lib/modules/2.2.17/net/tulip.o' every time. Here is the lspci -v output: 00:0b.0 Ethernet controller: Bridgecom, Inc: Unknown device 0985 (rev 11) Subsystem: Bridgecom, Inc: Unknown device 0570 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at e000 Memory at d8000000 (32-bit, non-prefetchable) Capabilities: [c0] Power Management version 2 which Donald identifies as an ADMtek Centaur-P chip to someone else in an earlier post. 'dmesg' lists nothing about the card, and 'cat /proc/interrupts' leaves IRQ 11 unassigned and makes no mention of the card. It seems this module doesn't work for me. I am running the stock 2.2.17pre6 kernel image that comes with Debian 2.2 and have tried compiling the kernel with the modules as described on the scyld.com page with similarly success. That was sometime in November and I can't remember the output anymore. What's left? Thank you for any suggestions. Jon I haven't yet decided to become a member of the list, so I can respond more quickly if you Cc: busey@grove.ufl.edu thanks From becker@scyld.com Sat, 13 Jan 2001 05:23:47 -0500 (EST) Date: Sat, 13 Jan 2001 05:23:47 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] 9 'unresolved symbol's, module problems On Fri, 12 Jan 2001, Jon Busey wrote: > I've combed the archives and found this same problem but none of the > solutions that worked for others worked for me. > The message I keep getting is: > tulip.o: unresolved symbol __kfree_skb_R33abe94a > tulip.o: unresolved symbol dev_close_R8da92aa7 The modversions.h that you compiled against, likely /usr/include/linux/modversions.h does not match the kernel that you are running. The modversions.h file is rebuilt each time the kernel is compiled, and a correctly structured distribution will install the proper modversion.h when it installs the boot kernel. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From danci@server.kibla.org Sun, 14 Jan 2001 19:08:02 +0100 (CET) Date: Sun, 14 Jan 2001 19:08:02 +0100 (CET) From: Danilo Godec danci@server.kibla.org Subject: [tulip] Problems with Intel LAN Has anyone else here had (and resolved) trouble with (newer) Intel LAN chipsets? I have one Intel D815EEA motherboard with integrated LAN and one D815EEA with PCI Intel LAN adapter. I have similar problems in both situations. It sometimes happens that the machine locks up, when the network is initalized (I guess when the interface is configured, but could be on module load). However, that is quite rare. Another problem happens, while the machine is already up. The LAN card stops working and reports something like 'card reports no resources'. If I re-initalize (ifdown - ifup) the interface, it works again (no need to reload the module). D. PS: It may be, that the problem is related to 815 chipset, as I had no problems with Intel LAN cards before. From becker@scyld.com Sun, 14 Jan 2001 15:40:20 -0500 (EST) Date: Sun, 14 Jan 2001 15:40:20 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Problems with Intel LAN On Sun, 14 Jan 2001, Danilo Godec wrote: > To: tulip@scyld.com > Subject: [tulip] Problems with Intel LAN > > Has anyone else here had (and resolved) trouble with (newer) Intel LAN > chipsets? > > I have one Intel D815EEA motherboard with integrated LAN and one D815EEA > with PCI Intel LAN adapter. I have similar problems in both situations. The hardware on the '815EEA is a eepro100, not a Tulip. You should post questions to the eepro100@scyld.com list, rather than here. > It sometimes happens that the machine locks up, when the network is > initalized (I guess when the interface is configured, but could be on > module load). However, that is quite rare. This is an undocumented timing "issue" (read "bug"). It appears to be related to the RxAddrLoad command. The ugly solution is to delay 10 microseconds after loading the SCBPointer before issuing the RxAddrLoad common. No clean solution has been found. That change is in the v1.13 driver. > Another problem happens, while the machine is already up. The LAN card > stops working and reports something like 'card reports no resources'. If I > re-initalize (ifdown - ifup) the interface, it works again (no need to > reload the module). The is a problem in the modified drivers. Use the driver directly from Scyld to avoid this. Users with RPM-based system may install this as rpm -i ftp://ftp.scyld.com/pub/network/test/netdriver-2.1.3.src.rpm cd /usr/src/redhat/ rpm -bb SPECS/netdriver.spec rpm -i --force RPMS/i386/netdriver-2.1-*.i386.rpm > PS: It may be, that the problem is related to 815 chipset, as I had no > problems with Intel LAN cards before. Correct. IIRC, neither problem existed with the original i82557 chips. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Mon, 15 Jan 2001 05:34:57 -0500 (EST) Date: Mon, 15 Jan 2001 05:34:57 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] New test version of tulip.c v0.92t On Sun, 14 Jan 2001, Patrick Dung wrote: > Subject: Re: Accton 1207b and tulip.c It took most of the day, but I've reproduced the problem with the 21143-TD rev 65 in 100baseTx-FDX SYM mode and found the solution. The chip ignore the CSR6 full duplex bit unless autonegotiation is disabled. Strangely, this isn't true with 10baseT-FDX. With the autonegotiation bit turned off, the link partner status is erased. So while cleaning up the status report for the mii-diag ioctl() calls, I fixed a few bits and added the ability to restart autonegotation. Please try ftp://www.scyld.com/pub/network/test/tulip.c and send a report. --------------------------- revision 1.57 date: 2001/01/15 07:29:36; author: becker; state: Exp; lines: +29 -15 tulip.c:v0.92t 1/15/2001 Disable the CSR6 SQE check when in 100Mbps mode. Disable autonegotiation when switching into autonegotiated 100baseTx mode so that the full duplex bit is honored. Better setting and reporting of the SYM-NWAY status through the MII registers, including autonegotiation restart. ---------------------------- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From r.burton@180sw.com Mon, 15 Jan 2001 14:21:23 +0000 Date: Mon, 15 Jan 2001 14:21:23 +0000 From: Ross Burton r.burton@180sw.com Subject: [tulip] Accton EN2242 This is a cryptographically signed message in MIME format. --------------ms62050B767DD67570183B1303 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I am considering buying a Toshiba Satellite 35DVD laptop which comes with an Accton EN2242. There was a thread recently (~Nov 2000) about this network card but it implied that the tulip drivers need to be modified to work. Is this still true? Also, are these drivers integrated into a Linux kernel version? Thanks for any help, Ross -- Ross Burton Software Engineer OneEighty Software Ltd Tel: +44 20 8263 2332 The Lansdowne Building Fax: +44 20 8263 6314 2 Lansdowne Road r.burton@180sw.com Croydon, Surrey CR9 2ER, UK http://www.180sw.com./ ==================================================================== Under the Regulation of Investigatory Powers (RIP) Act 2000 together with any and all Regulations in force pursuant to the Act OneEighty Software Ltd reserves the right to monitor any or all incoming or outgoing communications as provided for under the Act --------------ms62050B767DD67570183B1303 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH3AYJKoZIhvcNAQcCoIIHzTCCB8kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Ba8wggJ+MIIB56ADAgECAgMD9LcwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTAxMTIxMDM4NDFaFw0wMjAxMTIxMDM4NDFa MEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEnIu YnVydG9uQDE4MHN3LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0GXiyp5ta6Lz JZH5nPjD+sDpj4Gc/9Pvjtj7VvseGFkBW7U+QO5VCGTqv1iKfyKDichFuZx8LsrOSJJ56UeJ bIuHan2KgxHdNB52kngb1Z4eRSnbwQjFM34LvE/MzBhmeB5dxQTZipN8GGvG2+ZoliQrGeI5 9m3tP0ooEA9xfuUCAwEAAaMvMC0wHQYDVR0RBBYwFIESci5idXJ0b25AMTgwc3cuY29tMAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEACcRDtAxE9dgJDM0zC/ro04+TmMdvZW2q fvx4SrsU6nN6EDPxvaWHrhkDFSga37zil8jMINoucvnlFTy8gQdrJ+lmn6vnCow2XLGmIq30 lCi3w63sPSa97V0NaIRoDjJzlddEPitvlzA/IJC/eBScC3oMEtYte+gjrzKgMlPusPAwggMp MIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIwODI5MjM1OTU5 WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2Vz MSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K73 7nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzp q+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREE IjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27 j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBv Lli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gx ggH1MIIB8QIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmlj YXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw AgMD9LcwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wMTAxMTUxNDIxMjNaMCMGCSqGSIb3DQEJBDEWBBTFa5hSs1OXEZ5BfQKO5xEk 0zoWxDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgHzz fdLahYJcrUYwT47ej+F/7RsOtF0QJpxcLOab3n0dO1vrDxH1i6al3T8GZDPDz7IWgK01Opld a6bdNEICQdujaA0OXZiFIUYR6VwHkCU1uDeQSUnXjnysS/lXHDkaKkatiVnPlya0+EIoeNRB z/ekZHqnbrJOAhYgunmVI2Ge --------------ms62050B767DD67570183B1303-- From jearle@nortelnetworks.com Mon, 15 Jan 2001 13:05:54 -0500 Date: Mon, 15 Jan 2001 13:05:54 -0500 From: Jonathan Earle jearle@nortelnetworks.com Subject: [tulip] Problem with tulip, 2.4.0test kernel Hi, Config is two PIII boxes, RH6.2, kernel 2.4.0-test9 (tulip driver lifted from kernel 2.4.0 - version 0.9.13 (January 2, 2001) but was previously using the proper 2.4.0-test9 driver - version 0.9.10 (September 6, 2000)) and Znyx ZX346Q 4port cards, with each port connected to the corresponding port in the other PC via a crossover cable. Tulip driver is built as a module. Other nic in the PC is a builtin 3c905C. Using the tulip driver that came with the 2.4.0-test9 kernel, or the latest kernel, produces the same effect: a fresh boot of the PC will load the tulip driver and ifconfig the interfaces, but the interfaces are not actually up - I can ping the interface itself, but I cannot ping the other PC. If I load the de4x5 driver instead, I _can_ ping the other PC. (Another odd thing is, if I load the de4x5 module, ifconfig the interfaces, then deconfig them, unload de4x5.o, load tulip.o and bring the interfaces up, it seems to work properly.) If I connect the ports to some real hardware such as a switch, the ports will work okay. dmesg shows: Linux Tulip driver version 0.9.13 (January 2, 2001) eth1: Digital DS21143 Tulip rev 65 at 0xec80, 00:C0:95:E6:49:38, IRQ 7. eth1: EEPROM default media type Autosense. eth1: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. eth1: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. eth1: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. eth1: Index #3 - Media 100baseTx-FD (#5) described by a 21143 SYM PHY (4) block. eth2: Digital DS21143 Tulip rev 65 at 0xec00, 00:C0:95:E6:49:39, IRQ 5. eth2: EEPROM default media type Autosense. eth2: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. eth2: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. eth2: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. eth2: Index #3 - Media 100baseTx-FD (#5) described by a 21143 SYM PHY (4) block. eth3: Digital DS21143 Tulip rev 65 at 0xe880, 00:C0:95:E6:49:3A, IRQ 3. eth3: EEPROM default media type Autosense. eth3: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. eth3: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. eth3: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. eth3: Index #3 - Media 100baseTx-FD (#5) described by a 21143 SYM PHY (4) block. eth4: Digital DS21143 Tulip rev 65 at 0xe800, 00:C0:95:E6:49:3B, IRQ 4. eth4: EEPROM default media type Autosense. eth4: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. eth4: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. eth4: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. eth4: Index #3 - Media 100baseTx-FD (#5) described by a 21143 SYM PHY (4) block. Playing with tulip-diag produces: root@onc1:~> tulip-diag -aa -f tulip-diag.c:v2.03 7/31/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xec80. Digital DS21143 Tulip chip registers at 0xec80: f8a08000 ffffffff ffffffff 06172000 06172200 f0260000 30002002 fbfffbff e0000000 ffffcbf8 ffffffff 00000000 000000c6 ffff0000 fff80000 8ff4c008 Port selection is 10mpbs-serial, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Waiting for Tx to finish'. The transmit threshold is 72. The NWay status register is 000000c6. Internal autonegotiation state is 'Autonegotiation disabled'. Index #2: Found a Digital DS21143 Tulip adapter at 0xec00. Digital DS21143 Tulip chip registers at 0xec00: f8a08000 ffffffff ffffffff 06179000 06179200 f0660000 b3862202 fbfffbff e0000000 ffffcbf8 ffffffff 00000000 41e1d2cd ffff0001 fffbffff 8ffdc008 Port selection is 100mbps-SYM/PCS 100baseTx scrambler, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 41e1d2cd. Internal autonegotiation state is 'Negotiation complete'. Index #3: Found a Digital DS21143 Tulip adapter at 0xe880. Digital DS21143 Tulip chip registers at 0xe880: f8a08000 ffffffff ffffffff 0619f000 0619f200 f0260000 b2422202 fbfffbff e0000000 ffffcbf8 ffffffff 00000000 000020c6 ffff0001 fffbffff 8ff50000 Port selection is 10mpbs-serial, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Waiting for Tx to finish'. The transmit threshold is 72. The NWay status register is 000020c6. Internal autonegotiation state is 'Ability detect'. Index #4: Found a Digital DS21143 Tulip adapter at 0xe800. Digital DS21143 Tulip chip registers at 0xe800: f8000000 ffffffff ffffffff 0f90a000 0f90a080 f0000000 b2420200 f3fe0000 e0000000 ffffcbf8 ffffffff 00000000 000020c6 ffff0001 fffbffff 8ff5c000 Port selection is 10mpbs-serial, full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. The NWay status register is 000020c6. Internal autonegotiation state is 'Ability detect'. root@onc1:~> tulip-diag -ee tulip-diag.c:v2.03 7/31/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xec80. Port selection is 10mpbs-serial, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Waiting for Tx to finish'. The transmit threshold is 72. The NWay status register is 000000c6. EEPROM size is 6. PCI Subsystem IDs, vendor 110d, device 0013. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:C0:95:E6:49:38. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 39, default media type 0800 (Autosense). 4 transceiver description blocks: Media 10baseT, block type 2, length 6. Serial transceiver for 10baseT (media type 0). GP pin direction 08af GP pin data 00a5. Media 10baseT-Full Duplex, block type 2, length 6. Serial transceiver for 10baseT-Full Duplex (media type 4). GP pin direction 08af GP pin data 00a5. Media 100baseTx, block type 4, length 8. SYM transceiver for 100baseTx (media type 3). GP pin direction 08af GP pin data 00a5. No media detection indication (command 80 61). Media 100baseTx Full Duplex, block type 4, length 8. SYM transceiver for 100baseTx Full Duplex (media type 5). GP pin direction 08af GP pin data 00a5. No media detection indication (command 80 61). EEPROM contents: 110d 0013 0000 0000 0000 0000 0000 0000 0047 0404 c000 e695 3849 2704 0500 0027 2706 0700 0027 0000 0408 0286 af00 a508 8600 0402 08af 00a5 0488 af03 a508 6100 8880 0504 08af 00a5 8061 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 524a 0001 1300 0001 061f 0072 8fff ID block CRC 0x47 (vs. 0x47). Full contents CRC 0x8fff (read as 0x8fff). Internal autonegotiation state is 'Autonegotiation disabled'. Index #2: Found a Digital DS21143 Tulip adapter at 0xec00. Port selection is 100mbps-SYM/PCS 100baseTx scrambler, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 41e1d2cd. EEPROM size is 6. PCI Subsystem IDs, vendor 110d, device 0013. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:C0:95:E6:49:39. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 30, default media type 0800 (Autosense). 4 transceiver description blocks: Media 10baseT, block type 2, length 6. Serial transceiver for 10baseT (media type 0). GP pin direction 08af GP pin data 00a5. Media 10baseT-Full Duplex, block type 2, length 6. Serial transceiver for 10baseT-Full Duplex (media type 4). GP pin direction 08af GP pin data 00a5. Media 100baseTx, block type 4, length 8. SYM transceiver for 100baseTx (media type 3). GP pin direction 08af GP pin data 00a5. No media detection indication (command 80 61). Media 100baseTx Full Duplex, block type 4, length 8. SYM transceiver for 100baseTx Full Duplex (media type 5). GP pin direction 08af GP pin data 00a5. No media detection indication (command 80 61). EEPROM contents: 110d 0013 0000 0000 0000 0000 0000 0000 0047 0104 c000 e695 3949 1e00 0000 0800 8604 0002 08af 00a5 0286 af04 a508 8800 0304 08af 00a5 8061 0488 af05 a508 6100 0080 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 524a 0001 1300 0001 061f 0072 027e ID block CRC 0x47 (vs. 0x47). Full contents CRC 0x027e (read as 0x027e). Internal autonegotiation state is 'Negotiation complete'. Index #3: Found a Digital DS21143 Tulip adapter at 0xe880. Port selection is 100mbps-SYM/PCS 100baseTx scrambler, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Waiting for Tx to finish'. The transmit threshold is 128. The NWay status register is 000000c6. EEPROM size is 6. PCI Subsystem IDs, vendor 110d, device 0013. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:C0:95:E6:49:3A. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 30, default media type 0800 (Autosense). 4 transceiver description blocks: Media 10baseT, block type 2, length 6. Serial transceiver for 10baseT (media type 0). GP pin direction 08af GP pin data 00a5. Media 10baseT-Full Duplex, block type 2, length 6. Serial transceiver for 10baseT-Full Duplex (media type 4). GP pin direction 08af GP pin data 00a5. Media 100baseTx, block type 4, length 8. SYM transceiver for 100baseTx (media type 3). GP pin direction 08af GP pin data 00a5. No media detection indication (command 80 61). Media 100baseTx Full Duplex, block type 4, length 8. SYM transceiver for 100baseTx Full Duplex (media type 5). GP pin direction 08af GP pin data 00a5. No media detection indication (command 80 61). EEPROM contents: 110d 0013 0000 0000 0000 0000 0000 0000 0047 0104 c000 e695 3a49 1e00 0000 0800 8604 0002 08af 00a5 0286 af04 a508 8800 0304 08af 00a5 8061 0488 af05 a508 6100 0080 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 524a 0001 1300 0001 061f 0072 947e ID block CRC 0x47 (vs. 0x47). Full contents CRC 0x947e (read as 0x947e). Internal autonegotiation state is 'Autonegotiation disabled'. Index #4: Found a Digital DS21143 Tulip adapter at 0xe800. Port selection is 10mpbs-serial, full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. The NWay status register is 000020c6. EEPROM size is 6. PCI Subsystem IDs, vendor 110d, device 0013. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:C0:95:E6:49:3B. EEPROM transceiver/media description for the Digital DS21143 Tulip chip. Leaf node at offset 30, default media type 0800 (Autosense). 4 transceiver description blocks: Media 10baseT, block type 2, length 6. Serial transceiver for 10baseT (media type 0). GP pin direction 08af GP pin data 00a5. Media 10baseT-Full Duplex, block type 2, length 6. Serial transceiver for 10baseT-Full Duplex (media type 4). GP pin direction 08af GP pin data 00a5. Media 100baseTx, block type 4, length 8. SYM transceiver for 100baseTx (media type 3). GP pin direction 08af GP pin data 00a5. No media detection indication (command 80 61). Media 100baseTx Full Duplex, block type 4, length 8. SYM transceiver for 100baseTx Full Duplex (media type 5). GP pin direction 08af GP pin data 00a5. No media detection indication (command 80 61). EEPROM contents: 110d 0013 0000 0000 0000 0000 0000 0000 0047 0104 c000 e695 3b49 1e00 0000 0800 8604 0002 08af 00a5 0286 af04 a508 8800 0304 08af 00a5 8061 0488 af05 a508 6100 0080 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 524a 0001 1300 0001 061f 0072 e441 ID block CRC 0x47 (vs. 0x47). Full contents CRC 0xe441 (read as 0xe441). Internal autonegotiation state is 'Ability detect'. Now, if I run tulip-diag -m (or -mm), it tells me there are no MII transceivers. However, if I run mii-diag, it shows: root@onc1:~> mii-diag eth1 Basic registers of MII PHY #32: 0000 784c 0000 0000 0401 0000 0000 0000. Basic mode control register 0x0000: Auto-negotiation disabled, with Speed fixed at 10 mbps, half-duplex. You have link beat, and everything is working OK. Link partner information information is not exchanged when in fixed speed mode. root@onc1:~> mii-diag eth2 Basic registers of MII PHY #32: 1000 786c 0000 0000 0621 41e1 0000 0000. Basic mode control register 0x1000: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner advertised 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT. root@onc1:~> mii-diag eth3 Basic registers of MII PHY #32: 0000 784c 0000 0000 05e1 0000 0000 0000. Basic mode control register 0x0000: Auto-negotiation disabled, with Speed fixed at 10 mbps, half-duplex. You have link beat, and everything is working OK. Link partner information information is not exchanged when in fixed speed mode. root@onc1:~> mii-diag eth4 Basic registers of MII PHY #32: 1000 784c 0000 0000 0621 0000 0000 0000. Basic mode control register 0x1000: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner does not do autonegotiation, and this transceiver type does not report the sensed link speed. So, not only does the link operate sporadically when connected to another PC instead of a switch, the diagnostic utils appear to report conflicting information - at least, the way I interpret the reports indicates so. Anyone have thoughts as to what is going on here and how I can get this working? Also, how can I force a specific speed? I know I can pass 'full_duplex=1' to the module to enable full duplex, but what do I pass to force 100TX instead of 10BT? Cheers! Jon From becker@scyld.com Mon, 15 Jan 2001 14:29:40 -0500 (EST) Date: Mon, 15 Jan 2001 14:29:40 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Problem with tulip, 2.4.0test kernel On Mon, 15 Jan 2001, Jonathan Earle wrote: > Config is two PIII boxes, RH6.2, kernel 2.4.0-test9 (tulip driver lifted > from kernel 2.4.0 - version 0.9.13 (January 2, 2001) but was previously > using the proper 2.4.0-test9 driver - version 0.9.10 (September 6, 2000)) > and Znyx ZX346Q 4port cards, with each port connected to the corresponding This appears to be a problem in the 2.4.0 driver. I've tested the '346 with 2.2 and my drivers. > Linux Tulip driver version 0.9.13 (January 2, 2001) > root@onc1:~> tulip-diag -aa -f > Index #1: Found a Digital DS21143 Tulip adapter at 0xec80. > Port selection is 10mpbs-serial, half-duplex. > The NWay status register is 000000c6. > Internal autonegotiation state is 'Autonegotiation disabled'. Hmmm, did you force full dulex? > The Tx process state is 'Waiting for Tx to finish'. This Tx state is normal for an incorrect media selection. > Index #2: Found a Digital DS21143 Tulip adapter at 0xec00. > Port selection is 100mbps-SYM/PCS 100baseTx scrambler, full-duplex. > The Rx process state is 'Waiting for packets'. > The Tx process state is 'Idle'. This interface looks normal. > Index #3: Found a Digital DS21143 Tulip adapter at 0xe880. > Port selection is 10mpbs-serial, full-duplex. > The Tx process state is 'Waiting for Tx to finish'. Same problem as #1. > Now, if I run tulip-diag -m (or -mm), it tells me there are no MII > transceivers. However, if I run mii-diag, it shows: > > root@onc1:~> mii-diag eth1 > Basic registers of MII PHY #32: 0000 784c 0000 0000 0401 0000 0000 0000. Valid MII addresses are 0-31. Address #32 is used when the driver is internally emulating the MII management registers. The recent 0.92t has substantially improved the accuracy of the emulation, notably the accuracy of the link beat report. > Also, how can I force a specific speed? I know I can pass 'full_duplex=1' > to the module to enable full duplex, but what do I pass to force 100TX > instead of 10BT? See the media table at http://www.scyld.com/network/tulip.html options=3,3,5,5 sets 100baseTx, 100baseTx, 100baseTx-FDX, 100baseTx-FDX I now recommend setting the speed+duplex based on the table rather than using the "full_duplex=" module option.
index media
0 Auto-select (default to the 10baseT link)
1 10base2
2 AUI
3 100baseTx
4 10baseT-FD
5 100baseTx-FD
6 100baseT4
7 100baseFx
8 100baseFx-FD
9 MII 10baseT
10 MII 10baseT-FD
11 MII (autoselect)
12 Serial 10baseT (no autoselect)
13 MII 100baseTx
14 MII 100baseTx-FD
15 MII 100baseT4
16 MII 100baseFx-HDX (half duplex)
17 MII 100baseFx-FDX (full duplex)
18 MII Home-PNA 1Mbps
0x200 (512 decimal) Added to other values to set full duplex
Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From jearle@nortelnetworks.com Mon, 15 Jan 2001 15:54:14 -0500 Date: Mon, 15 Jan 2001 15:54:14 -0500 From: Jonathan Earle jearle@nortelnetworks.com Subject: [tulip] Problem with tulip, 2.4.0test kernel This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07F35.51BC40E0 Content-Type: text/plain; charset="iso-8859-1" Thanks for the tip regarding the options line! I added "options tulip options=5,5,5,5" to the modules.conf on the two boxes in question, and now dmesg will show: eth1: Using user-specified media 100baseTx-FD. eth2: Using user-specified media 100baseTx-FD. eth3: Using user-specified media 100baseTx-FD. eth4: Using user-specified media 100baseTx-FD. >From a cold boot, I now have all four ports operating. I didn't realize that all four had to be set individually, although it's fairly obvious now. Hindsight is always 20/20. Is it fair to say that the 2.4.0 driver has problems auto-negotiating or is the problem I saw symptomatic of something else? Also, I infer that this card does not use MII registers, but emulates them instead. What does that ultimately mean? What does this card use in place of those registers? What I'm now observing, is an initial drop in performance after bootup. Once I was able to ping back and forth betweem the two NICs, I tried an FTP transfer (20+MB file). For the first few minutes, the cards will show transfer rates all over the map - from a few hundred kB/s to perhaps a few MB/s. The transfer will generally start at a higher rate, then drop. Eventually, everything seems to settle down and I then see the appropriate rates (11.2MB/s for full duplex, 100TX). This is a lead to another problem I'm having, which I'll post separately. Many thanks Donald! Cheers! Jon > -----Original Message----- > From: Donald Becker [mailto:becker@scyld.com] > Sent: Monday, January 15, 2001 2:30 PM > To: Earle, Jonathan [KAN:1A31:EXCH] > Cc: 'Tulip Driver List' > Subject: Re: [tulip] Problem with tulip, 2.4.0test kernel > > > On Mon, 15 Jan 2001, Jonathan Earle wrote: > > > Config is two PIII boxes, RH6.2, kernel 2.4.0-test9 (tulip > driver lifted > > from kernel 2.4.0 - version 0.9.13 (January 2, 2001) but > was previously > > using the proper 2.4.0-test9 driver - version 0.9.10 > (September 6, 2000)) > > and Znyx ZX346Q 4port cards, with each port connected to > the corresponding > > This appears to be a problem in the 2.4.0 driver. > > I've tested the '346 with 2.2 and my drivers. > > > Linux Tulip driver version 0.9.13 (January 2, 2001) > > > root@onc1:~> tulip-diag -aa -f > > Index #1: Found a Digital DS21143 Tulip adapter at 0xec80. > > Port selection is 10mpbs-serial, half-duplex. > > The NWay status register is 000000c6. > > Internal autonegotiation state is 'Autonegotiation disabled'. > > Hmmm, did you force full dulex? > > > The Tx process state is 'Waiting for Tx to finish'. > > This Tx state is normal for an incorrect media selection. > > > Index #2: Found a Digital DS21143 Tulip adapter at 0xec00. > > Port selection is 100mbps-SYM/PCS 100baseTx scrambler, full-duplex. > > The Rx process state is 'Waiting for packets'. > > The Tx process state is 'Idle'. > > This interface looks normal. > > > Index #3: Found a Digital DS21143 Tulip adapter at 0xe880. > > Port selection is 10mpbs-serial, full-duplex. > > The Tx process state is 'Waiting for Tx to finish'. > > Same problem as #1. > > > Now, if I run tulip-diag -m (or -mm), it tells me there are no MII > > transceivers. However, if I run mii-diag, it shows: > > > > root@onc1:~> mii-diag eth1 > > Basic registers of MII PHY #32: 0000 784c 0000 0000 0401 > 0000 0000 0000. > > Valid MII addresses are 0-31. > Address #32 is used when the driver is internally emulating the MII > management registers. > > The recent 0.92t has substantially improved the accuracy of the > emulation, notably the accuracy of the link beat report. > > > Also, how can I force a specific speed? I know I can pass > 'full_duplex=1' > > to the module to enable full duplex, but what do I pass to > force 100TX > > instead of 10BT? > > See the media table at > http://www.scyld.com/network/tulip.html > > options=3,3,5,5 sets 100baseTx, 100baseTx, 100baseTx-FDX, > 100baseTx-FDX > > I now recommend setting the speed+duplex based on the table > rather than > using the "full_duplex=" module option. > > > > > > > > > > > > > > > > > > > > > > > >
index media
0 Auto-select (default to the 10baseT link)
1 10base2
2 AUI
3 100baseTx
4 10baseT-FD
5 100baseTx-FD
6 100baseT4
7 100baseFx
8 100baseFx-FD
9 MII 10baseT
10 MII 10baseT-FD
11 MII (autoselect)
12 Serial 10baseT (no autoselect)
13 MII 100baseTx
14 MII 100baseTx-FD
15 MII 100baseT4
16 MII 100baseFx-HDX (half duplex)
17 MII 100baseFx-FDX (full duplex)
18 MII Home-PNA 1Mbps
0x200 (512 decimal) Added to other values to > set full duplex
> > > > > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation > Beowulf Clusters > Annapolis MD 21403 410-990-9993 > > > _______________________________________________ > tulip mailing list > tulip@scyld.com > http://www.scyld.com/mailman/listinfo/tulip > ------_=_NextPart_001_01C07F35.51BC40E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [tulip] Problem with tulip, 2.4.0test kernel

Thanks for the tip regarding the options line!  = I added "options tulip options=3D5,5,5,5" to the modules.conf = on the two boxes in question, and now dmesg will show:

eth1: Using user-specified media 100baseTx-FD.
eth2: Using user-specified media = 100baseTx-FD.
eth3: Using user-specified media = 100baseTx-FD.
eth4: Using user-specified media = 100baseTx-FD.    

From a cold boot, I now have all four ports = operating.  I didn't realize that all four had to be set = individually, although it's fairly obvious now.  Hindsight is = always 20/20.

Is it fair to say that the 2.4.0 driver has problems = auto-negotiating or is the problem I saw symptomatic of something = else?

Also, I infer that this card does not use MII = registers, but emulates them instead.  What does that ultimately = mean?  What does this card use in place of those = registers?

What I'm now observing, is an initial drop in = performance after bootup.  Once I was able to ping back and forth = betweem the two NICs, I tried an FTP transfer (20+MB file).  For = the first few minutes, the cards will show transfer rates all over the = map - from a few hundred kB/s to perhaps a few MB/s.  The transfer = will generally start at a higher rate, then drop.  Eventually, = everything seems to settle down and I then see the appropriate rates = (11.2MB/s for full duplex, 100TX).

This is a lead to another problem I'm having, which = I'll post separately.

Many thanks Donald!

Cheers!
Jon

> -----Original Message-----
> From: Donald Becker [mailto:becker@scyld.com]
> Sent: Monday, January 15, 2001 2:30 PM
> To: Earle, Jonathan [KAN:1A31:EXCH]
> Cc: 'Tulip Driver List'
> Subject: Re: [tulip] Problem with tulip, = 2.4.0test kernel
>
>
> On Mon, 15 Jan 2001, Jonathan Earle = wrote:
>
> > Config is two PIII boxes, RH6.2, kernel = 2.4.0-test9 (tulip
> driver lifted
> > from kernel 2.4.0 - version 0.9.13 = (January 2, 2001) but
> was previously
> > using the proper 2.4.0-test9 driver - = version 0.9.10
> (September 6, 2000))
> > and Znyx ZX346Q 4port cards, with each = port connected to
> the corresponding
>
> This appears to be a problem in the 2.4.0 = driver.
>
> I've tested the '346 with 2.2 and my = drivers.
>
> > Linux Tulip driver version 0.9.13 (January = 2, 2001)
>
> > root@onc1:~> tulip-diag -aa -f
> > Index #1: Found a Digital DS21143 Tulip = adapter at 0xec80.
> >  Port selection is 10mpbs-serial, = half-duplex.
> >   The NWay status register is = 000000c6.
> >   Internal autonegotiation state = is 'Autonegotiation disabled'.
>
> Hmmm, did you force full dulex?
>
> >   The Tx process state is = 'Waiting for Tx to finish'.
>
> This Tx state is normal for an incorrect media = selection.
>
> > Index #2: Found a Digital DS21143 Tulip = adapter at 0xec00.
> >  Port selection is 100mbps-SYM/PCS = 100baseTx scrambler, full-duplex.
> >   The Rx process state is = 'Waiting for packets'.
> >   The Tx process state is = 'Idle'.
>
> This interface looks normal.
>
> > Index #3: Found a Digital DS21143 Tulip = adapter at 0xe880.
> >  Port selection is 10mpbs-serial, = full-duplex.
> >   The Tx process state is = 'Waiting for Tx to finish'.
>
> Same problem as #1.
>
> > Now, if I run tulip-diag -m (or -mm), it = tells me there are no MII
> > transceivers.  However, if I run = mii-diag, it shows:
> >
> > root@onc1:~> mii-diag eth1
> > Basic registers of MII PHY #32:  0000 = 784c 0000 0000 0401
> 0000 0000 0000.
>
> Valid MII addresses are 0-31.
> Address #32 is used when the driver is = internally emulating the MII
> management registers.
>
> The recent 0.92t has substantially improved the = accuracy of the
> emulation, notably the accuracy of the link = beat report.
>
> > Also, how can I force a specific = speed?  I know I can pass
> 'full_duplex=3D1'
> > to the module to enable full duplex, but = what do I pass to
> force 100TX
> > instead of 10BT?
>
> See the media table at
>    http://www.scyld.com/network/tulip.html
>
> options=3D3,3,5,5  sets 100baseTx, = 100baseTx, 100baseTx-FDX,
> 100baseTx-FDX
>
> I now recommend setting the speed+duplex based = on the table
> rather than
> using the "full_duplex=3D" module = option.
>
> <table border=3D2>
> <tr><td> = index        <td>  = media</tr>
> <tr><td>  0   = <td> Auto-select (default to the 10baseT link)</tr>
> <tr><td>  1   = <td> 10base2</tr>
> <tr><td>  2   = <td> AUI</tr>
> <tr><td>  3   = <td> 100baseTx</tr>
> <tr><td>  4   = <td> 10baseT-FD</tr>
> <tr><td>  5   = <td> 100baseTx-FD</tr>
> <tr><td>  6   = <td> 100baseT4</tr>
> <tr><td>  7   = <td> 100baseFx</tr>
> <tr><td>  8   = <td> 100baseFx-FD</tr>
> <tr><td>  9   = <td> MII 10baseT</tr>
> <tr><td> 10   <td> = MII 10baseT-FD</tr>
> <tr><td> 11   <td> = MII (autoselect)</tr>
> <tr><td> 12   = <td>  Serial 10baseT (no autoselect)</tr>
> <tr><td> 13   <td> = MII 100baseTx</tr>
> <tr><td> 14   <td> = MII 100baseTx-FD</tr>
> <tr><td> 15   <td> = MII 100baseT4</tr>
> <tr><td> 16     = <td> MII 100baseFx-HDX (half duplex)</tr>
> <tr><td> 17   <td> = MII 100baseFx-FDX (full duplex)</tr>
> <tr><td> 18   <td> = MII Home-PNA 1Mbps</tr>
> <tr><td> 0x200 (512 decimal)  = <td> Added to other values to
> set full duplex</tr>
> </table>
>
>
>
>
> Donald Becker =         =         =         becker@scyld.com
> Scyld Computing Corporation   =         http://www.scyld.com
> 410 Severn Ave. Suite = 210             = Second Generation
> Beowulf Clusters
> Annapolis MD 21403    =         =         410-990-9993
>
>
> = _______________________________________________
> tulip mailing list
> tulip@scyld.com
> http://www.scyld.com/mailman/listinfo/tulip=
>

------_=_NextPart_001_01C07F35.51BC40E0-- From becker@scyld.com Mon, 15 Jan 2001 16:40:47 -0500 (EST) Date: Mon, 15 Jan 2001 16:40:47 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Problem with tulip, 2.4.0test kernel On Mon, 15 Jan 2001, Jonathan Earle wrote: > Thanks for the tip regarding the options line! I added "options tulip > options=5,5,5,5" to the modules.conf on the two boxes in question, and now > dmesg will show: > > eth1: Using user-specified media 100baseTx-FD. > eth2: Using user-specified media 100baseTx-FD. > eth3: Using user-specified media 100baseTx-FD. > eth4: Using user-specified media 100baseTx-FD. > > >From a cold boot, I now have all four ports operating. I didn't realize > that all four had to be set individually, although it's fairly obvious now. > Hindsight is always 20/20. > > Is it fair to say that the 2.4.0 driver has problems auto-negotiating or is > the problem I saw symptomatic of something else? Correct. The 2.4.0 obviously driver doesn't have the 21143 autonegotiation code quite right. It's tricky to do correctly, especially with a board that uses the general purpose pins to select the power to SYM transceiver chip and light the correct LEDs. The driver sometime must use the information in the EEPROM media table, and other times should just guess what to do. Autonegotiation in SYM mode is complicated by the illogical layout and changing mode of the 21143 control bits. For instance the FullDuplex bit in CSR6 used to mean that the chip was in full duplex mode. But in the 21143 it sets the 10baseT-FDX bit in the NWay capability word. All of the other advertised bits are in CSR14! > Also, I infer that this card does not use MII registers, but emulates them > instead. What does that ultimately mean? What does this card use in place > of those registers? It uses a SYM (Symbol mode) transceiver instead of a MII transceiver. SYM transceivers are an older type, simpler and slightly less expensive. But they were not designed with autonegotiation or hardware diagnostics in mind, and thus are a pain to deal with. The 21143 is pretty much the only chip that still ships with SYM transceiver support. Most modern chips have an on-chip transceiver with MII-like management registers. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From astewart@world.std.com Mon, 15 Jan 2001 18:34:58 -0500 Date: Mon, 15 Jan 2001 18:34:58 -0500 From: root astewart@world.std.com Subject: [tulip] I can't make multiple tulips work properly. Hi everybody, I am using the 0.92t tulip driver loaded as a kernel module. I have tried this experiment with kernel revs 2.2.14 and 2.2.18 with similar results. 1) Install one Linksys card (tulip-diag reports it as a Digital DC21041 Tulip). Works great. Call this eth0. 2) Install 2nd Linksys card (tulip-diag reports this as an ADMtek AL985 Centaur-P but I call it a Linksys LNE100TX v4.1). This one is eth1. 3) 2nd Linksys card eth1 works great...but eth0 stopped working. Here is an excerpt from /var/log/messages: Jan 15 18:06:50 firewall kernel: eth0: 21041 media switched to 10baseT. Jan 15 18:06:52 firewall kernel: eth0: 21041 transmit timed out, status fc678057 , CSR12 000060c8, CSR13 ffffef01, CSR14 ffffffff, resetting... Jan 15 18:06:57 firewall kernel: eth0: 21041 transmit timed out, status fc678057 , CSR12 000052c8, CSR13 ffffef09, CSR14 fffff7fd, resetting... Jan 15 18:07:02 firewall kernel: eth0: 21041 transmit timed out, status fc678057 , CSR12 000051c8, CSR13 ffffef01, CSR14 ffffffff, resetting... Jan 15 18:07:07 firewall kernel: eth0: 21041 transmit timed out, status fc678057 , CSR12 000052c8, CSR13 ffffef09, CSR14 fffff7fd, resetting... I can't fathom what I might have done wrong. Any help or suggestions would be greatly appreciated. Thanks, Andy Stewart astewart@world.std.com Worcester Linux Users' Group Worcester, MA, USA From becker@scyld.com Mon, 15 Jan 2001 19:16:13 -0500 (EST) Date: Mon, 15 Jan 2001 19:16:13 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] I can't make multiple tulips work properly. On Mon, 15 Jan 2001, root wrote: > I am using the 0.92t tulip driver loaded as a kernel module. I have > tried this experiment with kernel revs 2.2.14 and 2.2.18 with similar > results. > > 1) Install one Linksys card (tulip-diag reports it as a Digital DC21041 > Tulip). Works great. Call this eth0. > > 2) Install 2nd Linksys card (tulip-diag reports this as an ADMtek AL985 > Centaur-P but I call it a Linksys LNE100TX v4.1). This one is eth1. > > 3) 2nd Linksys card eth1 works great...but eth0 stopped working. Here > is an excerpt from /var/log/messages: > > Jan 15 18:06:50 firewall kernel: eth0: 21041 media switched to 10baseT. > Jan 15 18:06:52 firewall kernel: eth0: 21041 transmit timed out, status > fc678057 Hmmm, looks like a simple IRQ problem. The chip is raising an interrupt, but it isn't getting through the system. Check /proc/interrupts to confirm. > I can't fathom what I might have done wrong. Any help or suggestions > would be greatly appreciated. Adding another card moved the interrupt assignments around. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From mihai@MIT.EDU Mon, 15 Jan 2001 20:52:30 -0500 Date: Mon, 15 Jan 2001 20:52:30 -0500 From: Mihai Badoiu mihai@MIT.EDU Subject: [tulip] lag problems with Linksys 10/100 I'm using a 10/100 Linksys-tulip chipset with RedHat 6.2, kernel 2.2.18. I have the latest drivers. The problem is that the network lags from time to time. It's something like this: 64 bytes from ZAMOLXIS.MIT.EDU (18.244.1.85): icmp_seq=941 ttl=255 time=2.0 ms 64 bytes from ZAMOLXIS.MIT.EDU (18.244.1.85): icmp_seq=942 ttl=255 time=1.6 ms 64 bytes from ZAMOLXIS.MIT.EDU (18.244.1.85): icmp_seq=943 ttl=255 time=0.3 ms 64 bytes from ZAMOLXIS.MIT.EDU (18.244.1.85): icmp_seq=944 ttl=255 time=4004.3 ms 64 bytes from ZAMOLXIS.MIT.EDU (18.244.1.85): icmp_seq=945 ttl=255 time=3008.2 ms 64 bytes from ZAMOLXIS.MIT.EDU (18.244.1.85): icmp_seq=946 ttl=255 time=2010.1 ms 64 bytes from ZAMOLXIS.MIT.EDU (18.244.1.85): icmp_seq=947 ttl=255 time=1011.9 ms 64 bytes from ZAMOLXIS.MIT.EDU (18.244.1.85): icmp_seq=948 ttl=255 time=13.6 ms 64 bytes from ZAMOLXIS.MIT.EDU (18.244.1.85): icmp_seq=949 ttl=255 time=1.5 ms 64 bytes from ZAMOLXIS.MIT.EDU (18.244.1.85): icmp_seq=950 ttl=255 time=0.2 ms 64 bytes from ZAMOLXIS.MIT.EDU (18.244.1.85): icmp_seq=951 ttl=255 time=0.3 ms 64 bytes from ZAMOLXIS.MIT.EDU (18.244.1.85): icmp_seq=952 ttl=255 time=0.2 ms I have tested 2 other network cards that have a rtl8139 chip and I get the same problem. Any ideas what can be wrong? Is it possible that the pci-scan driver bugs? I have an Athlon 1Gz on a KT7 motherboard. thanks, --mihai From lbickley@bickleywest.com Mon, 15 Jan 2001 20:26:33 -0800 Date: Mon, 15 Jan 2001 20:26:33 -0800 From: Lyle Bickley lbickley@bickleywest.com Subject: [tulip] Netgear.... Hi Donald, I've noticed that when using Netgear FA310tx boards with the 82C169C "Tulip" chip and 700MHz+ Athlon or Duron ASUS motherboards , that IRQ's are NOT recognized by the tulip driver [displays IRQ 0 in the log]. This is true of both Linux 2.2.x or Linux 2.4 kernels. Windows 98/Millenium/2000 work O.K. with the same MB/processor/Netgear board - and pick up the correct IRQ (as set manually or "auto" in the MB EPROM). 1) What do you think is causing this problem? 2) Is there a way to manually set the "tulip" IRQ? Lyle -- Lyle Bickley | Bickley Consulting West Inc. lbickley@acm.org | lbickley@bickleywest.com | V 650-428-0621 http://bickleywest.com/ | F 650-428-0599 "Black holes exist where GOD is dividing by zero" From becker@scyld.com Mon, 15 Jan 2001 22:46:27 -0500 (EST) Date: Mon, 15 Jan 2001 22:46:27 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Re: Netgear.... On Mon, 15 Jan 2001, Lyle Bickley wrote: > I've noticed that when using Netgear FA310tx boards with the 82C169C > "Tulip" chip and 700MHz+ Athlon or Duron ASUS motherboards , that IRQ's > are NOT recognized by the tulip driver [displays IRQ 0 in the log]. Easy answer http://www.scyld.com/expert/irq-conflict.html Summary: this is a BIOS setup issue. > This is true of both Linux 2.2.x or Linux 2.4 kernels. The 2.4 kernel can supposedly access the ACPI methods to turn on the IRQ routing. The haven't been many reports on how reliable this is. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From lbickley@bickleywest.com Mon, 15 Jan 2001 21:35:47 -0800 Date: Mon, 15 Jan 2001 21:35:47 -0800 From: Lyle Bickley lbickley@bickleywest.com Subject: [tulip] Re: Netgear.... Donald Becker wrote: > > On Mon, 15 Jan 2001, Lyle Bickley wrote: > > > I've noticed that when using Netgear FA310tx boards with the 82C169C > > "Tulip" chip and 700MHz+ Athlon or Duron ASUS motherboards , that IRQ's > > are NOT recognized by the tulip driver [displays IRQ 0 in the log]. > > Easy answer > http://www.scyld.com/expert/irq-conflict.html > > Summary: this is a BIOS setup issue. 100% Correct. I turned off "PNP OS" and I noted that the BIOS displayed the proper IRQ on boot and Linux and the Tulip picked it IRQ up as well. Works perfectly. THANKS! However this leads me to another question: Why did an Intel Pro 100+ work O.K. with the BIOS set to PNP, but the Tulip requires PNP to be off?? Cheers, Lyle -- Lyle Bickley | Bickley Consulting West Inc. lbickley@acm.org | lbickley@bickleywest.com | V 650-428-0621 http://bickleywest.com/ | F 650-428-0599 "Black holes exist where GOD is dividing by zero" From lbickley@bickleywest.com Tue, 16 Jan 2001 08:53:33 -0800 Date: Tue, 16 Jan 2001 08:53:33 -0800 From: Lyle Bickley lbickley@bickleywest.com Subject: [tulip] Re: Netgear.... Donald Becker wrote: > > However this leads me to another question: Why did an Intel Pro 100+ > > work O.K. with the BIOS set to PNP, but the Tulip requires PNP to be > > off?? > > Did the Pro 100+ board have an on-board Flash with network boot capability? > If so, it made BIOS calls to configure itself. > If not, please let me know the BIOS type and the exact eepro100 type -- > I would like to investigate further. Yep, it has the on-board Flash with network host capability - and so it DID configure itself. Thanks again, Donald. Lyle -- Lyle Bickley | Bickley Consulting West Inc. lbickley@acm.org | lbickley@bickleywest.com | V 650-428-0621 http://bickleywest.com/ | F 650-428-0599 "Black holes exist where GOD is dividing by zero" From becker@scyld.com Tue, 16 Jan 2001 03:12:47 -0500 (EST) Date: Tue, 16 Jan 2001 03:12:47 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Re: Netgear.... On Mon, 15 Jan 2001, Lyle Bickley wrote: > Donald Becker wrote: > > On Mon, 15 Jan 2001, Lyle Bickley wrote: > > > are NOT recognized by the tulip driver [displays IRQ 0 in the log]. > > http://www.scyld.com/expert/irq-conflict.html > > > > Summary: this is a BIOS setup issue. > > 100% Correct. I turned off "PNP OS" and I noted that the BIOS displayed > the proper IRQ on boot and Linux and the Tulip picked it IRQ up as > well. Works perfectly. THANKS! > > However this leads me to another question: Why did an Intel Pro 100+ > work O.K. with the BIOS set to PNP, but the Tulip requires PNP to be > off?? Did the Pro 100+ board have an on-board Flash with network boot capability? If so, it made BIOS calls to configure itself. If not, please let me know the BIOS type and the exact eepro100 type -- I would like to investigate further. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From jctoman@compendium-tech.com Tue, 16 Jan 2001 16:27:18 -0800 Date: Tue, 16 Jan 2001 16:27:18 -0800 From: John C. Toman jctoman@compendium-tech.com Subject: [tulip] Can't Get Linksys PCMPC200 V2 Working Hi, I've got a brand new Linksys CardBus PCMPC200 V2 I'm trying to get working on a RedHat 7.0 system. The kernel is 2.2.18 and I'm using pcmcia-cs 3.1.22. I've followed the instructions on the web site to correctly create and place the tulip driver in the correct area. I think(?) I've done that right. Here's what my message log is saying: Jan 16 16:06:34 europa kernel: kernel build: 2.2.18 #2 Tue Jan 16 11:05:29 PST 2001 Jan 16 16:06:34 europa kernel: options: [pci] [cardbus] [apm] Jan 16 16:06:34 europa kernel: PCI routing table version 1.0 at 0xfbd60 Jan 16 16:06:34 europa kernel: 00:03.0 -> irq 11 Jan 16 16:06:34 europa kernel: 00:03.1 -> irq 11 Jan 16 16:06:34 europa kernel: Intel PCIC probe: Jan 16 16:06:34 europa kernel: TI 1225 rev 01 PCI-to-CardBus at slot 00:03, me m 0x68000000 Jan 16 16:06:34 europa kernel: host opts [0]: [ring] [serial pci & irq] [pci irq 11] [lat 32/32] [bus 32/34] Jan 16 16:06:34 europa kernel: host opts [1]: [ring] [serial pci & irq] [pci irq 11] [lat 32/32] [bus 35/37] Jan 16 16:06:34 europa kernel: ISA irqs (scanned) = 3,4,7,9,10 PCI status ch anges Jan 16 16:06:34 europa pcmcia: cardmgr. Jan 16 16:06:34 europa rc: Starting pcmcia: succeeded Jan 16 16:06:34 europa cardmgr[512]: starting, version is 3.1.22 Jan 16 16:06:34 europa cardmgr[512]: watching 2 sockets Jan 16 16:06:34 europa kernel: cs: IO port probe 0x0c00-0x0cff: excluding 0xcf8- 0xcff Jan 16 16:06:34 europa kernel: cs: IO port probe 0x0800-0x08ff: excluding 0x800- 0x84f Jan 16 16:06:34 europa kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x378- 0x37f 0x4d0-0x4d7 Jan 16 16:06:34 europa kernel: cs: IO port probe 0x0a00-0x0aff: clean. Jan 16 16:06:35 europa kernel: cs: cb_alloc(bus 32): vendor 0x13d1, device 0xab0 2 Jan 16 16:06:35 europa cardmgr[512]: initializing socket 0 Jan 16 16:06:35 europa cardmgr[512]: socket 0: Linksys EtherFast PCM200 v2 Jan 16 16:06:35 europa cardmgr[512]: executing: 'modprobe cb_enabler' Jan 16 16:06:35 europa cardmgr[512]: executing: 'modprobe pci-scan' Jan 16 16:06:35 europa cardmgr[512]: executing: 'modprobe cb_shim' Jan 16 16:06:35 europa kernel: cb_shim.c:v1.00 4/15/2000 Donald Becker Jan 16 16:06:35 europa kernel: http://www.scyld.com/linux/drivers.html Jan 16 16:06:35 europa cardmgr[512]: executing: 'modprobe tulip' Jan 16 16:06:35 europa kernel: tulip.c:v0.92 4/17/2000 Written by Donald Becker Jan 16 16:06:35 europa kernel: http://www.scyld.com/network/tulip.html Jan 16 16:06:35 europa kernel: cs: cb_config(bus 32) Jan 16 16:06:35 europa kernel: fn 0 bar 1: io 0x200-0x2ff Jan 16 16:06:35 europa kernel: fn 0 bar 2: mem 0x60060000-0x600603ff Jan 16 16:06:35 europa kernel: fn 0 rom: mem 0x60040000-0x6005ffff Jan 16 16:06:35 europa kernel: irq 11 Jan 16 16:06:35 europa kernel: No driver match for device ab0213d1 at 32/0. Jan 16 16:06:35 europa cardmgr[512]: get dev info on socket 0 failed: No such de vice I grabbed a copy of tulip-diag and this is the output: [root@europa NewTulip]# ./tulip-diag tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a ADMtek AL985 Centaur (Linksys CardBus v2) adapter at 0x200. * A recognized chip has been found, but it does not appear to exist in * I/O space. Use the '-f' flag to see the register values anyway. Use '-a' or '-aa' to show device registers, '-e' to show EEPROM contents, -ee for parsed contents, or '-m' or '-mm' to show MII management registers. [root@europa NewTulip]# ./tulip-diag -f tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a ADMtek AL985 Centaur (Linksys CardBus v2) adapter at 0x200. Comet duplex is reported in the MII status registers. Transmit started, Receive started, full-duplex. The Rx process state is 'Transferring Rx frame into memory'. The Tx process state is 'Closing Tx descriptor'. PCI bus error!: Unknown 7. The transmit unit is set to store-and-forward. Interrupt sources are pending! CSR5 is ffffffff. Tx done indication. Tx complete indication. Tx out of buffers indication. Transmit Jabber indication. Link passed indication. Tx FIFO Underflow indication. Rx Done indication. Receiver out of buffers indication. Receiver stopped indication. Receiver jabber indication. Link changed indication. Timer expired indication. Link failed indication. PCI bus error indication. Early Rx indication. Comet MAC address registers ffffffff ffffffff Comet multicast filter ffffffffffffffff. WARNING: The EEPROM is missing or erased! Use '-a' or '-aa' to show device registers, '-e' to show EEPROM contents, -ee for parsed contents, or '-m' or '-mm' to show MII management registers. What am I doing wrong? I've read that people have got these cards to work ... Thanks, John Toman From becker@scyld.com Tue, 16 Jan 2001 21:41:26 -0500 (EST) Date: Tue, 16 Jan 2001 21:41:26 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Can't Get Linksys PCMPC200 V2 Working On Tue, 16 Jan 2001, John C. Toman wrote: > Date: Tue, 16 Jan 2001 16:27:18 -0800 > From: John C. Toman > To: tulip@scyld.com > Subject: [tulip] Can't Get Linksys PCMPC200 V2 Working > > Hi, > > I've got a brand new Linksys CardBus PCMPC200 V2 I'm trying to get > working on a RedHat 7.0 system. The kernel is 2.2.18 and I'm using > pcmcia-cs 3.1.22. I've followed the instructions on the web site to > correctly create and place the tulip driver in the correct area. I > think(?) I've done that right. Here's what my message log is saying: > Jan 16 16:06:35 europa kernel: tulip.c:v0.92 4/17/2000 Written by .... > Jan 16 16:06:35 europa kernel: No driver match for device ab0213d1 at 32/0. There are two similar IDs, and the driver must have both: In tulip.c { "ADMtek Centaur-C (Linksys v2)", { 0xab0213d1, 0xffffffff }, TULIP_IOTYPE, TULIP_SIZE1, COMET }, { "ADMtek Centaur-C (Linksys)", { 0xab0313d1, 0xffffffff }, TULIP_IOTYPE, TULIP_SIZE1, COMET }, In /etc/pcmcia/config.opts device "tulip" class "network" module "cb_enabler", "pci-scan", "cb_shim", "tulip" card "Linksys EtherFast 10/100" manfid 0x0149, 0x0231 bind "tulip" card "Linksys EtherFast 10/100 v2.0" manfid 0x0149, 0xc2ab bind "tulip" card "Linksys EtherFast PCM200 v2" manfid 0x13d1, 0xab02 bind "tulip" card "Linksys EtherFast PCM200" manfid 0x13d1, 0xab03 bind "tulip" The driver update from http://www.scyld.com/network/updates.html works, but I'm guessing that David will put the updates into his version RSN. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From jearle@nortelnetworks.com Tue, 16 Jan 2001 14:48:31 -0500 Date: Tue, 16 Jan 2001 14:48:31 -0500 From: Jonathan Earle jearle@nortelnetworks.com Subject: [tulip] Ethernet Bonding Performance under kernel 2.4.0 Hi all, I've a system comprosed of two PIII machines, equipped with Znyx 346Q 4port ethernet cards (tulip driver) which I'd like to connect together in a bonded configuration. For various reasons, we require 2.4.0 kernels on our machines - currently we are using 2.4.0-test9. The setup is simple: each port on a 346Q in one machine is connected to the corresponding port on the 346Q in the other machine via a crossover cable. +-------+ +-------+ | |------| | -----| Box A |------| Box B |----- | |------| | | |------| | +-------+ +-------+ Problem #1 ---------- Initally, after bootup, the performance of each of the four networks between the two PCs is subpar. Transfer rates will vary from a few hundred KB/s to perhaps a few MB/s, and the transfer time is appreciably long. This, on a forced 100TX-FD link. After a few minutes however, things appear to settle down, and I can achieve 11.2MB/s when transferring a large binary file via ftp (rate as reported by ncftp). The de4x5 driver shows the same behaviour. Problem #2 ---------- I built the bonding driver, and using a copy of ifenslave.c which I found for kernel 2.3.50, I was able to make a bonded channel. The trouble I found is that the performance was not at all what I expected. Using the first eth port, I achieved a throughput (FTP transfer of a large binary file) of 10.4 MB/s (11.2MB/s if set to full duplex). Using 2 ports, the performance dropped to about 3.5MB/s. Adding a third port brings the throughput to about 5.2MB/s and adding the fourth port only takes it up to 5.75MB/s. The de4x5 driver shows the same drop in performance as the tulip driver. Using the TEQL (trivial link equalizer) (instructions from the Adv-routing howto) provides the same measurements exactly. Thoughts? Cheers! Jon From astewart@world.std.com Tue, 16 Jan 2001 23:01:30 -0500 Date: Tue, 16 Jan 2001 23:01:30 -0500 From: Andy Stewart astewart@world.std.com Subject: [tulip] I can't make multiple tulips work properly. Hi everyone, The motherboard's automatic configuration of the PCI interrupts was somehow making choices which caused this error. By manually overriding those settings, I was able to get 2 Tulip based NICs to work in my system with kernel rev 2.2.18 and v0.92t of the driver. Thanks for the help! Andy -- Andy Stewart, Founder -o) | I predict that today will be remembered Worcester Linux Users' Group /\ | until tomorrow! Worcester, MA, USA _\_v | http://www.wlug.org | Donald Becker wrote: > > On Mon, 15 Jan 2001, root wrote: > > > I am using the 0.92t tulip driver loaded as a kernel module. I have > > tried this experiment with kernel revs 2.2.14 and 2.2.18 with similar > > results. > > > > 1) Install one Linksys card (tulip-diag reports it as a Digital DC21041 > > Tulip). Works great. Call this eth0. > > > > 2) Install 2nd Linksys card (tulip-diag reports this as an ADMtek AL985 > > Centaur-P but I call it a Linksys LNE100TX v4.1). This one is eth1. > > > > 3) 2nd Linksys card eth1 works great...but eth0 stopped working. Here > > is an excerpt from /var/log/messages: > > > > Jan 15 18:06:50 firewall kernel: eth0: 21041 media switched to 10baseT. > > Jan 15 18:06:52 firewall kernel: eth0: 21041 transmit timed out, status > > fc678057 > > Hmmm, looks like a simple IRQ problem. The chip is raising an > interrupt, but it isn't getting through the system. > > Check /proc/interrupts to confirm. > > > I can't fathom what I might have done wrong. Any help or suggestions > > would be greatly appreciated. > > Adding another card moved the interrupt assignments around. > > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters > Annapolis MD 21403 410-990-9993 From jctoman@compendium-tech.com Tue, 16 Jan 2001 21:06:39 -0800 Date: Tue, 16 Jan 2001 21:06:39 -0800 From: John C. Toman jctoman@compendium-tech.com Subject: [tulip] Can't Get Linksys PCMPC200 V2 Working Donald, I didn't realize there was a later version of your driver than on your tulip page... The updated driver in your rpm obviously includes the correct IDs, and I'm up and running now with that! Thanks for your help! John Donald Becker wrote: > On Tue, 16 Jan 2001, John C. Toman wrote: > >> Date: Tue, 16 Jan 2001 16:27:18 -0800 >> From: John C. Toman >> To: tulip@scyld.com >> Subject: [tulip] Can't Get Linksys PCMPC200 V2 Working >> >> Hi, >> >> I've got a brand new Linksys CardBus PCMPC200 V2 I'm trying to get >> working on a RedHat 7.0 system. The kernel is 2.2.18 and I'm using >> pcmcia-cs 3.1.22. I've followed the instructions on the web site to >> correctly create and place the tulip driver in the correct area. I >> think(?) I've done that right. Here's what my message log is saying: > >> Jan 16 16:06:35 europa kernel: tulip.c:v0.92 4/17/2000 Written by > > .... > >> Jan 16 16:06:35 europa kernel: No driver match for device ab0213d1 at 32/0. > > > There are two similar IDs, and the driver must have both: > In tulip.c > { "ADMtek Centaur-C (Linksys v2)", { 0xab0213d1, 0xffffffff }, > TULIP_IOTYPE, TULIP_SIZE1, COMET }, > { "ADMtek Centaur-C (Linksys)", { 0xab0313d1, 0xffffffff }, > TULIP_IOTYPE, TULIP_SIZE1, COMET }, > > In /etc/pcmcia/config.opts > device "tulip" class "network" module "cb_enabler", "pci-scan", "cb_shim", "tulip" > > card "Linksys EtherFast 10/100" manfid 0x0149, 0x0231 bind "tulip" > card "Linksys EtherFast 10/100 v2.0" manfid 0x0149, 0xc2ab bind "tulip" > card "Linksys EtherFast PCM200 v2" manfid 0x13d1, 0xab02 bind "tulip" > card "Linksys EtherFast PCM200" manfid 0x13d1, 0xab03 bind "tulip" > > > The driver update from > http://www.scyld.com/network/updates.html > works, but I'm guessing that David will put the updates into his version > RSN. > > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters > Annapolis MD 21403 410-990-9993 From jrc@art-render.com Wed, 17 Jan 2001 11:32:22 +0000 Date: Wed, 17 Jan 2001 11:32:22 +0000 From: John Connett jrc@art-render.com Subject: [tulip] v0.92 and NetPIPE 2.4 I have been conducting some performance tests on three flavours of tulip cards (Kingston KNE100TX; KNE110TX; KNE111TX) using NetPIPE 2.4 (http://www.scl.ameslab.gov/netpipe/). The tests used two systems connected back-to-back with a crossover cable. receiver: 533MHz Alpha 21164 running Red Hat 6.2 kernel 2.2.16-3 KNE100TX (Digital DS21140 Tulip rev 34) transmitter: 806MHz Intel PIII running Red Hat 6.2 kernel 2.2.16-3smp KNE100TX (Digital DS21140 Tulip rev 34) KNE110TX (Lite-On 82c168 PNIC rev 32) KNE111TX (Lite-On PNIC-II rev 37) On receiver I ran "mii-diag -A 0x0080 eth2" to restrict it to advertising 100baseTx-HD and ran the NetPIPE server with "NPtcp -r". On transmitter I ran: NPtcp -t -h receiver -u 1000000 -P -o Using the default Red Hat 6.2 driver ("tulip.c:91g-ppc 7/16/99 ...") produced reasonable results for all three cards. However, using the latest driver ("tulip.c:v0.92 4/17/2000 ...") on transmitter produced a very marked loss of performance (~66Mbit/s to ~0.6Mbit/s) for block sizes of 4093 bytes and above with the KNE110TX and KNE111TX. The KNE100TX appeared to stick trying to process a 4093 byte transfer. Can anyone shed some light on this behaviour? Any comments or suggestions would be gratefully received. I can supply further information if that would be helpful. -- John Connett (jrc@art-render.com) From jrc@art-render.com Thu, 18 Jan 2001 16:21:53 +0000 Date: Thu, 18 Jan 2001 16:21:53 +0000 From: John Connett jrc@art-render.com Subject: [tulip] Re: v0.92 and NetPIPE 2.4 Some more evidence to ponder over. It appeared possible that the root of the problem may have been the KNE100TX on the receiver system. To test this I replaced it with an EEPRO100 using the default Red Hat 6.2 driver (eepro100.c:v1.09j-t 9/29/99 ..., eth2: Intel PCI EtherExpress Pro100 82557). This ran NetPIPE without problems on the transmitter system with either the KNE110TX or KNE111TX and either of the v0.91g-ppc, v0.92, and v0.92t drivers. I then replaced the EEPRO100 on the receiver system with a 3C905C, again with the Red hat 6.2 default driver (3c59x.c:v0.99H 27May00 ..., eth2: 3Com 3c905C Tornado). With a KNE110TX on the transmitter system I again encountered the very marked loss of performance for block sizes of 4093 bytes and above with either of the v0.91g-ppc, v0.92, and v0.92t drivers. If the block size is restricted to less than 4093 bytes the contents of /proc/net/dev shows few errors. After a full run of NetPIPE /proc/net/dev contains the following: Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed eth1:307517474 917852 0 0 0 0 0 0 307811527 913203 36453 0 0 17883 36453 0 I suspect the high values of errs; colls; and carrier on the transmit side are related to the slow down! I have looked back through the archives and it appears that this problem with low performance with blocks around 4k and upwards has been encountered by others on anything from a cross over cable to large Beowulf clusters. However, I have not found a clear explanation (or fix) for the problem. Anyone care to enlighten me? Thanks in anticipation -- John Connett (jrc@art-render.com) From brian@chpc.utah.edu Thu, 18 Jan 2001 20:18:08 -0700 Date: Thu, 18 Jan 2001 20:18:08 -0700 From: Brian Haymore brian@chpc.utah.edu Subject: [tulip] Performance Issue with tulip driver in netdrivers-2.1.6 package I installed this netdriver set on our system and found that it had corrected a problem I have been seeing for a while where these newer versions of the tulip driver as found in the netdriver src rpm have been reading in the wrong MAC address from our Kingston KNE100TX cards. But performance has gone out the window now. With the previous release I was seeing 88 micro seconds of latency between two boxes over mpi and now I'm over 250 micro seconds with this newer version. Any ideas? -- Brian D. Haymore University of Utah Center for High Performance Computing 155 South 1452 East RM 405 Salt Lake City, Ut 84112-0190 Email: brian@chpc.utah.edu - Phone: (801) 585-1755 - Fax: (801) 585-5366 From brian@chpc.utah.edu Thu, 18 Jan 2001 20:22:03 -0700 Date: Thu, 18 Jan 2001 20:22:03 -0700 From: Brian Haymore brian@chpc.utah.edu Subject: [tulip] Oops... Please disregard that last message. Our networking people just found a problem with the new Cisco switch module these nodes are attached to. -- Brian D. Haymore University of Utah Center for High Performance Computing 155 South 1452 East RM 405 Salt Lake City, Ut 84112-0190 Email: brian@chpc.utah.edu - Phone: (801) 585-1755 - Fax: (801) 585-5366 From jrc@art-render.com Fri, 19 Jan 2001 15:19:13 +0000 Date: Fri, 19 Jan 2001 15:19:13 +0000 From: John Connett jrc@art-render.com Subject: [tulip] Re: v0.92 and NetPIPE 2.4 Some further evidence. I used the v0.92t driver with debug=3 on the transmitter and a 3Com 3c905C on the receiver. Here are the errors reported on the transmitter with each of the three cards: KNE100TX: eth1: Transmit error, Tx status 7fffb200 KNE110TX: eth1: Transmit error, Tx status 7fff8200 KNE111TX: eth1: Transmit error, Tx status 7fffb200 I've tried swapping the cross over cable which appears to make no difference. Please can someone venture an opinion as to the source of the problem? If the problem is with the receiver system I am open to suggestions for a good card/driver combination for card testing. Something that is stable over a wide range of operating conditions and can be persuaded to advertise particular media selections. Thanks in anticipation -- John Connett (jrc@art-render.com) From brucehyatt@mediaone.net Fri, 19 Jan 2001 19:57:49 -0500 Date: Fri, 19 Jan 2001 19:57:49 -0500 From: Bruce Hyatt brucehyatt@mediaone.net Subject: [tulip] DEC21041 & RH7 Sorry if this has been addressed. I've looked & looked & ............at HOWTOs, mail lists, etc. If I could get on the internet in Linux, problem solving would be so much easier. I have DEC21041 card & RH7 with 2.2.16 kernel trying to connect to AT&T broadband Roadrunner in eastern Massachusetts and I can't get the card to initialize(delayed). I've tried many settings of linuxconf. I've tried passing arguments to the kernel on boot. 1) Do I have the latest version of Tulip driver? 2) Is this an impossible project? Nearly Impossible? 3) Why can't I find conf.modules? 4) My ISP doesn't use a DNS and uses a dynamic IP. Is there ANY card that will work? 5) What info do I need if I select DHCP in linuxconf? 6) Windows shows my I/O as range; 0500-057F. How do I enter this in linuxconf? Thanks for indulging. From b@mighty.morphism.org Sat, 20 Jan 2001 15:21:13 -0600 (CST) Date: Sat, 20 Jan 2001 15:21:13 -0600 (CST) From: brian b@mighty.morphism.org Subject: [tulip] Cogent Quartet/400 multiport NIC problem. I know that questions of this nature have been addressed on this mailing list in the recent past, but none of them seem to really confront the kind of problems I've been having. I'm building a small-scale cluster and will be connecting four other machines to the Quartet/400 (4 x 21140 + 21050) via crossover cable. The problem is the machine locks up on issuing 'ifconfig' for any of the 2nd - 4th interfaces on the card. You can call "ifconfig eth0 10.1.0.1" and it will work properly. If you call any of "ifconfig eth1 ..." to "ifconfig eth3 ..." the machine will lock up. The BIOS is making the IRQ assignments of 11, 9, 10, 5 for eth0 through eth3 respectively. No APCI is compiled into the kernel. No APIC support is compiled in. The machine also has an RTL8139C based adapter. Here is some of the pertinent information: dmesg: Linux Tulip driver version 0.9.13 (January 2, 2001) eth0: Digital DS21140 Tulip rev 18 at 0xc000, 00:00:92:95:0C:00, IRQ 11. eth0: Old format EEPROM on 'Cogent EM100' board. Using substitute media control info. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media 100baseFx (#7) described by a 21140 non-MII (0) block. eth0: Index #1 - Media 100baseFx-FD (#8) described by a 21140 non-MII (0) block. eth0: Index #2 - Media 10baseT (#0) described by a 21140 non-MII (0) block. eth0: Index #3 - Media 10baseT-FD (#4) described by a 21140 non-MII (0) block. eth0: Index #4 - Media 100baseTx (#3) described by a 21140 non-MII (0) block. eth0: Index #5 - Media 100baseTx-FD (#5) described by a 21140 non-MII (0) block. eth1: Digital DS21140 Tulip rev 18 at 0xc400, EEPROM not present, 00:00:92:95:0C:01, IRQ 11. eth1: Old format EEPROM on 'Cogent EM100' board. Using substitute media control info. eth1: EEPROM default media type Autosense. eth1: Index #0 - Media 100baseFx (#7) described by a 21140 non-MII (0) block. eth1: Index #1 - Media 100baseFx-FD (#8) described by a 21140 non-MII (0) block. eth1: Index #2 - Media 10baseT (#0) described by a 21140 non-MII (0) block. eth1: Index #3 - Media 10baseT-FD (#4) described by a 21140 non-MII (0) block. eth1: Index #4 - Media 100baseTx (#3) described by a 21140 non-MII (0) block. eth1: Index #5 - Media 100baseTx-FD (#5) described by a 21140 non-MII (0) block. eth2: Digital DS21140 Tulip rev 18 at 0xc800, EEPROM not present, 00:00:92:95:0C:02, IRQ 11. eth2: Old format EEPROM on 'Cogent EM100' board. Using substitute media control info. eth2: EEPROM default media type Autosense. eth2: Index #0 - Media 100baseFx (#7) described by a 21140 non-MII (0) block. eth2: Index #1 - Media 100baseFx-FD (#8) described by a 21140 non-MII (0) block. eth2: Index #2 - Media 10baseT (#0) described by a 21140 non-MII (0) block. eth2: Index #3 - Media 10baseT-FD (#4) described by a 21140 non-MII (0) block. eth2: Index #4 - Media 100baseTx (#3) described by a 21140 non-MII (0) block. eth2: Index #5 - Media 100baseTx-FD (#5) described by a 21140 non-MII (0) block. eth3: Digital DS21140 Tulip rev 18 at 0xcc00, EEPROM not present, 00:00:92:95:0C:03, IRQ 11. eth3: Old format EEPROM on 'Cogent EM100' board. Using substitute media control info. eth3: EEPROM default media type Autosense. eth3: Index #0 - Media 100baseFx (#7) described by a 21140 non-MII (0) block. eth3: Index #1 - Media 100baseFx-FD (#8) described by a 21140 non-MII (0) block. eth3: Index #2 - Media 10baseT (#0) described by a 21140 non-MII (0) block. eth3: Index #3 - Media 10baseT-FD (#4) described by a 21140 non-MII (0) block. eth3: Index #4 - Media 100baseTx (#3) described by a 21140 non-MII (0) block. eth3: Index #5 - Media 100baseTx-FD (#5) described by a 21140 non-MII (0) block. 8139too Fast Ethernet driver 0.9.13 loaded PCI: Found IRQ 10 for device 00:0d.0 PCI: The same IRQ used for device 00:0f.0 eth4: RealTek RTL8139 Fast Ethernet at 0xe0800000, 00:50:ba:85:70:46, IRQ 10 eth4: Identified 8139 chip type 'RTL-8139B' I noticed that in earlier version of the driver, other people showed that it reported each interface was part of a multiport adapter, whereas this one does not. /proc/ioports c000-cfff : PCI Bus #02 c000-c07f : Digital Equipment Corporation DECchip 21140 [FasterNet] c000-c07f : eth0 c400-c47f : Digital Equipment Corporation DECchip 21140 [FasterNet] (#2) c400-c47f : eth1 c800-c87f : Digital Equipment Corporation DECchip 21140 [FasterNet] (#3) c800-c87f : eth2 cc00-cc7f : Digital Equipment Corporation DECchip 21140 [FasterNet] (#4) cc00-cc7f : eth3 /proc/pci Bus 0, device 11, function 0: PCI bridge: Digital Equipment Corporation DECchip 21050 (rev 2). Master Capable. Latency=32. Min Gnt=6. Bus 0, device 13, function 0: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 16). IRQ 10. Master Capable. Latency=32. Min Gnt=32.Max Lat=64. I/O at 0xe000 [0xe0ff]. Non-prefetchable 32 bit memory at 0xd5101000 [0xd51010ff]. Bus 2, device 4, function 0: Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 18). IRQ 11. Master Capable. Latency=32. I/O at 0xc000 [0xc07f]. Non-prefetchable 32 bit memory at 0xd5000000 [0xd500007f]. Bus 2, device 5, function 0: Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (#2) (rev 18). IRQ 9. Master Capable. Latency=32. I/O at 0xc400 [0xc47f]. Non-prefetchable 32 bit memory at 0xd5001000 [0xd500107f]. Bus 2, device 6, function 0: Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (#3) (rev 18). IRQ 10. Master Capable. Latency=32. I/O at 0xc800 [0xc87f]. Non-prefetchable 32 bit memory at 0xd5002000 [0xd500207f]. Bus 2, device 7, function 0: Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (#4) (rev 18). IRQ 5. Master Capable. Latency=32. I/O at 0xcc00 [0xcc7f]. Non-prefetchable 32 bit memory at 0xd5003000 [0xd500307f]. tulip-diag: tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21140 Tulip adapter at 0xc000. Digital DS21140 Tulip chip registers at 0xc000: 0x00: fff88000 ffffffff ffffffff 1ffc8000 1ffc8200 fc000106 e2840000 fffe0000 0x40: fffe0000 fffd97ff ffffffff fffe0000 ffffff81 ffffffff 1c09fdc0 fffffec8 Port selection is 100mbps-SYM/PCS, 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 64 words, 6 address bits. * 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. EEPROM contents (64 words): 0x00: 0000 9592 000c 2b31 312b 0c00 9295 0000 0x08: 0000 9592 000c 2b31 00ff aa55 00ff aa55 0x10: 0013 0000 9592 010c 2c31 312c 0c01 9295 0x18: 0000 0000 9592 010c 2c31 00ff aa55 00ff 0x20: aa55 0013 0000 9592 020c 2d31 312d 0c02 0x28: 9295 0000 0000 9592 020c 2d31 00ff aa55 0x30: 00ff aa55 0013 0000 9592 030c 2e31 312e 0x38: 0c03 9295 0000 0000 9592 030c 2e31 ffff ID block CRC 0x28 (vs. 00). Full contents CRC 0xecd3 (read as 0xffff). No MII transceivers found! Index #2: Found a Digital DS21140 Tulip adapter at 0xc400. Digital DS21140 Tulip chip registers at 0xc400: 0x00: fff80000 ffffffff ffffffff ffce3c8f af4ed76e fc000000 e2000040 fffe0000 0x40: fffe0000 fffd97ff ffffffff fffe0000 ffffff80 ffffffff 1c09fdc0 fffffec8 Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. EEPROM 64 words, 6 address bits. * 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. EEPROM contents (64 words): 0x00: 0000 0000 0000 0000 0000 0000 0000 0000 0x08: 0000 0000 0000 0000 0000 0000 0000 0000 0x10: 0000 0000 0000 0000 0000 0000 0000 0000 0x18: 0000 0000 0000 0000 0000 0000 0000 0000 0x20: 0000 0000 0000 0000 0000 0000 0000 0000 0x28: 0000 0000 0000 0000 0000 0000 0000 0000 0x30: 0000 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 0000 ID block CRC 0xe3 (vs. 00). Full contents CRC 0x6523 (read as 0x0000). No MII transceivers found! Index #3: Found a Digital DS21140 Tulip adapter at 0xc800. Digital DS21140 Tulip chip registers at 0xc800: 0x00: fff80000 ffffffff ffffffff cecd8dcf edcddfcf fc000000 e2000040 fffe0000 0x40: fffe0000 fffd97ff ffffffff fffe0000 ffffff80 ffffffff 1c09fdc0 fffffec8 Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. EEPROM 64 words, 6 address bits. * 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. EEPROM contents (64 words): 0x00: 0000 0000 0000 0000 0000 0000 0000 0000 0x08: 0000 0000 0000 0000 0000 0000 0000 0000 0x10: 0000 0000 0000 0000 0000 0000 0000 0000 0x18: 0000 0000 0000 0000 0000 0000 0000 0000 0x20: 0000 0000 0000 0000 0000 0000 0000 0000 0x28: 0000 0000 0000 0000 0000 0000 0000 0000 0x30: 0000 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 0000 ID block CRC 0xe3 (vs. 00). Full contents CRC 0x6523 (read as 0x0000). No MII transceivers found! Index #4: Found a Digital DS21140 Tulip adapter at 0xcc00. Digital DS21140 Tulip chip registers at 0xcc00: 0x00: fff80000 ffffffff ffffffff edbade87 6ffeaafe fc000000 e2000040 fffe0000 0x40: fffe0000 fffd97ff ffffffff fffe0000 ffffff80 ffffffff 1c09fdc0 fffffec8 Port selection is 10mpbs-serial, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. EEPROM 64 words, 6 address bits. * 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. EEPROM contents (64 words): 0x00: 0000 0000 0000 0000 0000 0000 0000 0000 0x08: 0000 0000 0000 0000 0000 0000 0000 0000 0x10: 0000 0000 0000 0000 0000 0000 0000 0000 0x18: 0000 0000 0000 0000 0000 0000 0000 0000 0x20: 0000 0000 0000 0000 0000 0000 0000 0000 0x28: 0000 0000 0000 0000 0000 0000 0000 0000 0x30: 0000 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 0000 ID block CRC 0xe3 (vs. 00). Full contents CRC 0x6523 (read as 0x0000). No MII transceivers found! I think that is all the information that you could possibly want. Has this specifically been addressed before? All the problems I've heard of haven't resulted in machine lockup, but rather simply no activity occuring over the line. Thanks, Brian From b@mighty.morphism.org Sat, 20 Jan 2001 16:17:55 -0600 (CST) Date: Sat, 20 Jan 2001 16:17:55 -0600 (CST) From: brian b@mighty.morphism.org Subject: [tulip] Cogent Quartet/400 multiport NIC problem. On an additional note, it _does_ work with 0.92t on 2.2.18. Do you think this is a fixable problem with respect to the 2.4.0 driver development? Brian > I know that questions of this nature have been addressed on this mailing > list in the recent past, but none of them seem to really confront the kind > of problems I've been having. > > I'm building a small-scale cluster and will be connecting four other > machines to the Quartet/400 (4 x 21140 + 21050) via crossover cable. The > problem is the machine locks up on issuing 'ifconfig' for any of the 2nd - > 4th interfaces on the card. You can call "ifconfig eth0 10.1.0.1" and it > will work properly. If you call any of "ifconfig eth1 ..." to "ifconfig > eth3 ..." the machine will lock up. From dkturner@qwest.net Sun, 21 Jan 2001 12:15:03 -0800 Date: Sun, 21 Jan 2001 12:15:03 -0800 From: Dave Turner dkturner@qwest.net Subject: [tulip] maybe its me, but I can't seem to get tulip.c to compile Hi I'm trying to compile tulip.c to address the "skbuff" problems I've been having. Hopefully I can fix the relative flakiness of this particular card. Here is the relevant info. tulip.c version: "tulip.c:v0.92t 1/15/2001 Written by Donald Becker \n"; The NIC is a Linksys LNE100TX if it makes a difference. I believe I have all the necessary files in place: [root@dave modules]# ls -al total 256 drwxr-xr-x 2 root root 4096 Jan 15 11:26 ./ drwxr-x--x 5 root adm 4096 Jan 13 19:19 ../ -rw-r--r-- 1 root root 6219 Nov 7 23:20 kern_compat.h -rw-r--r-- 1 root root 14194 Jan 13 19:23 pci-scan.c -rw-r--r-- 1 root root 2979 Oct 5 03:51 pci-scan.h -rwxr-xr-x 1 root root 40004 Jan 13 19:35 tulip-diag* -rw-r--r-- 1 root root 54555 Jan 13 19:33 tulip-diag.c -rw-r--r-- 1 root root 117420 Jan 15 11:25 tulip.c [root@dave modules]# here is the make command I'm using: gcc -DMODULE -Wall -Wstrict-prototypes -O6 -c tulip.c here's the last portion of the compile: /usr/include/linux/fs.h:1011: parse error before `size_t' /usr/include/linux/fs.h:1011: warning: data definition has no type or storage cl ass /usr/include/linux/fs.h:1014: parse error before `char_write' /usr/include/linux/fs.h:1014: parse error before `size_t' /usr/include/linux/fs.h:1014: warning: data definition has no type or storage cl ass /usr/include/linux/fs.h:1015: parse error before `block_write_Rf47c2311' /usr/include/linux/fs.h:1015: parse error before `size_t' /usr/include/linux/fs.h:1015: warning: data definition has no type or storage cl ass /usr/include/linux/fs.h: In function `make_shadow_writable': /usr/include/linux/fs.h:1028: dereferencing pointer to incomplete type /usr/include/linux/fs.h:1028: dereferencing pointer to incomplete type /usr/include/linux/fs.h:1029: dereferencing pointer to incomplete type /usr/include/linux/fs.h:1030: dereferencing pointer to incomplete type /usr/include/linux/fs.h:1030: dereferencing pointer to incomplete type In file included from /usr/include/linux/tty.h:24, from /usr/include/linux/sched.h:21, from /usr/include/linux/mm.h:4, from /usr/include/linux/slab.h:14, from /usr/include/linux/malloc.h:4, from tulip.c:148: /usr/include/linux/tty_driver.h: At top level: /usr/include/linux/tty_driver.h:169: parse error before `off_t' In file included from /usr/include/linux/tty.h:25, from /usr/include/linux/sched.h:21, from /usr/include/linux/mm.h:4, from /usr/include/linux/slab.h:14, from /usr/include/linux/malloc.h:4, from tulip.c:148: /usr/include/linux/tty_ldisc.h:114: parse error before `ssize_t' /usr/include/linux/tty_ldisc.h:114: warning: no semicolon at end of struct or un ion /usr/include/linux/tty_ldisc.h:115: parse error before `*' /usr/include/linux/tty_ldisc.h:116: parse error before `size_t' /usr/include/linux/tty_ldisc.h:116: `ssize_t' declared as function returning a f unction /usr/include/linux/tty_ldisc.h:116: warning: data definition has no type or stor age class /usr/include/linux/tty_ldisc.h:117: parse error before `*' /usr/include/linux/tty_ldisc.h:118: parse error before `size_t' /usr/include/linux/tty_ldisc.h:118: `ssize_t' declared as function returning a f unction /usr/include/linux/tty_ldisc.h:118: warning: data definition has no type or stor age class /usr/include/linux/tty_ldisc.h:120: conflicting types for `ioctl' /usr/include/linux/fs.h:630: previous declaration of `ioctl' /usr/include/linux/tty_ldisc.h:123: conflicting types for `poll' /usr/include/linux/fs.h:629: previous declaration of `poll' /usr/include/linux/tty_ldisc.h:132: parse error before `}' In file included from /usr/include/linux/sched.h:21, from /usr/include/linux/mm.h:4, from /usr/include/linux/slab.h:14, from /usr/include/linux/malloc.h:4, from tulip.c:148: /usr/include/linux/tty.h:262: field `ldisc' has incomplete type In file included from /usr/include/linux/sched.h:22, from /usr/include/linux/mm.h:4, from /usr/include/linux/slab.h:14, from /usr/include/linux/malloc.h:4, from tulip.c:148: /usr/include/linux/sem.h:108: parse error before `key' In file included from /usr/include/linux/signal.h:4, from /usr/include/linux/sched.h:23, from /usr/include/linux/mm.h:4, from /usr/include/linux/slab.h:14, from /usr/include/linux/malloc.h:4, from tulip.c:148: /usr/include/asm/signal.h:173: parse error before `size_t' /usr/include/asm/signal.h:173: warning: no semicolon at end of struct or union /usr/include/asm/signal.h:174: warning: data definition has no type or storage c lass In file included from /usr/include/linux/signal.h:5, from /usr/include/linux/sched.h:23, from /usr/include/linux/mm.h:4, from /usr/include/linux/slab.h:14, from /usr/include/linux/malloc.h:4, from tulip.c:148: /usr/include/asm/siginfo.h:26: parse error before `pid_t' /usr/include/asm/siginfo.h:26: warning: no semicolon at end of struct or union /usr/include/asm/siginfo.h:26: warning: no semicolon at end of struct or union /usr/include/asm/siginfo.h:27: warning: no semicolon at end of struct or union /usr/include/asm/siginfo.h:28: warning: data definition has no type or storage c lass /usr/include/asm/siginfo.h:38: parse error before `pid_t' /usr/include/asm/siginfo.h:38: warning: no semicolon at end of struct or union /usr/include/asm/siginfo.h:39: warning: data definition has no type or storage c lass /usr/include/asm/siginfo.h:41: parse error before `}' /usr/include/asm/siginfo.h:41: warning: data definition has no type or storage c lass /usr/include/asm/siginfo.h:45: parse error before `pid_t' /usr/include/asm/siginfo.h:45: warning: no semicolon at end of struct or union /usr/include/asm/siginfo.h:46: warning: data definition has no type or storage c lass /usr/include/asm/siginfo.h:48: parse error before `_utime' /usr/include/asm/siginfo.h:48: warning: data definition has no type or storage c lass /usr/include/asm/siginfo.h:49: parse error before `_stime' /usr/include/asm/siginfo.h:49: warning: data definition has no type or storage c lass /usr/include/asm/siginfo.h:50: warning: data definition has no type or storage c lass /usr/include/asm/siginfo.h:62: parse error before `}' /usr/include/asm/siginfo.h:62: warning: data definition has no type or storage c lass /usr/include/asm/siginfo.h:63: parse error before `}' /usr/include/asm/siginfo.h:63: warning: data definition has no type or storage c lass In file included from /usr/include/linux/sched.h:23, from /usr/include/linux/mm.h:4, from /usr/include/linux/slab.h:14, from /usr/include/linux/malloc.h:4, from tulip.c:148: /usr/include/linux/signal.h:15: parse error before `siginfo_t' /usr/include/linux/signal.h:15: warning: no semicolon at end of struct or union In file included from /usr/include/linux/sched.h:71, from /usr/include/linux/mm.h:4, from /usr/include/linux/slab.h:14, from /usr/include/linux/malloc.h:4, from tulip.c:148: /usr/include/linux/resource.h:22: field `ru_utime' has incomplete type /usr/include/linux/resource.h:23: field `ru_stime' has incomplete type In file included from /usr/include/linux/mm.h:4, from /usr/include/linux/slab.h:14, from /usr/include/linux/malloc.h:4, from tulip.c:148: /usr/include/linux/sched.h:137: parse error before `fd_set' /usr/include/linux/sched.h:137: warning: no semicolon at end of struct or union /usr/include/linux/sched.h:138: warning: data definition has no type or storage class /usr/include/linux/sched.h:139: parse error before `close_on_exec_init' /usr/include/linux/sched.h:139: warning: data definition has no type or storage class /usr/include/linux/sched.h:140: parse error before `open_fds_init' /usr/include/linux/sched.h:140: warning: data definition has no type or storage class /usr/include/linux/sched.h:142: parse error before `}' /usr/include/linux/sched.h:262: parse error before `pid_t' /usr/include/linux/sched.h:262: warning: no semicolon at end of struct or union /usr/include/linux/sched.h:263: warning: data definition has no type or storage class /usr/include/linux/sched.h:264: parse error before `tty_old_pgrp' /usr/include/linux/sched.h:264: warning: data definition has no type or storage class /usr/include/linux/sched.h:265: parse error before `session' /usr/include/linux/sched.h:265: warning: data definition has no type or storage class /usr/include/linux/sched.h:293: parse error before `:' /usr/include/linux/sched.h:295: warning: data definition has no type or storage class /usr/include/linux/sched.h:296: parse error before `gid' /usr/include/linux/sched.h:296: warning: data definition has no type or storage class /usr/include/linux/sched.h:298: parse error before `groups' /usr/include/linux/sched.h:298: warning: data definition has no type or storage class /usr/include/linux/sched.h:328: parse error before `sas_ss_size' /usr/include/linux/sched.h:328: warning: data definition has no type or storage class /usr/include/linux/sched.h:336: parse error before `}' /usr/include/linux/sched.h:408: field `task' has incomplete type /usr/include/linux/sched.h: In function `hash_pid': /usr/include/linux/sched.h:448: dereferencing pointer to incomplete type /usr/include/linux/sched.h:448: dereferencing pointer to incomplete type /usr/include/linux/sched.h:450: dereferencing pointer to incomplete type /usr/include/linux/sched.h:451: dereferencing pointer to incomplete type /usr/include/linux/sched.h:451: dereferencing pointer to incomplete type /usr/include/linux/sched.h:453: dereferencing pointer to incomplete type /usr/include/linux/sched.h: In function `unhash_pid': /usr/include/linux/sched.h:458: dereferencing pointer to incomplete type /usr/include/linux/sched.h:459: dereferencing pointer to incomplete type /usr/include/linux/sched.h:459: dereferencing pointer to incomplete type /usr/include/linux/sched.h:460: dereferencing pointer to incomplete type /usr/include/linux/sched.h:460: dereferencing pointer to incomplete type /usr/include/linux/sched.h: In function `find_task_by_pid': /usr/include/linux/sched.h:467: dereferencing pointer to incomplete type /usr/include/linux/sched.h:467: dereferencing pointer to incomplete type In file included from /usr/include/linux/mm.h:4, from /usr/include/linux/slab.h:14, from /usr/include/linux/malloc.h:4, from tulip.c:148: /usr/include/linux/sched.h: At top level: /usr/include/linux/sched.h:510: parse error before `grp' /usr/include/linux/sched.h:511: parse error before `grp' /usr/include/linux/sched.h:515: parse error before `siginfo_t' /usr/include/linux/sched.h:518: parse error before `pid_t' /usr/include/linux/sched.h:519: parse error before `pid_t' /usr/include/linux/sched.h:520: parse error before `pid_t' /usr/include/linux/sched.h:525: parse error before `int' /usr/include/linux/sched.h:526: parse error before `int' /usr/include/linux/sched.h:527: parse error before `int' /usr/include/linux/sched.h:530: parse error before `*' /usr/include/linux/sched.h: In function `signal_pending': /usr/include/linux/sched.h:534: dereferencing pointer to incomplete type /usr/include/linux/sched.h:535: warning: control reaches end of non-void functio n /usr/include/linux/sched.h: In function `recalc_sigpending_R57723815': /usr/include/linux/sched.h:549: dereferencing pointer to incomplete type /usr/include/linux/sched.h:549: dereferencing pointer to incomplete type /usr/include/linux/sched.h:552: dereferencing pointer to incomplete type /usr/include/linux/sched.h:552: dereferencing pointer to incomplete type /usr/include/linux/sched.h:553: dereferencing pointer to incomplete type /usr/include/linux/sched.h:553: dereferencing pointer to incomplete type /usr/include/linux/sched.h:554: dereferencing pointer to incomplete type /usr/include/linux/sched.h:554: dereferencing pointer to incomplete type /usr/include/linux/sched.h:555: dereferencing pointer to incomplete type /usr/include/linux/sched.h:555: dereferencing pointer to incomplete type /usr/include/linux/sched.h:558: dereferencing pointer to incomplete type /usr/include/linux/sched.h:558: dereferencing pointer to incomplete type /usr/include/linux/sched.h:559: dereferencing pointer to incomplete type /usr/include/linux/sched.h:559: dereferencing pointer to incomplete type /usr/include/linux/sched.h:562: dereferencing pointer to incomplete type /usr/include/linux/sched.h:562: dereferencing pointer to incomplete type /usr/include/linux/sched.h:565: dereferencing pointer to incomplete type /usr/include/linux/sched.h: In function `on_sig_stack': /usr/include/linux/sched.h:572: dereferencing pointer to incomplete type /usr/include/linux/sched.h:573: dereferencing pointer to incomplete type /usr/include/linux/sched.h:573: dereferencing pointer to incomplete type /usr/include/linux/sched.h:574: warning: control reaches end of non-void functio n /usr/include/linux/sched.h: In function `sas_ss_flags': /usr/include/linux/sched.h:578: dereferencing pointer to incomplete type /usr/include/linux/sched.h:580: warning: control reaches end of non-void functio n /usr/include/linux/sched.h: In function `suser': /usr/include/linux/sched.h:605: dereferencing pointer to incomplete type /usr/include/linux/sched.h:606: dereferencing pointer to incomplete type /usr/include/linux/sched.h: In function `fsuser': /usr/include/linux/sched.h:614: dereferencing pointer to incomplete type /usr/include/linux/sched.h:615: dereferencing pointer to incomplete type /usr/include/linux/sched.h: In function `capable': /usr/include/linux/sched.h:630: dereferencing pointer to incomplete type /usr/include/linux/sched.h:635: dereferencing pointer to incomplete type /usr/include/linux/sched.h: At top level: /usr/include/linux/sched.h:660: parse error before `*' /usr/include/linux/sched.h:660: warning: data definition has no type or storage class /usr/include/linux/sched.h:662: parse error before `*' /usr/include/linux/sched.h: In function `expand_files': /usr/include/linux/sched.h:673: dereferencing pointer to incomplete type /usr/include/linux/sched.h:678: dereferencing pointer to incomplete type In file included from /usr/include/linux/slab.h:14, from /usr/include/linux/malloc.h:4, from tulip.c:148: /usr/include/linux/mm.h: At top level: /usr/include/linux/mm.h:101: parse error before `size_t' /usr/include/linux/mm.h:102: parse error before `size_t' /usr/include/linux/mm.h:103: parse error before `size_t' /usr/include/linux/mm.h:104: parse error before `size_t' /usr/include/linux/mm.h:322: parse error before `size_t' /usr/include/linux/mm.h: In function `expand_stack': /usr/include/linux/mm.h:381: dereferencing pointer to incomplete type /usr/include/linux/mm.h:382: dereferencing pointer to incomplete type /usr/include/linux/mm.h:384: dereferencing pointer to incomplete type In file included from /usr/include/linux/malloc.h:4, from tulip.c:148: /usr/include/linux/slab.h: At top level: /usr/include/linux/slab.h:50: warning: parameter names (without types) in functi on declaration /usr/include/linux/slab.h:51: parse error before `size_t' /usr/include/linux/slab.h:52: `kmem_cache_create_Rd1c0b4e6' declared as function returning a function /usr/include/linux/slab.h:53: parse error before `void' /usr/include/linux/slab.h:59: parse error before `int' /usr/include/linux/slab.h:61: parse error before `size_t' In file included from /usr/include/linux/netdevice.h:133, from tulip.c:151: /usr/include/linux/skbuff.h:44: field `stamp' has incomplete type In file included from tulip.c:151: /usr/include/linux/netdevice.h:371: parse error before `off_t' /usr/include/linux/netdevice.h: In function `dev_lock_wait': /usr/include/linux/netdevice.h:413: dereferencing pointer to incomplete type In file included from /usr/include/linux/vmalloc.h:7, from /usr/include/asm/io.h:102, from tulip.c:156: /usr/include/asm/pgtable.h: In function `flush_tlb_mm': /usr/include/asm/pgtable.h:60: dereferencing pointer to incomplete type /usr/include/asm/pgtable.h: In function `flush_tlb_page': /usr/include/asm/pgtable.h:67: dereferencing pointer to incomplete type /usr/include/asm/pgtable.h: In function `flush_tlb_range': /usr/include/asm/pgtable.h:74: dereferencing pointer to incomplete type /usr/include/asm/pgtable.h: In function `set_pgdir': /usr/include/asm/pgtable.h:558: dereferencing pointer to incomplete type /usr/include/asm/pgtable.h:559: dereferencing pointer to incomplete type /usr/include/asm/pgtable.h:561: dereferencing pointer to incomplete type tulip.c: In function `strnlen': /usr/include/asm/string.h:392: warning: `__res' might be used uninitialized in t his function tulip.c: At top level: /usr/include/linux/coda.h:261: storage size of `va_atime' isn't known /usr/include/linux/coda.h:262: storage size of `va_mtime' isn't known /usr/include/linux/coda.h:263: storage size of `va_ctime' isn't known /usr/include/linux/coda.h:563: storage size of `attr' isn't known /usr/include/linux/fs.h:444: storage size of `f_owner' isn't known /usr/include/linux/reiserfs_fs_sb.h:188: storage size of `j_journal_list' isn't known /usr/include/linux/sched.h:288: storage size of `times' isn't known [root@dave modules]# I've gotten the tulip.c to compile before but it was the version written in April of 2000. Maybe I'm doing something wrong now . . . I'm not sure. Any tips or advice is appreciated. thanks Dave From L.Szychowski@securegate.net Mon, 22 Jan 2001 15:55:10 +1100 Date: Mon, 22 Jan 2001 15:55:10 +1100 From: Leszek Szychowski L.Szychowski@securegate.net Subject: [tulip] Starfire kernel rpm build. I'm hoping to build a new kernel rpm with the starfire driver (which is not included as standard) for automatic CDROM installs. 1. How do I add the Starfire driver as an option under make menuconfig (config). ? Hand cranking all the required files for this to happen is an ugly option. Does anyone have an easier method? I'm compiling under RH 2.2.16-3 using 'rpm -ba --target-i686 SPEC/kernel-2.2.16-3.spec' This automatically extracts linux BUILD root directory/files from the original linux-2.2.16.tar.gz and adds patches plus builds a new kernel rpm. I guess I could recreate a new gz image with the right netdriver files, but how to link Starfire into the kernel has me a bit confused. Any suggestions would be appreciated. Regards --------------------------------------------- Leszek A Szychowski Product Development Manager - Engineering 90east (Asia Pacific) Pty Ltd Canberra ACT 2609, Australia Tel: (61 2) 6283 1731, Fax: (61 2) 6283 1701 Mob: 0404067265 Email: From L.Szychowski@securegate.net Mon, 22 Jan 2001 20:58:39 +1100 Date: Mon, 22 Jan 2001 20:58:39 +1100 From: Leszek Szychowski L.Szychowski@securegate.net Subject: [tulip] Loading starfire driver gives Transmit timed out: Status 0050 Guys, I have managed to compile the Starfire driver and pci-scan under RH kernel 2.2.16-3, however I now get console error output. Transmit timed out: Status 0050 Dmesg reports eth2: 0 00001a0000 " eth2: 30 00000000 eth2: Printing Rx ring (next to recieve into 0) RX ring entry 0 00000001 " RX ring entry 30 00000001 Anyone seen this before. PS. I'm now trying the recompile using 2048 as a native ring size. --------------------------------------------- Leszek A Szychowski Product Development Manager - Engineering 90east (Asia Pacific) Pty Ltd Canberra ACT 2609, Australia Tel: (61 2) 6283 1731, Fax: (61 2) 6283 1701 Mob: 0404067265 Email: From clifto@clifto.com Mon, 22 Jan 2001 08:48:39 -0600 Date: Mon, 22 Jan 2001 08:48:39 -0600 From: Clifton T. Sharp Jr. clifto@clifto.com Subject: [tulip] maybe its me, but I can't seem to get tulip.c to compile Dave Turner wrote: > /usr/include/linux/fs.h:1011: parse error before `size_t' I got errors like this with numerous programs on my nephew's system, programs that compiled fine on mine. I finally persuaded him to update his compiler package, and I no longer have to wrestle with these. -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cliff Sharp | Hate spam? Take the Boulder Pledge! | | WA9PDM | http://www.zdnet.com/yil/content/mag/9612/ebert9612.html | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From dkturner@qwest.net Mon, 22 Jan 2001 09:15:30 -0800 Date: Mon, 22 Jan 2001 09:15:30 -0800 From: Dave Turner dkturner@qwest.net Subject: [tulip] RE: maybe it's me Clifto wrote: *** Message: 4 Date: Mon, 22 Jan 2001 08:48:39 -0600 From: "Clifton T. Sharp Jr." Organization: as little as possible To: tulip@scyld.com Subject: Re: [tulip] maybe its me, but I can't seem to get tulip.c to compile Dave Turner wrote: > /usr/include/linux/fs.h:1011: parse error before `size_t' I got errors like this with numerous programs on my nephew's system, programs that compiled fine on mine. I finally persuaded him to update his compiler package, and I no longer have to wrestle with these. *** Thanks Clifton - I'll see if updates are available for my version. I'm running Mandrake 7.2 so one would *think* they have the latest version included, but who knows. The Mandrake team have started doing some strange things since version 7.0 came out and I'm less and less happy with them and their distribution. I'll give it a shot. Dave From jrc@art-render.com Mon, 22 Jan 2001 17:47:19 +0000 Date: Mon, 22 Jan 2001 17:47:19 +0000 From: John Connett jrc@art-render.com Subject: [tulip] PNIC-II advertisement register read only? I have a Kingston KNE111TX which reports itself as follows: tulip.c:v0.92t 1/15/2001 Written by Donald Becker http://www.scyld.com/network/tulip.html eth1: Lite-On LC82C115 PNIC-II rev 37 at 0xf083af00, 00:0C:F0:76:C1:74, IRQ 17 Attempts to set the advertisement register using: mii-diag -A 0x00A0 eth1 have been unsuccessful. The advertisement register stays set at 0x03E1. Is the advertisement register read only for these cards? Can anyone point me to an online specification for the PNIC-II? Thanks in anticipation -- John Connett (jrc@art-render.com) From patrickdk@usa.net Mon, 22 Jan 2001 19:01:35 -0500 Date: Mon, 22 Jan 2001 19:01:35 -0500 From: Patrick Domack patrickdk@usa.net Subject: [tulip] Natsemi.c driver Multicast hash problem This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C084A5.BDFE3E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I know this isn't the right mailing list, but I didn't find any that = would be more correct. My netgear with the dp83815 chipset, won't recieve multicast packets = correctly. It seems to me the problem is in the multicast hash table, though, I = can't track it down myself. If the card is set to promisc or to allmulti, it works fine. When the card is setup for hashed multicast, the rx mode is set for = 0xc8200000. This is the Rx Multicast hash table: 0000 0000 0000 0000 0000 2000 0000 0000 0000 0000 0000 0000 0000 0000 = 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 = 0080 4000 for the moment I'm using allmulti to correct this problem, as a temp = fix. thanks ------=_NextPart_000_0007_01C084A5.BDFE3E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I know this isn't the right mailing = list, but I=20 didn't find any that would be more correct.
 
My netgear with the dp83815 chipset, = won't recieve=20 multicast packets correctly.
It seems to me the problem is in the = multicast hash=20 table, though, I can't track it down myself.
If the card is set to promisc or to = allmulti, it=20 works fine.
When the card is setup for hashed = multicast, the rx=20 mode is set for 0xc8200000.
This is the Rx Multicast hash = table:
  0000 0000 0000 0000 0000 2000 = 0000 0000 0000=20 0000 0000 0000 0000 0000 0000 0000
  0000 0000 0000 0000 0000 0000 = 0000 0000 0000=20 0000 0000 0000 0000 0000 0080 4000
 
 
for the moment I'm using allmulti to = correct this=20 problem, as a temp fix. thanks
 
------=_NextPart_000_0007_01C084A5.BDFE3E00-- From mondshein2000@mediaone.net Mon, 22 Jan 2001 23:44:56 -0500 Date: Mon, 22 Jan 2001 23:44:56 -0500 From: Lee Mondshein mondshein2000@mediaone.net Subject: [tulip] Problem with insmod tulip -- Device or resource busy This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C084CD.52F628C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear fellow/sister enthusiasts:=20 I hope this posting is appropriately addressed. I am running Linux = 2.2.12-20 and am attempting to configure a LAN using Linksys' Combo = PCMIA Ethernet card (EC2T). I have configured meticulously, per = instructions in HOW-TOs and Linux texts. My NIC fails to be recognized = during boot. Moreover, attempts to load tulip fail. The following will give a good sense of my current status: >modprobe -c alias eth0 tulip >modprobe eth0 /lib/modules/2.2.12-20 /net/tulip.o: init_module: Device or resource = busy >ifconfig eth0 192.168.0.1=20 SIOCSIFADDR: No such device eth0: unknown interface: No such device >lsmod lp parport memory_os ds i82365 pcmcia_card > /etc/rc.d/init.d/network start Bringing up interface lo Bringing up interface eth0. Delaying eth0 initialization [FAILED] Before I go about installing a new version of tulip, do the above = results suggest I may have a problem unrelated to the currency of the = tulip driver. For example, I previously attempted to configure my = machine with an entirely different Linksys NIC, which I tried to = associate with tulip; could that have caused confusion in the driver's = ability to recognize my current NIC. Having read through innumerable mailing list entries on topic, I would = much appreciate any guidance. Lee ------=_NextPart_000_000D_01C084CD.52F628C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear fellow/sister enthusiasts:
 
I hope this posting is appropriately addressed. I am = running=20 Linux 2.2.12-20 and am attempting to configure a LAN using = Linksys'  Combo=20 PCMIA Ethernet card (EC2T).  I have configured meticulously, = per=20 instructions in HOW-TOs and Linux texts. My NIC fails to be recognized = during=20 boot. Moreover, attempts to load tulip fail.
 
The following will give a good sense of my current=20 status:
 
>modprobe -c
alias eth0 tulip
 
>modprobe eth0
/lib/modules/2.2.12-20 /net/tulip.o: init_module: = Device or=20 resource busy
 
>ifconfig eth0 192.168.0.1
SIOCSIFADDR: No such device
eth0: unknown interface: No such device
 
>lsmod
lp
parport
memory_os
ds
i82365
pcmcia_card
 
> /etc/rc.d/init.d/network   = start
Bringing up interface lo
Bringing up interface eth0.  Delaying eth0=20 initialization
          &nbs= p;            = ;            =              = [FAILED]
 
Before I go about installing a new version of tulip, = do the=20 above results suggest I may have a problem unrelated to the currency of = the=20 tulip driver.   For example, I previously attempted to = configure my=20 machine with an entirely different Linksys NIC, which I tried to = associate with=20 tulip;  could that have caused confusion in the driver's ability to = recognize my current NIC.
 
Having read through innumerable mailing list entries = on topic,=20 I would much appreciate any guidance.
 
Lee
------=_NextPart_000_000D_01C084CD.52F628C0-- From becker@scyld.com Tue, 23 Jan 2001 00:38:08 -0500 (EST) Date: Tue, 23 Jan 2001 00:38:08 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Natsemi.c driver Multicast hash problem On Mon, 22 Jan 2001, Patrick Domack wrote: > I know this isn't the right mailing list, but I didn't find any that > would be more correct. > > My netgear with the dp83815 chipset, won't recieve multicast packets > correctly. > It seems to me the problem is in the multicast hash table, though, I > can't track it down myself. > If the card is set to promisc or to allmulti, it works fine. You are correct. That's a symptom of a screwed up multicast filter. Which driver version are you using? The v1.07 driver made a change in how the multicast filter is configured. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From becker@scyld.com Tue, 23 Jan 2001 00:42:00 -0500 (EST) Date: Tue, 23 Jan 2001 00:42:00 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Problem with insmod tulip -- Device or resource busy On Mon, 22 Jan 2001, Lee Mondshein wrote: > I hope this posting is appropriately addressed. I am running Linux > 2.2.12-20 and am attempting to configure a LAN using Linksys' Combo > PCMIA Ethernet card (EC2T). Is that a PCMCIA (16 bit) card or a CardBus (32 bit) card? I suspect that it's a PCMCIA card. If so, it doesn't use the Tulip driver. > >modprobe eth0 > /lib/modules/2.2.12-20 /net/tulip.o: init_module: Device or resource busy The PCMCIA control system will load the proper module for you. It cannot be done by hand, since the mapping registers must be configured first. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From patrickdk@usa.net Tue, 23 Jan 2001 07:22:51 -0500 Date: Tue, 23 Jan 2001 07:22:51 -0500 From: Patrick Domack patrickdk@usa.net Subject: [tulip] netsemi.c milticast hash problem Opps, meant to include that infomation in my last post. Well I was using driver version 1.05b when I first noticed the problem, and then I updated it to 1.07 and it didn't fix it. I looked at the source myself last night, and the national semiconductors datasheets and can't find anything wrong with it myself, though the datasheet didn't give the crc routines they where using. From haplo@wwa.com Tue, 23 Jan 2001 22:04:25 -0600 Date: Tue, 23 Jan 2001 22:04:25 -0600 From: Bryan Burns haplo@wwa.com Subject: [tulip] Netgear FA310TX I have a bit of a problem. I am setting up a Beowulf cluster at my school (Illinois State University) and cannot get the Netgear cards to work, here is my setup: Pentium 200mhz (HP Vectra) with Netgear FA310TX cards and a D-Link DSS-16+ switch. I have tried every mode for the cards and cannot get them to send or recieve. The switch never shows any link beat for any of the cards/modes. Here is my output from tulip-diag with options set to 13: -- tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Lite-On 82c168 PNIC adapter at 0xfc00. Port selection is 10mpbs-serial, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Waiting for Tx to finish'. The transmit threshold is 96. -- It says 10mpbs even though the '100' light on the card is on. And here is mii-diag: -- Using the default interface 'eth0'. Basic registers of MII PHY #1: 3000 7809 0040 6212 0081 0000 0000 0000. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x7809 ... 7809. Link status: not established. -- Any help would be appreciated. -- Bryan Burns a.k.a "Haplo" A copy of my PGP key is available at: http://www.wwa.com/~haplo/public_key From becker@scyld.com Wed, 24 Jan 2001 00:18:44 -0500 (EST) Date: Wed, 24 Jan 2001 00:18:44 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Netgear FA310TX On Tue, 23 Jan 2001, Bryan Burns wrote: > I am setting up a Beowulf cluster at my school (Illinois State University) > and cannot get the Netgear cards to work, here is my setup: You should be specific about the chip used. Netgear, much like Linksys, used a variety of chips without changing the part number. > I have tried every mode for the cards In general, you should not override the default unless you are certain you need to. > Here is my output from tulip-diag with options set to 13: Bad... > tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a Lite-On 82c168 PNIC adapter at 0xfc00. > And here is mii-diag: > Using the default interface 'eth0'. > Basic registers of MII PHY #1: 3000 7809 0040 6212 0081 0000 0000 0000. > Basic mode control register 0x3000: Auto-negotiation enabled. > Basic mode status register 0x7809 ... 7809. > Link status: not established. OK, this is the problem. You don't have link beat. Check your cable. Use the 'mii-diag' to monitor if the cable is working. When you have link beat, restart the driver with no options. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From jrc@art-render.com Wed, 24 Jan 2001 11:24:51 +0000 Date: Wed, 24 Jan 2001 11:24:51 +0000 From: John Connett jrc@art-render.com Subject: [tulip] Re: v0.92 and NetPIPE 2.4 I have not received any e-mail responses to this thread and would be grateful for any suggestions as to how to identify the cause of the very marked loss of performance for block sizes of 4093 bytes and above. Is it a problem with the NetPIPE test; the tulip driver; the NIC hardware; or something else? Any suggestions as to how to set up a suitable test environment to evaluate and compare NICs would be appreciated. My objective is to identify any potential problems with the NIC under test. Ideally the system at the far end of the cross over cable should be a "reference implementation". If this requires a non-Linux operating system or a particular NIC to achieve this I am willing to try to set that up. Thanks again -- John Connett (jrc@art-render.com) From jens.flucke@berlin.de Wed, 24 Jan 2001 19:02:37 +0100 Date: Wed, 24 Jan 2001 19:02:37 +0100 From: Jens Flucke jens.flucke@berlin.de Subject: [tulip] Diver Problem!!! Dear Mr. Becker, at first i want to say thanks to you for your work an tulip chip sets. But i have the problem that my card does not works. I am using Suse Linux 7.0 with Kernel 2.2.16. It is possible via "yast" to selcet the tulip chip for my network card. But it does not work. So i hope that you can help me, because i am not a programmer to solve the problem by myself. I hope that there are enough informations for you to solve the problem. The PC-Card (PCI) is a 4 Port integrated HUB with the Tulip Chip. The revision is A4. There is a label on it "NEF-4C". In the middle the is a great IC with a fan on it. Near to this IC there is a second one wich is labeld "ASIX AX 88141P 9904 US 1 ECR 56-3" I hope this will help you. The kernel give the following information: tara kernel: eth0: Transmit timed out, status 00160400, CSR 12 00000101, resetting But with the command "ifconfig" you can the the eth0 device: eth0 Link encap:Ethernet HWaddr 00:50:00:00:0C:46 inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:25 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:11 Base address:0x9800 Also a ping on the networkdevice workes fine: bash-2.04# ping tara PING tara.somephreax.all (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: icmp_seq=0 ttl=255 time=0.271 ms 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=0.173 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=0.160 ms 64 bytes from 192.168.0.1: icmp_seq=3 ttl=255 time=0.157 ms 64 bytes from 192.168.0.1: icmp_seq=4 ttl=255 time=0.160 ms --- tara.somephreax.all ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.157/0.184/0.271 ms bash-2.04# 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=0 ttl=255 time=0.221 ms 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=0.173 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=0.161 ms 64 bytes from 192.168.0.1: icmp_seq=3 ttl=255 time=0.167 ms --- 192.168.0.1 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.161/0.180/0.221 ms With your diagnostics Programm you can see the following outputs: bash-2.04# ./tulip-diag tulip-diag.c:v2.03 7/31/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a ASIX AX88140 adapter at 0x9800. Port selection is 10mpbs-serial, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Reading a Tx descriptor'. The transmit threshold is 72. The MAC/filter registers are 00005000 0000460c 80000000 00000000. Use '-a' or '-aa' to show device registers, '-e' to show EEPROM contents, -ee for parsed contents, or '-m' or '-mm' to show MII management registers. bash-2.04# ./tulip-diag -aa bash: ./tulip-diag: Datei oder Verzeichnis nicht gefunden bash-2.04# /usr/sbin/./tulip-diag -aa tulip-diag.c:v2.03 7/31/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a ASIX AX88140 adapter at 0x9800. * A potential Tulip chip has been found, but it appears to be active. * Either shutdown the network, or use the '-f' flag to see all values. Port selection is 10mpbs-serial, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Reading a Tx descriptor'. The transmit threshold is 72. bash-2.04# /usr/sbin/./tulip-diag -e tulip-diag.c:v2.03 7/31/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a ASIX AX88140 adapter at 0x9800. Port selection is 10mpbs-serial, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Reading a Tx descriptor'. The transmit threshold is 72. The MAC/filter registers are 00005000 0000460c 80000000 00000000. EEPROM size is 6. PCI Subsystem IDs, vendor 0000, device 0000. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:50:00:00:0C:46. EEPROM transceiver/media description for the ASIX AX88140 chip. Leaf node at offset 30, default media type 0003 (100baseTx). CSR12 direction setting bits 0x1f. 1 transceiver description blocks: 21140 Non-MII transceiver for media 3 (100baseTx). CSR12 control port setting 00, command 0x40 0x8b. Media detection by looking for a 0 on bit 5 of the CSR12 control port. bash-2.04# /usr/sbin/./tulip-diag -m tulip-diag.c:v2.03 7/31/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a ASIX AX88140 adapter at 0x9800. Port selection is 10mpbs-serial, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Reading a Tx descriptor'. The transmit threshold is 72. The MAC/filter registers are 00005000 0000460c 80000000 00000000. No MII transceivers found! May you help me. Whats the Problem? Please excuse, but i am newbie on networking. Thanks!!! For your information. I want to connect directly via LAN to another computer, using also linux with a realtex ? networkcard. Best regards Jens Flucke -- Dipl.-Ing. (FH) Jens Flucke Im Domstift 53 12309 Berlin Tel.: +49 (0)30 7 46 10 44 Mobil: +49 (0)170 3 42 87 66 e-Mail: jens.flucke@berlin.de "Die Perfektion der Mittel und die Verwirrung der Ziele - das scheint unsere Zeit zu charakterisieren" Albert Einstein From becker@scyld.com Wed, 24 Jan 2001 18:22:48 -0500 (EST) Date: Wed, 24 Jan 2001 18:22:48 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Diver Problem!!! On Wed, 24 Jan 2001, Jens Flucke wrote: > at first i want to say thanks to you for your work an tulip chip sets. But i > have the problem that my card does not works. I am using Suse Linux 7.0 with > Kernel 2.2.16. It is possible via "yast" to selcet the tulip chip for my > network card. But it does not work. What driver version are you using? You should be using v0.92 or later for the 88140 series. > The PC-Card (PCI) is a 4 Port integrated HUB with the Tulip Chip. The > revision is A4. There is a label on it "NEF-4C". In the middle the is > a great IC with a fan on it. Near to this IC there is a second one > wich is labeld "ASIX AX 88141P 9904 US 1 ECR 56-3" I hope this will > help you. I only have a 88140 board here, but the 88141 should work the same. I just tested the v0.92t driver that we have in the Scyld Beowulf distribution and the 88140 works properly. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From unixj@yahoo.com Wed, 24 Jan 2001 17:38:47 -0800 (PST) Date: Wed, 24 Jan 2001 17:38:47 -0800 (PST) From: Jonah Michaud unixj@yahoo.com Subject: [tulip] eth0 resets every 5 mins! My card is a LinkSys Etherfast 10/100, I'm running Mandrake 7.2 with the standard kernel, 2.2.17mdk. Every 5 minutes on average my connection hangs and there is the following message: localhost kernel: eth0: Tx hung, 15728 vs. 15723. localhost kernel: eth0: PNIC2 transmit timed out, status e4000000, CSR6/7 01000000 / effffbff CSR12 41e1d0cc, resetting... I was assuming it was due to my RoadRunner connection or maybe the RCA cable modem. Because I have 2 relatives with the exact same hardware/OS/everything except they're using @home and a different modem. It's been happening ever since I got a cable modem about 2 months ago and I've spent hours trying to contact RoadRunner but no one ever picks up the phone or replies to email. Today I tried replacing the tulip from Mandrake (version 0.921) with the test one (0.92t) but it doesn't seem to help. Is there any number I can change in tulip.c to help the driver work around this problem? Thanks! __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ From daniel.pfenniger@obs.unige.ch Thu, 25 Jan 2001 22:23:39 +0100 Date: Thu, 25 Jan 2001 22:23:39 +0100 From: Pfenniger Daniel daniel.pfenniger@obs.unige.ch Subject: [tulip] 21143 refuses full-duplex This is a multi-part message in MIME format. --Boundary_(ID_BxjhQNIEKZ/SAIObkNV5GQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit I have a series of 21140 (Lantronix) and 21143-PD cards (unknown origin). The 21140's understand the full duplex option but not the 21143. I understand that Don's latest tulip driver is more up-to-date about the 21143 chip, but it doesn't compile in the 2.2.18 kernel, or I don't know how to do it correctly. (In the 2.4.0 kernel the tulip driver is split into several files.) What tulip-diag -ee and -mm say about the second card is joined below. The modules.conf files has the following lines: alias eth0 tulip alias eth1 tulip options tulip full_duplex=1,1 Any clue? I cannot retrograde to a too old kernel because the bonding driver for which the second card is intended doesn't work then Daniel --Boundary_(ID_BxjhQNIEKZ/SAIObkNV5GQ) Content-type: text/plain; name=tulip-diag-ee; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline; filename=tulip-diag-ee 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 f394 0000 0000 0000 0000 b51c 0bc9 0040 0000 0000 0000 0000 0000 0000 0000 0000 00be ID block CRC 0xc5 (vs. 0xc5). Full contents CRC 0x263a (read as 0x00be). MII PHY found at address 5, status 0x782d. Internal autonegotiation state is 'Autonegotiation disabled'. --Boundary_(ID_BxjhQNIEKZ/SAIObkNV5GQ) Content-type: text/plain; name=tulip-diag-mm; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline; filename=tulip-diag-mm Link partner capability is 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Negotiation completed. Internal autonegotiation state is 'Autonegotiation disabled'. --Boundary_(ID_BxjhQNIEKZ/SAIObkNV5GQ)-- From becker@scyld.com Thu, 25 Jan 2001 17:33:15 -0500 (EST) Date: Thu, 25 Jan 2001 17:33:15 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] 21143 refuses full-duplex On Thu, 25 Jan 2001, Pfenniger Daniel wrote: > I have a series of 21140 (Lantronix) and 21143-PD cards (unknown origin). > The 21140's understand the full duplex option but not the 21143. Do the 21143 cards have MII or SYM transceivers? > I understand that Don's latest tulip driver is more up-to-date about the > 21143 chip, but it doesn't compile in the 2.2.18 kernel, or I don't > know how to do it correctly. That's likely your problem -- using an old driver. Read http://www.scyld.com/network/updates.html The driver *really does* work with 2.2.18... > alias eth0 tulip > alias eth1 tulip > options tulip full_duplex=1,1 You do know that forcing full duplex will break autonegotiation, right? Try using the driver without forcing the duplex. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From wagner@phenomedia.de Fri, 26 Jan 2001 14:13:49 +0100 Date: Fri, 26 Jan 2001 14:13:49 +0100 From: Frank Wagner wagner@phenomedia.de Subject: [tulip] D-Link 530TX Hallo, i have a D-Link 530TX (Chip 100030A) and i canīt compile the viarhine driver with the new 2.4.0 sourcetree. What can i do? The tulip driver does not work. Frank From blah@blah.com Sat, 27 Jan 2001 13:17:36 -0500 Date: Sat, 27 Jan 2001 13:17:36 -0500 From: me2 blah@blah.com Subject: [tulip] Accton EN2242 on HP Pavilion Laptop hi'z .. Ive an HP Pavilion (N5170) Laptop which has the Accton EN2242 ethernet (at least per Win98's Device Manager interrogation). Cant seem to get it running in Linux (RH 7.0, SuSE 7.0). I learn that Accton is 'old' and was ? bought out by SMC . A generous fellow at SMC found an old file with drivers for SCO5 and for UnixWare7 , both of which i have neither access or knowledge of. Any help at getting this going would be appreciated. tnx jon anderson jonander@idt.net From becker@scyld.com Sat, 27 Jan 2001 16:51:12 -0500 (EST) Date: Sat, 27 Jan 2001 16:51:12 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Accton EN2242 on HP Pavilion Laptop On Sat, 27 Jan 2001, me2 wrote: > Ive an HP Pavilion (N5170) Laptop which has the > Accton EN2242 ethernet (at least per Win98's Device > Manager interrogation). Cant seem to get it running > in Linux (RH 7.0, SuSE 7.0). I don't have that card on my list. Is it CardBus, PCMCIA, or PCI? > I learn that Accton is 'old' and was ? bought out by SMC. It's pretty much the other way around. Accton bought the very respected SMC brand name for network adapters, and the SMC chip people became SMSC. > A generous fellow at SMC found an old file > with drivers for SCO5 and for UnixWare7 , both of > which i have neither access or knowledge of. Those drivers are useless. This card is almost certainly supported by one of my drivers, but you have to provide some chip ID number to us (PCI vendor ID, or CardBus vendor ID). Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From matthew@psychohorse.com Sun, 28 Jan 2001 00:33:18 -0800 Date: Sun, 28 Jan 2001 00:33:18 -0800 From: Matthew matthew@psychohorse.com Subject: [tulip] Macronix 98715 PMAC rev 37 Good day, Hello I am new to this list, hopefully I will not make a fool out of myself...:-). Having an interesting problem with a SoHOware Fast NDC 10/100 F/E Adapter card. Its chipset is being seen as Macronix 98715 PMAC rev 37 by the Tulip driver. First question: Anyone got decent information on this card? Do not hold back.... Second (main question): I am using the newest driver for this card from the src rpm, but everytime I have setup the options=3 or 16 I get a segfault when bringing up eth0. Then the system hangs on route (had to do rescue system to get it back). Would be nice to have this running at 100 half duplex if that is possible...Any ideas what the cause is? I am using SuSE 7.0 with the default 2.2.16 kernel. Thanks, Matt From becker@scyld.com Sun, 28 Jan 2001 12:37:32 -0500 (EST) Date: Sun, 28 Jan 2001 12:37:32 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Macronix 98715 PMAC rev 37 On Sun, 28 Jan 2001, Matthew wrote: > Having an interesting problem with a SoHOware Fast NDC 10/100 F/E Adapter > card. Its chipset is being seen as Macronix 98715 PMAC rev 37 by the Tulip > driver. > > First question: Anyone got decent information on this card? Do not hold > back.... It's difficult to get info. LiteOn apparently sold their PNIC-II design to Macronix sometime after the 98725 was released. It's curious that Macronix would buy an external design if there were happy with the design they already owned. Anyway, the 987** series seems to have disappeared from the marketplace. > Second (main question): I am using the newest driver for this card > from the src rpm, Please don't say "newest driver". Use the version number. (The "newest driver" is usually the half-broken test copy on my machine.) > but everytime I have setup the options=3 or 16 I > get a segfault when bringing up eth0. This I can check out. Why are using passing options? Does your card actually have a MII 100baseFX-HDX transceiver (media type 16)? What is the detection message for the card? (I need to know the approximate media table to figure out what is going wrong.) Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From jspaint@flash.net Sun, 28 Jan 2001 12:06:11 -0600 Date: Sun, 28 Jan 2001 12:06:11 -0600 From: Russell jspaint@flash.net Subject: [tulip] Unknown ISA Ethernet card Hello I have an old computer that i am going to try to setup as a internet router for a small home network. The box has a ISA non plug&pray ethernet adapter that i want to use as one of the NIC. It has Artisoft 1991 stamped on the board the chip has no manufacturer only #S9136BP and #DP83902V does anyone know what module could be used for this card under Red Hat 7.0.? or how to get this card to work? The only thing i can tell from the jumpers are that it is set on irq 15 the IO Jumpers has only letters and the #16. Any help for this linuxnewbe would be greatly appreciated. Russ From becker@scyld.com Sun, 28 Jan 2001 15:29:17 -0500 (EST) Date: Sun, 28 Jan 2001 15:29:17 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Unknown ISA Ethernet card On Sun, 28 Jan 2001, Russell wrote: > I have an old computer that i am going to try to setup as a internet > router > for a small home network. The box has a ISA non plug&pray ethernet > adapter > that i want to use as one of the NIC. Please don't post off-topic questions to the Tulip list. This list is for Tulip architecture Ethernet adapters. > It has Artisoft 1991 stamped on the board > the chip has no manufacturer only #S9136BP and #DP83902V does anyone The 83902 is often used with NE2000 clones. It's an 8390 with extra circuitry for twisted pair. > know what module could be used for this card under Red Hat 7.0.? or > how to get this card to work? > The only thing i can tell from the jumpers are that it is set on irq 15 > the IO Jumpers has only letters and the #16. Any help for this > linuxnewbe would be greatly appreciated. Try the 'ne' driver. You might have to experiment with jumper setting. The card is liked at 0x20 offsets from 0x200-0x3e0 e.g. 0x200, 0x220... 0x3c0, 0x3e0 If you have four I/O jumpers, set all the same side and try io=0x200 and io=0x3e0. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From matthew@psychohorse.com Sun, 28 Jan 2001 13:31:33 -0800 Date: Sun, 28 Jan 2001 13:31:33 -0800 From: Matthew matthew@psychohorse.com Subject: [tulip] Macronix 98715 PMAC rev 37 Thanks for answering my questions! >Please don't say "newest driver". Use the version number. >(The "newest driver" is usually the half-broken test copy on my machine.) My bad, I should have known better about which driver version number I was using. Its v0.92t dated 1/15/2001. > This I can check out. > Why are using passing options? > Does your card actually have a MII 100baseFX-HDX transceiver (media type > 16)? To be honest, I had no idea. Took a couple of shots in the dark, luckily I managed to remember how to get into the system without networking. I was passing options to try and force 100 half duplex. Here is the relevant section I extracted from dmesg, hope this is sufficient. If not I can dig for more. tulip.c:v0.92t 1/15/2001 Written by Donald Becker http://www.scyld.com/network/tulip.html eth0: Macronix 98715 PMAC rev 37 at 0xc8842000, 00:80:C6:EB:B1:03, IRQ 5. eth0: EEPROM default media type 10baseT. Its attached to a Linksys 10/100 Hub. Thanks so much for looking into this. Many thanks, Matthew Johnson On Sunday 28 January 2001 09:37 am, Donald Becker wrote: > On Sun, 28 Jan 2001, Matthew wrote: > > Having an interesting problem with a SoHOware Fast NDC 10/100 F/E Adapter > > card. Its chipset is being seen as Macronix 98715 PMAC rev 37 by the > > Tulip driver. > > > > First question: Anyone got decent information on this card? Do not hold > > back.... > > It's difficult to get info. LiteOn apparently sold their PNIC-II design > to Macronix sometime after the 98725 was released. It's curious that > Macronix would buy an external design if there were happy with the > design they already owned. Anyway, the 987** series seems to have > disappeared from the marketplace. > > > Second (main question): I am using the newest driver for this card > > from the src rpm, > > Please don't say "newest driver". Use the version number. > (The "newest driver" is usually the half-broken test copy on my machine.) > > > but everytime I have setup the options=3 or 16 I > > get a segfault when bringing up eth0. > > This I can check out. > Why are using passing options? > Does your card actually have a MII 100baseFX-HDX transceiver (media type > 16)? > > What is the detection message for the card? (I need to know the > approximate media table to figure out what is going wrong.) > > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters > Annapolis MD 21403 410-990-9993 From matthew@psychohorse.com Sun, 28 Jan 2001 16:09:40 -0800 Date: Sun, 28 Jan 2001 16:09:40 -0800 From: Matthew matthew@psychohorse.com Subject: [tulip] Macronix 98715 PMAC rev 37 This card does not seem to use MII transceiver as I ran the mii-diag, but it said quite catagorically: SIOCGMIIPHY on eth0 failed: No such device Guess that explains that...From the pdf file I downloaded from Macronix I have discovered that it comes with something called Adaptive Network Throughput Control (ANTC), they call it innovative and proprietary design (although thats not what comes to my mind...). Just wish the box would detail these things more, half the time its like a lucky dip. The pdf goes into more technical details with lots of diagrams. Not sure if its any use though. Thanks for all the effort, I do appreciate it. Matthew On Sunday 28 January 2001 02:29 pm, Iggy Reko wrote: > Matthew wrote: > > <> > Does your card actually have a MII 100baseFX-HDX transceiver (media > type <> > 16)? > <> > <> To be honest, I had no idea. Took a couple of shots in the dark, luckily > I <> managed to remember how to get into the system without networking. I > was <> passing options to try and force 100 half duplex. > > Matthew, > > There's a very useful diagnostic program for tulip based > NICs available from the same site as the drivers ('coz > Donald wrote 'em both ...) > > ftp://ftp.scyld.com/pub/diag/mii-diag.c > > It compiles and runs easily: > > % gcc mii-diag.c -o mii-diag > % ./mii-diag -v > mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Using the default interface 'eth0'. > MII PHY #0 transceiver registers: > 1000 782d 7810 0000 01e1 0021 0000 0000 > 0000 0000 0000 0000 0000 0000 0000 0000 > 0000 0000 4000 0000 26bb 0010 0000 0002 > 0001 0000 0000 0000 0000 0000 0000 0000. > Basic mode control register 0x1000: Auto-negotiation enabled. > You have link beat, and everything is working OK. > This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD > 10baseT. Able to perform Auto-negotiation, negotiation complete. > Your link partner is generating 10baseT link beat (no > autonegotiation). % > > THat's the info we're looking for to help you out. > > Reto From jtillman@bigfoot.com Sun, 28 Jan 2001 23:43:44 -0500 Date: Sun, 28 Jan 2001 23:43:44 -0500 From: James Tillman jtillman@bigfoot.com Subject: [tulip] Mandrake 7.2 and AMDTek Comet AN983 This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C08984.26B07200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi: I'm running Mandrake 7.2 (kernel 2.2.17-21) on an HP Pavilion = n5190. I followed instructions at: http://www.lanset.com/pilotodd/Linux_on_HP_N5190_Notebook.html#ethernet_c= ard on how to get the tulip driver working with the built-in Accton EN2242 = (AMDtek Comet AN983). However, after compiling tulip.o and pci-scan.o = and moving them into the modules net directory, I get "Device or = resource busy" when running "modprobe tulip". I've been able to run = tulip-diag successfully when specifying the memory address with -p = (wouldn't detect without it), and I get some nice information about the = card (I can send it if it will help). Any ideas about where I should start, or what extra information I could = provide to get help? Thanks, jpt ------=_NextPart_000_0016_01C08984.26B07200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi:  I'm running Mandrake 7.2 = (kernel=20 2.2.17-21) on an HP Pavilion n5190.  I followed instructions=20 at:
 
http://www.lanset.com/pilotodd/Linux_on_HP_N5190_Notebook.ht= ml#ethernet_card
 
on how to get the tulip driver working = with the=20 built-in Accton EN2242 (AMDtek Comet AN983).  However, after = compiling=20 tulip.o and pci-scan.o and moving them into the modules net directory, I = get=20 "Device or resource busy" when running "modprobe tulip".  I've been = able to=20 run tulip-diag successfully when specifying the memory address with -p = (wouldn't=20 detect without it), and I get some nice information about the card (I = can send=20 it if it will help).
 
Any ideas about where I should start, = or what extra=20 information I could provide to get help?
 
Thanks,
 
jpt
------=_NextPart_000_0016_01C08984.26B07200-- From becker@scyld.com Mon, 29 Jan 2001 03:04:59 -0500 (EST) Date: Mon, 29 Jan 2001 03:04:59 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [tulip] Mandrake 7.2 and AMDTek Comet AN983 On Sun, 28 Jan 2001, James Tillman wrote: > Hi: I'm running Mandrake 7.2 (kernel 2.2.17-21) on an HP Pavilion > n5190. I followed instructions at: > > http://www.lanset.com/pilotodd/Linux_on_HP_N5190_Notebook.html#ethernet_card > > on how to get the tulip driver working with the built-in Accton EN2242 > (AMDtek Comet AN983). Hmmm, it turns out I did add a PCI table entry for the Accton EN2242 a while back. It's a ADMtek Comet chip with a unique EEPROM-set device ID. It should "just work" with the updated driver at ftp://ftp.scyld.com/pub/network/netdriver-2.1.src.rpm Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From mike.a.morrell@appliance.invensys.com Mon, 29 Jan 2001 07:28:08 -0600 Date: Mon, 29 Jan 2001 07:28:08 -0600 From: Morrell, Mike A mike.a.morrell@appliance.invensys.com Subject: [tulip] Macronix 98715 PMAC rev 37 I'm running two of these same cards in a Debian (Potato) box with 2.2.16 kernel without any problems. I am using v.91g-ppc driver that was installed by default and it works much better for me than the v.92X drivers (I've tried them all except .92t). I do not pass any options to the card. BTW, why do you want to force half duplex instead of using autonegotiation? -----Original Message----- From: Matthew [mailto:matthew@psychohorse.com] Sent: Sunday, January 28, 2001 7:10 PM To: Iggy Reko Cc: tulip@scyld.com Subject: Re: [tulip] Macronix 98715 PMAC rev 37 This card does not seem to use MII transceiver as I ran the mii-diag, but it said quite catagorically: SIOCGMIIPHY on eth0 failed: No such device Guess that explains that...From the pdf file I downloaded from Macronix I have discovered that it comes with something called Adaptive Network Throughput Control (ANTC), they call it innovative and proprietary design (although thats not what comes to my mind...). Just wish the box would detail these things more, half the time its like a lucky dip. The pdf goes into more technical details with lots of diagrams. Not sure if its any use though. Thanks for all the effort, I do appreciate it. Matthew On Sunday 28 January 2001 02:29 pm, Iggy Reko wrote: > Matthew wrote: > > <> > Does your card actually have a MII 100baseFX-HDX transceiver (media > type <> > 16)? > <> > <> To be honest, I had no idea. Took a couple of shots in the dark, luckily > I <> managed to remember how to get into the system without networking. I > was <> passing options to try and force 100 half duplex. > > Matthew, > > There's a very useful diagnostic program for tulip based > NICs available from the same site as the drivers ('coz > Donald wrote 'em both ...) > > ftp://ftp.scyld.com/pub/diag/mii-diag.c > > It compiles and runs easily: > > % gcc mii-diag.c -o mii-diag > % ./mii-diag -v > mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Using the default interface 'eth0'. > MII PHY #0 transceiver registers: > 1000 782d 7810 0000 01e1 0021 0000 0000 > 0000 0000 0000 0000 0000 0000 0000 0000 > 0000 0000 4000 0000 26bb 0010 0000 0002 > 0001 0000 0000 0000 0000 0000 0000 0000. > Basic mode control register 0x1000: Auto-negotiation enabled. > You have link beat, and everything is working OK. > This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD > 10baseT. Able to perform Auto-negotiation, negotiation complete. > Your link partner is generating 10baseT link beat (no > autonegotiation). % > > THat's the info we're looking for to help you out. > > Reto _______________________________________________ tulip mailing list tulip@scyld.com http://www.scyld.com/mailman/listinfo/tulip From kai@secunet.de Mon, 29 Jan 2001 15:07:28 +0100 Date: Mon, 29 Jan 2001 15:07:28 +0100 From: Kai Martius kai@secunet.de Subject: [tulip] 21143 Problem Hello, we are using a 21143 based 100Base-FX card (Longshine), Kernel 2.4.0, patched tulip.c (from 2.4.1-test10). There are performance problems with TCP-based sessions, that seem to come from full-duplex / half-duplex misbehavoir described earlier on the list. There is no way to put the card in HDX, which was proposed as a solution here. Ifconfig reports transmit / carrier errors for every packet. In debug level 5, the card reports: eth1: interrupt csr5=0xf0670004 new csr5=0xf0660000 eth1: Transmit error, Tx status 7fffbc00 eth1: exiting interrupt, csr5=0xf0660000 Could the change in tulip.c 0.92t by Donald Becker (message from Mon Jan 15, Accton EN2242) be a solution for this? And, if yes, how can it be integrated in 2.4.0-sources (a diff from 0.92s to 0.92t would be helpful)? Thanks a lot for the help! Greetings Kai -- Kai Martius secunet Security Networks AG, Dresden / Germany From jasiel@ecpi.com Mon, 29 Jan 2001 18:56:30 -0600 Date: Mon, 29 Jan 2001 18:56:30 -0600 From: Jasiel Spelman jasiel@ecpi.com Subject: [tulip] Tulip I have Redhat 7.0 with the 2.4 kernel. I have a Linksys LNE100TX ETHERFAST 10/100 LAN card, and I get get it to work in Linux. The main problem that I am having is that I can't get correct drivers for the instructions that I find. Also, my card didn't come with a Linux driver, please help. Jason From matthew@psychohorse.com Mon, 29 Jan 2001 18:39:32 -0800 Date: Mon, 29 Jan 2001 18:39:32 -0800 From: Matthew matthew@psychohorse.com Subject: [tulip] Tulip Hold on, its working, but its not the correct driver? The fact that its working is I deem a good indication that you have the correct module loading (tulip.o). The Linux modules most of these cards come with are pretty old anyhow, so no loss there. If you need more detailed information then look at www.scyld.com/network/tulip.html Matt Offtopic: Any plans for having Scyld merchandise? On Monday 29 January 2001 04:56 pm, Jasiel Spelman wrote: > I have Redhat 7.0 with the 2.4 kernel. I have a Linksys LNE100TX > ETHERFAST 10/100 LAN card, and I get get it to work in Linux. The main > problem that I am having is that I can't get correct drivers for the > instructions that I find. Also, my card didn't come with a Linux driver, > please help. > > Jason > > > _______________________________________________ > tulip mailing list > tulip@scyld.com > http://www.scyld.com/mailman/listinfo/tulip From matthew@psychohorse.com Mon, 29 Jan 2001 20:56:08 -0800 Date: Mon, 29 Jan 2001 20:56:08 -0800 From: Matthew matthew@psychohorse.com Subject: [tulip] Tulip What happens with lspci and insmod tulip? Does the pci-scan module load? Which driver version are you using? Actually, I had a problem with the tulip driver not seeing the device either.....But not tried since I re-installed my OS whilst trying to get an Nvidia geforce2 GTS working.... Take it you have installed the newest set of device drivers (the one for RH7). lspci most likely see's it there....Maybe pci-scan is not loading for some reason? Matt On Monday 29 January 2001 07:24 pm, Jasiel Spelman wrote: > That's the thing though, it doesn't work, it doesn't even recognize that it > is there > J > > Matthew wrote: > > Hold on, its working, but its not the correct driver? The fact that its > > working is I deem a good indication that you have the correct module > > loading (tulip.o). > > The Linux modules most of these cards come with are pretty old anyhow, so > > no loss there. If you need more detailed information then look at > > www.scyld.com/network/tulip.html > > > > Matt > > > > Offtopic: Any plans for having Scyld merchandise? > > > > On Monday 29 January 2001 04:56 pm, Jasiel Spelman wrote: > > > I have Redhat 7.0 with the 2.4 kernel. I have a Linksys LNE100TX > > > ETHERFAST 10/100 LAN card, and I get get it to work in Linux. The main > > > problem that I am having is that I can't get correct drivers for the > > > instructions that I find. Also, my card didn't come with a Linux > > > driver, please help. > > > > > > Jason > > > > > > > > > _______________________________________________ > > > tulip mailing list > > > tulip@scyld.com > > > http://www.scyld.com/mailman/listinfo/tulip From mallik@beer.com Tue, 30 Jan 2001 11:19:04 -0600 Date: Tue, 30 Jan 2001 11:19:04 -0600 From: Mallik Kandula mallik@beer.com Subject: [tulip] LNE100TX, RH7 Hi , I have a problem not to recognize my second NIC card which is a Linksys LNE100TX card. My kernel version is 2.2.16-22smp for a dual processor compaq proliant running RH7.0. When the system boots it dint pick the card, so I had to use the driver that came version v0.92 (netdrivers.tgz which is same as the latest out there at donald's site.) which fails to compile. The output: [mallik@webprod drive]$ make gcc -D__SMP__ -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -I/usr/src/linux/include -DMODVERSIONS -c -o pci-skeleton.o pci-skeleton.c In file included from /usr/src/linux/include/linux/smp.h:12, from /usr/src/linux/include/linux/sched.h:21, from /usr/src/linux/include/linux/mm.h:5, from /usr/src/linux/include/linux/slab.h:15, from /usr/src/linux/include/linux/malloc.h:5, from pci-skeleton.c:98: /usr/src/linux/include/asm/smp.h: In function `hard_smp_processor_id': /usr/src/linux/include/asm/smp.h:209: warning: implicit declaration of function `GET_APIC_ID' /usr/src/linux/include/asm/smp.h:209: `APIC_BASE' undeclared (first use in this function) /usr/src/linux/include/asm/smp.h:209: (Each undeclared identifier is reported only once /usr/src/linux/include/asm/smp.h:209: for each function it appears in.) /usr/src/linux/include/asm/smp.h:209: `APIC_ID' undeclared (first use in this function) make: *** [pci-skeleton.o] Error 1 Problem1 : I know RH7.0 has a problem loading dynamic modules due to the compilation problems concerning kgcc and the headers from 2.4. I cant compile the kernel becoz the server is a production machine and i dont have a smp kernel anywhere to test . I got the card working as a second nic on a RH6.2 . Any help is greatly appreciated . Mallik A beer.com Beer Mail fanatic Beer Mail, brought to you by your friends at beer.com. From rmcgarry@usd.edu Tue, 30 Jan 2001 10:54:30 -0600 Date: Tue, 30 Jan 2001 10:54:30 -0600 From: Ryan M McGarry rmcgarry@usd.edu Subject: [tulip] LNE 100TX failing after a month... Hi, I've got 2 identical LNE100TX in a Pentium-120 running RedHat 6.2. I'm using it as a router/firewall. It took a miracle but I got the network cards to work last summer, and have been using it continually for almost a year now. My problem is that after a month of continual uptime, my network connectin will freeze on me. The system is still responsive, the only problem is in the network. The only way to get it up again is to power-cycle the Pentium. Rebooting doesn't fix the problem. This isn't really a problem, more of an annoyance, but have any of you experienced this? Am I wrong to think it's the drivers? Thanks for your input, Ryan McGarry From matthewe@virginia.edu Tue, 30 Jan 2001 21:00:30 -0500 Date: Tue, 30 Jan 2001 21:00:30 -0500 From: Matthew S. Eaton matthewe@virginia.edu Subject: [tulip] tulip + 2.4? Hi all, Should the tulip driver compile/run on 2.4 kernels? Compilation with 2.4.1 : tulip.c: In function `tulip_open': tulip.c:1488: structure has no member named `tbusy' tulip.c:1489: structure has no member named `start' tulip.c: In function `tulip_start_xmit': tulip.c:2607: structure has no member named `tbusy' tulip.c:2640: structure has no member named `tbusy' tulip.c: In function `tulip_interrupt': tulip.c:2659: structure has no member named `interrupt' tulip.c:2663: structure has no member named `interrupt' tulip.c:2744: structure has no member named `tbusy' tulip.c:2748: structure has no member named `tbusy' tulip.c:2749: `NET_BH' undeclared (first use in this function) tulip.c:2749: (Each undeclared identifier is reported only once tulip.c:2749: for each function it appears in.) tulip.c:2845: structure has no member named `interrupt' tulip.c: In function `tulip_close': tulip.c:2991: structure has no member named `start' tulip.c:2992: structure has no member named `tbusy' tulip.c: In function `tulip_get_stats': tulip.c:3031: structure has no member named `start' tulip.c: In function `set_rx_mode': tulip.c:3303: structure has no member named `tbusy' I would use the native 2.4.1 tulip driver included with the kernel. but: i get a bunch of these: NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timed out, status fc664010, CSR12 00000000, resetting... so I prefer the high performance one's here better :-) -- Matthew S. Eaton Undergraduate University of Virginia School of Engineering and Applied Science From matthew@psychohorse.com Tue, 30 Jan 2001 19:35:27 -0800 Date: Tue, 30 Jan 2001 19:35:27 -0800 From: Matthew matthew@psychohorse.com Subject: [tulip] tulip + 2.4? No problems here at the moment....However I had to build the module into the kernel, which I should do anyway I guess. The tulip.o module ended up in its own directory under net. Was that normal? I have no idea what normal is though with this kernel. What distribution are you using?? Matt On Tuesday 30 January 2001 06:00 pm, Matthew S. Eaton wrote: > Hi all, > > Should the tulip driver compile/run on 2.4 kernels? > > Compilation with 2.4.1 : > > tulip.c: In function `tulip_open': > tulip.c:1488: structure has no member named `tbusy' > tulip.c:1489: structure has no member named `start' > tulip.c: In function `tulip_start_xmit': > tulip.c:2607: structure has no member named `tbusy' > tulip.c:2640: structure has no member named `tbusy' > tulip.c: In function `tulip_interrupt': > tulip.c:2659: structure has no member named `interrupt' > tulip.c:2663: structure has no member named `interrupt' > tulip.c:2744: structure has no member named `tbusy' > tulip.c:2748: structure has no member named `tbusy' > tulip.c:2749: `NET_BH' undeclared (first use in this function) > tulip.c:2749: (Each undeclared identifier is reported only once > tulip.c:2749: for each function it appears in.) > tulip.c:2845: structure has no member named `interrupt' > tulip.c: In function `tulip_close': > tulip.c:2991: structure has no member named `start' > tulip.c:2992: structure has no member named `tbusy' > tulip.c: In function `tulip_get_stats': > tulip.c:3031: structure has no member named `start' > tulip.c: In function `set_rx_mode': > tulip.c:3303: structure has no member named `tbusy' > > > I would use the native 2.4.1 tulip driver included with the kernel. but: > i get a bunch of these: > NETDEV WATCHDOG: eth0: transmit timed out > eth0: Transmit timed out, status fc664010, CSR12 00000000, resetting... > > so I prefer the high performance one's here better :-) From dkturner@qwest.net Wed, 31 Jan 2001 09:47:50 -0800 Date: Wed, 31 Jan 2001 09:47:50 -0800 From: Dave Turner dkturner@qwest.net Subject: [tulip] Re: tulip + 2.4 Try compiling using kgcc rather than gcc and see if that makes a difference. Also, put -I/usr/src/linux/include in your compile command line. I had similar errors and those two changes got the source to compile. FWIW, this information is on the scyld.com site under "Redhat 7.0 Instructions" or somesuch. I didn't see it the first time around either, but it is there in plain site. Dave ----- Original Message ----- From: To: Sent: Wednesday, January 31, 2001 9:00 AM Subject: tulip digest, Vol 1 #192 - 2 msgs > > Send tulip mailing list submissions to > tulip@scyld.com > > To subscribe or unsubscribe via the web, visit > http://www.scyld.com/mailman/listinfo/tulip > or, via email, send a message with subject or body 'help' to > tulip-request@scyld.com > You can reach the person managing the list at > tulip-admin@scyld.com > > When replying, please edit your Subject line so it is more specific than > "Re: Contents of tulip digest..." > > > Today's Topics: > > 1. tulip + 2.4? (Matthew S. Eaton) > 2. Re: tulip + 2.4? (Matthew) > > --__--__-- > > Message: 1 > Date: Tue, 30 Jan 2001 21:00:30 -0500 > From: "Matthew S. Eaton" > Organization: University of Virginia > To: tulip@scyld.com > Subject: [tulip] tulip + 2.4? > > Hi all, > > Should the tulip driver compile/run on 2.4 kernels? > > Compilation with 2.4.1 : > > tulip.c: In function `tulip_open': > tulip.c:1488: structure has no member named `tbusy' > tulip.c:1489: structure has no member named `start' > tulip.c: In function `tulip_start_xmit': > tulip.c:2607: structure has no member named `tbusy' > tulip.c:2640: structure has no member named `tbusy' > tulip.c: In function `tulip_interrupt': > tulip.c:2659: structure has no member named `interrupt' > tulip.c:2663: structure has no member named `interrupt' > tulip.c:2744: structure has no member named `tbusy' > tulip.c:2748: structure has no member named `tbusy' > tulip.c:2749: `NET_BH' undeclared (first use in this function) > tulip.c:2749: (Each undeclared identifier is reported only once > tulip.c:2749: for each function it appears in.) > tulip.c:2845: structure has no member named `interrupt' > tulip.c: In function `tulip_close': > tulip.c:2991: structure has no member named `start' > tulip.c:2992: structure has no member named `tbusy' > tulip.c: In function `tulip_get_stats': > tulip.c:3031: structure has no member named `start' > tulip.c: In function `set_rx_mode': > tulip.c:3303: structure has no member named `tbusy' > > > I would use the native 2.4.1 tulip driver included with the kernel. but: > i get a bunch of these: > NETDEV WATCHDOG: eth0: transmit timed out > eth0: Transmit timed out, status fc664010, CSR12 00000000, resetting... > > so I prefer the high performance one's here better :-) > > -- > Matthew S. Eaton > Undergraduate > University of Virginia > School of Engineering and Applied Science > > > --__--__-- > > Message: 2 > From: Matthew > Reply-To: matthew@psychohorse.com > To: "Matthew S. Eaton" , tulip@scyld.com > Subject: Re: [tulip] tulip + 2.4? > Date: Tue, 30 Jan 2001 19:35:27 -0800 > charset="us-ascii" > > No problems here at the moment....However I had to build the module into the > kernel, which I should do anyway I guess. The tulip.o module ended up in its > own directory under net. Was that normal? I have no idea what normal is > though with this kernel. > > What distribution are you using?? > > Matt > On Tuesday 30 January 2001 06:00 pm, Matthew S. Eaton wrote: > > Hi all, > > > > Should the tulip driver compile/run on 2.4 kernels? > > > > Compilation with 2.4.1 : > > > > tulip.c: In function `tulip_open': > > tulip.c:1488: structure has no member named `tbusy' > > tulip.c:1489: structure has no member named `start' > > tulip.c: In function `tulip_start_xmit': > > tulip.c:2607: structure has no member named `tbusy' > > tulip.c:2640: structure has no member named `tbusy' > > tulip.c: In function `tulip_interrupt': > > tulip.c:2659: structure has no member named `interrupt' > > tulip.c:2663: structure has no member named `interrupt' > > tulip.c:2744: structure has no member named `tbusy' > > tulip.c:2748: structure has no member named `tbusy' > > tulip.c:2749: `NET_BH' undeclared (first use in this function) > > tulip.c:2749: (Each undeclared identifier is reported only once > > tulip.c:2749: for each function it appears in.) > > tulip.c:2845: structure has no member named `interrupt' > > tulip.c: In function `tulip_close': > > tulip.c:2991: structure has no member named `start' > > tulip.c:2992: structure has no member named `tbusy' > > tulip.c: In function `tulip_get_stats': > > tulip.c:3031: structure has no member named `start' > > tulip.c: In function `set_rx_mode': > > tulip.c:3303: structure has no member named `tbusy' > > > > > > I would use the native 2.4.1 tulip driver included with the kernel. but: > > i get a bunch of these: > > NETDEV WATCHDOG: eth0: transmit timed out > > eth0: Transmit timed out, status fc664010, CSR12 00000000, resetting... > > > > so I prefer the high performance one's here better :-) > > > > --__--__-- > > _______________________________________________ > tulip mailing list > tulip@scyld.com > http://www.scyld.com/mailman/listinfo/tulip > > > End of tulip Digest > From matthewe@virginia.edu Wed, 31 Jan 2001 13:22:10 -0500 Date: Wed, 31 Jan 2001 13:22:10 -0500 From: Matthew S. Eaton matthewe@virginia.edu Subject: [tulip] Re: tulip + 2.4 --------------12D39E417A9E155800EB640F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm using the latest debian frozen(woody). In any event, the RedHat 7.0 instructions with that error referred to the 2.3 headers that RedHat 7.0 has on their system by default. It also says on at http://www.scyld.com/network/updates.html : -Note that as of December 2000 the 2.4 kernel has not been released, and thus is not supported. I am assuming that perhaps this information is still valid? =) Dave Turner wrote: > Try compiling using kgcc rather than gcc and see if that makes a difference. > Also, put -I/usr/src/linux/include in your compile command line. I had > similar errors and those two changes got the source to compile. FWIW, this > information is on the scyld.com site under "Redhat 7.0 Instructions" or > somesuch. I didn't see it the first time around either, but it is there in > plain site. > > Dave > ----- Original Message ----- > From: > To: > Sent: Wednesday, January 31, 2001 9:00 AM > Subject: tulip digest, Vol 1 #192 - 2 msgs > > > > > Send tulip mailing list submissions to > > tulip@scyld.com > > > > To subscribe or unsubscribe via the web, visit > > http://www.scyld.com/mailman/listinfo/tulip > > or, via email, send a message with subject or body 'help' to > > tulip-request@scyld.com > > You can reach the person managing the list at > > tulip-admin@scyld.com > > > > When replying, please edit your Subject line so it is more specific than > > "Re: Contents of tulip digest..." > > > > > > Today's Topics: > > > > 1. tulip + 2.4? (Matthew S. Eaton) > > 2. Re: tulip + 2.4? (Matthew) > > > > --__--__-- > > > > Message: 1 > > Date: Tue, 30 Jan 2001 21:00:30 -0500 > > From: "Matthew S. Eaton" > > Organization: University of Virginia > > To: tulip@scyld.com > > Subject: [tulip] tulip + 2.4? > > > > Hi all, > > > > Should the tulip driver compile/run on 2.4 kernels? > > > > Compilation with 2.4.1 : > > > > tulip.c: In function `tulip_open': > > tulip.c:1488: structure has no member named `tbusy' > > tulip.c:1489: structure has no member named `start' > > tulip.c: In function `tulip_start_xmit': > > tulip.c:2607: structure has no member named `tbusy' > > tulip.c:2640: structure has no member named `tbusy' > > tulip.c: In function `tulip_interrupt': > > tulip.c:2659: structure has no member named `interrupt' > > tulip.c:2663: structure has no member named `interrupt' > > tulip.c:2744: structure has no member named `tbusy' > > tulip.c:2748: structure has no member named `tbusy' > > tulip.c:2749: `NET_BH' undeclared (first use in this function) > > tulip.c:2749: (Each undeclared identifier is reported only once > > tulip.c:2749: for each function it appears in.) > > tulip.c:2845: structure has no member named `interrupt' > > tulip.c: In function `tulip_close': > > tulip.c:2991: structure has no member named `start' > > tulip.c:2992: structure has no member named `tbusy' > > tulip.c: In function `tulip_get_stats': > > tulip.c:3031: structure has no member named `start' > > tulip.c: In function `set_rx_mode': > > tulip.c:3303: structure has no member named `tbusy' > > > > > > I would use the native 2.4.1 tulip driver included with the kernel. but: > > i get a bunch of these: > > NETDEV WATCHDOG: eth0: transmit timed out > > eth0: Transmit timed out, status fc664010, CSR12 00000000, resetting... > > > > so I prefer the high performance one's here better :-) > > > > -- > > Matthew S. Eaton > > Undergraduate > > University of Virginia > > School of Engineering and Applied Science > > > > > > --__--__-- > > > > Message: 2 > > From: Matthew > > Reply-To: matthew@psychohorse.com > > To: "Matthew S. Eaton" , tulip@scyld.com > > Subject: Re: [tulip] tulip + 2.4? > > Date: Tue, 30 Jan 2001 19:35:27 -0800 > > charset="us-ascii" > > > > No problems here at the moment....However I had to build the module into > the > > kernel, which I should do anyway I guess. The tulip.o module ended up in > its > > own directory under net. Was that normal? I have no idea what normal is > > though with this kernel. > > > > What distribution are you using?? > > > > Matt > > On Tuesday 30 January 2001 06:00 pm, Matthew S. Eaton wrote: > > > Hi all, > > > > > > Should the tulip driver compile/run on 2.4 kernels? > > > > > > Compilation with 2.4.1 : > > > > > > tulip.c: In function `tulip_open': > > > tulip.c:1488: structure has no member named `tbusy' > > > tulip.c:1489: structure has no member named `start' > > > tulip.c: In function `tulip_start_xmit': > > > tulip.c:2607: structure has no member named `tbusy' > > > tulip.c:2640: structure has no member named `tbusy' > > > tulip.c: In function `tulip_interrupt': > > > tulip.c:2659: structure has no member named `interrupt' > > > tulip.c:2663: structure has no member named `interrupt' > > > tulip.c:2744: structure has no member named `tbusy' > > > tulip.c:2748: structure has no member named `tbusy' > > > tulip.c:2749: `NET_BH' undeclared (first use in this function) > > > tulip.c:2749: (Each undeclared identifier is reported only once > > > tulip.c:2749: for each function it appears in.) > > > tulip.c:2845: structure has no member named `interrupt' > > > tulip.c: In function `tulip_close': > > > tulip.c:2991: structure has no member named `start' > > > tulip.c:2992: structure has no member named `tbusy' > > > tulip.c: In function `tulip_get_stats': > > > tulip.c:3031: structure has no member named `start' > > > tulip.c: In function `set_rx_mode': > > > tulip.c:3303: structure has no member named `tbusy' > > > > > > > > > I would use the native 2.4.1 tulip driver included with the kernel. but: > > > i get a bunch of these: > > > NETDEV WATCHDOG: eth0: transmit timed out > > > eth0: Transmit timed out, status fc664010, CSR12 00000000, resetting... > > > > > > so I prefer the high performance one's here better :-) > > > > > > > > --__--__-- > > > > _______________________________________________ > > tulip mailing list > > tulip@scyld.com > > http://www.scyld.com/mailman/listinfo/tulip > > > > > > End of tulip Digest > > > > _______________________________________________ > tulip mailing list > tulip@scyld.com > http://www.scyld.com/mailman/listinfo/tulip -- Matthew S. Eaton Undergraduate University of Virginia School of Engineering and Applied Science --------------12D39E417A9E155800EB640F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I'm using the latest debian frozen(woody). In any event, the RedHat 7.0 instructions
with that error referred to the 2.3 headers that RedHat 7.0 has on their system
by default. It also says on at http://www.scyld.com/network/updates.html :

-Note that as of December 2000 the 2.4 kernel has not been released, and thus
is not supported.

I am assuming that perhaps this information is still valid? =)

Dave Turner wrote:

Try compiling using kgcc rather than gcc and see if that makes a difference.
Also, put -I/usr/src/linux/include in your compile command line.  I had
similar errors and those two changes got the source to compile.  FWIW, this
information is on the scyld.com site under "Redhat 7.0 Instructions" or
somesuch.  I didn't see it the first time around either, but it is there in
plain site.

Dave
----- Original Message -----
From: <tulip-admin@scyld.com>
To: <tulip@scyld.com>
Sent: Wednesday, January 31, 2001 9:00 AM
Subject: tulip digest, Vol 1 #192 - 2 msgs

>
> Send tulip mailing list submissions to
> tulip@scyld.com
>
> To subscribe or unsubscribe via the web, visit
> http://www.scyld.com/mailman/listinfo/tulip
> or, via email, send a message with subject or body 'help' to
> tulip-request@scyld.com
> You can reach the person managing the list at
> tulip-admin@scyld.com
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of tulip digest..."
>
>
> Today's Topics:
>
>   1. tulip + 2.4? (Matthew S. Eaton)
>   2. Re: tulip + 2.4? (Matthew)
>
> --__--__--
>
> Message: 1
> Date: Tue, 30 Jan 2001 21:00:30 -0500
> From: "Matthew S. Eaton" <matthewe@virginia.edu>
> Organization: University of Virginia
> To: tulip@scyld.com
> Subject: [tulip] tulip + 2.4?
>
> Hi all,
>
> Should the tulip driver compile/run on 2.4 kernels?
>
> Compilation with 2.4.1 :
>
> tulip.c: In function `tulip_open':
> tulip.c:1488: structure has no member named `tbusy'
> tulip.c:1489: structure has no member named `start'
> tulip.c: In function `tulip_start_xmit':
> tulip.c:2607: structure has no member named `tbusy'
> tulip.c:2640: structure has no member named `tbusy'
> tulip.c: In function `tulip_interrupt':
> tulip.c:2659: structure has no member named `interrupt'
> tulip.c:2663: structure has no member named `interrupt'
> tulip.c:2744: structure has no member named `tbusy'
> tulip.c:2748: structure has no member named `tbusy'
> tulip.c:2749: `NET_BH' undeclared (first use in this function)
> tulip.c:2749: (Each undeclared identifier is reported only once
> tulip.c:2749: for each function it appears in.)
> tulip.c:2845: structure has no member named `interrupt'
> tulip.c: In function `tulip_close':
> tulip.c:2991: structure has no member named `start'
> tulip.c:2992: structure has no member named `tbusy'
> tulip.c: In function `tulip_get_stats':
> tulip.c:3031: structure has no member named `start'
> tulip.c: In function `set_rx_mode':
> tulip.c:3303: structure has no member named `tbusy'
>
>
> I would use the native 2.4.1 tulip driver included with the kernel. but:
> i get a bunch of these:
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: Transmit timed out, status fc664010, CSR12 00000000, resetting...
>
> so I prefer the high performance one's here better :-)
>
> --
> Matthew S. Eaton
> Undergraduate
> University of Virginia
> School of Engineering and Applied Science
>
>
> --__--__--
>
> Message: 2
> From: Matthew <matthew@psychohorse.com>
> Reply-To: matthew@psychohorse.com
> To: "Matthew S. Eaton" <matthewe@virginia.edu>, tulip@scyld.com
> Subject: Re: [tulip] tulip + 2.4?
> Date: Tue, 30 Jan 2001 19:35:27 -0800
> charset="us-ascii"
>
> No problems here at the moment....However I had to build the module into
the
> kernel, which I should do anyway I guess. The tulip.o module ended up in
its
> own directory under net. Was that normal? I have no idea what normal is
> though with this kernel.
>
> What distribution are you using??
>
> Matt
> On Tuesday 30 January 2001 06:00 pm, Matthew S. Eaton wrote:
> > Hi all,
> >
> > Should the tulip driver compile/run on 2.4 kernels?
> >
> > Compilation with 2.4.1 :
> >
> > tulip.c: In function `tulip_open':
> > tulip.c:1488: structure has no member named `tbusy'
> > tulip.c:1489: structure has no member named `start'
> > tulip.c: In function `tulip_start_xmit':
> > tulip.c:2607: structure has no member named `tbusy'
> > tulip.c:2640: structure has no member named `tbusy'
> > tulip.c: In function `tulip_interrupt':
> > tulip.c:2659: structure has no member named `interrupt'
> > tulip.c:2663: structure has no member named `interrupt'
> > tulip.c:2744: structure has no member named `tbusy'
> > tulip.c:2748: structure has no member named `tbusy'
> > tulip.c:2749: `NET_BH' undeclared (first use in this function)
> > tulip.c:2749: (Each undeclared identifier is reported only once
> > tulip.c:2749: for each function it appears in.)
> > tulip.c:2845: structure has no member named `interrupt'
> > tulip.c: In function `tulip_close':
> > tulip.c:2991: structure has no member named `start'
> > tulip.c:2992: structure has no member named `tbusy'
> > tulip.c: In function `tulip_get_stats':
> > tulip.c:3031: structure has no member named `start'
> > tulip.c: In function `set_rx_mode':
> > tulip.c:3303: structure has no member named `tbusy'
> >
> >
> > I would use the native 2.4.1 tulip driver included with the kernel. but:
> > i get a bunch of these:
> > NETDEV WATCHDOG: eth0: transmit timed out
> > eth0: Transmit timed out, status fc664010, CSR12 00000000, resetting...
> >
> > so I prefer the high performance one's here better :-)
>
>
>
> --__--__--
>
> _______________________________________________
> tulip mailing list
> tulip@scyld.com
> http://www.scyld.com/mailman/listinfo/tulip
>
>
> End of tulip Digest
>

_______________________________________________
tulip mailing list
tulip@scyld.com
http://www.scyld.com/mailman/listinfo/tulip

-- 
Matthew S. Eaton
Undergraduate
University of Virginia
School of Engineering and Applied Science
  --------------12D39E417A9E155800EB640F-- From matthew@psychohorse.com Wed, 31 Jan 2001 10:30:50 -0800 (PST) Date: Wed, 31 Jan 2001 10:30:50 -0800 (PST) From: Matthew matthew@psychohorse.com Subject: [tulip] Re: tulip + 2.4 Another to make sure you have is the latest modutils package.....The latest it 2.4.2 Matt On Wed, 31 Jan 2001, Dave Turner wrote: > Try compiling using kgcc rather than gcc and see if that makes a difference. > Also, put -I/usr/src/linux/include in your compile command line. I had > similar errors and those two changes got the source to compile. FWIW, this > information is on the scyld.com site under "Redhat 7.0 Instructions" or > somesuch. I didn't see it the first time around either, but it is there in > plain site. > > Dave > ----- Original Message ----- > From: > To: > Sent: Wednesday, January 31, 2001 9:00 AM > Subject: tulip digest, Vol 1 #192 - 2 msgs > > > > > > Send tulip mailing list submissions to > > tulip@scyld.com > > > > To subscribe or unsubscribe via the web, visit > > http://www.scyld.com/mailman/listinfo/tulip > > or, via email, send a message with subject or body 'help' to > > tulip-request@scyld.com > > You can reach the person managing the list at > > tulip-admin@scyld.com > > > > When replying, please edit your Subject line so it is more specific than > > "Re: Contents of tulip digest..." > > > > > > Today's Topics: > > > > 1. tulip + 2.4? (Matthew S. Eaton) > > 2. Re: tulip + 2.4? (Matthew) > > > > --__--__-- > > > > Message: 1 > > Date: Tue, 30 Jan 2001 21:00:30 -0500 > > From: "Matthew S. Eaton" > > Organization: University of Virginia > > To: tulip@scyld.com > > Subject: [tulip] tulip + 2.4? > > > > Hi all, > > > > Should the tulip driver compile/run on 2.4 kernels? > > > > Compilation with 2.4.1 : > > > > tulip.c: In function `tulip_open': > > tulip.c:1488: structure has no member named `tbusy' > > tulip.c:1489: structure has no member named `start' > > tulip.c: In function `tulip_start_xmit': > > tulip.c:2607: structure has no member named `tbusy' > > tulip.c:2640: structure has no member named `tbusy' > > tulip.c: In function `tulip_interrupt': > > tulip.c:2659: structure has no member named `interrupt' > > tulip.c:2663: structure has no member named `interrupt' > > tulip.c:2744: structure has no member named `tbusy' > > tulip.c:2748: structure has no member named `tbusy' > > tulip.c:2749: `NET_BH' undeclared (first use in this function) > > tulip.c:2749: (Each undeclared identifier is reported only once > > tulip.c:2749: for each function it appears in.) > > tulip.c:2845: structure has no member named `interrupt' > > tulip.c: In function `tulip_close': > > tulip.c:2991: structure has no member named `start' > > tulip.c:2992: structure has no member named `tbusy' > > tulip.c: In function `tulip_get_stats': > > tulip.c:3031: structure has no member named `start' > > tulip.c: In function `set_rx_mode': > > tulip.c:3303: structure has no member named `tbusy' > > > > > > I would use the native 2.4.1 tulip driver included with the kernel. but: > > i get a bunch of these: > > NETDEV WATCHDOG: eth0: transmit timed out > > eth0: Transmit timed out, status fc664010, CSR12 00000000, resetting... > > > > so I prefer the high performance one's here better :-) > > > > -- > > Matthew S. Eaton > > Undergraduate > > University of Virginia > > School of Engineering and Applied Science > > > > > > --__--__-- > > > > Message: 2 > > From: Matthew > > Reply-To: matthew@psychohorse.com > > To: "Matthew S. Eaton" , tulip@scyld.com > > Subject: Re: [tulip] tulip + 2.4? > > Date: Tue, 30 Jan 2001 19:35:27 -0800 > > charset="us-ascii" > > > > No problems here at the moment....However I had to build the module into > the > > kernel, which I should do anyway I guess. The tulip.o module ended up in > its > > own directory under net. Was that normal? I have no idea what normal is > > though with this kernel. > > > > What distribution are you using?? > > > > Matt > > On Tuesday 30 January 2001 06:00 pm, Matthew S. Eaton wrote: > > > Hi all, > > > > > > Should the tulip driver compile/run on 2.4 kernels? > > > > > > Compilation with 2.4.1 : > > > > > > tulip.c: In function `tulip_open': > > > tulip.c:1488: structure has no member named `tbusy' > > > tulip.c:1489: structure has no member named `start' > > > tulip.c: In function `tulip_start_xmit': > > > tulip.c:2607: structure has no member named `tbusy' > > > tulip.c:2640: structure has no member named `tbusy' > > > tulip.c: In function `tulip_interrupt': > > > tulip.c:2659: structure has no member named `interrupt' > > > tulip.c:2663: structure has no member named `interrupt' > > > tulip.c:2744: structure has no member named `tbusy' > > > tulip.c:2748: structure has no member named `tbusy' > > > tulip.c:2749: `NET_BH' undeclared (first use in this function) > > > tulip.c:2749: (Each undeclared identifier is reported only once > > > tulip.c:2749: for each function it appears in.) > > > tulip.c:2845: structure has no member named `interrupt' > > > tulip.c: In function `tulip_close': > > > tulip.c:2991: structure has no member named `start' > > > tulip.c:2992: structure has no member named `tbusy' > > > tulip.c: In function `tulip_get_stats': > > > tulip.c:3031: structure has no member named `start' > > > tulip.c: In function `set_rx_mode': > > > tulip.c:3303: structure has no member named `tbusy' > > > > > > > > > I would use the native 2.4.1 tulip driver included with the kernel. but: > > > i get a bunch of these: > > > NETDEV WATCHDOG: eth0: transmit timed out > > > eth0: Transmit timed out, status fc664010, CSR12 00000000, resetting... > > > > > > so I prefer the high performance one's here better :-) > > > > > > > > --__--__-- > > > > _______________________________________________ > > tulip mailing list > > tulip@scyld.com > > http://www.scyld.com/mailman/listinfo/tulip > > > > > > End of tulip Digest > > > > > _______________________________________________ > tulip mailing list > tulip@scyld.com > http://www.scyld.com/mailman/listinfo/tulip >