Avneet Bhatia
abhatia@uwaterloo.ca ------=_NextPart_000_0006_01BF293F.302B8460-- From eliot.muir@interfaceware.com Mon Nov 8 15:28:11 1999 Date: Mon Nov 8 15:28:11 1999 From: Eliot Muir eliot.muir@interfaceware.com Subject: Strange cutting out problem with tulip driver. Hi, I have a strange cutting out problem with my TCP/IP ethernet connection using the tulip driver. I'm running two machines, one Linux running a Mandrake Redhat distribution and the other is a Windows NT 4.0 machine. They're connected using 20m of BNC cable and have both been assigned static IPs (no other machines are connected). The behaviour is that I have to ping from the Linux box to the NT box to get the TCP/IP connection working. Then everything works fine, I can use telnet, samba and ftp etc. etc. with no trouble. Then usually after about half an hour all the TCP/IP connections break and the only way I seem to be able to get the TCP/IP working again is to go to the Linux box and ping the NT box. I usually have to do this a couple of times before it works. Once it starts being able to ping again and the TCP/IP connections work until it cuts out again after half an hour. The printout from dmesg is: Linux version 2.2.10 (root@testbox.interfaceware) (gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release)) #12 Fri Nov 5 18:41:18 NZDT 1999 Detected 400920929 Hz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 399.77 BogoMIPS Memory: 63244k/65472k available (916k kernel code, 412k reserved, 864k data, 36k init) CPU: Intel Celeron (Mendocino) stepping 05 Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.10 entry at 0xfb350 PCI: Using configuration type 1 PCI: Probing PCI hardware Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP Starting kswapd v 1.5 parport0: PC-style at 0x378 [SPP,PS2] parport0: no IEEE-1284 device present. Detected PS/2 Mouse Port. Serial driver version 4.27 with no serial options enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A PIIX4: IDE controller on PCI bus 00 dev 39 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio hda: ST310232A, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: ST310232A, 9768MB w/512kB Cache, CHS=1245/255/63, UDMA Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 tulip.c:v0.91e 5/27/99 becker@cesdis.gsfc.nasa.gov eth0: ASIX AX88140 rev 16 at 0xd400, 00:80:AD:F0:21:23, IRQ 5. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. eth0: MII transceiver #1 config 1000 status 786b advertising 01e1. eth0: Advertising 0001 on PHY 1, previously advertising 01e1. Partition check: hda: hda1 hda2 hda3 < hda5 hda6 > hda4 NTFS version 990411 VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 36k freed Adding Swap: 128484k swap-space (priority -1) I'm happy to do what it takes to print out more debugging information if it helps - has anyone else seen anything like this? Cheers, Eliot -- Eliot Muir, Technical Director iNTERFACEWARE mailto:eliot.muir@interfaceware.com Voice 64-21-333068 http://www.interfaceware.com Makers of iNTERFACEWARE Chameleon "Program to the iNTERFACE not the implementation" From becker@cesdis.gsfc.nasa.gov Mon Nov 8 15:47:26 1999 Date: Mon Nov 8 15:47:26 1999 From: Donald Becker becker@cesdis.gsfc.nasa.gov Subject: Strange cutting out problem with tulip driver. On Tue, 9 Nov 1999, Eliot Muir wrote: > I have a strange cutting out problem with my TCP/IP ethernet connection > using the tulip driver. .. > The behaviour is that I have to ping from the Linux box to the NT box to > get the TCP/IP connection working. Then everything works fine, I can use > telnet, samba and ftp etc. etc. with no trouble. ... > tulip.c:v0.91e 5/27/99 becker@cesdis.gsfc.nasa.gov > eth0: ASIX AX88140 rev 16 at 0xd400, 00:80:AD:F0:21:23, IRQ 5. You must update to the v0.91g driver, which has the setting needed to allow the AX88140 to receive broadcast packets. ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/test/tulip.c Donald Becker Scyld Computing Corporation, and USRA-CESDIS, becker@cesdis.gsfc.nasa.gov From marc@destek.net Wed Nov 10 11:09:29 1999 Date: Wed Nov 10 11:09:29 1999 From: Marc Evans marc@destek.net Subject: Compaq Presario 1900T laptop dock with 21142 rev 65 Hello - I have just acquired a Compaq 1900T with a docking wedge that contains a Tulip 21142 rev 65 ethernet. I have installed RedHat 6.1 on it, and am unable to use the ethernet. Prior to loading RH, Windows/98 was installed, and worked fine through the ethernet device. I have experimented a bit and have discovered the following: - When connected to my 10baseT half-duplex hub, the partition light immediately comes on. This did not happen under windows/98. - When connected to my 10/100 switch, if I do: ifconfig eth0 down ifconfig eth0 up ping {addr_on_lan} I get 4 seconds worth of pings through, before failure. I can instead do a "ping -f {addr_on_lan}" and get about 10000 packets through (or four seconds worth) before failure. I also observe that RH comes with the tulip driver version 0.89H which appears to be slightly behind the most current available 0.91e. Is there any reason for me to believe that what I am seeing has been fixed in the newer version? (Somewhat retorical question, since I plan to try to compile that soon anyway). Does anyone have any suggestions as to how I might get this device operational? Please reply directly, since I am not a list member. Thanks in advance - Marc From frank.stefani@ead-systeme.de Thu Nov 11 03:00:47 1999 Date: Thu Nov 11 03:00:47 1999 From: Frank Stefani frank.stefani@ead-systeme.de Subject: Beeeeeeeeep [Fastline-II-PCI UTP, SuSE Linux 6.2 (Kernel 2.2.10)] Hi all, we use discless clients with Tulip based Fastline network cards. Everything works well most of the time. Occasionally one or the other of the clients starts to beeeeeeeeeep for a long time, while everything is still working. I found no reason to avoid this, no debug/error messages in the syslog or elsewhere. Finally I gave up and disconnected the speaker :-) but I'd rather like to know a reason for this beeping and a way to avoid it (kernel module option??) Any help is greatly appreciated, TIA, Frank -- ____ ___ ___ Frank Stefani | frank.stefani@ead-systeme.de / / | / \ EAD-Systeme GmbH | www.ead-systeme.de /--- /---| / / Nachfeldstr. 4 | Phone +49 8821 9623-0 /____ / | /____/ D-82490 Farchant | Fax +49 8821 9623-20 From bob@drzyzgula.org Thu Nov 11 07:00:14 1999 Date: Thu Nov 11 07:00:14 1999 From: Bob Drzyzgula bob@drzyzgula.org Subject: Beeeeeeeeep Do your systems have environmental monitors? If so, there should be a page in the BIOS/CMOS setup utility to set thresholds for CPU temperature, supply voltages, fan speeds, etc. Often there will be one temperature threshold for sounding an alarm and another for system shutdown. It could be that on occasion some of your systems reach a temperature between those two setpoints. --Bob On Thu, Nov 11, 1999 at 09:01:15AM +0100, Frank Stefani wrote: > [Fastline-II-PCI UTP, SuSE Linux 6.2 (Kernel 2.2.10)] > > Hi all, > > we use discless clients with Tulip based Fastline network cards. > Everything works well most of the time. Occasionally one or the > other of the clients starts to beeeeeeeeeep for a long time, while > everything is still working. > > I found no reason to avoid this, no debug/error messages in the > syslog or elsewhere. Finally I gave up and disconnected the > speaker :-) but I'd rather like to know a reason for this beeping > and a way to avoid it (kernel module option??) > > Any help is greatly appreciated, TIA, > Frank > -- > ____ ___ ___ Frank Stefani | frank.stefani@ead-systeme.de > / / | / \ EAD-Systeme GmbH | www.ead-systeme.de > /--- /---| / / Nachfeldstr. 4 | Phone +49 8821 9623-0 > /____ / | /____/ D-82490 Farchant | Fax +49 8821 9623-20 -- ============================================================ Bob Drzyzgula It's not a problem bob@drzyzgula.org until something bad happens ============================================================ http://www.drzyzgula.org/bob/electronics/ ============================================================ From frank.stefani@ead-systeme.de Thu Nov 11 08:49:43 1999 Date: Thu Nov 11 08:49:43 1999 From: Frank Stefani frank.stefani@ead-systeme.de Subject: Beeeeeeeeep We do have those BIOS features, but there is nothing related to network cards. The behaviour appears to be solely network relevant and has nothing to do with temperatures or fan speeds. If we change the network card to a different manufacturer, we never hear a sound. Simply, we MUST use the FASTline cards and they are really good for all our purposes. Just that beeeeeep thing gets on our nerves ... Frank Bob Drzyzgula schrieb: > > Do your systems have environmental monitors? If > so, there should be a page in the BIOS/CMOS setup > utility to set thresholds for CPU temperature, > supply voltages, fan speeds, etc. Often there will > be one temperature threshold for sounding an alarm > and another for system shutdown. It could be that > on occasion some of your systems reach a temperature > between those two setpoints. > > --Bob > > On Thu, Nov 11, 1999 at 09:01:15AM +0100, Frank Stefani wrote: > > [Fastline-II-PCI UTP, SuSE Linux 6.2 (Kernel 2.2.10)] > > > > Hi all, > > > > we use discless clients with Tulip based Fastline network cards. > > Everything works well most of the time. Occasionally one or the > > other of the clients starts to beeeeeeeeeep for a long time, while > > everything is still working. > > > > I found no reason to avoid this, no debug/error messages in the > > syslog or elsewhere. Finally I gave up and disconnected the > > speaker :-) but I'd rather like to know a reason for this beeping > > and a way to avoid it (kernel module option??) > > > > Any help is greatly appreciated, TIA, > > Frank > > -- > > ____ ___ ___ Frank Stefani | frank.stefani@ead-systeme.de > > / / | / \ EAD-Systeme GmbH | www.ead-systeme.de > > /--- /---| / / Nachfeldstr. 4 | Phone +49 8821 9623-0 > > /____ / | /____/ D-82490 Farchant | Fax +49 8821 9623-20 > > -- > ============================================================ > Bob Drzyzgula It's not a problem > bob@drzyzgula.org until something bad happens > ============================================================ > http://www.drzyzgula.org/bob/electronics/ > ============================================================ -- ____ ___ ___ Frank Stefani | frank.stefani@ead-systeme.de / / | / \ EAD-Systeme GmbH | www.ead-systeme.de /--- /---| / / Nachfeldstr. 4 | Phone +49 8821 9623-0 /____ / | /____/ D-82490 Farchant | Fax +49 8821 9623-20 From jds@aixulsa.ulsa.mx Mon Nov 15 12:51:20 1999 Date: Mon Nov 15 12:51:20 1999 From: Ing. Jesus Delgado jds@aixulsa.ulsa.mx Subject: Drivers for network card ANSEL 2095 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BF2F60.06DCE910 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Iam need the drivers for Network Card ANSEL 2095 Fast Ethernet = for LINUX redhat 6.1 Help me please Regards. ------=_NextPart_000_0005_01BF2F60.06DCE910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

= Iam need the=20 drivers for Network Card ANSEL 2095 Fast Ethernet for LINUX redhat=20 6.1

= Help me=20 please

Regards.

------=_NextPart_000_0005_01BF2F60.06DCE910-- From bmullins@asante.com Mon Nov 15 13:37:44 1999 Date: Mon Nov 15 13:37:44 1999 From: Breen Mullins bmullins@asante.com Subject: tulip driver & Asante Fast 10/100 card >Bob Farmer (ucs_brf@unx1.shsu.edu) reported: > The net cards we've been buying, Asante Fast 10/100, recently switched >> > from 21140A chips to the PNIC chips. On startup, the driver reports the >> > chip as a "Lite-On 82c168 PNIC rev 32". It works for a bit, but as soon >> > as you try to transfer more than about 50K of data through the card, it >> > locks, and the interface has to be taken down and brought back up again to >> > restore connectivity. >> I've been looking at this problem with Bob and I see the same things here. >> What's the whole detection message? >> Is the an MII transceiver, or does it use the internal encoder and an >> external twister (SYM PHY)? > >The whole detection message is this (with 0.89H): > >tulip.c:v0.89H 5/23/98 becker@cesdis.gsfc.nasa.gov >eth0: Lite-On 82c168 PNIC at 0xe400, 00 00 b4 94 e0 99, IRQ 10. >eth0: MII transceiver found at MDIO address 1, config 3100 status 7829. >eth0: Advertising 01e1 on PHY 1, previously advertising 01e1. >eth0: Changing PNIC configuration to full-duplex, CSR6 812e0200. > >I am using Intel BX chipset Pentium II motherboards. > >If, while doing the receive-file test, I turn on "debug=3" on the module, >I get this output when the interface hangs: > >eth0: Oversized Ethernet frame spanned multiple buffers, status 7fff0200! >eth0: Oversized Ethernet frame spanned multiple buffers, status 08018192! I get these messages, but the interface has not yet frozen when I receive them -- my ftp transfers (about 30MB) always complete. The first (and other odd-numbered) message always report status 7fff0200. The even numbered messages are of the form 06xx8186 or occasionally 06xx8182. > >When using half-duplex those warnings above never appear. > >Now, retrying all of the above things with 0.91g, everything's the same >except one thing: no crash or interface hang when I send a large file with >FTP. Just a ton of the "Oversized Ethernet frame spanned multiple >buffers" warnings (debug=3). Still the same interface hang when receiving >a large file with FTP, though, at full-duplex. After the transfer finishes if I either exit the ftp program or wait a minute or two, I get these messages: Too much work during an interrupt, csr5=0x026f0050. Too much work during an interrupt, csr5=0x026d80d4. at which point the interface must be brought down and restarted, as Bob reports. I also see another problem which worries me even more: the address is being put on the wire incorrectly. >eth0: Lite-On 82c168 PNIC at 0xe400, 00 00 b4 94 e0 99, IRQ 10. That isn't an Asante address; it should be 000094 b499e0. The byte-reversal happens only with the tulip driver; our MacOS and Windows drivers pick up the address correctly. A generic LiteOn card works correctly with the same tulip driver. Here are the EEPROM contents of the two cards I'm using here: LiteOn: 00a0 cc2c 5734 f001 128a 00f1 0000 f19e 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 Asante: 0000 94b4 6061 f001 128a 00f1 0000 8851 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 Any help with these problems is much appreciated. Breen Mullins SQA Engineer Asante Technologies, Inc. 800-662-9686x323 From ucs_brf@unx1.shsu.edu Mon Nov 15 16:13:45 1999 Date: Mon Nov 15 16:13:45 1999 From: Bob Farmer ucs_brf@unx1.shsu.edu Subject: tulip driver & Asante Fast 10/100 card > >Bob Farmer (ucs_brf@unx1.shsu.edu) reported: > > The net cards we've been buying, Asante Fast 10/100, recently switched > >> > from 21140A chips to the PNIC chips. On startup, the driver reports the > >> > chip as a "Lite-On 82c168 PNIC rev 32". It works for a bit, but as soon > >> > as you try to transfer more than about 50K of data through the card, it > >> > locks, and the interface has to be taken down and brought back up again to > >> > restore connectivity. > >> > > I've been looking at this problem with Bob and I see the same things > here. > > >> What's the whole detection message? > >> Is the an MII transceiver, or does it use the internal encoder and an > >> external twister (SYM PHY)? > > > >The whole detection message is this (with 0.89H): > > > >tulip.c:v0.89H 5/23/98 becker@cesdis.gsfc.nasa.gov > >eth0: Lite-On 82c168 PNIC at 0xe400, 00 00 b4 94 e0 99, IRQ 10. > >eth0: MII transceiver found at MDIO address 1, config 3100 status 7829. > >eth0: Advertising 01e1 on PHY 1, previously advertising 01e1. > >eth0: Changing PNIC configuration to full-duplex, CSR6 812e0200. > > > >I am using Intel BX chipset Pentium II motherboards. > > > >If, while doing the receive-file test, I turn on "debug=3" on the module, > >I get this output when the interface hangs: > > > >eth0: Oversized Ethernet frame spanned multiple buffers, status 7fff0200! > >eth0: Oversized Ethernet frame spanned multiple buffers, status 08018192! > > I get these messages, but the interface has not yet frozen when > > The first (and other odd-numbered) message always report status 7fff0200. > The even numbered messages are of the form 06xx8186 or occasionally > 06xx8182. > > > > >When using half-duplex those warnings above never appear. > > > > >Now, retrying all of the above things with 0.91g, everything's the same > >except one thing: no crash or interface hang when I send a large file with > >FTP. Just a ton of the "Oversized Ethernet frame spanned multiple > >buffers" warnings (debug=3). Still the same interface hang when receiving > >a large file with FTP, though, at full-duplex. > > > After the transfer finishes if I either exit the ftp program or > wait a minute or two, I get these messages: > > Too much work during an interrupt, csr5=0x026f0050. > Too much work during an interrupt, csr5=0x026d80d4. > > at which point the interface must be brought down and restarted, > as Bob reports. The "too much work during an interrupt" error is normal when transferring a whole lot of data when you haven't modified the "max_interrupt_work" variable. When I did my testing, I had modified it. I think I was using "max_interrupt_work=32000". So, I didn't get the "Too much work" error, yet my interface still froze. Bob From esnible@goodnet.com Mon Nov 15 22:22:06 1999 Date: Mon Nov 15 22:22:06 1999 From: Ed Snible esnible@goodnet.com Subject: Newbie question I am new to Linux. I have two Kingston KNE100TX tulip cards. I installed Linux and it found the cards but they could not ping each other. I suspected link speed problems (the cards are 100mbps, but my SOHOware four port hub is 10mbps). I tried some stuff on the cesdis page and came here. Any help greatly appreciated, I'm attaching the output from insmod, ifconfig up, and tulip-diag: # /sbin/insmod tulip.o debug=3 options=9 (/var/log/messages reports) ... kernel: tulip.c:v0.89H 5/23/98 becker@cesdis.gsfc.nasa.gov Nov 15 21:55:03 asus kernel: eth0: Digital DS21142/3 Tulip at 0xb800, 00 c0 f0 3b 66 ae, IRQ 10. xxx kernel: eth0: EEPROM default media type Autosense. ... kernel: eth0: MII interface PHY 0, setup/reset sequences 0/0 long, capabilities e0 78. ... kernel: eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. ... kernel: eth0: MII transceiver found at MDIO address 1, config 3100 status 782d. ... kernel: PCI latency timer (CFLT) is 0x20, PCI command is 0017. # /sbin/ifconfig eth0 up (var/log/messages reports) ... kernel: eth0: Using user-specified media MII 10baseT. ... kernel: eth0: 21142 negotiation status 000000c6, MII. ... kernel: eth0: 21142 negotiation failed, status 000000c6. ... kernel: eth0: Testing new 21142 media 100baseTx. ... kernel: eth0: The transmitter stopped! CSR5 is f0678006, CSR6 b3862002. # tulip-diag -m tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0xb800. 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 threshold is 128. The NWay status register is 000000c6. MII PHY found at address 1, status 0x782d. MII PHY #1 transceiver registers: 3100 782d 0016 f831 0021 0021 ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff 0022 ff00 0000 fff0 00a0 ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff. Internal autonegotiation state is 'Autonegotiation disabled'. Any ideas? PS: If it helps, I'm using PII-400, Asus P2B, Redhat 6.0. The cards and hub have worked in the past under Windows98. From jds@aixulsa.ulsa.mx Wed Nov 17 11:58:43 1999 Date: Wed Nov 17 11:58:43 1999 From: Ing. Jesus Delgado jds@aixulsa.ulsa.mx Subject: Ayuda para compilar driver ?? This is a multi-part message in MIME format. ------=_NextPart_000_0023_01BF30EA.F5B4CA90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hola a todos: Tengo un problema al compilar un driver para una tarjeta de = red,=20 ya trate de ponerle la bandera "-O" con diferentes valores que es la que = me pide, pero no he tenido exito, el mensaje es el siguiente: #make tulip cc tulip.c -o tulip tulip.c:100: warning: #warning You must compile this file with the = correct options! tulip.c:101: warning: #warning See the last lines of the source file. tulip.c:102: #error You must compile this driver with "-O". make: *** [tulip] Error 1 otra opciones que he tratado es : gcc -O1 tulip.c -o tulip gcc -O2 tulip.c -o tulip gcc -O0 tulip.c -o tulip gcc tulip.c -o tulip -O2 etc, etc. y sigo teniendo el mismo error. Espero me puedan ayudar. Saludos. Se libre usa LINUX. ------=_NextPart_000_0023_01BF30EA.F5B4CA90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hola a todos:

= Tengo =20 un problema al compilar un driver para una tarjeta de red,

ya trate de ponerle la bandera "-O" con = diferentes=20 valores que es la que me pide, pero no he tenido exito, el mensaje es el = siguiente:

#make tulip

cc tulip.c -o tulip

tulip.c:100: warning: #warning You must compile this file with the = correct=20 options!

tulip.c:101: warning: #warning See the last lines of the source = file.

tulip.c:102: #error You must compile this driver with "-O".

make: *** [tulip] Error 1

otra opciones que he tratado es = :

gcc -O1 tulip.c -o tulip

gcc -O2 tulip.c -o = tulip

gcc -O0 tulip.c -o = tulip

gcc tulip.c -o tulip = -O2

etc, etc.

y sigo teniendo el mismo error.

Espero me puedan ayudar.

Saludos.

Se libre usa LINUX.

------=_NextPart_000_0023_01BF30EA.F5B4CA90-- From jds@aixulsa.ulsa.mx Wed Nov 17 12:05:25 1999 Date: Wed Nov 17 12:05:25 1999 From: Ing. Jesus Delgado jds@aixulsa.ulsa.mx Subject: problemas para compilar un driver Hola a todos: Tengo un problema al compilar un driver para una tarjeta de red, ya trate de ponerle la bandera "-O" con diferentes valores que es la que me pide, pero no he tenido exito, el mensaje es el siguiente: #make tulip cc tulip.c -o tulip tulip.c:100: warning: #warning You must compile this file with the correct options! tulip.c:101: warning: #warning See the last lines of the source file. tulip.c:102: #error You must compile this driver with "-O". make: *** [tulip] Error 1 otra opciones que he tratado es : gcc -O1 tulip.c -o tulip gcc -O2 tulip.c -o tulip gcc -O0 tulip.c -o tulip gcc tulip.c -o tulip -O2 etc, etc.y sigo teniendo el mismo error. Espero me puedan ayudar. Saludos. Se libre usa LINUX From becker@cesdis.gsfc.nasa.gov Wed Nov 17 16:29:07 1999 Date: Wed Nov 17 16:29:07 1999 From: Donald Becker becker@cesdis.gsfc.nasa.gov Subject: problemas para compilar un driver On Wed, 17 Nov 1999, Ing. Jesus Delgado wrote: > Tengo un problema al compilar un driver para una tarjeta de red, > ya trate de ponerle la bandera "-O" con diferentes valores que es la que > me pide, pero no he tenido exito, el mensaje es el siguiente: > #make tulip > cc tulip.c -o tulip > > tulip.c:100: warning: #warning You must compile this file with the correct > options! > > tulip.c:101: warning: #warning See the last lines of the source file. > > tulip.c:102: #error You must compile this driver with "-O". > > make: *** [tulip] Error 1 > > otra opciones que he tratado es : > > gcc -O1 tulip.c -o tulip Use gcc -DMODULE -D__KERNEL__ -O6 -c tulip.c Donald Becker Scyld Computing Corporation, and USRA-CESDIS, becker@cesdis.gsfc.nasa.gov From wolfgang.walter@stusta.mhn.de Mon Nov 22 23:10:59 1999 Date: Mon Nov 22 23:10:59 1999 From: Wolfgang Walter wolfgang.walter@stusta.mhn.de Subject: bug in tulip_rx? Hi, We have a server with heavy load (2.2.14pre4, 64MB Ram, D-Link 530CT+) running squid. The problem is that it sometimes just stops receiving frames. A ifconfig down and then restart of the network cures the problem. Nothing is logged. The same machine just worked fine with 2.0.38 for month. So I first thought it might be a problem of the tulip-driver of 2.2.14pre4 and I replaced it with several older versions - didn't help. I now took a closer look at the drivers and I think I found a problem. Please correct me if I'm wrong. The following situation may happens: cur_rx == dirty_rx + RX_RING_SIZE This case happens if (and only if) we cannot allocate any skb for the receive-ring. In this situation therefor we cannot receive frames any more. If a frame arrives, the 21041 sets a RU-interrupt and the receiving process is suspended. tulip_rx is entered. 2 possibilities: 1. we can allocate at least one skb. In this case dirty_rx gets increased and 21041 will switch in running mode when the next frame arrives. 2. we cannot allocate a skb. In this case 21041 remains in suspend mode and will not send any further interrupt (if I read the manual correctly) which will call tulip_rx => hang. A workaround would either to use the timer of the chip and a receive poll command or the following modification (is not meant as patch but as idea) in tulip_rx: unsigned int orx_dirty = tp->rx_dirty; int skbs = rx_work_limit; int lskb = -1; .... while(...) { if ( (pkt_len < rx_copybreak || skbs == 1) && (skb = dev_alloc_skb(pkt_len + 2)) != NULL) { lskb = entry; .... } else if (skbs != 1) { skbs--; ... } else { /* drop the packet and keep the skb: it is our last * and we couldn't allocate another one */ lskb = entry; } .... } /* Refill the Rx ring buffers. */ .... if (lskb>=0 && odirty_rx == tp->dirty_rx) { /* could not allocate a skb for dirty_rx */ entry = tp->dirty_rx % RX_RING_SIZE; tp->rx_skbuff[entry] = tp->rx_skbuff[lskb]; tp->rx_ring[entry].buffer1 = tp->rx_ring[lskb].buffer1; tp->rx_skbuff[lskb] = NULL; } The above scenario can not happen any more because there will be always a next buffer for 21041. So even if it is already in suspend mode it will go to running mode when receiving another packet. What do you think? Could this be the reason for these spurious hangs? Greetings, Wolfgang Walter From wolfgang.walter@stusta.mhn.de Tue Nov 23 20:30:38 1999 Date: Tue Nov 23 20:30:38 1999 From: Wolfgang Walter wolfgang.walter@stusta.mhn.de Subject: bug in tulip_rx? patch Hi Donald, First (as I post it on linux-kernel, too) again a short description of my problem: Since we use 2.2.14pre4 instead of 2.0.38 we observe random hangs of the network interface which is a tulip card. I tried older tulip-drivers, but this happens with all of them. Now I had a closer look at the code and found a situation which will cause a hang (see my older mail on tulip-bug). I now could catch the driver this state (switched suspend mode): tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DC21041 Tulip adapter at 0xe000. Digital DC21041 Tulip chip registers at 0xe000: ffe08000 ffffffff ffffffff 002f5810 002f5a10 fc680000 fffe2002 ffffebef fffe0001 ffff4bf8 ffffffff fffe0000 000001c8 ffffef05 ffffff3f ffff0008 Port selection is half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Suspended -- no Rx buffers'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. The NWay status register is 000001c8. PCI Subsystem IDs, vendor 1186, device 0100. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:80:C8:E6:1C:2F. EEPROM transceiver/media description for the Digital DC21041 Tulip chip. Leaf node at offset 30, default media type 0800 (Autosense). 3 transceiver description blocks: 21041 media index 00 (10baseT). 21041 media index 04 (10baseT-Full Duplex). 21041 media index 01 (10base2). Internal autonegotiation state is 'Autonegotiation disabled'. The driver does not recover from this state. I attached a patch which seems to work. But it runs only since some hours. I post it here so that you may have a look at it. Also, there seem to be people who have the same problem, they may try it out. Wolfgang Walter --- 2.2.14pre4/drivers/net/tulip.c Fri Nov 5 18:02:35 1999 +++ 2.2.14pre4-m/drivers/net/tulip.c Wed Nov 24 02:04:13 1999 @@ -509,6 +509,7 @@ int interrupt; /* In-interrupt flag. */ unsigned int cur_rx, cur_tx; /* The next free ring entry */ unsigned int dirty_rx, dirty_tx; /* The ring entries to be free()ed. */ + unsigned int nr_skbs_rx; /* number of skbs */ unsigned int tx_full:1; /* The Tx queue is full. */ unsigned int full_duplex:1; /* Full-duplex operation requested. */ unsigned int full_duplex_lock:1; @@ -2484,6 +2485,7 @@ tp->tx_full = 0; tp->cur_rx = tp->cur_tx = 0; tp->dirty_rx = tp->dirty_tx = 0; + tp->nr_skbs_rx = 0; for (i = 0; i < RX_RING_SIZE; i++) { tp->rx_ring[i].status = 0x00000000; @@ -2503,6 +2505,7 @@ tp->rx_skbuff[i] = skb; if (skb == NULL) break; + tp->nr_skbs_rx++; skb->dev = dev; /* Mark as being used by this device. */ tp->rx_ring[i].status = cpu_to_le32(DescOwned); /* Owned by Tulip chip */ tp->rx_ring[i].buffer1 = virt_to_le32desc(skb->tail); @@ -2607,7 +2610,11 @@ if ((csr5 & (NormalIntr|AbnormalIntr)) == 0) break; - if (csr5 & (RxIntr | RxNoBuf)) + /* tp->nr_skbs_rx == 0 can only happen if we never succeeded to allocate at least + * one skb (which we usually do at initialisation time. + * We then hope do do so now or any later non-RD/RU interrupt + */ + if (csr5 & (RxIntr | RxNoBuf) || tp->nr_skbs_rx == 0) work_budget -= tulip_rx(dev); if (csr5 & (TxNoBuf | TxDied | TxIntr)) { @@ -2797,7 +2804,7 @@ #endif /* Check if the packet is long enough to accept without copying to a minimally-sized skbuff. */ - if (pkt_len < rx_copybreak + if ((pkt_len < rx_copybreak || tp->nr_skbs_rx < 2) && (skb = dev_alloc_skb(pkt_len + 2)) != NULL) { skb->dev = dev; skb_reserve(skb, 2); /* 16 byte align the IP header */ @@ -2809,9 +2816,10 @@ pkt_len); #endif work_done++; - } else { /* Pass up the skb already on the Rx ring. */ + } else if (tp->nr_skbs_rx > 1) { /* Pass up the skb already on the Rx ring. */ char *temp = skb_put(skb = tp->rx_skbuff[entry], pkt_len); tp->rx_skbuff[entry] = NULL; + tp->nr_skbs_rx--; #ifndef final_version if (le32desc_to_virt(tp->rx_ring[entry].buffer1) != temp) printk(KERN_ERR "%s: Internal fault: The skbuff addresses " @@ -2820,6 +2828,9 @@ le32desc_to_virt(tp->rx_ring[entry].buffer1), skb->head, temp); #endif + } else { + /* we have only one skb; we must keep it: drop the packet */ + tp->stats.rx_dropped++; } skb->protocol = eth_type_trans(skb, dev); netif_rx(skb); @@ -2840,11 +2851,55 @@ skb = tp->rx_skbuff[entry] = dev_alloc_skb(PKT_BUF_SZ); if (skb == NULL) break; + tp->nr_skbs_rx++; skb->dev = dev; /* Mark as being used by this device. */ tp->rx_ring[entry].buffer1 = virt_to_le32desc(skb->tail); work_done++; } tp->rx_ring[entry].status = cpu_to_le32(DescOwned); + } + + /* + * We must catch the situation: + * the card run out of RX-buffers when this interrupt was triggered (but we have a skb available) + * + * This is the case, if + * tp->nr_skbs_rx > 0 + * and + * all buffers are dirty + * <=> tp->dirty_rx + RX_RING_SIZE == tp->cur_rx + * <=> tp->cur_rx has no skb associated + * + * Why? + * => + * If at this stage all buffers are dirty this means that + * tp->dirty_rx + RX_RING_SIZE == tp->cur_rx + * must hold. This means that the above refill did not change tp->dirty_rx at all + * which means that the associated skb must be null. As this is the same in the ring as + * tp->cur_rx represents, there is no skb associated with tp->cur_rx. + * + * <= + * If tp->cur_rx has no skb associated the rx-loop must be terminated with + * rx_work_limit<0 (tp->rx_ring[entry].status & cpu_to_le32(DescOwned) can't be + * true if no skb is associated). This means that + * tp->dirty_rx + RX_RING_SIZE == tp->cur_rx + * holds which means that all buffers are dirty + * + */ + entry = tp->cur_rx % RX_RING_SIZE; + if (tp->nr_skbs_rx > 0 && tp->rx_skbuff[entry] == NULL) { + int i; + /* search a free buffer */ + for (i = 0; i < RX_RING_SIZE; i++) { + if (tp->rx_skbuff[i] != NULL) { + tp->rx_skbuff[entry] = tp->rx_skbuff[i]; + tp->rx_ring[entry].buffer1 = tp->rx_ring[i].buffer1; + tp->rx_skbuff[i] = NULL; + tp->rx_ring[entry].status = cpu_to_le32(DescOwned); + tp->dirty_rx++; + break; + } + } } return work_done; From avneetb@sympatico.ca Wed Nov 24 01:14:57 1999 Date: Wed Nov 24 01:14:57 1999 From: Avneet Bhatia avneetb@sympatico.ca Subject: SMC 8432BT With DEC21041 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01BF361A.07D34880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I have the following network card: SMC 8432BT=20 With DEC21041 Where can I find the latest driver for this card??? thanks avneetb@sympatico.ca ------=_NextPart_000_000B_01BF361A.07D34880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello, I have the following network card:

SMC 8432BT=20

With DEC21041

Where can I find the latest driver for = this=20 card???

thanks

avneetb@sympatico.ca

------=_NextPart_000_000B_01BF361A.07D34880-- From b-@n-iterate.org Wed Nov 24 02:04:41 1999 Date: Wed Nov 24 02:04:41 1999 From: byoung b-@n-iterate.org Subject: tulip failure on NetGear FA 310TX (10/100) -----BEGIN PGP SIGNED MESSAGE----- Hi, I am experiencing problem with tulip driver used with NetGear FA 310TX 10/100Mbps ethernet card. It appears that after several days of fine operation, eth (tulip) suddenly stops working - it fails to send or receive packets, and any commands to do so just hangs (and nope, it's not dns hangup). I'm using the tulip driver integrated into the source tree of linux kernel 2.0.38. the following is the kernel messages generated when the interface is brought up (when system booted - empty line represents line break, as the log line runs longer than 80 columns): Nov 23 22:30:33 foo kernel: tulip.c:v0.90 10/20/98 becker@cesdis.gsfc.nasa.gov Nov 23 22:30:33 foo kernel: eth0: Lite-On 82c168 PNIC at 0xd000, 00 a0 cc 53 43 87, IRQ 5. Nov 23 22:30:33 foo kernel: eth0: MII transceiver #1 config 3000 status 7829 advertising 01e1. after a couple of seconds, the above are always followed by the following lines: Nov 23 22:30:35 foo kernel: eth0: The transmitter stopped! CSR5 is 2678016, CSR6 816e2002. Nov 23 22:30:35 foo kernel: eth0: Changing PNIC configuration to half-duplex, CSR6 816e0000. the host is a single-homed, connected to a 10Mbps shared hub (half-duplex). there is no warning/error messages before the driver stops working. At one time, i may have gotten it to work again by removing and reloading the driver, but i'm not sure that was the case, and it certainly doesn't seem to work always. Anyone with similar problem? Thanx for any info. byoung -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: noconv iQCVAwUBODuNpY8n9J7I/lFdAQGFgQQAzcoXp2zYDwya7wWcci67JYhzJVVbYRyD H7QVlwmgXSAKi1MsmZ2RtQniTmkRFBzd3beYHWY13nIuogztXdOqYB7o5yNu0qhp BZpnLRrLoHQcDiGqDIsfbNK+XQShgwfAKqxjV1QU9qbIvj5JnZc5KGUIHMyroJcu wo1B+8SQ/Zw= =xIt9 -----END PGP SIGNATURE----- From b-@n-iterate.org Wed Nov 24 02:25:25 1999 Date: Wed Nov 24 02:25:25 1999 From: byoung b-@n-iterate.org Subject: tulip failure on NetGear FA 310TX (10/100) sorry for the repeat post - my pgp filter may not have been set up corectly. Again, any info would be appreciated. byoung ---------------------------------------------------- Hi, I am experiencing problem with tulip driver used with NetGear FA 310TX 10/100Mbps ethernet card. It appears that after several days of fine operation, eth (tulip) suddenly stops working - it fails to send or receive packets, and any commands to do so just hangs (and nope, it's not dns hangup). I'm using the tulip driver integrated into the source tree of linux kernel 2.0.38. the following is the kernel messages generated when the interface is brought up (when system booted - empty line represents line break, as the log line runs longer than 80 columns): Nov 23 22:30:33 foo kernel: tulip.c:v0.90 10/20/98 becker@cesdis.gsfc.nasa.gov Nov 23 22:30:33 foo kernel: eth0: Lite-On 82c168 PNIC at 0xd000, 00 a0 cc 53 43 87, IRQ 5. Nov 23 22:30:33 foo kernel: eth0: MII transceiver #1 config 3000 status 7829 advertising 01e1. after a couple of seconds, the above are always followed by the following lines: Nov 23 22:30:35 foo kernel: eth0: The transmitter stopped! CSR5 is 2678016, CSR6 816e2002. Nov 23 22:30:35 foo kernel: eth0: Changing PNIC configuration to half-duplex, CSR6 816e0000. the host is a single-homed, connected to a 10Mbps shared hub (half-duplex). there is no warning/error messages before the driver stops working. At one time, i may have gotten it to work again by removing and reloading the driver, but i'm not sure that was the case, and it certainly doesn't seem to work always. Anyone with similar problem? Thanx for any info. byoung From srb@cuci.nl Wed Nov 24 07:38:22 1999 Date: Wed Nov 24 07:38:22 1999 From: Stephen R. van den Berg srb@cuci.nl Subject: bug in tulip_rx? patch Wolfgang Walter wrote: >Since we use 2.2.14pre4 instead of 2.0.38 we observe random hangs of the >network interface which is a tulip card. > Transmit started, Receive started, half-duplex. > The Rx process state is 'Suspended -- no Rx buffers'. > The Tx process state is 'Idle'. >The driver does not recover from this state. I can confirm this. I've experienced this bug on some cards and some machines for ages now (at least for the past three years, I guess). When it first became a problem I didn't have the tulip-diag program. So I put in a very crude workaround which periodically checks for this condition and empties all receive buffers. -- Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless). Are they twins? Yes. Are they *both* yours? From marcs@skyhunter.com Wed Nov 24 17:05:45 1999 Date: Wed Nov 24 17:05:45 1999 From: Marc Stiegler marcs@skyhunter.com Subject: Unknown Tulip-style chip? Dear Sirs: I recently installed a Linksys EtherFast 10/100 PCI card in my Linux machine. I followed the manufacturer instructions for compiling the tulip driver (version 0.91) and installing into the system. After this did not work (modprobe would install the driver, but when I did an lsmod it would describe the tulip driver as "unused"), I recompiled my kernel (version 2.2.5) with the tulip driver specified as a module. Now I get during the startup process, Unknown Tulip-style PCI ethernet chip type 11ad c115 detected: not configured. I have compiled and run the diagnostic tulip-diag.c program (v1.19), and it gives me this: Index #1: Found a Lite-On PNIC-II adapter at 0x6600. Port selection is 10mpbs-serial, half-duplex Transmitt stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. The NWay status register is 000050ca. The current PNIC-II MAC address is 00:a0:cc:33:9b:38 (a000a000 33cc389b). The current PNIC-II WOL address is 00:a0:cc:33:9b:38. Internal autonegotiation state is 'Negotiation complete'. If I try to do a modprobe at this point, I am told init_module: Device or resource busy. I currently have it hooked up to a LAN running 10Mbps hubs. I get the same "not configured" message regardless of whether I use the tulip.o module created during the kernel compilation or whether I use the 0.91 version tulip.o I compiled myself. Does anyone have a clue what I am doing wrong here? Thank you. --marcs From wolfgang.walter@stusta.mhn.de Wed Nov 24 21:23:23 1999 Date: Wed Nov 24 21:23:23 1999 From: Wolfgang Walter wolfgang.walter@stusta.mhn.de Subject: bug in tulip_rx? corrected patch Hi, a just realised that my patch is buggy :-). Of course, if I drop the packet I must not give it to netif_rx() :-). Wolfgang Walter Here is the corrected version: --- 2.2.14pre4/drivers/net/tulip.c Fri Nov 5 18:02:35 1999 +++ 2.2.14pre4-m/drivers/net/tulip.c Thu Nov 25 03:48:23 1999 @@ -509,6 +509,7 @@ int interrupt; /* In-interrupt flag. */ unsigned int cur_rx, cur_tx; /* The next free ring entry */ unsigned int dirty_rx, dirty_tx; /* The ring entries to be free()ed. */ + unsigned int nr_skbs_rx; /* number of skbs */ unsigned int tx_full:1; /* The Tx queue is full. */ unsigned int full_duplex:1; /* Full-duplex operation requested. */ unsigned int full_duplex_lock:1; @@ -2484,6 +2485,7 @@ tp->tx_full = 0; tp->cur_rx = tp->cur_tx = 0; tp->dirty_rx = tp->dirty_tx = 0; + tp->nr_skbs_rx = 0; for (i = 0; i < RX_RING_SIZE; i++) { tp->rx_ring[i].status = 0x00000000; @@ -2503,6 +2505,7 @@ tp->rx_skbuff[i] = skb; if (skb == NULL) break; + tp->nr_skbs_rx++; skb->dev = dev; /* Mark as being used by this device. */ tp->rx_ring[i].status = cpu_to_le32(DescOwned); /* Owned by Tulip chip */ tp->rx_ring[i].buffer1 = virt_to_le32desc(skb->tail); @@ -2595,6 +2598,13 @@ dev->interrupt = 1; #endif + /* tp->nr_skbs_rx == 0 can only happen if we never succeeded to allocate at least + * one skb (which we usually do at initialisation time. + * We then hope do do so now or any later non-RD/RU interrupt + */ + if (tp->nr_skbs_rx == 0) + work_budget -= tulip_rx(dev); + do { csr5 = inl(ioaddr + CSR5); /* Acknowledge all of the current interrupt sources ASAP. */ @@ -2729,7 +2739,7 @@ break; } } while (1); - + if (tulip_debug > 4) printk(KERN_DEBUG "%s: exiting interrupt, csr5=%#4.4x.\n", dev->name, inl(ioaddr + CSR5)); @@ -2797,7 +2807,7 @@ #endif /* Check if the packet is long enough to accept without copying to a minimally-sized skbuff. */ - if (pkt_len < rx_copybreak + if ((pkt_len < rx_copybreak || tp->nr_skbs_rx < 2) && (skb = dev_alloc_skb(pkt_len + 2)) != NULL) { skb->dev = dev; skb_reserve(skb, 2); /* 16 byte align the IP header */ @@ -2809,9 +2819,10 @@ pkt_len); #endif work_done++; - } else { /* Pass up the skb already on the Rx ring. */ + } else if (tp->nr_skbs_rx > 1) { /* Pass up the skb already on the Rx ring. */ char *temp = skb_put(skb = tp->rx_skbuff[entry], pkt_len); tp->rx_skbuff[entry] = NULL; + tp->nr_skbs_rx--; #ifndef final_version if (le32desc_to_virt(tp->rx_ring[entry].buffer1) != temp) printk(KERN_ERR "%s: Internal fault: The skbuff addresses " @@ -2820,14 +2831,20 @@ le32desc_to_virt(tp->rx_ring[entry].buffer1), skb->head, temp); #endif - } - skb->protocol = eth_type_trans(skb, dev); - netif_rx(skb); - dev->last_rx = jiffies; - tp->stats.rx_packets++; + } else { + /* we have only one skb; we must keep it: drop the packet */ + tp->stats.rx_dropped++; + skb = NULL; + } + if (skb) { + skb->protocol = eth_type_trans(skb, dev); + netif_rx(skb); + dev->last_rx = jiffies; + tp->stats.rx_packets++; #if LINUX_VERSION_CODE > 0x20127 - tp->stats.rx_bytes += pkt_len; + tp->stats.rx_bytes += pkt_len; #endif + } } entry = (++tp->cur_rx) % RX_RING_SIZE; } @@ -2840,11 +2857,55 @@ skb = tp->rx_skbuff[entry] = dev_alloc_skb(PKT_BUF_SZ); if (skb == NULL) break; + tp->nr_skbs_rx++; skb->dev = dev; /* Mark as being used by this device. */ tp->rx_ring[entry].buffer1 = virt_to_le32desc(skb->tail); work_done++; } tp->rx_ring[entry].status = cpu_to_le32(DescOwned); + } + + /* + * We must catch the situation: + * the card run out of RX-buffers when this interrupt was triggered (but we have a skb available) + * + * This is the case, if + * tp->nr_skbs_rx > 0 + * and + * all buffers are dirty + * <=> tp->dirty_rx + RX_RING_SIZE == tp->cur_rx + * <=> tp->cur_rx has no skb associated + * + * Why? + * => + * If at this stage all buffers are dirty this means that + * tp->dirty_rx + RX_RING_SIZE == tp->cur_rx + * must hold. This means that the above refill did not change tp->dirty_rx at all + * which means that the associated skb must be null. As this is the same in the ring as + * tp->cur_rx represents, there is no skb associated with tp->cur_rx. + * + * <= + * If tp->cur_rx has no skb associated the rx-loop must be terminated with + * rx_work_limit<0 (tp->rx_ring[entry].status & cpu_to_le32(DescOwned) can't be + * true if no skb is associated). This means that + * tp->dirty_rx + RX_RING_SIZE == tp->cur_rx + * holds which means that all buffers are dirty + * + */ + entry = tp->cur_rx % RX_RING_SIZE; + if (tp->nr_skbs_rx > 0 && tp->rx_skbuff[entry] == NULL) { + int i; + /* search the one free buffer */ + for (i = 0; i < RX_RING_SIZE; i++) { + if (tp->rx_skbuff[i] != NULL) { + tp->rx_skbuff[entry] = tp->rx_skbuff[i]; + tp->rx_ring[entry].buffer1 = tp->rx_ring[i].buffer1; + tp->rx_skbuff[i] = NULL; + tp->rx_ring[entry].status = cpu_to_le32(DescOwned); + tp->dirty_rx++; + break; + } + } } return work_done; From wolfgang.walter@stusta.mhn.de Thu Nov 25 13:54:06 1999 Date: Thu Nov 25 13:54:06 1999 From: Wolfgang Walter wolfgang.walter@stusta.mhn.de Subject: bug in tulip_rx? corrected patch 2 Hi, another version of my patch. My previous one generally works but has a problem when we get a lot of packets while we drop packets. This is because I did not return a work_done>0 in this case. Another thing I changed is to always call tulip_rx() in the interrupt. The reason is that (especially in "dropping mode") we switch off interrupts and wait for a timer interrupt. If such a timer interrupt occurs, I'm not sure that always a RD or a RU interrupt is generated. Of course one could change that to call it when a timer-interrupt occurs. I can't see any performance difference so (sending as many 64byte sized packets as possible via 10Base-T from the machine without receiving actually something). Can this be a problem with 100Base-T? Can't test it here. Would appreciate if someone with a 100MBit card could test that. Another possibilty would be to check the card for suspend mode. Wolfgang Walter --- 2.2.14pre4/drivers/net/tulip.c Fri Nov 5 18:02:35 1999 +++ 2.2.14pre4-m/drivers/net/tulip.c Thu Nov 25 19:45:47 1999 @@ -509,6 +509,7 @@ int interrupt; /* In-interrupt flag. */ unsigned int cur_rx, cur_tx; /* The next free ring entry */ unsigned int dirty_rx, dirty_tx; /* The ring entries to be free()ed. */ + unsigned int nr_skbs_rx; /* number of skbs */ unsigned int tx_full:1; /* The Tx queue is full. */ unsigned int full_duplex:1; /* Full-duplex operation requested. */ unsigned int full_duplex_lock:1; @@ -2484,6 +2485,7 @@ tp->tx_full = 0; tp->cur_rx = tp->cur_tx = 0; tp->dirty_rx = tp->dirty_tx = 0; + tp->nr_skbs_rx = 0; for (i = 0; i < RX_RING_SIZE; i++) { tp->rx_ring[i].status = 0x00000000; @@ -2503,6 +2505,7 @@ tp->rx_skbuff[i] = skb; if (skb == NULL) break; + tp->nr_skbs_rx++; skb->dev = dev; /* Mark as being used by this device. */ tp->rx_ring[i].status = cpu_to_le32(DescOwned); /* Owned by Tulip chip */ tp->rx_ring[i].buffer1 = virt_to_le32desc(skb->tail); @@ -2595,6 +2598,9 @@ dev->interrupt = 1; #endif + /* to be sure we restart receiving */ + tulip_rx(dev); + do { csr5 = inl(ioaddr + CSR5); /* Acknowledge all of the current interrupt sources ASAP. */ @@ -2797,7 +2803,7 @@ #endif /* Check if the packet is long enough to accept without copying to a minimally-sized skbuff. */ - if (pkt_len < rx_copybreak + if ((pkt_len < rx_copybreak || tp->nr_skbs_rx < 2) && (skb = dev_alloc_skb(pkt_len + 2)) != NULL) { skb->dev = dev; skb_reserve(skb, 2); /* 16 byte align the IP header */ @@ -2809,9 +2815,10 @@ pkt_len); #endif work_done++; - } else { /* Pass up the skb already on the Rx ring. */ + } else if (tp->nr_skbs_rx > 1) { /* Pass up the skb already on the Rx ring. */ char *temp = skb_put(skb = tp->rx_skbuff[entry], pkt_len); tp->rx_skbuff[entry] = NULL; + tp->nr_skbs_rx--; #ifndef final_version if (le32desc_to_virt(tp->rx_ring[entry].buffer1) != temp) printk(KERN_ERR "%s: Internal fault: The skbuff addresses " @@ -2820,14 +2827,24 @@ le32desc_to_virt(tp->rx_ring[entry].buffer1), skb->head, temp); #endif + } else { + /* we have only one skb; we must keep it: drop the packet */ + tp->stats.rx_dropped++; + skb = NULL; + /* Make this expensive: we do not want to be called immediately again + * the situation only gets after this interrupt handler finished + */ + work_done++; } - skb->protocol = eth_type_trans(skb, dev); - netif_rx(skb); - dev->last_rx = jiffies; - tp->stats.rx_packets++; + if (skb) { + skb->protocol = eth_type_trans(skb, dev); + netif_rx(skb); + dev->last_rx = jiffies; + tp->stats.rx_packets++; #if LINUX_VERSION_CODE > 0x20127 - tp->stats.rx_bytes += pkt_len; + tp->stats.rx_bytes += pkt_len; #endif + } } entry = (++tp->cur_rx) % RX_RING_SIZE; } @@ -2840,11 +2857,55 @@ skb = tp->rx_skbuff[entry] = dev_alloc_skb(PKT_BUF_SZ); if (skb == NULL) break; + tp->nr_skbs_rx++; skb->dev = dev; /* Mark as being used by this device. */ tp->rx_ring[entry].buffer1 = virt_to_le32desc(skb->tail); work_done++; } tp->rx_ring[entry].status = cpu_to_le32(DescOwned); + } + + /* + * We must catch the situation: + * the card run out of RX-buffers when this interrupt was triggered (but we have a skb available) + * + * This is the case, if + * tp->nr_skbs_rx > 0 + * and + * all buffers are dirty + * <=> tp->dirty_rx + RX_RING_SIZE == tp->cur_rx + * <=> tp->cur_rx has no skb associated + * + * Why? + * => + * If at this stage all buffers are dirty this means that + * tp->dirty_rx + RX_RING_SIZE == tp->cur_rx + * must hold. This means that the above refill did not change tp->dirty_rx at all + * which means that the associated skb must be null. As this is the same in the ring as + * tp->cur_rx represents, there is no skb associated with tp->cur_rx. + * + * <= + * If tp->cur_rx has no skb associated the rx-loop must be terminated with + * rx_work_limit<0 (tp->rx_ring[entry].status & cpu_to_le32(DescOwned) can't be + * true if no skb is associated). This means that + * tp->dirty_rx + RX_RING_SIZE == tp->cur_rx + * holds which means that all buffers are dirty + * + */ + entry = tp->cur_rx % RX_RING_SIZE; + if (tp->nr_skbs_rx > 0 && tp->rx_skbuff[entry] == NULL) { + int i; + /* search the one free buffer */ + for (i = 0; i < RX_RING_SIZE; i++) { + if (tp->rx_skbuff[i] != NULL) { + tp->rx_skbuff[entry] = tp->rx_skbuff[i]; + tp->rx_ring[entry].buffer1 = tp->rx_ring[i].buffer1; + tp->rx_skbuff[i] = NULL; + tp->rx_ring[entry].status = cpu_to_le32(DescOwned); + tp->dirty_rx++; + break; + } + } } return work_done; From mark@lightning.cistron.nl Fri Nov 26 06:05:22 1999 Date: Fri Nov 26 06:05:22 1999 From: mark@lightning.cistron.nl mark@lightning.cistron.nl Subject: 100baseTx-FD problem with 21143 Hi, Yesterday I made a testsetup with a 3com 8 port Officeconnect switch and some Linux PC's. Two of the PC's have 100Mbit cards, one is a 3com 905 and the other a Tulip 21143 (unknown brand). The 3com works perfectly at 100Mbit full duplex. But the Tulip has problems. The switch gives both full duplex and 100Mbit link lights, but when I try to transfer data it is very slow. When I force the tulip into half dulpex mode it works great. Here some stats: Insert module, using auto detect. Switch goes to 100Mbit full duplex thunder# ./mii-diag Using the default interface 'eth0'. Basic registers of MII PHY #32: 1000 786c 0000 0000 01e1 45e1 0000 0000. Basic mode control register 0x1000: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control. thunder# tcpspray -n 600 192.168.1.20 Transmitted 614400 bytes in 25.639532 seconds (23.401 kbytes/s) Interface stats: eth0 Link encap:Ethernet HWaddr 00:00:CB:53:16:02 inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:203 errors:0 dropped:0 overruns:0 frame:0 TX packets:431 errors:113 dropped:0 overruns:0 carrier:113 collisions:0 txqueuelen:100 Interrupt:9 Base address:0xec00 Insert module using options=3, switch goes to 100mbit, half duplex thunder# ./mii-diag Using the default interface 'eth0'. Basic registers of MII PHY #32: 0000 784c 0000 0000 0001 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. So, according to mii-diag it's in 10mbps, half duplex. thunder# tcpspray -n 600 192.168.1.20 Transmitted 6144000 bytes in 0.587399 seconds (10214.522 kbytes/s) Interface stats: eth0 Link encap:Ethernet HWaddr 00:00:CB:53:16:02 inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6289 errors:0 dropped:0 overruns:0 frame:0 TX packets:12548 errors:0 dropped:0 overruns:0 carrier:0 collisions:6261 txqueuelen:100 Interrupt:9 Base address:0xec00 Am I doing something wrong, or is there a problem with my card or driver? Thanks, Mark From minfrin@sharp.fm Fri Nov 26 09:37:11 1999 Date: Fri Nov 26 09:37:11 1999 From: Graham Leggett minfrin@sharp.fm Subject: Off topic question... Hi all, Sorry for what might be a silly question, but how do you get off this list? Regards, Graham -- ----------------------------------------- minfrin@sharp.fm "There's a moon over Bourbon Street tonight... From wolfgang.walter@stusta.mhn.de Fri Nov 26 11:51:51 1999 Date: Fri Nov 26 11:51:51 1999 From: Wolfgang Walter wolfgang.walter@stusta.mhn.de Subject: bug in tulip_rx? corrected patch 2 On Fri, Nov 26, 1999 at 01:48:43AM -0700, Edward Schlunder wrote: > On Thu, 25 Nov 1999, Wolfgang Walter wrote: > > > another version of my patch. My previous one generally works but has a > > problem when we get a lot of packets while we drop packets. This is > > because I did not return a work_done>0 in this case. > > Okay, one of my systems consistently runs into the tulip_rx bug every > night (other than Sun/Mon) between 1:00AM and 1:05AM. Your first and > second patches didn't seem to make any differences. Last night, on the To begin: thank you very much for you mail. This helps me a lot finding a good way for fixing the bug. The first one was buggy, the second one has problems if you constantly receive a lot of packets - one must call it buggy, too :-). > dot, my system go stuck in the "Suspended -- no Rx buffers" state with > your second patch: > > Date: Thu, 25 Nov 1999 01:05:00 -0700 > From: Cron Daemon > To: edward@ajusd.org > Subject: Cron /root/bin/reset-eth0.pl > > tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > Index #1: Found a Lite-On 82c168 PNIC adapter at 0xe400. > Lite-On 82c168 PNIC chip registers at 0xe400: > 00008000 01ff01ff 42422600 00f03810 00f03a10 026800d7 816ce202 0000eb28 > 000006aa 00000000 00f03b00 05454844 00000020 00000000 00000000 10000001 > 00000000 00000000 f0041385 000000bf 609641e1 00f03870 393e8810 0001e978 > 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > Port selection is MII, full-duplex. > Transmit started, Receive started, full-duplex. > The Rx process state is 'Suspended -- no Rx buffers'. > The Tx process state is 'Idle'. > The transmit unit is set to store-and-forward. > A simplifed EEPROM data table was found. > The EEPROM does not contain transceiver control information. > MII PHY found at address 1, status 0x782d. > MII PHY #1 transceiver registers: > 3000 782d 0040 6212 01e1 41e1 0003 0000 > 0000 0000 0000 0000 0000 0000 0000 0000 > 5000 0300 0000 0000 0000 0f74 0700 0000 > 003f 853e 0f00 ff00 002f 4000 80a0 000b. > Couldn't ping 206.207.140.1. Assuming network offline, restarting eth0 > > This third patch of yours I tried and tonight got a different result: > > tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > Index #1: Found a Lite-On 82c168 PNIC adapter at 0xe400. > Lite-On 82c168 PNIC chip registers at 0xe400: > 00008000 01ff0000 aaaa6100 00f03010 00f03210 02670055 810ca202 0000fbaf > 00000000 00000000 00f032b0 30a4cc60 00000020 00000000 00000000 10000001 > 00000000 00000000 f0041385 000000bf 60fe000b 00f03060 393e8010 0001e978 > 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > Port selection is MII, full-duplex. > Transmit started, Receive started, full-duplex. > The Rx process state is 'Waiting for packets'. > The Tx process state is 'Idle'. > The transmit threshold is 512. > Interrupt sources are pending! CSR5 is 02670055. > Tx done indication. > Tx out of buffers indication. > Link passed indication. > Rx Done indication. > A simplifed EEPROM data table was found. > The EEPROM does not contain transceiver control information. > MII PHY found at address 1, status 0x782d. > MII PHY #1 transceiver registers: > 3000 782d 0040 6212 01e1 41e1 0003 0000 > 0000 0000 0000 0000 0000 0000 0000 0000 > 5000 0300 0000 0000 0000 00af 0100 0000 > 003f 853e 0f00 ff00 002f 4000 80a0 000b. > > The machine seems to be able to recieve packets fine, but now transmitting > doesn't work very well. Pinging the machine from my home computer over > cable modem normally looks something like: > > 64 bytes from 206.207.140.3: icmp_seq=0 ttl=242 time=69.1 ms > 64 bytes from 206.207.140.3: icmp_seq=1 ttl=242 time=77.1 ms > 64 bytes from 206.207.140.3: icmp_seq=2 ttl=242 time=57.5 ms > > But right now it looks like: > > 64 bytes from 206.207.140.5: icmp_seq=1290 ttl=242 time=22351.6 ms > 64 bytes from 206.207.140.5: icmp_seq=1293 ttl=242 time=25455.2 ms > 64 bytes from 206.207.140.5: icmp_seq=1291 ttl=242 time=27456.5 ms > > tcpdump -i eth0 shows the machine recieving packets seemingly fine. > ifconfig eth0: > eth0 Link encap:Ethernet HWaddr 00:A0:CC:55:8D:99 > inet addr:206.207.140.5 Bcast:206.207.140.255 Mask:255.255.255.0 > IPX/Ethernet 802.2 addr:000143AA:00A0CC558D99 > IPX/Ethernet 802.3 addr:00000002:00A0CC558D99 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:267115 errors:0 dropped:0 overruns:0 frame:0 > TX packets:214608 errors:121 dropped:0 overruns:2 carrier:3 > collisions:0 txqueuelen:100 > Interrupt:20 Base address:0xe400 > Yes, this is what I expect. Short explanation. In the interrupt handler we have a loop which finish when no further event of the card arrived or if we processed to many of them. If there are to many, the driver sets a timer on the card and disables all interrupts but the timer interrupt. This way it controls that we are not overstressed. In the criticial situation you have only one skb left. This means we call tulip_rx for every single packet. Therefor we would be really overstressed. And so sending is temporarly stopped, too. What we would need is to temporarly suspend receiving. I think I will have a patch tomorrow with the following strategy: accept rx suspend mode (and therefor no skb can be allowed again), but if we are in rx suspend mode when leaving the interrupt handler then set the card timer if the interrupt handling is called and we are already in rx suspend mode: call tulip_rx (which tries to allocate new skbs). This should work much better then the approach I use now. Well, I had no experience with network-drivers at all. But now I get a feeling for it :-). I would be very glad if you would try out this alternativ approach (I'll send you the patch). As I sometimes have to wait 2 or 3 days to get into this skb-shortage it. Greetings, Wolfgang Walter > -- > Ed Schlunder > From wolfgang.walter@stusta.mhn.de Fri Nov 26 19:31:17 1999 Date: Fri Nov 26 19:31:17 1999 From: Wolfgang Walter wolfgang.walter@stusta.mhn.de Subject: bug in tulip_rx? corrected patch 2 On Fri, Nov 26, 1999 at 05:51:46PM +0100, Wolfgang Walter wrote: > On Fri, Nov 26, 1999 at 01:48:43AM -0700, Edward Schlunder wrote: > > On Thu, 25 Nov 1999, Wolfgang Walter wrote: > > > > > another version of my patch. My previous one generally works but has a > > > problem when we get a lot of packets while we drop packets. This is > > > because I did not return a work_done>0 in this case. > > > > Okay, one of my systems consistently runs into the tulip_rx bug every > > night (other than Sun/Mon) between 1:00AM and 1:05AM. Your first and > > second patches didn't seem to make any differences. Last night, on the > > To begin: thank you very much for you mail. This helps me a lot finding a > good way for fixing the bug. > > The first one was buggy, the second one has problems if you constantly receive > a lot of packets - one must call it buggy, too :-). > > > dot, my system go stuck in the "Suspended -- no Rx buffers" state with > > your second patch: > > > > Date: Thu, 25 Nov 1999 01:05:00 -0700 > > From: Cron Daemon > > To: edward@ajusd.org > > Subject: Cron /root/bin/reset-eth0.pl > > > > tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > > Index #1: Found a Lite-On 82c168 PNIC adapter at 0xe400. > > Lite-On 82c168 PNIC chip registers at 0xe400: > > 00008000 01ff01ff 42422600 00f03810 00f03a10 026800d7 816ce202 0000eb28 > > 000006aa 00000000 00f03b00 05454844 00000020 00000000 00000000 10000001 > > 00000000 00000000 f0041385 000000bf 609641e1 00f03870 393e8810 0001e978 > > 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > > Port selection is MII, full-duplex. > > Transmit started, Receive started, full-duplex. > > The Rx process state is 'Suspended -- no Rx buffers'. > > The Tx process state is 'Idle'. > > The transmit unit is set to store-and-forward. > > A simplifed EEPROM data table was found. > > The EEPROM does not contain transceiver control information. > > MII PHY found at address 1, status 0x782d. > > MII PHY #1 transceiver registers: > > 3000 782d 0040 6212 01e1 41e1 0003 0000 > > 0000 0000 0000 0000 0000 0000 0000 0000 > > 5000 0300 0000 0000 0000 0f74 0700 0000 > > 003f 853e 0f00 ff00 002f 4000 80a0 000b. > > Couldn't ping 206.207.140.1. Assuming network offline, restarting eth0 > > > > This third patch of yours I tried and tonight got a different result: > > > > tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > > Index #1: Found a Lite-On 82c168 PNIC adapter at 0xe400. > > Lite-On 82c168 PNIC chip registers at 0xe400: > > 00008000 01ff0000 aaaa6100 00f03010 00f03210 02670055 810ca202 0000fbaf > > 00000000 00000000 00f032b0 30a4cc60 00000020 00000000 00000000 10000001 > > 00000000 00000000 f0041385 000000bf 60fe000b 00f03060 393e8010 0001e978 > > 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > > Port selection is MII, full-duplex. > > Transmit started, Receive started, full-duplex. > > The Rx process state is 'Waiting for packets'. > > The Tx process state is 'Idle'. > > The transmit threshold is 512. > > Interrupt sources are pending! CSR5 is 02670055. > > Tx done indication. > > Tx out of buffers indication. > > Link passed indication. > > Rx Done indication. > > A simplifed EEPROM data table was found. > > The EEPROM does not contain transceiver control information. > > MII PHY found at address 1, status 0x782d. > > MII PHY #1 transceiver registers: > > 3000 782d 0040 6212 01e1 41e1 0003 0000 > > 0000 0000 0000 0000 0000 0000 0000 0000 > > 5000 0300 0000 0000 0000 00af 0100 0000 > > 003f 853e 0f00 ff00 002f 4000 80a0 000b. > > > > The machine seems to be able to recieve packets fine, but now transmitting > > doesn't work very well. Pinging the machine from my home computer over > > cable modem normally looks something like: > > > > 64 bytes from 206.207.140.3: icmp_seq=0 ttl=242 time=69.1 ms > > 64 bytes from 206.207.140.3: icmp_seq=1 ttl=242 time=77.1 ms > > 64 bytes from 206.207.140.3: icmp_seq=2 ttl=242 time=57.5 ms > > > > But right now it looks like: > > > > 64 bytes from 206.207.140.5: icmp_seq=1290 ttl=242 time=22351.6 ms > > 64 bytes from 206.207.140.5: icmp_seq=1293 ttl=242 time=25455.2 ms > > 64 bytes from 206.207.140.5: icmp_seq=1291 ttl=242 time=27456.5 ms > > > > tcpdump -i eth0 shows the machine recieving packets seemingly fine. > > ifconfig eth0: > > eth0 Link encap:Ethernet HWaddr 00:A0:CC:55:8D:99 > > inet addr:206.207.140.5 Bcast:206.207.140.255 Mask:255.255.255.0 > > IPX/Ethernet 802.2 addr:000143AA:00A0CC558D99 > > IPX/Ethernet 802.3 addr:00000002:00A0CC558D99 > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > RX packets:267115 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:214608 errors:121 dropped:0 overruns:2 carrier:3 > > collisions:0 txqueuelen:100 > > Interrupt:20 Base address:0xe400 > > > > Yes, this is what I expect. Short explanation. > > In the interrupt handler we have a loop which finish when no further event > of the card arrived or if we processed to many of them. If there are to > many, the driver sets a timer on the card and disables all interrupts but > the timer interrupt. This way it controls that we are not overstressed. > > In the criticial situation you have only one skb left. This means we call > tulip_rx for every single packet. Therefor we would be really overstressed. > And so sending is temporarly stopped, too. > > What we would need is to temporarly suspend receiving. I have to correct me: the code does not disable all interrupts from the card, only the last one processed. But these may be send interrupts, too. > > I think I will have a patch tomorrow with the following strategy: > > accept rx suspend mode (and therefor no skb can be allowed again), > but if we are in rx suspend mode when leaving the interrupt handler > then set the card timer > > if the interrupt handling is called and we are already in rx suspend > mode: call tulip_rx (which tries to allocate new skbs). > > This should work much better then the approach I use now. I now implemented that and do a short test (if it runs under normal conditions), then I'll post it. > > Well, I had no experience with network-drivers at all. But now I get a feeling > for it :-). > > I would be very glad if you would try out this alternativ approach (I'll send > you the patch). As I sometimes have to wait 2 or 3 days to get into this > skb-shortage it. I now had this situation again and my patch really worked fine: the interface continued to work fine after 55 packets got dropped. Greetings, Wolfgang Walter From mark@lightning.cistron.nl Fri Nov 26 19:46:59 1999 Date: Fri Nov 26 19:46:59 1999 From: mark@lightning.cistron.nl mark@lightning.cistron.nl Subject: 100baseTx-FD problem with 21143 Hi. On Fri, 26 Nov 1999, Wolfgang Walter wrote: > On Fri, Nov 26, 1999 at 12:01:16PM +0100, mark@lightning.cistron.nl wrote: > > Hi, > > > > Yesterday I made a testsetup with a 3com 8 port Officeconnect switch and some > > Linux PC's. Two of the PC's have 100Mbit cards, one is a 3com 905 and the other > > a Tulip 21143 (unknown brand). The 3com works perfectly at 100Mbit full duplex. > > But the Tulip has problems. The switch gives both full duplex and 100Mbit > > link lights, but when I try to transfer data it is very slow. When I force the > > tulip into half dulpex mode it works great. > > > > Here some stats: > > > > Which driver do you use? I head similar problems with drivers 0.89H, too. > Indeed, the driver didn't really put the card to FD-mode with flow-control. I'm using driver: Nov 26 11:52:26 localhost kernel: tulip.c:v0.91 4/14/99 becker@cesdis.gsfc.nasa.gov Bye, Mark -- Discussion is futile, you will be ignored, - Linus From wolfgang.walter@stusta.mhn.de Fri Nov 26 20:16:49 1999 Date: Fri Nov 26 20:16:49 1999 From: Wolfgang Walter wolfgang.walter@stusta.mhn.de Subject: tulip bug, alternative fix (untested) Hi Edward, my patch (corrected patch 2) does work here. Now I implemented another approach which may be more elegant and better. It works under normal condition without problems. If it works under the hang-condition I could not verify yet. Try out :-). Greetings, Wolfgang Walter --- 2.2.14pre4/drivers/net/tulip.c Fri Nov 5 18:02:35 1999 +++ 2.2.14pre4-m/drivers/net/tulip.c Sat Nov 27 02:03:32 1999 @@ -530,6 +530,8 @@ int cur_index; /* Current media index. */ int saved_if_port; unsigned char pci_bus, pci_devfn; + int ttimer; + int susp_rx; int pad0, pad1; /* Used for 8-byte alignment */ }; @@ -2484,6 +2486,8 @@ tp->tx_full = 0; tp->cur_rx = tp->cur_tx = 0; tp->dirty_rx = tp->dirty_tx = 0; + tp->susp_rx = 0; + tp->ttimer = 0; for (i = 0; i < RX_RING_SIZE; i++) { tp->rx_ring[i].status = 0x00000000; @@ -2578,6 +2582,8 @@ struct tulip_private *tp = (struct tulip_private *)dev->priv; long ioaddr = dev->base_addr; int csr5, work_budget = max_interrupt_work; + int entry; + int missed; #if defined(__i386__) && defined(SMP_CHECK) if (test_and_set_bit(0, (void*)&dev->interrupt)) { @@ -2594,7 +2600,7 @@ } dev->interrupt = 1; #endif - + do { csr5 = inl(ioaddr + CSR5); /* Acknowledge all of the current interrupt sources ASAP. */ @@ -2607,7 +2613,10 @@ if ((csr5 & (NormalIntr|AbnormalIntr)) == 0) break; - if (csr5 & (RxIntr | RxNoBuf)) + if (csr5 & RxNoBuf) + tp->susp_rx = 1; + + if (csr5 & RxIntr) work_budget -= tulip_rx(dev); if (csr5 & (TxNoBuf | TxDied | TxIntr)) { @@ -2708,6 +2717,7 @@ printk(KERN_ERR "%s: Re-enabling interrupts, %8.8x.\n", dev->name, csr5); outl(tulip_tbl[tp->chip_id].valid_intrs, ioaddr + CSR7); + tp->ttimer = 0; } if (csr5 & (TPLnkPass | TPLnkFail | 0x08000000)) { if (tp->link_change) @@ -2726,9 +2736,34 @@ outl(((~csr5) & 0x0001ebef) | AbnormalIntr | TimerInt, ioaddr + CSR7); outl(12, ioaddr + CSR11); + tp->ttimer = 1; break; } } while (1); + + + /* if in suspend mode: try to get an skb */ + entry = tp->cur_rx % RX_RING_SIZE; + if (tp->susp_rx) { + tulip_rx(dev); + tp->susp_rx = 0; + } + + /* check if we card is in suspend mode */ + if (tp->rx_skbuff[entry] == NULL) { + tp->susp_rx = 1; + if (tp->ttimer == 0 || (inl(ioaddr + CSR11) & 0xffff) == 0) { + outl(tulip_tbl[tp->chip_id].valid_intrs | TimerInt, + ioaddr + CSR7); + outl(TimerInt, ioaddr + CSR5); + outl(12, ioaddr + CSR11); + tp->ttimer = 1; + } + } + + if ((missed = inl(ioaddr + CSR8) & 0x1ffff)) { + tp->stats.rx_dropped += missed & 0x10000 ? 0x10000 : missed; + } if (tulip_debug > 4) printk(KERN_DEBUG "%s: exiting interrupt, csr5=%#4.4x.\n", From wolfgang.walter@stusta.mhn.de Sat Nov 27 23:38:12 1999 Date: Sat Nov 27 23:38:12 1999 From: Wolfgang Walter wolfgang.walter@stusta.mhn.de Subject: another tuilp bug? Hi, there seems to be another tulip bug. The timer interrupt is handled as abnormal interrupt. At least for 21041 it seems to be a normal interrupt. This means that the handling of TimeInt should be moved. As I don't know if it is not an abnormal interrupt for other chips of the tulip familie, one should move out of normal and abnormal. And one should explicit enable NormalInt when setting the timer. The 21041-manual says in 3-45 that is an normal interrupt, too. Greetings, Wolfgang Walter From wolfgang.walter@stusta.mhn.de Sat Nov 27 23:48:04 1999 Date: Sat Nov 27 23:48:04 1999 From: Wolfgang Walter wolfgang.walter@stusta.mhn.de Subject: tulip bug, alternative fix, #3 (tested) Hi, this patch works for me. Would be nice if you could confirm it :-). Change compared with my previous one I sent you: TimerInt handling changed. Thanks, Wolfgang Walter --- 2.2.14pre4/drivers/net/tulip.c Fri Nov 5 18:02:35 1999 +++ 2.2.14pre4-m/drivers/net/tulip.c Sun Nov 28 05:59:44 1999 @@ -530,6 +530,9 @@ int cur_index; /* Current media index. */ int saved_if_port; unsigned char pci_bus, pci_devfn; + int ttimer; + int susp_rx; + unsigned long nir; int pad0, pad1; /* Used for 8-byte alignment */ }; @@ -2484,6 +2487,9 @@ tp->tx_full = 0; tp->cur_rx = tp->cur_tx = 0; tp->dirty_rx = tp->dirty_tx = 0; + tp->susp_rx = 0; + tp->ttimer = 0; + tp->nir = 0; for (i = 0; i < RX_RING_SIZE; i++) { tp->rx_ring[i].status = 0x00000000; @@ -2578,6 +2584,8 @@ struct tulip_private *tp = (struct tulip_private *)dev->priv; long ioaddr = dev->base_addr; int csr5, work_budget = max_interrupt_work; + int entry; + int missed; #if defined(__i386__) && defined(SMP_CHECK) if (test_and_set_bit(0, (void*)&dev->interrupt)) { @@ -2595,6 +2603,8 @@ dev->interrupt = 1; #endif + tp->nir++; + do { csr5 = inl(ioaddr + CSR5); /* Acknowledge all of the current interrupt sources ASAP. */ @@ -2703,12 +2713,6 @@ tp->stats.rx_missed_errors += inl(ioaddr + CSR8) & 0xffff; outl(tp->csr6 | 0x2002, ioaddr + CSR6); } - if (csr5 & TimerInt) { - if (tulip_debug > 2) - printk(KERN_ERR "%s: Re-enabling interrupts, %8.8x.\n", - dev->name, csr5); - outl(tulip_tbl[tp->chip_id].valid_intrs, ioaddr + CSR7); - } if (csr5 & (TPLnkPass | TPLnkFail | 0x08000000)) { if (tp->link_change) (tp->link_change)(dev, csr5); @@ -2716,6 +2720,13 @@ /* Clear all error sources, included undocumented ones! */ outl(0x0800f7ba, ioaddr + CSR5); } + if (csr5 & TimerInt) { + if (tulip_debug > 2) + printk(KERN_ERR "%s: Re-enabling interrupts, %8.8x.\n", + dev->name, csr5); + outl(tulip_tbl[tp->chip_id].valid_intrs, ioaddr + CSR7); + tp->ttimer = 0; + } if (--work_budget < 0) { if (tulip_debug > 1) printk(KERN_WARNING "%s: Too much work during an interrupt, " @@ -2723,12 +2734,43 @@ /* Acknowledge all interrupt sources. */ outl(0x8001ffff, ioaddr + CSR5); /* Clear all interrupting sources, set timer to re-enable. */ - outl(((~csr5) & 0x0001ebef) | AbnormalIntr | TimerInt, + outl(((~csr5) & 0x0001ebef) | NormalIntr | AbnormalIntr | TimerInt, ioaddr + CSR7); outl(12, ioaddr + CSR11); + tp->ttimer = 1; break; } } while (1); + + + /* if in suspend mode: try to get an skb */ + entry = tp->cur_rx % RX_RING_SIZE; + /* if in suspend mode: try to get an skb; if received packets pending: receive */ + if (tp->susp_rx || (tp->rx_skbuff[entry] != NULL && ! (tp->rx_ring[entry].status & cpu_to_le32(DescOwned)))) { + if (tp->susp_rx) + printk(KERN_WARNING "%s: in rx suspend mode: (%lu) (cur_rx = %u, ttimer = %d) try to get some skbs\n", dev->name, tp->nir, tp->cur_rx, tp->ttimer); + tulip_rx(dev); + tp->susp_rx = 0; + entry = tp->cur_rx % RX_RING_SIZE; + } + + /* check if we card is in suspend mode */ + if (tp->rx_skbuff[entry] == NULL) { + printk(KERN_WARNING "%s: in rx suspend mode: (%lu) (tp->cur_rx = %u, ttimer = %d) go/stay in suspend mode\n", dev->name, tp->nir, tp->cur_rx, tp->ttimer); + tp->susp_rx = 1; + if (tp->ttimer == 0 || (inl(ioaddr + CSR11) & 0xffff) == 0) { + printk(KERN_WARNING "%s: in rx suspend mode: (%lu) set timer\n", dev->name, tp->nir); + outl(tulip_tbl[tp->chip_id].valid_intrs | TimerInt, + ioaddr + CSR7); + outl(TimerInt, ioaddr + CSR5); + outl(12, ioaddr + CSR11); + tp->ttimer = 1; + } + } + + if ((missed = inl(ioaddr + CSR8) & 0x1ffff)) { + tp->stats.rx_dropped += missed & 0x10000 ? 0x10000 : missed; + } if (tulip_debug > 4) printk(KERN_DEBUG "%s: exiting interrupt, csr5=%#4.4x.\n", From kernel@venus.ajusd.org Sun Nov 28 02:54:28 1999 Date: Sun Nov 28 02:54:28 1999 From: Edward Schlunder kernel@venus.ajusd.org Subject: tulip bug, alternative fix, #3 (tested) On Sun, 28 Nov 1999, Wolfgang Walter wrote: > How long transmitting does not work very well after hang situation is > over (rx-dropped does not increase any more?). Does it help if you > just kill some applications whioch allocated a lot of memory? It stayed in the bad transmitting state up until I reset it ("ifdown eth0; ifup eth0") at least 30 minutes after it went phooey. I didn't try killing off any applications, but I doubt memory should be a problem. It dies in the middle of the night (around 1AM) when nobody is using the system and the system has 1GB of memory to begin with. > It is interesting that you run out of skbs always at a certain time. > What runs then (do you start special cron-jobs?). How much memory do > you have and how big is your swap? Yes, it is rather interesting that it always konks out at around 1AM. Let me explain my set up... I have 8 servers: a main one (the one that's konking out) with 1GB RAM and quad PPro 200s, and 7 site ones with 512MB RAM and dual PPro 200s. The site server each have their time syncronized via xntpd to the main server. At 1:01AM, each server is set up to run a cronjob that basically does "mt lock" to lock a tape in the SCSI tape drive (of which there hasn't been one lately), fails, and then sends off an email complaining to the main server. The main server also runs nntpsend every hour at 1 minute past the hour (ie, *:01). The tape drive cronjob seems to be part of the cause, as it consistently crashes the network every night around 1AM -- except for the two nights (Sun and Mon) that the tape drive cronjobs were turned off last week. But -- it's not just the tape drive cornjob because one day I tried setting all the servers to do the tape drive job hourly (ie, *:01) and it didn't crash during the day (I only tried a few times and then set it back). > How long does your skript wait before it resets eth0? Because with my > script Rx should remain in supsend mode until skbs are again > available. Could you send me the output of ifconfig eth0? If your > script detects the situation: The network reset script was set to run every 5 minutes and reset immediately if it finds the net broken. I have now set it to run at *:05 hourly and to show "ifconfig eth0 ; sleep 2" ten times before resetting the network card. > this patch works for me. Would be nice if you could confirm it :-). Change > compared with my previous one I sent you: TimerInt handling changed. Will do.. Since I've never had the system crash before on Sun or Mon night, we will not really know if your patch is working or if it it just never happens on Sun/Mon if it doesn't crash. ;-) But after Tuesday night we will know for sure. -- Ed Schlunder From Mike.Rudgyard@comlab.ox.ac.uk Tue Nov 30 08:25:06 1999 Date: Tue Nov 30 08:25:06 1999 From: Mike Rudgyard Mike.Rudgyard@comlab.ox.ac.uk Subject: Intel EtherExpress PRO/100 Mobile Cardbus 32 Adapter Hi, According to the latest PCMCIA howto, this card is now supported, although it does not work on my setup. I have mailed the PCMCIA Message Forum, with no response, so I am not sure whether the problem is in the Tulip driver, the Cardbus interface or the PCMCIA package. As you will see below, the tulip-diag programme informs me about a PCI bus error, before moaning about the EEPROM, hence this mail. Many thanks, Mike Rudgyard -------------------------------------------------------------------------- System: Red Hat 6.1 Kernel 2.2.12 tulip.c:v0.91g 7/16/99 pcmcia-cs-3.1.4 Here's what I get in /var/log/messages : Nov 18 10:52:43 rock last message repeated 19 times Nov 18 10:52:44 rock cardmgr[360]: initializing socket 1 Nov 18 10:52:44 rock cardmgr[360]: socket 1: Intel EtherExpress PRO/100 CardBus Mobile Adapter32 Nov 18 10:52:44 rock kernel: cs: cb_alloc(bus 35): vendor 0x1011, device 0x0019 Nov 18 10:52:44 rock cardmgr[360]: executing: 'insmod /lib/modules/2.2.12-20/pcmcia/cb_enabler.o' Nov 18 10:52:44 rock cardmgr[360]: executing: 'insmod /lib/modules/2.2.12-20/pcmcia/tulip_cb.o' Nov 18 10:52:44 rock kernel: cs: cb_config(bus 35) Nov 18 10:52:44 rock kernel: fn 0 bar 1: io 0x100-0x17f Nov 18 10:52:44 rock kernel: fn 0 bar 2: mem 0x60081000-0x6008107f Nov 18 10:52:44 rock kernel: fn 0 rom: mem 0x60041000-0x60080fff Nov 18 10:52:44 rock kernel: tulip_attach(bus 35, function 0) Nov 18 10:52:44 rock kernel: tulip.c:v0.91 4/14/99 becker@cesdis.gsfc.nasa.gov (modified by danilo@cs.uni-magdeburg.de for XIRCOM CBE, fixed by Doug Ledford) Nov 18 10:52:44 rock kernel: eth0: Digital DS21143 Tulip rev 48 at 0x100, EEPROM not present, 00:4C:69:6E:75:79, IRQ 3. Nov 18 10:52:44 rock cardmgr[360]: executing: './network start eth0' Nov 18 10:52:45 rock modprobe: can't locate module block-major-22 Here's what I get with another 3COM card (that works fine...): Nov 18 10:52:17 rock last message repeated 53 times Nov 18 10:52:18 rock cardmgr[360]: initializing socket 1 Nov 18 10:52:18 rock cardmgr[360]: socket 1: 3Com 3CCFE575B/3CXFE575B Fast EtherLink XL Nov 18 10:52:18 rock kernel: cs: cb_alloc(bus 35): vendor 0x10b7, device 0x5157 Nov 18 10:52:18 rock cardmgr[360]: executing: 'insmod /lib/modules/2.2.12-20/pcmcia/cb_enabler.o' Nov 18 10:52:18 rock cardmgr[360]: executing: 'insmod /lib/modules/2.2.12-20/pcmcia/3c575_cb.o' Nov 18 10:52:18 rock kernel: 3c59x.c:v0.99L 5/28/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html Nov 18 10:52:18 rock kernel: cs: cb_config(bus 35) Nov 18 10:52:18 rock kernel: fn 0 bar 1: io 0x100-0x17f Nov 18 10:52:18 rock kernel: fn 0 bar 2: mem 0x60021000-0x6002107f Nov 18 10:52:18 rock kernel: fn 0 bar 3: mem 0x60020000-0x6002007f Nov 18 10:52:18 rock kernel: fn 0 rom: mem 0x60000000-0x6001ffff Nov 18 10:52:18 rock kernel: vortex_attach(bus 35, function 0, device 5157) Nov 18 10:52:18 rock kernel: eth0: 3Com 3CCFE575 Cyclone CardBus at 0x100, 00:50:04:5b:b0:b9, IRQ 3 Nov 18 10:52:18 rock kernel: eth0: CardBus functions mapped 60020000->c8073000 Nov 18 10:52:18 rock kernel: 8K byte-wide RAM 5:3 Rx:Tx split, MII interface. Nov 18 10:52:18 rock kernel: MII transceiver found at address 0, status 7809. Nov 18 10:52:18 rock kernel: Enabling bus-master transmits and whole-frame receives. Nov 18 10:52:18 rock cardmgr[360]: executing: './network start eth0' Nov 18 10:52:18 rock modprobe: can't locate module block-major-22 Nov 18 10:52:21 rock last message repeated 5 times Nov 18 10:52:21 rock kernel: eth0: Setting full-duplex based on MII #0 link partner capability of 41e1. Nov 18 10:52:22 rock modprobe: can't locate module block-major-22 Here's what tulip-diag gives on the EEPRO card: [root@rock incoming]# tulip-diag tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0x60081000. Port selection is 100mbps-SYM/PCS 100baseTx scrambler, full-duplex. 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. The NWay status register is ffffffff. WARNING: The EEPROM is missing or erased! Internal autonegotiation state is 'Invalid state'. 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. Since it tells me there is a PCI bus error, here's some info on the PCI devices on Dell Latitude CPi (with the EtherExpress card in....) PCI devices found: Bus 35, device 0, function 0: Ethernet controller: DEC DC21142 (rev 48). Medium devsel. Fast back-to-back capable. IRQ 3. Non-prefetchable 32 bit memory at 0x100 [0x100]. Non-prefetchable 32 bit memory at 0x60081000 [0x60081000]. Bus 0, device 0, function 0: Host bridge: Intel 440BX - 82443BX Host (no AGP) (rev 2). Medium devsel. Master Capable. Latency=32. Prefetchable 32 bit memory at 0xd0000000 [0xd0000008]. Bus 0, device 2, function 0: VGA compatible controller: Neomagic MagicGraph NM2160 (rev 1). Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=32. Min Gnt=16.Max Lat=255. Prefetchable 32 bit memory at 0xe1000000 [0xe1000008]. Non-prefetchable 32 bit memory at 0xfde00000 [0xfde00000]. Non-prefetchable 32 bit memory at 0xfdd00000 [0xfdd00000]. Bus 0, device 3, function 0: CardBus bridge: Texas Instruments PCI1131 (rev 1). Medium devsel. IRQ 11. Master Capable. Latency=32. Min Gnt=192.Max Lat=7. Bus 0, device 3, function 1: CardBus bridge: Texas Instruments PCI1131 (rev 1). Medium devsel. IRQ 11. Master Capable. Latency=32. Min Gnt=128.Max Lat=7. Bus 0, device 7, function 0: Bridge: Intel 82371AB PIIX4 ISA (rev 1). Medium devsel. Fast back-to-back capable. Master Capable. No bursts. Bus 0, device 7, function 1: IDE interface: Intel 82371AB PIIX4 IDE (rev 1). Medium devsel. Fast back-to-back capable. Master Capable. Latency=32. I/O at 0x860 [0x861]. Bus 0, device 7, function 2: USB Controller: Intel 82371AB PIIX4 USB (rev 1). Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=32. I/O at 0xece0 [0xece1]. Bus 0, device 7, function 3: Bridge: Intel 82371AB PIIX4 ACPI (rev 1). Medium devsel. Fast back-to-back capable. -- Michael Rudgyard Smith Fellow Oxford University Computing Laboratory Wolfson Building Parks Rd Oxford OX1 3QD UK Tel : +44 (0)1865 273896 Fax : +44 (0)1865 273839 From becker@cesdis.gsfc.nasa.gov Tue Nov 30 16:00:46 1999 Date: Tue Nov 30 16:00:46 1999 From: Donald Becker becker@cesdis.gsfc.nasa.gov Subject: Intel EtherExpress PRO/100 Mobile Cardbus 32 Adapter On Tue, 30 Nov 1999, Mike Rudgyard wrote: > Subject: Intel EtherExpress PRO/100 Mobile Cardbus 32 Adapter > According to the latest PCMCIA howto, this card is now supported, although > it does not work on my setup. I have mailed the PCMCIA Message Forum, with > no response, so I am not sure whether the problem is in the Tulip driver, > the Cardbus interface or the PCMCIA package. As you will see below, the > tulip-diag programme informs me about a PCI bus error, before moaning > about the EEPROM, hence this mail. It's supported *IF* the EEPROM media table is correct. Some editions of the card don't have a blank EEPROM, and you must use a recent tulip-diag program to write it. > Nov 18 10:52:44 rock cardmgr[360]: socket 1: Intel EtherExpress PRO/100 CardBus Mobile Adapter32 > Nov 18 10:52:44 rock kernel: cs: cb_alloc(bus 35): vendor 0x1011, device 0x0019 Yup, a 21143. > Nov 18 10:52:44 rock kernel: fn 0 bar 1: io 0x100-0x17f > Nov 18 10:52:44 rock kernel: fn 0 bar 2: mem 0x60081000-0x6008107f I/O address 0x100. > Nov 18 10:52:44 rock kernel: tulip.c:v0.91 4/14/99 becker@cesdis.gsfc.nasa.gov (modified by danilo@cs.uni-magdeburg.de for XIRCOM CBE, fixed by Doug Ledford) I don't trust the modified version, but that's not the problem here. > Nov 18 10:52:44 rock kernel: eth0: Digital DS21143 Tulip rev 48 at 0x100, > EEPROM not present, 00:4C:69:6E:75:79, IRQ 3. This is the problem -- the EEPROM is blank. Intel doesn't follow their own design manual. They are the *only* 21143 CardBus vendor that doesn't. > [root@rock incoming]# tulip-diag > tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) > Index #1: Found a Digital DS21143 Tulip adapter at 0x60081000. I don't know where it picked this address from! It should use the I/O address from BAR0, not the memory address from BAR1. I'm guessing the PCMCIA code does not leave the I/O space bit set in /proc/bus/pci/devices. (David, can you comment on this?) > Bus 35, device 0, function 0: > Ethernet controller: DEC DC21142 (rev 48). > Medium devsel. Fast back-to-back capable. IRQ 3. > Non-prefetchable 32 bit memory at 0x100 [0x100]. > Non-prefetchable 32 bit memory at 0x60081000 [0x60081000]. Yup. That's what is happening. This is likely David's bug. The work-around is tulip-diag -t 4 -p 0x100 -e Follow the directions to update your EEPROM, if everything looks good from the report. Donald Becker Scyld Computing Corporation, and USRA-CESDIS, becker@cesdis.gsfc.nasa.gov From dhinds@tao.stanford.edu Tue Nov 30 16:19:56 1999 Date: Tue Nov 30 16:19:56 1999 From: David Hinds dhinds@tao.stanford.edu Subject: Intel EtherExpress PRO/100 Mobile Cardbus 32 Adapter On Tue, Nov 30, 1999 at 04:09:30PM -0500, Donald Becker wrote: > > I don't know where it picked this address from! It should use the I/O > address from BAR0, not the memory address from BAR1. I'm guessing the > PCMCIA code does not leave the I/O space bit set in /proc/bus/pci/devices. > > (David, can you comment on this?) Yup, this would seem to be a bug in my CardBus setup code; I didn't really think about what other things might make use of the values I stick in the pci_dev structure. I'll fix it for 3.1.5. -- Dave