From buerkl@hoover.ee.cooper.edu Wed Sep 30 20:25:13 1998 Date: Wed Sep 30 20:25:13 1998 From: Gus Buerkle buerkl@hoover.ee.cooper.edu Subject: v1.03 on Alpha, 2.1.122/111 Hello, I am running Linux 2.1.x on an Alpha 164LX. I had been using a 3Com 905TX card, but always encountered kernel panics whenever the eth0 interface was brought up under 2.1.x (worked fine for 2.0.x). So the switch was made to the Intel EtherExpress Pro100 ('82557). I started using Becker's driver v0.36, built into kernel 2.1.122. It worked fairly well, but there was an occasional 'network crash', for lack of a better term, in which the interface would become unresponsive and the only way to get back on the network was to reboot. Bringing eth0 down and back up had no effect. So I decided to move up to the v1.03 driver Then I built the 2.1.123 kernel with eepro100.c v1.03 as a module. When bringing the interface up, no errors are encountered, but nothing happens. I'd like to get the new driver working, whether as a module or built in. Here are some diagnostics: /sbin/ifconfig: [root@dunkel /root]# depmod -a [root@dunkel net]# modprobe eepro100.o [root@dunkel net]# cat /proc/modules eepro100 17672 0 (unused) [root@dunkel net]# ifup eth0 [root@dunkel net]# ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:8020 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 coll:0 eth0 Link encap:Ethernet HWaddr 00:A0:C9:2A:9F:EB inet addr:199.98.20.240 Bcast:199.98.20.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:0 dropped:0 overruns:0 carrier:0 coll:0 Interrupt:18 Base address:0x8000 /var/log/messages: Sep 30 14:00:10 dunkel kernel: eepro100.c:v1.03 8/11/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html Sep 30 14:00:10 dunkel kernel: eepro100.c:v1.03 8/11/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html Sep 30 14:00:10 dunkel kernel: eth0: Intel EtherExpress Pro 10/100 at 0x8000, 00:A0:C9:2A:9F:EB, IRQ 18. Sep 30 14:00:10 dunkel kernel: Board assembly 352509-003, Physical connectors present: RJ45 Sep 30 14:00:10 dunkel kernel: Primary interface chip DP83840 PHY #1. Sep 30 14:00:10 dunkel kernel: DP83840 specific setup, setting register 23 to 8462. Sep 30 14:00:10 dunkel kernel: General self-test: passed. Sep 30 14:00:10 dunkel kernel: Serial sub-system self-test: passed. Sep 30 14:00:10 dunkel kernel: Internal registers self-test: passed. Sep 30 14:00:10 dunkel kernel: ROM checksum self-test: passed (0x49caa8d6). Sep 30 14:00:10 dunkel kernel: Receiver lock-up workaround activated. /proc/net/dev: [root@dunkel net]# cat /proc/net/dev Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 /proc/modules: [root@dunkel net]# cat /proc/modules eepro100 17672 0 (unused) It appears that the module has been loaded correctly, but the network interface doesn't work. Separately, I cannot compile the eepro-diag program from becker's site. The following gcc error results: [root@dunkel linux-2.1.122]# gcc -O -Wall -o eepro-diag eepro100-diag.c In file included from eepro100-diag.c:30: /usr/include/linux/in.h:109: parse error before `sa_family_t' /usr/include/linux/in.h:109: warning: no semicolon at end of struct or union /usr/include/linux/in.h:116: parse error before `}' In file included from /usr/include/asm/io.h:6, from eepro100-diag.c:32: /usr/include/asm/machvec.h:58: parse error before `*' /usr/include/asm/machvec.h:60: parse error before `*' /usr/include/asm/machvec.h:62: parse error before `*' /usr/include/asm/machvec.h:65: parse error before `value' /usr/include/asm/machvec.h:67: parse error before `value' /usr/include/asm/machvec.h:69: parse error before `value' /usr/include/asm/machvec.h:82: parse error before `vector' My symlinks to /usr/src/linux are set up properly: [root@dunkel linux-2.1.122]# ls -l /usr/include lrwxrwxrwx 1 root root 28 Sep 18 13:53 linux -> /usr/src/linux/include/linux lrwxrwxrwx 1 root root 32 Sep 18 17:41 asm -> /usr/src/linux/include/asm-alpha lrwxrwxrwx 1 root root 27 Sep 18 13:53 scsi -> /usr/src/linux/include/scsi Any things I should check regarding this problem? Thanks August Buerkle From becker@cesdis1.gsfc.nasa.gov Wed Sep 30 20:50:54 1998 Date: Wed Sep 30 20:50:54 1998 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: v1.03 on Alpha, 2.1.122/111 On Wed, 30 Sep 1998, Gus Buerkle wrote: > I am running Linux 2.1.x on an Alpha 164LX. I had been using a 3Com 905TX > card, but always encountered kernel panics whenever the eth0 interface was > brought up under 2.1.x (worked fine for 2.0.x). So the switch was made Hmmm, I don't regularly test my drivers under 2.1.* on the Alpha. I run 2.0.35 on my Alpha at home. > So I decided to move up to the v1.03 driver > Then I built the 2.1.123 kernel with eepro100.c v1.03 as a module. > When bringing the interface up, no errors are encountered, but nothing > happens. I'd like to get the new driver working, whether as a module > or built in. Here are some diagnostics: Does it work under 2.0.35? > Separately, I cannot compile the eepro-diag program from becker's site. > The following gcc error results: > [root@dunkel linux-2.1.122]# gcc -O -Wall -o eepro-diag eepro100-diag.c > In file included from eepro100-diag.c:30: > /usr/include/linux/in.h:109: parse error before `sa_family_t' I suspect that this is a 2.1.122 kernel bug. Donald Becker becker@cesdis.gsfc.nasa.gov USRA-CESDIS, Center of Excellence in Space Data and Information Sciences. Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html From hp3@gmx.net Mon Oct 5 02:44:07 1998 Date: Mon Oct 5 02:44:07 1998 From: Minnie Mouse hp3@gmx.net Subject: Known max. MBit/s What is the highest known rate of MBit/s of the EtherExpress 100+? With netperf i could only reach 50MBit/s between a linux and a win98 box. (forced to full-duplex and 100MBit/s) I know that with a 3com card nearly 80MBit/s are possible. Is the eepro100 driver not as optimized as the 3com driver? When the driver is loaded at the boot a 82555 chip is found. According to the serial-number i have a EtherExpress 100+ with a 82558 chip. Is there an other driver for the 100+? thanks patrick --- Sent through Global Message Exchange - http://www.gmx.net From rgb@phy.duke.edu Mon Oct 5 10:00:22 1998 Date: Mon Oct 5 10:00:22 1998 From: Robert G. Brown rgb@phy.duke.edu Subject: Known max. MBit/s On Mon, 5 Oct 1998, Minnie Mouse wrote: > > What is the highest known rate of MBit/s of the EtherExpress 100+? > With netperf i could only reach 50MBit/s between a linux and a > win98 box. (forced to full-duplex and 100MBit/s) > I know that with a 3com card nearly 80MBit/s are possible. Is the > eepro100 driver not as optimized as the 3com driver? > > When the driver is loaded at the boot a 82555 chip is found. > According to the serial-number i have a EtherExpress 100+ with > a 82558 chip. Is there an other driver for the 100+? > > thanks > patrick > --- > Sent through Global Message Exchange - http://www.gmx.net > I just posted benchmarks to beowulf.org showing 95.6 Mbps of DATA (not including headers) in BOTH DIRECTIONS on a full duplex eepro100 to eepro100 link through a switch. This is 98.5% data efficiency (allowing for the headers). Hard to do much better than this... rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu From buerkl@hoover.ee.cooper.edu Mon Oct 5 13:17:40 1998 Date: Mon Oct 5 13:17:40 1998 From: Gus Buerkle buerkl@hoover.ee.cooper.edu Subject: eepro100 on alpha, linux 2.1 Donald, Regarding my attempt to use the eepro100 drivers under linux-alpha 2.1.122, I compiled the eepro-diag program under 2.0.32 and ran it on the 2.1.122 kernel running the v0.36 driver. (It failed to compile under a development kernel) Here are the results: [root@marzen /root]# ./eepro-diag -f -e -e -a -m eepro100-diag.c:v0.07 2/25/98 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Intel 82557 EtherExpressPro100B adapter at 0x8000. i82557 chip registers at 0x8000: 00000050 4065b018 00000000 00080002 14378462 00000600 No interrupt sources are pending. The transmit unit state is 'Suspended'. The receive unit state is 'Ready'. EEPROM contents: d000 1564 4ad0 0000 0000 0080 2200 0000 1a92 0481 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 6b93 The EEPROM checksum (should be 0xbaba) is 0xdd5a. Intel EtherExpress Pro 10/100 EEPROM contents: Station address 00:D0:64:15:D0:4A. Receiver lock-up bug exists. (The driver work-around *is* implemented.) Board assembly 1a9204-129, Physical connectors present: Primary interface chip i82553-C PHY #0. What about this EEPROM checksum? Here's the logged messages when the network interface crashes: Aug 28 10:43:46 dunkel kernel: eth0: Transmit timed out: status 0050 command 0000. Aug 28 10:43:46 dunkel kernel: eth0: Tx timeout fill index 53098 scavenge index 53084. Aug 28 10:43:46 dunkel kernel: Tx queue 000ca000 000ca000 000ca000 000ca000 000ca000 000ca000 000ca000 000ca000 000ca000 400ca000 000ca000 000ca000 000c0000 000ca000 000ca000 000ca000. Aug 28 10:43:46 dunkel kernel: Rx ring 00000003 00000003 00000003 00000003 00000003 00000003 00000003 00000003 00000003 00000003 00000003 c0000003 00000003 00000003 00000003 00000003. Aug 28 10:43:46 dunkel kernel: eth0: Trying to restart the transmitter... >From this point the network is unresponsive, and the only way to bring it back is to unload the eepro module and then reinsert it. Simply bringing the eth0 interface down and up will not do it. Thanks for checking this out. Gus Buerkle From jordy@wserv.com Mon Oct 5 18:17:17 1998 Date: Mon Oct 5 18:17:17 1998 From: Jordan Mendelson jordy@wserv.com Subject: General problems with 2.1.x Attempting to compile the 1.03 driver into Linux 2.1.124 results in the following errors: make[3]: Entering directory `/usr/src/linux-2.1.122/drivers/net' gcc -D__KERNEL__ -I/usr/src/linux-2.1.122/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -D__SMP__ -pipe -fno-strength-reduce -m486 -malign- loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -c -o eepro100.o eepro100.c eepro100.c:79: parse error before string constant eepro100.c:79: warning: type defaults to `int' in declaration of `MODULE_AUTHOR' eepro100.c:79: warning: function declaration isn't a prototype eepro100.c:79: warning: data definition has no type or storage class eepro100.c:80: parse error before string constant eepro100.c:80: warning: type defaults to `int' in declaration of `MODULE_DESCRIPTION' eepro100.c:80: warning: function declaration isn't a prototype eepro100.c:80: warning: data definition has no type or storage class eepro100.c:81: parse error before string constant eepro100.c:81: warning: type defaults to `int' in declaration of `MODULE_PARM' eepro100.c:81: warning: function declaration isn't a prototype eepro100.c:81: warning: data definition has no type or storage class eepro100.c:82: parse error before string constant eepro100.c:83: parse error before string constant eepro100.c:84: parse error before string constant eepro100.c:84: warning: type defaults to `int' in declaration of `MODULE_PARM' eepro100.c:84: warning: function declaration isn't a prototype eepro100.c:84: warning: data definition has no type or storage class eepro100.c:85: parse error before string constant eepro100.c:85: warning: type defaults to `int' in declaration of `MODULE_PARM' eepro100.c:85: warning: function declaration isn't a prototype eepro100.c:85: warning: data definition has no type or storage class eepro100.c:86: parse error before string constant eepro100.c:86: warning: type defaults to `int' in declaration of `MODULE_PARM' eepro100.c:86: warning: function declaration isn't a prototype eepro100.c:86: warning: data definition has no type or storage class eepro100.c:87: parse error before string constant eepro100.c:87: warning: type defaults to `int' in declaration of `MODULE_PARM' eepro100.c:87: warning: function declaration isn't a prototype eepro100.c:87: warning: data definition has no type or storage class eepro100.c:88: parse error before string constant eepro100.c:88: warning: type defaults to `int' in declaration of `MODULE_PARM' eepro100.c:88: warning: function declaration isn't a prototype eepro100.c:88: warning: data definition has no type or storage class eepro100.c:89: parse error before string constant eepro100.c:89: warning: type defaults to `int' in declaration of `MODULE_PARM' eepro100.c:89: warning: function declaration isn't a prototype eepro100.c:89: warning: data definition has no type or storage class eepro100.c:90: parse error before string constant eepro100.c:90: warning: type defaults to `int' in declaration of `MODULE_PARM' eepro100.c:90: warning: function declaration isn't a prototype eepro100.c:90: warning: data definition has no type or storage class eepro100.c:91: parse error before string constant eepro100.c:91: warning: type defaults to `int' in declaration of `MODULE_PARM' eepro100.c:91: warning: function declaration isn't a prototype eepro100.c:91: warning: data definition has no type or storage class make[3]: *** [eepro100.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.1.122/drivers/net' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux-2.1.122/drivers/net' make[1]: *** [_subdir_net] Error 2 make[1]: Leaving directory `/usr/src/linux-2.1.122/drivers' make: *** [_dir_drivers] Error 2 Putting an #ifdef MODULE/#endif around the MODULE_* blocks fixes it. In 2.1.123, I get these error messages every time a socket is closed: Oct 5 18:13:46 solid kernel: Socket destroy delayed (r=128 w=0) And the version of eepro100.c that comes with 2.1.x will not work reliably with my SMP machine (crashes, ifconfig down/up breaks it, etc). This card is: eepro100.c:v1.03 8/11/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eth0: OEM i82557/i82558 10/100 Ethernet at 0xef80, 00:A0:C9:E1:F3:D8, IRQ 10. Board assembly 697680-001, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x24c9f043). Receiver lock-up workaround activated. eepro100.c:v1.03 8/11/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html Jordan -- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com From sstone@ume.pht.co.jp Mon Oct 5 20:20:30 1998 Date: Mon Oct 5 20:20:30 1998 From: Scott Stone sstone@ume.pht.co.jp Subject: eepro100 on alpha, linux 2.1 On Mon, 5 Oct 1998, Gus Buerkle wrote: > Donald, > > Regarding my attempt to use the eepro100 drivers under linux-alpha > 2.1.122, > > I compiled the eepro-diag program under 2.0.32 and ran it on the 2.1.122 > kernel running the v0.36 driver. (It failed to compile under a > development kernel) Here are the results: > > [root@marzen /root]# ./eepro-diag -f -e -e -a -m > eepro100-diag.c:v0.07 2/25/98 Donald Becker (becker@cesdis.gsfc.nasa.gov) > Index #1: Found a Intel 82557 EtherExpressPro100B adapter at 0x8000. > i82557 chip registers at 0x8000: > 00000050 4065b018 00000000 00080002 14378462 00000600 > No interrupt sources are pending. > The transmit unit state is 'Suspended'. > The receive unit state is 'Ready'. > > Here's the logged messages when the network interface crashes: > > Aug 28 10:43:46 dunkel kernel: eth0: Transmit timed out: status 0050 > command 0000. > Aug 28 10:43:46 dunkel kernel: eth0: Tx timeout fill index 53098 > scavenge index 53084. > Aug 28 10:43:46 dunkel kernel: Tx queue 000ca000 000ca000 000ca000 > 000ca000 000ca000 000ca000 000ca000 000ca000 000ca000 400ca000 000ca000 > 000ca000 000c0000 000ca000 > 000ca000 000ca000. > Aug 28 10:43:46 dunkel kernel: Rx ring 00000003 00000003 00000003 > 00000003 00000003 00000003 00000003 00000003 00000003 00000003 00000003 > c0000003 00000003 00000003 00000003 00000003. > Aug 28 10:43:46 dunkel kernel: eth0: Trying to restart the transmitter... You're not running netatalk on this box, are you? If I run netatalk on my x86 with 2.0.35, eepro100, it will start doing this. It will work at first, but generate huge amounts of TX timeouts and 'Trying to restart the transmitter'. Then, it seems the driver gives up and suspends the TX unit. You can reset it by: 1. take down eth0 2. modprobe -r eepro100 3. modprobe eepro100 4. restart eth0 -------------------------------------------------- Scott M. Stone Head of TurboLinux Development/Systems Administrator Pacific HiTech, Inc (USA) / Pacific HiTech, KK (Japan) http://www.pht.com http://armadillo.pht.co.jp http://www.pht.co.jp http://www.turbolinux.com From oa@spray.fi Tue Oct 6 04:09:23 1998 Date: Tue Oct 6 04:09:23 1998 From: Osma Ahvenlampi oa@spray.fi Subject: "Transmit timed out" with EtherExpress Pro100B On a Dell PowerEdge 2300, using Linux 2.0.35 with the aic7xxx 5.1.0-pre15 and eepro100 1.03 drivers I get the "eth0: Transmit timed out status 0050 command 0000" error with the associated massive broadcast flooding when I install the appletalk module (this machine is intended to be a Samba/Netatalk file server). I was able to determine the cause of the problem with help of the list archive, however the release notes for this driver seemed to indicate the bug should have been fixed by now. It most clearly isn't, though. Additionally eepro100-diag just crashes on line 298 when I try to run it, and mii-diag doesn't tell a lot.. As far as I understand, the multicast_filter_limit option doesn't work with kernel 2.0.x (at least it didn't seem to take when I put it in /etc/conf.modules). I haven't tried patching the driver yet. Assuming the driver just does not work, I have to replace the card in the machine. I've used 3c905's in the past, and although they haven't caused me any problems, I've heard all the usual horror stories and they haven't seemed terribly fast. I suppose I should get a DEC Tulip based card then. Which one would be good? Of course, I'd prefer to keep the original configuration and have a working driver.. fragment from dmesg: eepro100.c:v1.03 8/11/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c:v1.03 8/11/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eth0: OEM i82557/i82558 10/100 Ethernet at 0xdce0, 00:A0:C9:E4:E2:5F, IRQ 14. Board assembly 697680-001, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x24c9f043). Receiver lock-up workaround activated. [root@pe2300 src]# ./eepro100-diag eepro100-diag.c:v0.07 2/25/98 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Intel 82557 EtherExpressPro100B adapter at 0xdce0. Segmentation fault (core dumped) [root@pe2300 src]# ./mii-diag -v mii-diag.c:v1.03 8/4/98 Donald Becker (becker@cesdis.gsfc.nasa.gov) Using the default interface 'eth0'. MII PHY in use is 1. [root@pe2300 src]# cat /proc/pci PCI devices found: Bus 0, device 14, function 0: Ethernet controller: Intel 82557 (rev 5). Medium devsel. Fast back-to-back capable. IRQ 14. Master Capable. Latency=32. Min Gnt=8.Max Lat=56. Prefetchable 32 bit memory at 0xf7000000. I/O at 0xdce0. Non-prefetchable 32 bit memory at 0xfe000000. Bus 0, device 7, function 3: Bridge: Intel 82371AB PIIX4 ACPI (rev 2). Medium devsel. Fast back-to-back capable. Bus 0, device 7, function 2: USB Controller: Intel 82371AB PIIX4 USB (rev 1). Medium devsel. Fast back-to-back capable. Master Capable. Latency=64. I/O at 0x0. Bus 0, device 7, function 1: IDE interface: Intel 82371AB PIIX4 IDE (rev 1). Medium devsel. Fast back-to-back capable. Master Capable. Latency=64. I/O at 0xffa0. Bus 0, device 7, function 0: ISA bridge: Intel 82371AB PIIX4 ISA (rev 2). Medium devsel. Fast back-to-back capable. Master Capable. No bursts. Bus 2, device 6, function 0: SCSI storage controller: Adaptec AIC-7860 (rev 3). Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=32. Min Gnt=4.Max Lat=4. I/O at 0xe800. Non-prefetchable 32 bit memory at 0xf9ffe000. Bus 2, device 4, function 0: SCSI storage controller: Adaptec AIC-7890/1 (rev 0). Medium devsel. Fast back-to-back capable. BIST capable. IRQ 11. Master Capable. Latency=32. Min Gnt=39.Max Lat=25. I/O at 0xec00. Non-prefetchable 64 bit memory at 0xf9fff000. Bus 0, device 2, function 0: PCI bridge: DEC DC21152 (rev 3). Medium devsel. Fast back-to-back capable. Master Capable. Latency=32. Min Gnt=2.Max Lat=3. Bus 1, device 0, function 0: VGA compatible controller: ATI Mach64 GD (Rage Pro) (rev 92). Medium devsel. Fast back-to-back capable. IRQ 255. Master Capable. Latency=32. Min Gnt=8. Non-prefetchable 32 bit memory at 0xfc000000. I/O at 0xfc00. Non-prefetchable 32 bit memory at 0xfbfff000. Bus 0, device 1, function 0: PCI bridge: Intel 440BX - 82443BX AGP (rev 2). Medium devsel. Master Capable. Latency=32. Min Gnt=136. Bus 0, device 0, function 0: Host bridge: Intel 440BX - 82443BX Host (rev 2). Medium devsel. Master Capable. Latency=32. Prefetchable 32 bit memory at 0xf0000000. From ksi@gu.net Tue Oct 6 05:30:29 1998 Date: Tue Oct 6 05:30:29 1998 From: Serguei Koubouchine ksi@gu.net Subject: "Transmit timed out" with EtherExpress Pro100B On 6 Oct 1998, Osma Ahvenlampi wrote: > On a Dell PowerEdge 2300, using Linux 2.0.35 with the aic7xxx > 5.1.0-pre15 and eepro100 1.03 drivers I get the "eth0: Transmit timed > out status 0050 command 0000" error with the associated massive > broadcast flooding when I install the appletalk module (this machine > is intended to be a Samba/Netatalk file server). I was able to > determine the cause of the problem with help of the list archive, > however the release notes for this driver seemed to indicate the bug > should have been fixed by now. It most clearly isn't, though. > > Additionally eepro100-diag just crashes on line 298 when I try to run > it, and mii-diag doesn't tell a lot.. > > As far as I understand, the multicast_filter_limit option doesn't work > with kernel 2.0.x (at least it didn't seem to take when I put it in > /etc/conf.modules). I haven't tried patching the driver yet. The eepro100 driver is BUGGY. Unfortunately enough, Donald Becker seems to consider it being top quality, so we don't have any hope to get those adapters work in our machines :-( The old driver included in the kernel trees does work with any number of multicast filters provided this number is one... Donald's recipe for the driver is "Don't use gated", which does effectively mean "Don't use eepro100 at all"... All bug reports sent to Donald seem to go to /dev/null - no answer, no reaction at all :-( So being a realist I'd suggest everybody to forget about eepro100 existance at all... ======================================================================= Serguei Koubouchine aka the Tamer < > The impossible we do immediately. e-mail: ksi@gu.net SK320-RIPE < > Miracles require 24-hour notice. ======================================================================= From James.Stevens@jrcs.co.uk Tue Oct 6 07:10:18 1998 Date: Tue Oct 6 07:10:18 1998 From: James Stevens James.Stevens@jrcs.co.uk Subject: "Transmit timed out" with EtherExpress Pro100B Osma Ahvenlampi wrote: > > On a Dell PowerEdge 2300, using Linux 2.0.35 with the aic7xxx > 5.1.0-pre15 and eepro100 1.03 drivers I get the "eth0: Transmit timed > out status 0050 command 0000" error I have suffered with this BUG for ever, there is no fix and despite repeated pleas, and even offers of cash, Donald seems to be unwilling to investigate / fix it. I have had a look at it myself and tried tweaking the "txfifo" & "rxfifo" values, but it didn't make any difference. Unfortunately, I have no information about this chip at all, so can't begin to try and fix it. Sadly, for me, we can not use a different "card" cos the Intel chip is soldered onto the motherboard and we only have one slot which we need for something else. It seems this problem is partly due to a bug with the Intel chip where by it trashes the status register under heavy load. I have a program called "open_socket" which breaks this driver within about 3 seconds. My advise is, if you are having a problem, don't use this driver, don't use this card. On the other hand, we have another box here which also has the Intel on board and the same test runs fine. We have only run the test with a 10Mbps hub, and will report the results on a 100Mbps hub as soon as it becomes free. James From James.Stevens@jrcs.co.uk Tue Oct 6 07:12:42 1998 Date: Tue Oct 6 07:12:42 1998 From: James Stevens James.Stevens@jrcs.co.uk Subject: "Transmit timed out" with EtherExpress Pro100B ======================================================================= Serguei Koubouchine aka the Tamer < > The impossible we do immediately. e-mail: ksi@gu.net SK320-RIPE < > Miracles require 24-hour notice. ======================================================================= ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Fix the EEPro-100 driver, consider this 24 hours notice. James From rgb@phy.duke.edu Tue Oct 6 07:20:25 1998 Date: Tue Oct 6 07:20:25 1998 From: Robert G. Brown rgb@phy.duke.edu Subject: "Transmit timed out" with EtherExpress Pro100B On Tue, 6 Oct 1998, Serguei Koubouchine wrote: > The eepro100 driver is BUGGY. Unfortunately enough, Donald Becker seems to > consider it being top quality, so we don't have any hope to get those > adapters work in our machines :-( The old driver included in the kernel > trees does work with any number of multicast filters provided this number is > one... Donald's recipe for the driver is "Don't use gated", which does > effectively mean "Don't use eepro100 at all"... All bug reports sent to > Donald seem to go to /dev/null - no answer, no reaction at all :-( > > So being a realist I'd suggest everybody to forget about eepro100 existance > at all... Oooo, brutal! I have to say that I use the eepro100 in (16) Dell poweredge 2300's and just benchmarked them full duplex through a switch at 95.6 Mbps (data only) or 98.5% of wire speed, accounting for the headers. This is going both ways at once, so the aggregate bandwidth was 191 Mbps. The network is stable enough that several of the systems were up for months diskless (while awaiting a functioning aic7xxx). The difficulties experienced on a poweredge 2300 could easily come from a mixture of a kernel swap/mmap bug, the aic7xxx 7890 driver (which is still pre-release, after all) and the eepro100. I don't deny that there are likely some problems in the driver and I'm sure Donald is aware of them, but most of the problems that are left very likely multiple layers of the system, and not just the drivers themselves. You also have to be aware that Don tries to make the same drivers function on all linux/PCI architectures, which makes debugging them even harder. I personally think that it is a miracle that Don maintains basically all the ethernet drivers in use in Linux today, and if he can only do so by being conservative and by trying to share the largest amount possible of internal code, then it is a small price to pay. And let us not forget -- each and every one of us has the source. If there is a feature you would like to see added, or a bug you would like to squash, feel free! I've tried to help Don out in the past (sometimes usefully, sometimes not:-) and I know he is very receptive to outside contributions and bug fixes. It's not like we're paying him for help so we should feel entitled to receive it...although I personally plan to buy him a beer the first chance I get! rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu From ksi@gu.net Tue Oct 6 07:47:27 1998 Date: Tue Oct 6 07:47:27 1998 From: Serguei Koubouchine ksi@gu.net Subject: "Transmit timed out" with EtherExpress Pro100B On Tue, 6 Oct 1998, James Stevens wrote: > ======================================================================= > Serguei Koubouchine aka the Tamer < > The impossible we do immediately. > e-mail: ksi@gu.net SK320-RIPE < > Miracles require 24-hour notice. > ======================================================================= > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Fix the EEPro-100 driver, consider this 24 hours notice. A plea for a miracle? ======================================================================= Serguei Koubouchine aka the Tamer < > The impossible we do immediately. e-mail: ksi@gu.net SK320-RIPE < > Miracles require 24-hour notice. ======================================================================= From ksi@gu.net Tue Oct 6 07:52:20 1998 Date: Tue Oct 6 07:52:20 1998 From: Serguei Koubouchine ksi@gu.net Subject: "Transmit timed out" with EtherExpress Pro100B On Tue, 6 Oct 1998, Robert G. Brown wrote: > On Tue, 6 Oct 1998, Serguei Koubouchine wrote: > > > The eepro100 driver is BUGGY. Unfortunately enough, Donald Becker seems to > > consider it being top quality, so we don't have any hope to get those > > adapters work in our machines :-( The old driver included in the kernel > > trees does work with any number of multicast filters provided this number is > > one... Donald's recipe for the driver is "Don't use gated", which does > > effectively mean "Don't use eepro100 at all"... All bug reports sent to > > Donald seem to go to /dev/null - no answer, no reaction at all :-( > > > > So being a realist I'd suggest everybody to forget about eepro100 existance > > at all... > > Oooo, brutal! I have to say that I use the eepro100 in (16) Dell > poweredge 2300's and just benchmarked them full duplex through a switch > at 95.6 Mbps (data only) or 98.5% of wire speed, accounting for the > headers. This is going both ways at once, so the aggregate bandwidth > was 191 Mbps. The network is stable enough that several of the systems > were up for months diskless (while awaiting a functioning aic7xxx). Did you try to get AT-2560TX working without mii-diag voodoo? Did you try to work it reliably with that voodoo? FYI: this card is clearly announced as working at Donald's site... BTW, do you happen to do any routing on that poweredges? Did you try to use gated or ipv6 with eepro100? ======================================================================= Serguei Koubouchine aka the Tamer < > The impossible we do immediately. e-mail: ksi@gu.net SK320-RIPE < > Miracles require 24-hour notice. ======================================================================= From oa@spray.fi Tue Oct 6 09:11:37 1998 Date: Tue Oct 6 09:11:37 1998 From: Osma Ahvenlampi oa@spray.fi Subject: "Transmit timed out" with EtherExpress Pro100B "Robert G. Brown" writes: > Oooo, brutal! I have to say that I use the eepro100 in (16) Dell > poweredge 2300's and just benchmarked them full duplex through a switch > at 95.6 Mbps (data only) or 98.5% of wire speed, accounting for the Interesting. I benchmarked the machine against another with a 3c905 using a crossover wire, with the result of 94 Mbps. I agree there's nothing wrong with the speed of the card (actually, I was surprised the 3com was that fast). > headers. This is going both ways at once, so the aggregate bandwidth > was 191 Mbps. The network is stable enough that several of the systems > were up for months diskless (while awaiting a functioning aic7xxx). In a network that has multicast traffic? > The difficulties experienced on a poweredge 2300 could easily come from > a mixture of a kernel swap/mmap bug, the aic7xxx 7890 driver (which is > still pre-release, after all) and the eepro100. I don't deny that there This is true. Since I can't boot the machine without the aic7xxx pre-release driver (which is in its last beta before the real release, so if there is a bug in it, it should be pointed out ASAP), it's difficult for me to eliminate that variable. PowerEdge has the eepro and the aic7xxx on different interrupts, though.. Anyway, I just patched the eepro100 driver to multicast_filter_limit=0, re-enabled appletalk, and put two machines pinging the pe2300 constantly. If I don't see the problem within one hour, I would consider it pretty clear what's broken. With only surface knowledge of Linux internals and absolutely no knowledge of the Intel Speedo3 chip, I can't do anything about a fix, though. > are likely some problems in the driver and I'm sure Donald is aware of > them, but most of the problems that are left very likely multiple layers > of the system, and not just the drivers themselves. You also have to be If the other poster is right, and this problem can be demonstrated simply by running gated, that doesn't leave THAT many layers. Pretty much the minimum layers for a functioning IP stack, in fact. While I would personally like to see this work, and do something to reach that goal, I simply can not justify the hours spent in internal hacking instead of business. It's cheaper for us to buy a new card for the machine. I'm just afraid that next time I'm configuring a server, I'll have the same problem in front of me. -- Chemistry professors never die, they just smell that way! Osma Ahvenlampi From oa@spray.fi Tue Oct 6 09:34:46 1998 Date: Tue Oct 6 09:34:46 1998 From: Osma Ahvenlampi oa@spray.fi Subject: "Transmit timed out" with EtherExpress Pro100B Osma Ahvenlampi writes: > Anyway, I just patched the eepro100 driver to > multicast_filter_limit=0, re-enabled appletalk, and put two machines > pinging the pe2300 constantly. If I don't see the problem within one > hour, I would consider it pretty clear what's broken. With only Okay, it's been running for 30 minutes with Netatalk on (and in use, although not heavily), and the pings haven't lost a packet yet. Resposnse time is consistent 0.3-0.4 milliseconds, and I haven't seen any spurious traffic on the switches. Considering that the machine used to go absolutely mad within 3 minutes of starting Netatalk before, I consider the immediate problem solved. What this does to performance, I have no idea of. Conclusion: eepro100 v1.03 multicast filtering is still broken. -- Possession, n. The whole of the law. Osma Ahvenlampi From James.Stevens@jrcs.co.uk Tue Oct 6 10:04:47 1998 Date: Tue Oct 6 10:04:47 1998 From: James Stevens James.Stevens@jrcs.co.uk Subject: "Transmit timed out" with EtherExpress Pro100B Robert G. Brown wrote: > > I personally think that it is a miracle that Don maintains basically all > the ethernet drivers in use in Linux today, and if he can only do so by > being conservative and by trying to share the largest amount possible of > internal code, then it is a small price to pay. > > And let us not forget -- each and every one of us has the source. If > there is a feature you would like to see added, or a bug you would like > to squash, feel free! I've tried to help Don out in the past (sometimes > usefully, sometimes not:-) and I know he is very receptive to outside > contributions and bug fixes. It's not like we're paying him for help so > we should feel entitled to receive it...although I personally plan to > buy him a beer the first chance I get! Robert, you are absolutly right. I can not agree more, however, I don't have access to Intel documentation, and don't have a clue how to get it (I have asked). I'm just about at my wits end on this one and to me the EEPro-100 driver is useless. It is obviuosly somthing to do with the exact way the chip has been implemented in the unit I am trying to use, but I just don't know where to start. At the end of the day I'm not paying anything for the drivers / support (although I have offered to) and what you say embodies the whole concept of Linux and GNU, "You have the source so fix it yourself"; but (and mine is a BIG "BUT", ha ha ha), I just feel so lost I don't know where to start, I have no experience in this field. James From rgb@phy.duke.edu Tue Oct 6 11:02:24 1998 Date: Tue Oct 6 11:02:24 1998 From: Robert G. Brown rgb@phy.duke.edu Subject: "Transmit timed out" with EtherExpress Pro100B On 6 Oct 1998, Osma Ahvenlampi wrote: > Interesting. I benchmarked the machine against another with a 3c905 > using a crossover wire, with the result of 94 Mbps. I agree there's > nothing wrong with the speed of the card (actually, I was surprised > the 3com was that fast). UDP, not TCP. I think TCP would come in around 94, by the time you factor in the larger headers. Don't remember. > > headers. This is going both ways at once, so the aggregate bandwidth > > was 191 Mbps. The network is stable enough that several of the systems > > were up for months diskless (while awaiting a functioning aic7xxx). > > In a network that has multicast traffic? It is a switched network and there are certainly broadcasts but not a ton of multicasts esp from e.g. Appletalk or NT -- these tend to be isolated on VLAN. > > The difficulties experienced on a poweredge 2300 could easily come from > > a mixture of a kernel swap/mmap bug, the aic7xxx 7890 driver (which is > > still pre-release, after all) and the eepro100. I don't deny that there > > This is true. Since I can't boot the machine without the aic7xxx > pre-release driver (which is in its last beta before the real release, > so if there is a bug in it, it should be pointed out ASAP), it's > difficult for me to eliminate that variable. PowerEdge has the eepro > and the aic7xxx on different interrupts, though.. > > Anyway, I just patched the eepro100 driver to > multicast_filter_limit=0, re-enabled appletalk, and put two machines > pinging the pe2300 constantly. If I don't see the problem within one > hour, I would consider it pretty clear what's broken. With only > surface knowledge of Linux internals and absolutely no knowledge of > the Intel Speedo3 chip, I can't do anything about a fix, though. Well, VLAN's are great if you can do it with your switch. Isolate the Macs off by themselves where the can chatter away. Spurious network traffic eats CPU in addition to bandwidth. I think that some of the problems may come from deeper in the kernel, though, and not just in the card. One reason I think this is that they are just (re)surfacing as a new generation of very fast systems like the 2300's appears. With U2W SCSI controllers, fast ethernet controllers, and a heavy task mix you are pushing some kernel latencies, possibly past some point of failure. Has anybody tried the 2.0.36pre stuff? Alan has released a bunch of patches that are supposed to address some of the kernel bugs in 2.0.35; perhaps one of them "fixes" this... > If the other poster is right, and this problem can be demonstrated > simply by running gated, that doesn't leave THAT many layers. Pretty > much the minimum layers for a functioning IP stack, in fact. That's a lot of room, if you think about it... especially if the problem is load dependent. Do you have an SMP system? Do you think that this could be an interrupt resolution issue? > While I would personally like to see this work, and do something to > reach that goal, I simply can not justify the hours spent in internal > hacking instead of business. It's cheaper for us to buy a new card for > the machine. I'm just afraid that next time I'm configuring a server, > I'll have the same problem in front of me. rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu From rgb@phy.duke.edu Tue Oct 6 11:19:23 1998 Date: Tue Oct 6 11:19:23 1998 From: Robert G. Brown rgb@phy.duke.edu Subject: "Transmit timed out" with EtherExpress Pro100B On Tue, 6 Oct 1998, James Stevens wrote: > Robert, you are absolutly right. I can not agree more, however, I don't > have access to Intel documentation, and don't have a clue how to get it > (I have asked). I'm just about at my wits end on this one and to me the > EEPro-100 driver is useless. > > It is obviuosly somthing to do with the exact way the chip has been > implemented in the unit I am trying to use, but I just don't know where > to start. > > At the end of the day I'm not paying anything for the drivers / support > (although I have offered to) and what you say embodies the whole concept > of Linux and GNU, "You have the source so fix it yourself"; but (and > mine is a BIG "BUT", ha ha ha), I just feel so lost I don't know where > to start, I have no experience in this field. I can't argue with that. The thing is, if you try to read the source it isn't so bad. If you are an expert C programmer, that is:-). And it isn't too unreasonable to "expect" Don to fix the problem, either. I just don't think it is productive to put pressure on him. I'm sure that he has seen the discussion thus far and is aware of the problem, but he has to deal with the Intel documents, local bugs, lower level kernel bugs, and around five or six other network devices with similar problems. Like I said, the guy's a miracle -- it's amazing that all these bears dance at all, and even dance gracefully to certain tunes. The key thing here is to figure out what you CAN offer to help fix the problem. I don't mean money, I mean time. Whenever I have serious problems with drivers, I at least try to offer to help and I actually dig into the code (intimidating or not) with some printk's and the like to see if I can at least isolate where in the code the problem is occurring. Sometimes this helps, sometimes I just add noise to the lists, but at least then I feel like I'm DOING something and not just waiting. I'm not trying to be critical of your need, by the way. I just think that it isn't productive to flame the one guy capable of helping you because he isn't moving fast enough... rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu From James.Stevens@jrcs.co.uk Tue Oct 6 11:47:48 1998 Date: Tue Oct 6 11:47:48 1998 From: James Stevens James.Stevens@jrcs.co.uk Subject: "Transmit timed out" with EtherExpress Pro100B Robert G. Brown wrote: > > The thing is, if you try to read the source it > isn't so bad. If you are an expert C programmer, that is:-). I like to think so. But I have never been involved with hardware drivers before. > The key thing here is to figure out what you CAN offer to help fix the > problem. I did, I was getting loads of counts in the TX-FIFO, so I tried upping (to 15) and downing (to 2) both the txiffo & rxfifo, and I tried removeing the transmitter restart, none of this made any difference. It chip still hung. I've had this bug, completely re-producable between two linux boxes on 10Mbps ethernet since 1st Sep and I'm just getting frustrated with it (the bug that is). If you have any ideas I'd really appricate them. The error I get is "status 0050 command 0000" generated by the function "speedo_tx_timeout". I believe the transmitter _has_ hung, as the system locks totally when I remove the transmitter restart, and I suspect it is down to a bug in the chip I outlined in my previous e-mail. I guess what I really need to do is throttle the transmit traffic to the card or somthing ? Can I reduce the TX FIFO to 0 to have packets sent immediatly, or not at all, instead of being queued ? I know it would hit performance, but it would be interesting to try. James From clif@cadmazing.com Tue Oct 6 11:40:44 1998 Date: Tue Oct 6 11:40:44 1998 From: Clif Schieck clif@cadmazing.com Subject: dual booting - Windows 98 and Linux - eepro 100 card gets in stuck mode - need to power off to reset card This is a multi-part message in MIME format. ------=_NextPart_000_0004_01BDF105.11BEF660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have my HP Pavilion PC setup to dual boot. If I put the floppy in and = boot, then it boots with Redhat 5.1 linux. Without the floppy it boots with = windows 98. I have an Intel eepro 100 board installed. I think there is a reset = problem on the board with respect to Linux. If I I click on windows 98 with start -> shutdown -> restart (then insert Linux floppy) - the board is = not reset and I receive error messages (I don't have the exact message) that the port = is not activated. It implies that the card needs to be reset. if I do: start -> shutdown -> shutdown -> manually hit the power switch to the = computer to turn off power -> insert Linux floppy - > turn power button on - > = reboot -> okay then the eepro 100 card is recognized. if I type in Linux shutdown -r now, the card also comes up okay (if the = system was previously reset with power off above). I think it might have something to do with the plug-n-play feature of = the card or a state that windows 98 sets the card to that makes it not = recognizable by Linux. ------=_NextPart_000_0004_01BDF105.11BEF660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have my HP Pavilion PC setup to = dual boot. If=20 I put the floppy in and boot,
then it boots with Redhat 5.1 linux. = Without the=20 floppy it boots with windows
98. I have an Intel eepro 100 board = installed. I=20 think there is a reset problem
on the board with respect to Linux. = If I I click=20 on windows 98 with
 
start -> shutdown -> restart = (then insert=20 Linux floppy) - the board is not reset and
I receive error messages (I don't = have the exact=20 message) that the port is not
activated. It implies that the card = needs to be=20 reset.
 
if I do:
 
start -> shutdown -> shutdown = ->=20 manually hit the power switch to the computer
to turn off power -> insert Linux = floppy -=20 > turn power button on - > reboot -> okay
 
 
then the eepro 100 card is=20 recognized.
 
if I type in Linux shutdown -r now, the card also = comes up=20 okay (if the system
was previously reset with power off = above).
 
I think it might have something to = do with the=20 plug-n-play feature of the card
or a state that windows 98 sets the = card to that=20 makes it not recognizable
by Linux.
 
 
 
 
------=_NextPart_000_0004_01BDF105.11BEF660-- From R.E.Wolff@BitWizard.nl Tue Oct 6 12:00:35 1998 Date: Tue Oct 6 12:00:35 1998 From: Rogier Wolff R.E.Wolff@BitWizard.nl Subject: "Transmit timed out" with EtherExpress Pro100B James Stevens wrote: > Robert G. Brown wrote: > > > > I personally think that it is a miracle that Don maintains basically all > > the ethernet drivers in use in Linux today, and if he can only do so by > > being conservative and by trying to share the largest amount possible of > > internal code, then it is a small price to pay. > > > > And let us not forget -- each and every one of us has the source. If > > there is a feature you would like to see added, or a bug you would like > > to squash, feel free! I've tried to help Don out in the past (sometimes > > usefully, sometimes not:-) and I know he is very receptive to outside > > contributions and bug fixes. It's not like we're paying him for help so > > we should feel entitled to receive it...although I personally plan to > > buy him a beer the first chance I get! > > Robert, you are absolutly right. I can not agree more, however, I don't > have access to Intel documentation, and don't have a clue how to get it > (I have asked). I'm just about at my wits end on this one and to me the > EEPro-100 driver is useless. Documentation is pretty easy. Call any intel representative and ask them for the xxx57 datasheet (I forgot the number). They might want you to sign an NDA. If that's the case, you won't be allowed to photocopy the datasheet and send it over to one of the others. If you don't feel safe writing the GPL code with an Intel NDA with your signature on it, then you should contact Intel about that, and get that cleared up. It seems that they are able to do that for Donald. Ask them for the errata sheet too. I seem to remember that Intel isn't very easy about those: They normally want to wait until you say: "I've spent two weeks full time debugging this, and I've come to the conclusion that there is a bug in your silicon." They like to answer: "Yup, you're right. That's erratum number 14, entered september 1997". Getting intel to call you back is a hassle though. I've never gotten the NDA thing finished, so I don't have the docs. If you don't want to go through the hassle, reading the driver together with the 80586 (it's on the etherexpress 16 card) docs allowed me to write the etherboot driver for the eepro100. The 80586 datasheet is not under NDA. Call an intel representative and ask them for the datasheet. > It is obviuosly somthing to do with the exact way the chip has been > implemented in the unit I am trying to use, but I just don't know where > to start. No I don't think so. PCI chips, you just hook up to the PCI bus, and they work. Roger. -- | Most people would die sooner than think.... | R.E.Wolff@BitWizard.nl | in fact, most do. -- Bertrand Russsell | phone: +31-15-2137555 We write Linux device drivers for any device you may have! fax: ..-2138217 From kfuge@home.com Tue Oct 6 12:12:52 1998 Date: Tue Oct 6 12:12:52 1998 From: Kent Fuge kfuge@home.com Subject: compiled driver This is a multi-part message in MIME format. --------------E0E35B29898DA9F7C9718439 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am new to Linux and am in the middle of installing Caldera Linux 1.3. I have the Intel EtherExpress PRO/100+ and am in need of the compiled driver. (haven't gotten the system up and running far enough to do the compiling myself). I would appreicate it if a reply to this message included the compiled driver and the instructions on how to do the compiling from source in the future. Thanks for all the help in advance!!!! Kent- --------------E0E35B29898DA9F7C9718439 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Kent Fuge Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Kent Fuge n: Fuge;Kent email;internet: kfuge@home.com x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------E0E35B29898DA9F7C9718439-- From James.Stevens@jrcs.co.uk Tue Oct 6 12:21:06 1998 Date: Tue Oct 6 12:21:06 1998 From: James Stevens James.Stevens@jrcs.co.uk Subject: "Transmit timed out" with EtherExpress Pro100B Rogier Wolff wrote: > > > It is obviuosly somthing to do with the exact way the chip has been > > implemented in the unit I am trying to use, but I just don't know where > > to start. > > No I don't think so. PCI chips, you just hook up to the PCI bus, and > they work. Then it must be the PCI chipset, MediaGX. Otherwise it would work wouldn't it ? Prehaps the CPU can't service the BUS quick enough or something ? I haven't a clue what I'm talking about, but we have two boxes here, both with the Intel on board, one is based on an Intel chipset with a Celery 266, the other is MediaGX P200 the former works with this driver the latter does not. Our CPU performance tests, at runing shell script, rate the Celery and double the MediaGX, but only 10% faster than a socket-7 Cyrix P200. We have no Intel cards, so I can't test the driver with the Cyrix P200. Our main concern is getting it running clean on the MediaGX box, cos its _SO_ cute and fits what we're trying to do (put Linux into [very serious] racing cars). James From rgb@phy.duke.edu Tue Oct 6 12:38:06 1998 Date: Tue Oct 6 12:38:06 1998 From: Robert G. Brown rgb@phy.duke.edu Subject: "Transmit timed out" with EtherExpress Pro100B On Tue, 6 Oct 1998, James Stevens wrote: > I did, I was getting loads of counts in the TX-FIFO, so I tried upping > (to 15) and downing (to 2) both the txiffo & rxfifo, and I tried > removeing the transmitter restart, none of this made any difference. It > chip still hung. I've had this bug, completely re-producable between two > linux boxes on 10Mbps ethernet since 1st Sep and I'm just getting > frustrated with it (the bug that is). > > If you have any ideas I'd really appricate them. The error I get is > "status 0050 command 0000" generated by the function > "speedo_tx_timeout". I believe the transmitter _has_ hung, as the system > locks totally when I remove the transmitter restart, and I suspect it is > down to a bug in the chip I outlined in my previous e-mail. A few questions (I don't remember your original posting): a) Are your systems SMP or UP? Fast (e.g. PPro or PII)? b) Is your 10Mbps interconnect crossover wire or hub or switch? The reasons for asking both is that the eepro100 has had known rentrancy problems for SMP systems. They don't appear to affect performance or cause lockups in most cases and I think the threshold for reporting them at all has been moved up, but it occurs to me that looping reentrancy on fast SMP box with a relatively slow channel might exhaust some resource and/or prevent the disentangling of all the interrupts. A SECOND reason for asking is that if you compiled your kernel with SMP and are using a hand-built non-SMP eepro100.o module, the test_and_set_bit and clear_bit commands used to manipulate the dev->tbusy flag will almost certainly fail by reordering and it would not surprise me at all to find both reentrancy and transmitter hang, if not a full IRQ deadlock. If you built the device into your kernel then of course it has __SMP__ correctly defined and this cannot be the cause. If you are connecting them with a wire (or CAN connect them with a wire or 100B hub/switch) you ought to be able to try out 100BT and see if the problem persists. I certainly don't see it here on a clean 100BT switched channel, which doesn't mean a thing, of course. A third thought is that I've experienced significant problems with "good" cards depending on the state of the hub or switch. As an example, I have a number of systems with Tulip cards in them, and have measured very good performance between pairs of tulips or eepro100's through our Cisco Cat5K switch. However, when we put our switch in fixed 100BT/full duplex mode on certain ports, the cards failed to correctly set themselves automatically. They appeared to run 100BT/FD, but all I could get out of them was around 1-2 Mpbs with tons of errors and resets, not unlike what you report. When I reset the switch so port negotiation was back to "auto", the cards worked perfectly again. Quite possibly a bug in the card driver, but I don't know enough about the MII/Nway process to know if it the bug was really in the hub. Either way, hub tuning and trying different card "options=xx" settings might help. I've found that it is almost always better to let the card negotiate with a hub set to negotiate. The curious thing is that your card works for a while and then fails, consistently, under any kind of heavy network load. (Right? About the "heavy load"?) If it were an out and out failure of a command, via a real, hard, bug, I'd sort of expect the driver to fail for everybody (and very quickly and not necessarily in a load dependent way) -- so I have to ask the list -- is ANYBODY successful with eepro100's on 10BT? Especially under load? If folks are successful with eepro100's and 10BT hubs, switches, and crossover wires, in SOME systems it strongly suggests that the problem is environmental -- something about your personal configuration or networking operation that is tweaking the bug. I assume that you've done things like swapped hub/switch ports, replaced the cables, and generally ensured that the problem isn't just bad media or hubs. Have you ruled out bad silicon? Are you overclocking? Could the net adapter be failing because of excessive heat in the cases? Sorry if these are studid questions, but sometimes it is little things that cause big failures. > I guess what I really need to do is throttle the transmit traffic to the > card or somthing ? > > Can I reduce the TX FIFO to 0 to have packets sent immediatly, or not at > all, instead of being queued ? I know it would hit performance, but it > would be interesting to try. The only thing that I can think of that you might usefully try after considering the stuff above is to put in some printk's around the points where the tbusy flag is being set or cleared. This might reveal just where in the queue things are screwing up -- I would guess that something "impossible" is happening. That's good as it should stand out like a sore thumb. I don't think any simple tuning will help... Hope some of this helps, rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu From rgb@phy.duke.edu Tue Oct 6 12:39:52 1998 Date: Tue Oct 6 12:39:52 1998 From: Robert G. Brown rgb@phy.duke.edu Subject: "Transmit timed out" with EtherExpress Pro100B On Tue, 6 Oct 1998, Rogier Wolff wrote: > No I don't think so. PCI chips, you just hook up to the PCI bus, and > they work. (Smile;-) rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu From buerkl@hoover.ee.cooper.edu Tue Oct 6 12:43:00 1998 Date: Tue Oct 6 12:43:00 1998 From: Gus Buerkle buerkl@hoover.ee.cooper.edu Subject: "Transmit timed out" with EtherExpress Pro100B How about Donald making use of his NDA and releasing Intel chip information to any one us who will agree to similar terms? I am with James in that I don't have much of an idea of how to start working on the problem, but I think there exists enough general information on linux ethernet drivers that it wouldn't be impossible. Gus Buerkle On Tue, 6 Oct 1998, James Stevens wrote: > Robert G. Brown wrote: > > > > I personally think that it is a miracle that Don maintains basically all > > the ethernet drivers in use in Linux today, and if he can only do so by > > being conservative and by trying to share the largest amount possible of > > internal code, then it is a small price to pay. > > > > And let us not forget -- each and every one of us has the source. If > > there is a feature you would like to see added, or a bug you would like > > to squash, feel free! I've tried to help Don out in the past (sometimes > > usefully, sometimes not:-) and I know he is very receptive to outside > > contributions and bug fixes. It's not like we're paying him for help so > > we should feel entitled to receive it...although I personally plan to > > buy him a beer the first chance I get! > > Robert, you are absolutly right. I can not agree more, however, I don't > have access to Intel documentation, and don't have a clue how to get it > (I have asked). I'm just about at my wits end on this one and to me the > EEPro-100 driver is useless. > > It is obviuosly somthing to do with the exact way the chip has been > implemented in the unit I am trying to use, but I just don't know where > to start. > > At the end of the day I'm not paying anything for the drivers / support > (although I have offered to) and what you say embodies the whole concept > of Linux and GNU, "You have the source so fix it yourself"; but (and > mine is a BIG "BUT", ha ha ha), I just feel so lost I don't know where > to start, I have no experience in this field. > > James > From James.Stevens@jrcs.co.uk Tue Oct 6 12:57:10 1998 Date: Tue Oct 6 12:57:10 1998 From: James Stevens James.Stevens@jrcs.co.uk Subject: "Transmit timed out" with EtherExpress Pro100B Robert G. Brown wrote: > > A few questions (I don't remember your original posting): > > a) Are your systems SMP or UP? Fast (e.g. PPro or PII)? Single CPU. Linux 2.0.34, on a MedixGX chipset, this is a "pentium system on a chip" type silicon. i.e. it has all the CPU, cache, USB, T.V., video, sound, chipset (PCI, EIDE, Floppy), 2xserial, parallel, LCD interface, mouse, KBD etc on the single chip which makes for a VERY small box (500 sheets of A4 paper type size, which includes internal power, 3.5 Hdd & floppy !!). It is REALLY CUTE, we pay $250 and just have to add ram & hdd. > b) Is your 10Mbps interconnect crossover wire or hub or switch? Cheap D-Link 8 port Hub, so switching, no full-duplex etc. But the same hub works fine with a different box which also has the Intel chip on board but is a proper (custom) mainboard with Intel chipset and Celery 266. Up till we got the 2nd box I thought the problem was the 10Mbps, but not anymore. Now I think it is the CPU not servicing the EEPro fast enough. I have not tried this box on cross over, it will be worth a try. > The curious thing is that your card works for a while and then fails, No. It runs fine under virtually no load, but fails quite quickly even under light / medium load and within 3 seconds under heavy load. It is another box altogether that works fine. > Have you ruled out bad silicon? No, good point. We do have two of these little boxes, so I could try the other one. But I know Doug Karl who make the freeware & commercial KarlBridge (firewall / Brouter), and he said he had BIG problems with the Intel in this box, but could not tell me about it because of an Intel NDA. > Are you overclocking? No chance. It is not possable with the MediaGX in the box we have. > Could the net adapter be failing because of excessive heat in the cases? I don't think so. It runs surprisingly cool for such a small box. James From rgb@phy.duke.edu Tue Oct 6 13:15:51 1998 Date: Tue Oct 6 13:15:51 1998 From: Robert G. Brown rgb@phy.duke.edu Subject: "Transmit timed out" with EtherExpress Pro100B On Tue, 6 Oct 1998, James Stevens wrote: > Robert G. Brown wrote: > > > > A few questions (I don't remember your original posting): > > > > a) Are your systems SMP or UP? Fast (e.g. PPro or PII)? > > Single CPU. Linux 2.0.34, on a MedixGX chipset, this is a "pentium > system on a chip" type silicon. i.e. it has all the CPU, cache, USB, > T.V., video, sound, chipset (PCI, EIDE, Floppy), 2xserial, parallel, LCD > interface, mouse, KBD etc on the single chip which makes for a VERY > small box (500 sheets of A4 paper type size, which includes internal > power, 3.5 Hdd & floppy !!). It is REALLY CUTE, we pay $250 and just > have to add ram & hdd. > > > b) Is your 10Mbps interconnect crossover wire or hub or switch? > > Cheap D-Link 8 port Hub, so switching, no full-duplex etc. But the same > hub works fine with a different box which also has the Intel chip on > board but is a proper (custom) mainboard with Intel chipset and Celery > 266. Up till we got the 2nd box I thought the problem was the 10Mbps, > but not anymore. Now I think it is the CPU not servicing the EEPro fast > enough. This is an interesting setup. What does your /proc/pci look like? /proc/interrupts? /proc/ioports? The reason that I ask is that if the PCI bios were at all munged, you might be sharing an interrupt or overlapping in iospace with some other device, e.g. a video controller or the sound card. I've certainly seen problems like that on a "normal" system with lots of slots, but in many cases they go away if you rearrange the cards or are firm with the firmware. With all this stuff onboard and a system designed (I'm sure:-( to run Windows, maybe it has hardware PnP stuff with "dumb" PCI conflicts that it expects Windows to be straightening out at boot time. > > I have not tried this box on cross over, it will be worth a try. > > > The curious thing is that your card works for a while and then fails, > > No. It runs fine under virtually no load, but fails quite quickly even > under light / medium load and within 3 seconds under heavy load. > > It is another box altogether that works fine. > > > Have you ruled out bad silicon? > > No, good point. We do have two of these little boxes, so I could try the > other one. But I know Doug Karl who make the freeware & commercial > KarlBridge (firewall / Brouter), and he said he had BIG problems with > the Intel in this box, but could not tell me about it because of an > Intel NDA. Is the eepro100 also onboard? Can you put a $30 tulip on the PCI bus (you said it has one, right)? I think all of Don's drivers are very similar in general layout, and differ primarily only where it counts, but it would help narrow down the cause of failure either way. > > > Are you overclocking? > > No chance. It is not possable with the MediaGX in the box we have. > > > Could the net adapter be failing because of excessive heat in the cases? > > I don't think so. It runs surprisingly cool for such a small box. Dumb questions, maybe, but a lot of people write driver problems into lists and you find out after everybody has been scratching their heads for a week that oh, yeah, they're running a 200 MHz system at 400 MHz with a turbocharged heatsink and when they put the clock back to normal (and let everything cool off) things "magically" start to work again... It sounds like it might well be an Intel problem; maybe you should try for the NDA... rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu From cg2v+@andrew.cmu.edu Tue Oct 6 19:39:30 1998 Date: Tue Oct 6 19:39:30 1998 From: Chaskiel M Grundman cg2v+@andrew.cmu.edu Subject: Intel Datasheets (was Re: "Transmit timed out" with EtherExpress Pro100B) Excerpts from internet.computing.linux-eepro100: 6-Oct-98 Re: "Transmit timed out" wi.. by Rogier Wolff@BitWizard.n > Documentation is pretty easy. Call any intel representative and ask > them for the xxx57 datasheet (I forgot the number). It seems even easier than that. I was able to fetch datasheets for the 8255{7,8} from http://developer.intel.com/design/network/datashts These datasheets seem a it skimpy on the software side, and only mention in passing that multicast filtering exists. I also ordered the 'Networking 1998 Databook' (no PDF, no mention of NDA) which may or may not have any information about the 557/8. Not unexpectedly, the errata don't seem to be available. From sstone@ume.pht.co.jp Tue Oct 6 20:13:56 1998 Date: Tue Oct 6 20:13:56 1998 From: Scott Stone sstone@ume.pht.co.jp Subject: compiled driver On Tue, 6 Oct 1998, Kent Fuge wrote: > I am new to Linux and am in the middle of installing Caldera Linux 1.3. > I have the Intel EtherExpress PRO/100+ and am in need of the compiled > driver. (haven't gotten the system up and running far enough to do the > compiling myself). I would appreicate it if a reply to this message > included the compiled driver and the instructions on how to do the > compiling from source in the future. CL 1.3's kernel, I believe, includes the driver already. > > Thanks for all the help in advance!!!! > > Kent- > -------------------------------------------------- Scott M. Stone Head of TurboLinux Development/Systems Administrator Pacific HiTech, Inc (USA) / Pacific HiTech, KK (Japan) http://www.pht.com http://armadillo.pht.co.jp http://www.pht.co.jp http://www.turbolinux.com From marko@iprg.nokia.com Tue Oct 6 21:42:40 1998 Date: Tue Oct 6 21:42:40 1998 From: Marko Kiiskila marko@iprg.nokia.com Subject: Intel Datasheets (was Re: "Transmit timed out" with EtherExpress Pro100B) > It seems even easier than that. > I was able to fetch datasheets for the 8255{7,8} from > http://developer.intel.com/design/network/datashts > These datasheets seem a it skimpy on the software side, and only mention > in passing that multicast filtering exists. I also ordered the > 'Networking 1998 Databook' (no PDF, no mention of NDA) which may or may > not have any information about the 557/8. Unfortunately that book is useless. What you need is Intel 82557 User's Manual, which I believe cannot be obtained without NDA. Intel website contains all kinds of preliminary docs about this chip, but in order to do any real software work you need to get that manual. -- Marko Kiiskila marko@iprg.nokia.com +1 408 990 2023 From oa@spray.fi Wed Oct 7 05:49:21 1998 Date: Wed Oct 7 05:49:21 1998 From: Osma Ahvenlampi oa@spray.fi Subject: "Transmit timed out" with EtherExpress Pro100B "Robert G. Brown" writes: > Well, VLAN's are great if you can do it with your switch. Isolate the > Macs off by themselves where the can chatter away. Spurious network > traffic eats CPU in addition to bandwidth. I think that some of the My switches support it, but I'm not going to start going through that hassle for just about any reason, with our people moving from desk to desk quite often and taking their laptops with them. In any case, VLANs would be impossible now, because this machine is supposed to become the primary file server (AppleShare and SMB). Pretty difficult to isolate it from the Macs and keep that working.. > problems may come from deeper in the kernel, though, and not just in the > card. One reason I think this is that they are just (re)surfacing as a > new generation of very fast systems like the 2300's appears. With U2W > SCSI controllers, fast ethernet controllers, and a heavy task mix you > are pushing some kernel latencies, possibly past some point of failure. Keep in mind this machine isn't really under any load at all yet. I have it sitting by my desk, with most network services installed and enabled, but it doesn't have the RAID connected yet, and no one but me is really accessing at all. It went crazy without anyone touching it, just by being on the network and seeing the multicast traffic between the Macs and their current file server. It hasn't really been pushed to any limit yet, and it's even connected to a 10Mbps switch port at the moment. It's remained quiet and behaved itself now that I patched the driver to not use the hardware multicast filtering at all. I'll receive the rest of the hardware next week and put it to a better stress test with all the components configured, and that's when I'll see if the patch makes the network interface too slow, or if it goes crazy again. > Has anybody tried the 2.0.36pre stuff? Alan has released a bunch of > patches that are supposed to address some of the kernel bugs in 2.0.35; > perhaps one of them "fixes" this... I suppose I could.. I was going to wait for the official release though, since I don't particularly think of constant kernel patching and recompiling as "fun". > That's a lot of room, if you think about it... especially if the problem > is load dependent. Do you have an SMP system? Do you think that this > could be an interrupt resolution issue? I don't think the machine has had a loadavg over 0.1 at any point during it's life here. It's a single-CPU system, and the only shared interrupt in it is the one used by aic7xxx (both 7880 and 7890 are on interrupt 11): [root@pe2300 /root]# cat /proc/interrupts 0: 8110722 timer 1: 1114 keyboard 2: 0 cascade 3: 495090 + serial 8: 1 + rtc 11: 72524 aic7xxx, aic7xxx 13: 1 math error 14: 348484 Intel EtherExpress Pro 10/100 Ethernet -- You know better than to trust a strange computer. Osma Ahvenlampi From oa@spray.fi Wed Oct 7 06:26:56 1998 Date: Wed Oct 7 06:26:56 1998 From: Osma Ahvenlampi oa@spray.fi Subject: "Transmit timed out" with EtherExpress Pro100B James Stevens writes: > If you have any ideas I'd really appricate them. The error I get is > "status 0050 command 0000" generated by the function > "speedo_tx_timeout". I believe the transmitter _has_ hung, as the system > locks totally when I remove the transmitter restart, and I suspect it is > down to a bug in the chip I outlined in my previous e-mail. okay.. My problem (same error message) went away with this patch: --- eepro100-1.03.c Wed Oct 7 13:01:38 1998 +++ eepro100.c Wed Oct 7 13:01:20 1998 @@ -41,7 +41,7 @@ static int max_interrupt_work = 20; /* Maximum number of multicast addresses to filter (vs. rx-all-multicast) */ -static int multicast_filter_limit = 64; +static int multicast_filter_limit = 0; #include #ifdef MODULE Try it, and see what happens. I think it multicast_filter_limit might be safely set to 3 before problems start appearing, but I'm not certain about it. I think I'll try it out now. Will find out if it works in an hour at max.. Anyway, if you look into the code, you'll see the variable is used in set_rx_mode, and there really shouldn't be any direct relation between the two functions (set_rx_mode and speedo_start_xmit). These are both entry points in the device structure, so they're functions called from other parts of the kernel. Apparently the 100 lines beginning from line 1487 is the cause of this problem. What it exactly does I really don't have a clue of - I've never been good with hardware programming, and without even any documentation, it might as well be a binary dump for all I can understand of it. In any case, the commands are sent to the device by appending them into the Tx queue, so it really isn't inconceivable that the queue is getting corrupted. That would be consistent with the physical evidence (massive packet flooding monitored on other hosts on the network). -- If they give you ruled paper, write the other way. Osma Ahvenlampi From becker@cesdis1.gsfc.nasa.gov Wed Oct 7 09:13:15 1998 Date: Wed Oct 7 09:13:15 1998 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: "Transmit timed out" with EtherExpress Pro100B On 7 Oct 1998, Osma Ahvenlampi wrote: > > If you have any ideas I'd really appricate them. The error I get is > > "status 0050 command 0000" generated by the function > > "speedo_tx_timeout". I believe the transmitter _has_ hung, as the system > > locks totally when I remove the transmitter restart, and I suspect it is > > down to a bug in the chip I outlined in my previous e-mail. > > okay.. My problem (same error message) went away with this patch: > /* Maximum number of multicast addresses to filter (vs. rx-all-multicast) */ > -static int multicast_filter_limit = 64; > +static int multicast_filter_limit = 0; You can change this value when loading the module: options eepro100 multicast_filter_limit=0 > Try it, and see what happens. I think it multicast_filter_limit might > be safely set to 3 before problems start appearing, but I'm not > certain about it. I think I'll try it out now. Will find out if it > works in an hour at max.. That would be useful data. The multicast filter on the EEPro100 is loaded by a pseudo-transmit command. Three multicast addresses is the breakpoint between putting the multicast address filter list in a single transmit descriptor vs. allocating a longer special descriptor just for loading the multicast list. (line 1487 > Anyway, if you look into the code, you'll see the variable is used in > set_rx_mode, and there really shouldn't be any direct relation between > the two functions (set_rx_mode and speedo_start_xmit). These are both > entry points in the device structure, so they're functions called from > other parts of the kernel. Apparently the 100 lines beginning from > line 1487 is the cause of this problem. What it exactly does I really > don't have a clue of - I've never been good with hardware programming, > and without even any documentation, it might as well be a binary dump > for all I can understand of it. In any case, the commands are sent to > the device by appending them into the Tx queue, so it really isn't > inconceivable that the queue is getting corrupted. That would be > consistent with the physical evidence (massive packet flooding > monitored on other hosts on the network). That was the earlier problem. Prior to v1.03 the driver would occasionally corrupt the transmit list when adding a long SetMulticastFilter command. The driver keeps a long SetMulticastFilter command in sp->mc_setup_frm, with the current length in sp->mc_setup_frm_len. If the multicast list grows so that it won't fit in the current command, the driver allocates a longer command with some slack (line 1531). This new allocation causes a bunch of problems. [[The whole concept of changing the receive state by queueing a command on a potentially-long transmit is broken. Intel chips do this for obscure historical reasons. But it causes unpredictable delays when changing the Rx mode and might lead to multiple commands on the Tx queue. Worse, the Tx queue command processing might be stopped by a hardware flow control signal from the other end.]] !!!Hmmm, writing up this descriptions points out a potential race condition: if the multicast list is rapidly extended, the list might grow again before the first command is processed. Here is a patch for line 1530 that wastes a little memory, but avoids complicated code to fix the problem: /* Allocate a new frame, 10bytes + addrs, with a few extra entries for growth. */ if (sp->mc_setup_frm) kfree(sp->mc_setup_frm); - sp->mc_setup_frm_len = 10 + dev->mc_count*6 + 24; + /* Avoid growth allocation race by allocating a max-sized entry. */ + sp->mc_setup_frm_len = 10 + multicast_filter_limit*6 + 6; Hmmm, let me read the code another dozen times. I suspect that there is another race condition that might occur... I don't know if the best solution is allocate a new command each time, which could results in high kmalloc()/kfree() cost, or to avoid queueing more than one SetMulticastFilter command at a time, which increases the latency for multicast filter commands to take effect. Donald Becker becker@cesdis.gsfc.nasa.gov USRA-CESDIS, Center of Excellence in Space Data and Information Sciences. Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html From oa@spray.fi Wed Oct 7 13:51:05 1998 Date: Wed Oct 7 13:51:05 1998 From: Osma Ahvenlampi oa@spray.fi Subject: "Transmit timed out" with EtherExpress Pro100B Donald Becker writes: > > -static int multicast_filter_limit = 64; > > +static int multicast_filter_limit = 0; > You can change this value when loading the module: > options eepro100 multicast_filter_limit=0 I thought it didn't work with kernel 2.0.x, but apparently it does.. > > Try it, and see what happens. I think it multicast_filter_limit might > > be safely set to 3 before problems start appearing, but I'm not > > certain about it. I think I'll try it out now. Will find out if it > > works in an hour at max.. > That would be useful data. I can't tell you for sure that it corrects the problem, but I can tell you it helps a lot. The machine has now been running for 6 hours with the filter limit at 3, and hasn't trashed the network like it did with the default value. I can try to run any test programs if someone has one that demonstrates the problem as long as it doesn't require installing a huge pile of stuff I don't already have on the machine.. Let me know if you'd like to know something else about the system. -- A truly wise man never plays leapfrog with a Unicorn. Osma Ahvenlampi From ksi@gu.net Thu Oct 15 03:34:28 1998 Date: Thu Oct 15 03:34:28 1998 From: Serguei Koubouchine ksi@gu.net Subject: eepro100 1.0.3 patch This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1573030078-346177162-908362612=:9708 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Sorry for posting this again, it seems that I did post it under wrong subject first time... And CC: list was wrong too... Please find the patch against 1.0.3 enclosed. I did never write ethernet drivers and I do not have any documentation on those cards, but knowing about that mii-diag voodoo the fix is rather obvious and I'm pretty sure I haven't done anything wrong. The patched driver does work here at my place like a charm with all the flavours of eepro100 cards in reach (AT-2560TX from Allied Telesyn inclusive). It does not have any problems with gated-3.5.10 and multicasting so far (kernel 2.1.125-ac2). ======================================================================= Serguei Koubouchine aka the Tamer < > The impossible we do immediately. e-mail: ksi@gu.net SK320-RIPE < > Miracles require 24-hour notice. ======================================================================= --1573030078-346177162-908362612=:9708 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="ksi-eepro100-1.0.3.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: ZGlmZiAtdXJOIGxpbnV4LTIuMS4xMjUub3JpZy9kcml2ZXJzL25ldC9lZXBy bzEwMC5jIGxpbnV4LTIuMS4xMjUvZHJpdmVycy9uZXQvZWVwcm8xMDAuYw0K LS0tIGxpbnV4LTIuMS4xMjUub3JpZy9kcml2ZXJzL25ldC9lZXBybzEwMC5j CVNhdCBTZXAgMTIgMTE6NTQ6MDIgMTk5OA0KKysrIGxpbnV4LTIuMS4xMjUv ZHJpdmVycy9uZXQvZWVwcm8xMDAuYwlXZWQgT2N0IDE0IDEyOjA4OjA5IDE5 OTgNCkBAIC0xMDYsNyArMTA2LDcgQEANCiAgICBUaGUgcmVnaXN0ZXJzIGJl eW9uZCAweDE4IG9ubHkgZXhpc3Qgb24gdGhlIGk4MjU1OC4gKi8NCiAjZGVm aW5lIFNQRUVETzNfVE9UQUxfU0laRSAweDIwDQogDQotaW50IHNwZWVkb19k ZWJ1ZyA9IDE7DQoraW50IHNwZWVkb19kZWJ1ZyA9IDA7DQogDQogLyoNCiAJ CQkJVGhlb3J5IG9mIE9wZXJhdGlvbg0KQEAgLTQzNyw3ICs0MzcsNyBAQA0K IHN0YXRpYyBpbnQgZnVsbF9kdXBsZXhbXSA9IHstMSwgLTEsIC0xLCAtMSwg LTEsIC0xLCAtMSwgLTF9Ow0KIHN0YXRpYyBpbnQgb3B0aW9uc1tdID0gey0x LCAtMSwgLTEsIC0xLCAtMSwgLTEsIC0xLCAtMX07DQogI2lmZGVmIE1PRFVM RQ0KLXN0YXRpYyBpbnQgZGVidWcgPSAtMTsJCQkvKiBUaGUgZGVidWcgbGV2 ZWwgKi8NCitzdGF0aWMgaW50IGRlYnVnID0gMDsJCQkvKiBUaGUgZGVidWcg bGV2ZWwgKi8NCiAjZW5kaWYNCiANCiAvKiBBIGxpc3Qgb2YgYWxsIGluc3Rh bGxlZCBTcGVlZG8gZGV2aWNlcywgZm9yIHJlbW92aW5nIHRoZSBkcml2ZXIg bW9kdWxlLiAqLw0KQEAgLTg4MCw2ICs4ODAsOCBAQA0KIA0KIAl3YWl0X2Zv cl9jbWRfZG9uZShpb2FkZHIgKyBTQ0JDbWQpOw0KIAlvdXR3KENVX0RVTVBT VEFUUywgaW9hZGRyICsgU0NCQ21kKTsNCisJd2FpdF9mb3JfY21kX2RvbmUo aW9hZGRyICsgU0NCQ21kKTsNCisJbWRpb19yZWFkKGlvYWRkciwgc3AtPnBo eVswXSAmIDB4MWYsIDApOw0KIAlyZXR1cm4gMDsNCiB9DQogDQo= --1573030078-346177162-908362612=:9708-- From mfrank@allot.com Thu Oct 15 05:10:26 1998 Date: Thu Oct 15 05:10:26 1998 From: Michael Frank mfrank@allot.com Subject: Error message We have x86 station based on Linux with kernel 2.0.32. Kernel includes bridge support. There are two NICS intel 82558b with the last eepro100 driver. During the very intensive test, when receives frames on eth0 and send on eht1 we have following error eth1: Transmit timed out: status 0x00d0(sometimes 0x0050) command 0x0000(sometimes 0x0080) eth1: Trying to restart transmitter Such pair of messages we have a couple of times, then eth1 stop working at all. eth0 continues to work as usuall. When we test the same thing in the opposite direction of flow: receive on eth1, send on eth0 everything is OK. Michael From oa@spray.fi Thu Oct 15 15:33:38 1998 Date: Thu Oct 15 15:33:38 1998 From: Osma Ahvenlampi oa@spray.fi Subject: eepro100 1.0.3 patch Serguei Koubouchine writes: > Please find the patch against 1.0.3 enclosed. I did never write ethernet > drivers and I do not have any documentation on those cards, but knowing about > that mii-diag voodoo the fix is rather obvious and I'm pretty sure I haven't > done anything wrong. The patched driver does work here at my place like a > charm with all the flavours of eepro100 cards in reach (AT-2560TX from Allied > Telesyn inclusive). It does not have any problems with gated-3.5.10 and > multicasting so far (kernel 2.1.125-ac2). I tried this and got "Transmit timed out" within 2 minutes with Netatalk installed. Back to multicast_filter_limit=3... Kernel version 2.0.35. -- Beauty is only skin deep, but ugly goes all the way to the bone. Osma Ahvenlampi From ksi@gu.net Thu Oct 15 15:59:29 1998 Date: Thu Oct 15 15:59:29 1998 From: Serguei Koubouchine ksi@gu.net Subject: eepro100 1.0.3 patch On 15 Oct 1998, Osma Ahvenlampi wrote: > Serguei Koubouchine writes: > > Please find the patch against 1.0.3 enclosed. I did never write ethernet > > drivers and I do not have any documentation on those cards, but knowing about > > that mii-diag voodoo the fix is rather obvious and I'm pretty sure I haven't > > done anything wrong. The patched driver does work here at my place like a > > charm with all the flavours of eepro100 cards in reach (AT-2560TX from Allied > > Telesyn inclusive). It does not have any problems with gated-3.5.10 and > > multicasting so far (kernel 2.1.125-ac2). > > I tried this and got "Transmit timed out" within 2 minutes with > Netatalk installed. Back to multicast_filter_limit=3... Kernel version > 2.0.35. Dunno about 2.0.xx ... I don't have it somewhere in reach, we do use either 2.0.34 on 6 month+ up servers where the default driver does work for us, multicasting included, or 2.1.1-almost-the-latest on lighter loaded servers and workstations. Anyway, this little patch does nothing to multicasting and another precious inner parts of the driver. It does solve the problem of some eepro100 cards with i82557 chip (the a.m. AT-2560TX among the others) turning their LEDs off right after being ifconfiged, i.e. those which could be cured by running mii-diag right after ifconfig. It was the only problem we did have with 1.0.3 and 2.1.1xx kernels. We do run gated with OSPF on every machine in mixed AIX/Solaris/Linux/Cisco7xxx environment. And we do have a huge zoo of eepro100's of almost any imagineable flavour... ======================================================================= Serguei Koubouchine aka the Tamer < > The impossible we do immediately. e-mail: ksi@gu.net SK320-RIPE < > Miracles require 24-hour notice. ======================================================================= From ksi@gu.net Fri Oct 16 02:52:21 1998 Date: Fri Oct 16 02:52:21 1998 From: Serguei Koubouchine ksi@gu.net Subject: eepro100 1.0.3 patch On Fri, 16 Oct 1998, Donald Becker wrote: > Use > http://cesdis.gsfc.nasa.gov/linux/drivers/test/eepro100.c I'll give it a try today. > > Anyway, this little patch does nothing to multicasting and another precious > > inner parts of the driver. It does solve the problem of some eepro100 cards > > with i82557 chip (the a.m. AT-2560TX among the others) turning their LEDs > > off right after being ifconfiged, i.e. those which could be cured by running > > mii-diag right after ifconfig. > > This problem is chip version specific. That's it. I hope we DO want the driver working on ANY eepro100 card... ======================================================================= Serguei Koubouchine aka the Tamer < > The impossible we do immediately. e-mail: ksi@gu.net SK320-RIPE < > Miracles require 24-hour notice. ======================================================================= From ksi@gu.net Fri Oct 16 13:31:54 1998 Date: Fri Oct 16 13:31:54 1998 From: Serguei Koubouchine ksi@gu.net Subject: eepro100 1.0.3 patch On Fri, 16 Oct 1998, Donald Becker wrote: > On Thu, 15 Oct 1998, Serguei Koubouchine wrote: > > > > > Please find the patch against 1.0.3 enclosed. I did never write ethernet > > The patch adds mdio_read() at the end of open() -- this shouldn't have any > effect -- and doesn't on my system. > But it's inexpensive and I'll it to my next driver release. > > > > > Telesyn inclusive). It does not have any problems with gated-3.5.10 and > > > > multicasting so far (kernel 2.1.125-ac2). > > > > > > I tried this and got "Transmit timed out" within 2 minutes with > > > Netatalk installed. Back to multicast_filter_limit=3... Kernel version > > > 2.0.35. > > Use > http://cesdis.gsfc.nasa.gov/linux/drivers/test/eepro100.c It does work. No problems so far, everybody's happy :)) But it DOES need that little patch to open() - some cards (namely ATX-2560) won't come up without it. Having the patch applied, I have all the machines under my control running without problems. The load is heavy, gateds running etc... Kernel is 2.1.125-ac2 with the latest OOM patch. Please, Donald, do add those two lines to open() ... ======================================================================= Serguei Koubouchine aka the Tamer < > The impossible we do immediately. e-mail: ksi@gu.net SK320-RIPE < > Miracles require 24-hour notice. ======================================================================= From eastep@loc1.tandem.com Fri Oct 16 21:45:19 1998 Date: Fri Oct 16 21:45:19 1998 From: Tom Eastep eastep@loc1.tandem.com Subject: eepro100 1.0.3 patch Hi, Servui Koubouchine wrote: > > Use > > http://cesdis.gsfc.nasa.gov/linux/drivers/test/eepro100.c I just downloaded, compiled and installed this version of the eepro100 driver. Upon installation, I saw the following from dmesg: TCPv4 bad check sum 204.21.196.3:0050 to 168.87.157.26:043d, len 20/20/40 TCPv4 bad check sum 204.21.196.3:0050 to 168.87.157.26:043e, len 20/20/40 TCPv4 bad check sum 204.21.196.3:0050 to 168.87.157.26:043e, len 20/20/40 TCPv4 bad check sum 204.21.196.3:0050 to 168.87.157.26:043b, len 20/20/40 TCPv4 bad check sum 204.21.196.3:0050 to 168.87.157.26:043b, len 20/20/40 I've seen complaints about "bad check sum" messages on l-k but this is the first time that I've seen them on one of my systems. I re-installed the eepro100.c from linux 2.1.125, rebuilt and reinstalled the eepro100.o module (ifdown eth0, rmmod eepro100 and ifup eth0) and these message haven't reappeared. -Tom -- Tom Eastep tom.eastep@compaq.com From torvalds@transmeta.com Sat Oct 17 00:24:52 1998 Date: Sat Oct 17 00:24:52 1998 From: Linus Torvalds torvalds@transmeta.com Subject: eepro100 1.0.3 patch On Fri, 16 Oct 1998, Donald Becker wrote: > > v1.05 is available from > http://cesdis.gsfc.nasa.gov/linux/drivers/test/eepro100.c This one does not seem to work at all on my machine. I can't test it out further, because I'm at home, and my eepro100 is at work and I no longer have anybody to fix up any mistakes, but I have to say that I've had a truly miserable time with any of the newer eepro100 drivers. The machine booted up, but never apparently saw any network activity (it never got past named starting, according to the person who was there to reboot it for me). Backed down to the old v0.36, which is rock solid for me. [ My setup is not very special - it's just reasonable high-end. Mid-range SMP and a 100Mbps network that can be fairly busy. ] Linus From torvalds@transmeta.com Sat Oct 17 00:54:15 1998 Date: Sat Oct 17 00:54:15 1998 From: Linus Torvalds torvalds@transmeta.com Subject: eepro100 1.0.3 patch Looking at some of the differences between v0.36 (good) and v1.05 (bad), one thing looked strange around line 1530: /* Disable interrupts while playing with the Tx Cmd list. */ save_flags(flags); cli(); ... and then it re-enables interrupts _before_ it has obviously stopped playing with the TX ring entries. Looks suspicious. In particular, it looks like a TX interrupt could occur while the new TX entry hasn't been filled in yet (this same thing is done in three places in set_rx_mode(). The above may not be the reason for the problems, but it looks like one potential thing to look at for somebody who knows the driver. The locking in general looks fairly strange. There's a very simple scheme that works beautifully for both SMP and UP, and on UP generates minimal code: - add a per-controller "controller spinlock": spinlock_t eepro100_lock = SPIN_LOCK_UNLOCKED; - the per-controller interrupt handler does a spin_lock(&eepro100_lock); ... do all controller accesses inside this lock ... spin_unlock(&eepro100_lock); which on UP compiles to no code at all, because on UP a normal spinlock just doesn't need to do anything. So you don't have to worry about any performance impact. NOTE! The above only works if it's a per-interrupt lock. If you have a driver that supports multiple controllers, the lock has to be a per-controller lock and be associated with only one interrupt. Or you have to protect against deadlocks by disabling interrupts locally. - A non-interrupt context does unsigned long flags; spin_lock_irqsave(&eepro100_lock, flags); ... do all controller accesses inside this lock ... spin_unlock_irqrestore(&eepro100_lock, flags); which on UP just boils down to a normal save_flags+cli thing, ie the same as what you have now. On SMP, it's a much faster spinlock rather than the global IRQ lock. So the above is equivalent to what you do now on UP, and much faster and more robust than what the current code does now on SMP. The reason the spin-lock has to be a per-controller thing is that when you get the lock without disabling local interrupts (which is good, because it's much faster that way) you have to guarantee that you can't have recursion. For a single interrupt source, the interrupt handling guarantees that, but if you try to share the lock across multiple controllers with multiple interrupt sources you could get deadlock situations when you get "nested" interrupts on different controllers. Alternatively, you can have one global lock for many drivers, but then you have to use the "irqsave" version for all lock accesses. Which is slower, and not "as pretty". Oh, btw, it looks like "set_rx_mode()" is called from within timers. Which makes it all the more imperative to use spinlocks, because the global interrupt lock can't protect against interrupts on another CPU from an interrupt context like a timer (more deadlock reasons - imagine two interrupt contexts on two different CPU's trying to do a global lock at the same time, and both wanting to wait for the other to go away). Donald, do you have any SMP machines available to you? I would have assumed that SMP was the next obvious step for beowulf.. I could try to see if my intel contacts are interested. Linus From babydr@baby-dragons.com Sat Oct 17 02:26:57 1998 Date: Sat Oct 17 02:26:57 1998 From: Mr. James W. Laferriere babydr@baby-dragons.com Subject: eepro100 1.0.3 patch Hello Linus , Ask your remote fingers (if get a chance) to look at the link state of the adapter after ifconfig in rc.d area if the link state light is OFF then get Mr. Beckers mii-diag.c & compile it up like shown at the bottom of the file & see if this doesn't bring the link state back ON . Hth, JimL On Fri, 16 Oct 1998, Linus Torvalds wrote: > On Fri, 16 Oct 1998, Donald Becker wrote: > > > > v1.05 is available from > > http://cesdis.gsfc.nasa.gov/linux/drivers/test/eepro100.c > > This one does not seem to work at all on my machine. I can't test it out > further, because I'm at home, and my eepro100 is at work and I no longer > have anybody to fix up any mistakes, but I have to say that I've had a > truly miserable time with any of the newer eepro100 drivers. > > The machine booted up, but never apparently saw any network activity (it > never got past named starting, according to the person who was there to > reboot it for me). > > Backed down to the old v0.36, which is rock solid for me. > > [ My setup is not very special - it's just reasonable high-end. Mid-range > SMP and a 100Mbps network that can be fairly busy. ] > > Linus > > > , JimL +-----------------------------------------------------------------------+ | James W. Laferriere - Network Engineer - babydr@baby-dragons.com | | System Techniques - 25416 - 22nd S. - Des-Moines, WA 98198 | | Give me VMS -or- Give me Linux -but- only on AXP | +-----------------------------------------------------------------------+ From ksi@gu.net Sat Oct 17 02:37:45 1998 Date: Sat Oct 17 02:37:45 1998 From: Serguei Koubouchine ksi@gu.net Subject: eepro100 1.0.3 patch On Fri, 16 Oct 1998, Donald Becker wrote: > On Fri, 16 Oct 1998, Serguei Koubouchine wrote: > > > > Use > > > http://cesdis.gsfc.nasa.gov/linux/drivers/test/eepro100.c > > > > It does work. No problems so far, everybody's happy :)) But it DOES need that > > little patch to open() - some cards (namely ATX-2560) won't come up without > > it. Having the patch applied, I have all the machines under my control > > running without problems. The load is heavy, gateds running etc... Kernel > > is 2.1.125-ac2 with the latest OOM patch. > > > > Please, Donald, do add those two lines to open() ... > > I added a corrected fix (only do the mdio_read() when the board has a MII > transceiver!), along with the low-memory fix. > > v1.05 is available from > http://cesdis.gsfc.nasa.gov/linux/drivers/test/eepro100.c > > Since this is a quick release (it has only had an hour of testing here), > this version doesn't include the adaptive multicast filter list code that > I've been working on. I'd like to see it asap... Do you have any idea when it could be out? > The mdio_read() shouldn't do anything, but I'm guessing the transceiver on > that board version does not recover from a reset unless the control register > is read. The transceiver reset was added a few versions ago to recover from > certain link partners hanging, so earlier driver versions likely did not > encounter this problem. You're right. The earlier drivers (0.36 etc.) did not have this problem, however they did not allow gated to run. And yes, it's chip specific - the newer cards with i82558 did not have this problem, only the older ones with i82557 did. Anyway it's a real pleasure to know that somebody does care :)) Keep up a good work! ======================================================================= Serguei Koubouchine aka the Tamer < > The impossible we do immediately. e-mail: ksi@gu.net SK320-RIPE < > Miracles require 24-hour notice. ======================================================================= From torvalds@transmeta.com Sat Oct 17 03:03:45 1998 Date: Sat Oct 17 03:03:45 1998 From: Linus Torvalds torvalds@transmeta.com Subject: eepro100 1.0.3 patch Donald, Serguei, could you take a look at this modified eepro100.c version? It seems to work for me, although I'm currently running it only on one of my home machines and haven't quite had the guts to try to remote-boot my work machine that I saw problems on earlier. More importantly, it's essentially based on Donald's 1.05 eepro100.c, but with cleanups and the proper SMP-safe locking that I mentioned in my last email. It should be noted that doing the locking properly actually simplifies the code. For example, this version makes sure that it has all the data structures properly initialized before it starts to accept interrupts. That's critical, especially in a shared interrupt environment where there might be other devices active that cause interrupts on the line even when the eepro driver thinks that the eepro card itself should be quiescent. Taking an interrupt with the data structures only half-initialized would be bad. Base 1.05 will not make it into any stable kernel: not working for me is simply something so fundamental that there's no way I can accept it even if thousands of people sent me reports that it works fine for them. Yes, I'm a callous bastard. As such I'd really like to hear from people whether this version might be acceptable to others too (and then assuming it really works on all the machines I have access to I can consider this for 2.1.126). Linus ----- begin 664 eepro100.c.gz M'XL("(@^*#8"`V5E<')O,3`P+F,`[7U]5]M8DO??]MD/<4.?)'9B$QL2PH20 M60)DANWPLD"Z=[8WQRML&32Q)8\D!YCN[&=_ZE=5]^I*E@GIGI<]>YX^,P$D MW;>Z=>N]ZCY[8D9I]#E,LV=QF#\+PUF:]'N]U>$KLQ.;@S@/)R;:7'OQXJ79 MSZ_"E#[2!F:FOKJ^^7#-!/#*3(*?>DGAR^Z#9^#&-\CR,3?]WO]OHTC^; MYN+6["5Q,!F9M^&0FJ\VFXUS=)\EX_PZ2$,S#6[-16CF&0V"#D=1EJ?1Q1R# M!L-ADHZB^-+D"(!YCQ,IK-H$G;IYQ0C!SD_#NE7!=*87LNBJ8MY M?D6+59"G83"\`I0S^@N;\Z^[^V=[!V>K\RP-5L/1O&/HX]UGQ\W&;ACS-H_- M_LTPG$P`29J[.9L%],M>D`>\[H.88#D-55;F24COE#&H;Q13C)S>&>6>N]?-EO-M[15.:S M$6TKX4X8-AN-JSR?O7KVC(8@E%F]S,;#U3C(@M7+Y/.S"3#[F86H@^95/ITP M)`CO:..#298`ID$T`8Y-"//,1<"(F-,`W$G7-O[7NH&:='::M(,YH>`PH;TT MPZL@-4_LX=ENKGB'\G-_M?>"\.E9?^,9G8W2P3"_G\FATS#J^! M%RDA0SR.+N=I<#$)S>=@,B>8Y5>$&L%L-KG%60+*6>RD[7D7I33UC*@#3N0\ M'B7#^12;(4OH_QF'(T3ZF=3^CF_,>\.WAU3 M$SJ?5PF!C]H_IQ.>8]Y1GG5,K]M_4>DEK?1R6NVE8T;A.)@3QJVO<6>9DD4: M\!E]O7>X0V<70"+4O\RO>)2UE_3#;&^;.#%$+L+I#`OKT)RWM_MKFZ;[!L0, MZQXM+FLT#8;)G'[=-O3M5GFVWLN>[.Y9F.MYG]'9I9/[:9;@6TN[\+P+*MS- MH_BV>S$?$[W#.J*3Z`@$P3T-^0?MQV:'FR^^.`Z'VZN@#! M`8;@D6E6:SV=UV%P$TWG4Q-^)G3)3(M&I!/]*<1&A/EPM0ULNR(DHLTG!`3% M07]AFLYG>760:7`S<"\'3%\Q5'FD>#Z]$%(TI?V*AC1=$XQ&(-=`\P0$#[2J M]9GV,+WI$JIWW9?MZHCVQ4!:#2;1-`+8-Y[3J-\1,YG,B7*]E@,HQ'?UZLWB M*SWP>%=])4RS[@T877Q9]R:/IK0'-2\(-G%2]R)*B.GE=6^F!(%D6-O&;43- MR]DPJGM,W&D4?B9N6SL[,,+EK[-/P,NZ-Z-P$MQ6`!MDTV?9+(II\I_*;?#F M(LJ36;;X/&+HL$!#.,,;9BPY8V+5!`H<'N]]>+\_V/EP_L?CT]9*F1*_5FY8 M1XK?K+2W;.N]_;/=TX.3\X/CH]:*+VP]4_Y_LGM0$B<@30@1]WHYV3D];(W" MB_EEQZQ$U1<)TQ0Z3"O][HH9#/3=V?GIP=$?6IOMFB;C^60R&,UGD_#F6YHI MR:Z;A!#ANC?ITC<%A:MO=_?;@MC4O5^D$[5?U9YM^V7S.Z+X41R:TP]'@YWS MUDW;M/XI,3Y-P\L(U!8"V&U"G+9WT]]D89J:01I)A#D*/C&Y MM',Z.]G?WSM>'YP?G^^\'YP=_.<^-5[K-9L@:\2PPU$R8*QR/(0DF@9D'Z+V MF,TQ<7,Y$,V#5?,6\R(Q;3JC9Q3EXZR9$:6#G$H/F<44"HD*`A-52NC0=""2LD*@Z^=.FG62 M.9'^8):S7G%@E]&EY0^C,9%XDFB('5YFS2:.XL7$.:2I@\'^>3PE@63.FU8'+D/P,>4DG*-LJFZJ=O#TX/K.J M@GX,P2L#\-"&IW1P=+YC\(0P!F]CT26NHPSB#(-`NSLX_7<24..0!OGQBD1Z M$^4$U5E"_4&PHL;9%1:%7MW9X!9$/(BEQ>$E[>SGD%`KHDT>$K.F];"X#EF> M.'23\8XD.Z"KU?2R^8RQ.,H9P@3B/4&$Q$.?@X.=5?.',*8GDR9`H#A@1(V\ MI15.HPG)Q31+T94$96CWF`4E5 M8];F6G)'M(0\(+W*Z4=$")LDET"2)?&1NAJFT2Q/Z-3A$9,) M^L:(S$1@21A^&9"0<.USE,PS.T42DIJL-5S12UK5;$)X%G*_Z(M&4O: M5IL>"G?7>:?MZK''5M.&ML':HB]]LI*5\B,F$X0LTP0"*NE;W@0LBBG%T/40 MB6#\R!A8?PW3A(F/=#J9-+45";CA9"0D++C(DLD\]^9@IR]48U>5K+<0HDSK M;/=M&RO.$D($A]MR&.7L,-O)E*PUF5K#@$*GEBD+N!H?&E8:!,C+L!S?RBXX M-B=H/F5E/Z.=);C32K6S*9UW`II%E@NBW0"*$J`XB;LWFQM-4GV)?F=T>H4@ MO2642(,X@]A.\O1\F!.*"0PJ^.G3`QQ8WA(184*OF58!=IT>C MB'`@MQMGS5&",8*]&;V'!F#,/O"I&,!<`/C-UOD-H`^S0P6[B0@2+D_#$9[A M5!`TMQYMB2=YTT,:#''2&4$ MS!7G*P8O(S9JL<'IH<`Y++GRILP)B)T\)GY)0K`)XV1^><7]\N$%ZA7;"9XX MO"(297:GHUTK0MA#`"8$%"/!,R_D"F'3+%7)<694Q.$BZD(T`E"YI<$#IAKT MCOCV)WNF+8#<>?4HN#%GB97#B`*[*5ZS=$/8+T/%1-L-Q%6?"*GHDJIY-3!' MR?%,=HK1O,DS+1H\SF1:BOOV).F8M$D[,:8-D4RAHD-W&PZLTB;%N';BZSW^9AW,1TVC5:G`I1*"L>7U%D@D(@>"3 M#P)>.VT9S2.:S6'*YG70$#GW$D"2S(OYLV#):]-M+Q819=X:1DFSL`Y[4CB6:">0Z(NI'19&XTP`_N-?=L$:4UB-I\4@AU$4T)_WCMJ])CH4WX[R&\> M@U9!\>,#=T6*+#Y1#+'XT96]H6-/6K03*/D0AOE\)H)"QCO!!!!O@!R.HBE[ ML%.=!NDGL2/;CN70$1BE`_MXY`VB?7685&"1^#H@+$\(\E,%1GXS\``&`@)1 M.H_HN&?!.&1Y%42@H_2B20V$*/_T41NQG?-IT1,@(6LG^#X53LF]/A MP%\XH<"NW58'`X)4QD)\N'JYBJ-_-L]`INWIM*"A?6?]((P@Z#8S_8H&S?)D M)J1/,?>9+TI4N*A.>3P)+H403DAG:KI!@%?%'#J&)&_+=A>G5@BQ%N20]NE- M3,#)8`P,S.Z'P>G^V8?#_=7F49*'K\R/`;AS,B],C+,$BBS0/X6(2#"4L\Y> M%I)*I\$E:1O-!N9B\=(-K7`@'=21/N7D.NWJ))=_2>JOD!>W%MM[UFR,$CNT M6]'RGD`6N[=AWOT<3")0O2SO37<),UB98D*?K`WI`:93?>6^2,P<7S(?4>C!\L(IV'(E?NKII3 MJ_,48N7;E_#':/ M3_[T]G1_YWLB^5;YSBE--'1&-:%?%(6ANV]K)F"$-@ M-XO^"B,"TT16:NWB0,5[,0)#SE2S#L^U,90DBC';%_!ZKI M0J@A)$TAN4]N2Z/0'L.AF$V];A>Z!$\*+R?1)5M86J0JKSH\EOD32[XF427E ML]R%_.9P$JY5H=,^*2!(THI9\V2AVKE+VRK`-.WVT2H(33JD+,419EF9OS&8 M_R1(27Q8,G_AJ1"XHL]$M852"BM)@>OL2A)=;#R99U?>O`F8.E/H!9A:DR@; M]LW,9[[FPU1*I.GK`K<86Q,Y1Z2RGZD,%_U5#$:>;I;.8T9*5H$*PM%1NT`7 M#CH6BL=TB#/99-9H"0#',-X.+33Z`()Y\$%AV8D/B4!C3-.DZD/ M)`)'2Z3J+@O1Q5`D3)+"QY;9"51W-HT2E6W)Q\""@E!V9_J,G8[9:KMA=E@.P"O;@E\Q;"%(9P7Y4PDVL*+KQ:VU:`L\ M87UZ;&U%JPW:/MF_14`S?H:YOX%LTU&1&1\*>7`[RN:5'U8-N'*&;0KB3ZR" MG>6$1.9'$L&C8,I'4G@S$^F41-M+NRX0'Q(RAI.$S7[!)7SDH54LL6I6".CW M`]IB2`GZ=:B0=M21=O'M')^)Z`\K'W5C@9ZP!1W&43J[S4DC61$K/U!D^,X7!"%'S*AL3+Y-;$[]>.KGT>T-"+*F6?F M)P6&O>P0$*Y%-0_'XXAC86Y+#ISS_QC`&<>NFT9_0Z(DB"5;5%SCW8<[:@QC M2ZGM:;DM!PC01$1(9%YDV8AGAGUE7CN?R^'YAS?F*9UN.OBK7LWYPN'_\ MX9R.9&NSUWORQ_]L/^OW>KTVC_)'DM)H*Z^#R(]J\"0[L//AD$U9A=$!CK3; M&B$$Y[5-F>B2.#C]EY0@#>$,,GV2,,J!1H`(.0!A:;/G!7U$"NTN[ M^7.S$;$(R_$`?00\D'9!X]'/:RC,K2B^:'DMS*-'IMOE[]]LFUY[J_F%%^8< M;43+B:83K\Y%N(-5\1A8V;<=_HY43-JMOF>0=> M2FJM[B0SFZ4YGO<.+MT]%)U;K$--Y``RS MI/5PFS5I@T8'CO,N;79^\PXF232D=IO:\`--:.6=NMS8QK_"%$8694F)PMT> M.]HU)3=J=4B(HEZ+;,V;6\2-%LX_CD![Y5&]!FP%9^<[I^>-!N;4[Y7>B!5! M7JWUJHW.SW;V]D[YY?/*RS\>_\@?\,L7/:R2-X))'3')82;8Q`I>93J[AWN# MMSMG^]QV@]N^]=Q83&='(_MC]X/#IH6>]CX%E,@VU+X-+"YBN3*?H@ M/B;`X?WJEUXH;/C-6NG-SMMCV^1Y^06!:_#^>&=/7F[4]'$Y5WS_=.?S@=T$L\)RQD3%+?M]HEK%;N0MD<[JCR7SB=645[MN"< MM?P)]@7?+OVS(.Z.C$2\RS?Y`]>S_H;24`EH%)IO>L5;W;32ZS5Y/5]?8TO^ M5D-IY^($G@C)).U,W.X3@&]-W>JDR%3;P%K<6;`5N'B=B>WNRJJ7N[=[,)VD7OC[_?5D*&#_;3=/=T MEY[T-N4U/=@!K\6CY^[1>9*\C2ZW!?GTV=GM]"*9;`LAD<[RJS62?\)MH2#X M[B@YA.EV6\Z'/#G8\9ZM44MAV]6Y,B`4JN>E;7(NUNH^0:NXSU[Y>T#O2.=` M'_XN[8BMDOF\$U[R8C/MKA2CR4;:$;[#;IV_W3.M[7Z[`SQD(Z'&^*Y*."JW M9<1E1UU,I#*?PU8&87V%6J\XJ;O;A367K;ML\8O#57_Z=EJ]$I)U"M/3A2\2 MCU0&R8K&0#W;^#T'%?,"E%;4CM7_+6/U[QY+S\!^!?5'1,X''E=A7_:JP(]_ M%_5&800_NT5=)LEH(*:K+?=P2%RVOS$@FNH]A%^.WWC/YO$( MA#?V/TNR?#`D%30*TRT/S8@6I>&H>$([6>V-8X"J#SF.K_0PK9LU@A73H3]E M>L)@J#PC-$SFZ3"L/(89@192>^<7`0.P-%JI M!:HO+&G(KNG.)I#"Q:JE7+?#B\PX:+.E'5EX?<(A&3\QA?.P/#%OK8[NF2?P MR$%_Y'F_1TBC%0^)>#S[(WLG_))Y26'LP]84^%?>;A#6,6M M]0UN$XYYYR%9&=>Y#?#Q;#=\(9%F&4&+!,*6!;$.P_F4B'-/!)(RQ&F-[ MF#AZ#&^/-=NLEF#O2V9^9UO&']^<'UCQ9LP-J97S%;,BNG3B0 M&#HC\5;5M/.BV5]9%O8.3B-Y5L2ATC&BOK+<`KZ\@Y+=,X"+CKNQR,3F\VC, M+\2X4M.:1W$`\.M2@MQ]#CL-208RE$DW6`D&UF6A8I(9[\]0]SB6AZ8,BZN.GM;6/9AN<<6VM M`V/!9@?F$?H?_R!I&/^NR[MU>MIG^U!_&Z:$PX,#^HQ_W?EPP&#FS]?VM8>; M#>Z+'M^,N8OGU+WV_)S_E<<8A3<"C[??P4TE_E!%;>[Y9GW,LWC1,;09U45M M?GU1_?*BUG[3HJ33F\U-7MV&@JVTJK=[;E5O][IO>L1GEJ^M[ZVM68^2XO3W M#;DEF>3J-OM)E[UR1`+1"A(\`)KU[LZSM]Y?N_;WWOH*S7Y%$P[Q=+,W7/-^ M\(?S^%.<7,?=33RW?_P.?V@7._Z+?K_4J+]6>KE>^NMYZ2\:#6!@I9*6 M-9"`W)\-K>IL/KPZN;K=)C`?\&IVWMK?=N47;*A.IV/.-GN[M*`.9WPT]$]M M\,)]M[--2B1&7`1KE`VF421P51SJ=\J_&!$XN24S$A4`QJ"*_59%.*2?'0FN M%&-YAVE:E/Y%Y]@PPJ:#=#2(1C?MK5(V*5RB`S'6MA8Z88;)>9?X"\_!8MNE MC,KI*$H&Z&6Q.2`=CW:0W]UZ3,YJU M+!*H1HNL*AMH[`:>T8K"RXQD7_JW=FAV&=XY^A(1]HEV<*F/L_O"+$J&^:06 MQ_591$+@7VC*?Q%D(.IM6_*QLMG' M+FJ'F"J';01B(%")@77.:!2"@?I4&8Y?<%R.<5S1SK;[&V(O?T>4W3U<7Y.' M*FYP[G$UG]>3W826=(EX+/__EQ*H=:![-OPN&I-08"3_S^_&YL!UK=C$T2?\ M[!X(?]H[WCT\'!'OP2^^_M_C<:>+FW_\/![KY[.6"9M_C$K:QC'MEE MN)>/2NMAJ#4XP`_3!QBL(JK?D=PE&XN_>9:($VK5@Z>-3AH"#C1AE0NA*P.U M@OS4_[CE''4_]3YJ3E!W&LQ83J3&Z5]<2X9DH_&EJ4H0(:B7:R2QZ"DG+47. M(6)'?[1M_F=]2Z%<2I)]8]9XU3-BG?FGULH[QKM29BMR4_2,(&2%1GSXW83` MB+ASM*=;KFC&^^&AG6ZC_>L7OR4\8^?[I[_XCPZ.MPH\ M=;/NH+(?'0O/[_=,CPLIWQV9%0NL`2LZ/19P7`@_"6$*1$<&Q8J&XHG3A M@3$?4/D%=`@M[9`/GZ\^O^F^X1\E\"\[8(*)%J0LTGT33*GO$E2K77]9LF'P M[M]OP][OG.\?[?Z)(V5.==L4+]H^U"VNO#;K:V58K_`<'3*Q_&A:N^_>GW/N MV3RFB65)S''/X%J$RH2\'LQ1:B37N"HX66"^S1B\ICJ;>E#>:[4*RLIZ:3$, M1Q-.,HZGKQ[2?OO^2WWXW4W=M*F#LJK"/GU*#[Y0 MEW4\YLO?43\"D_2%G&@T<"6'3,]YU"2OC,%%A\M^@<"ZL@&\[#`@L7A++7_6 MYK\E/#GJJ%BF[E/1R7Z"`>"CY<*5'>L9Q$7Y,WSZ%#5S>MA)W4A]P9LCL&9% MQE83D1V"#RL9MVJGW&[;T9E%$/,0M0;C8QR9-/5;?DVK<(AF0MGG83I53"S M:942_(62.VQ!0URK-I:(%2>P,79UN`<.R;@.Q?"&D%9-;54,A$]'PM4EGID. M?QJR4913P]/4NN1_5B$FFT]5+&/,^+/]Q2K@]-)7VRU:DTRZT>;]OQG3?^;W M9M.\,AM\+%DD^[-$*D7<.?UXS>8E^LU*9#PZ\\@E0Q"2>E8`:J!8&D&FYH;\ M%`MXZC\`%F"\=1VGP<@"G13=_?3GIT_+'=SQWKQY0](D/OJB;(%/!HWX`"M_ MN_-VIUWECS_NG!X='/W!K#S,D`4C*4F*&BPSH/G#[\#L2`US]%K$"6OY+/`@ MQ\&PJ3J6D?I,DF>/;>]@+QE2B'!)@!O,)B1<<"`%?UJLE1J;!4+S2A-61&DD M\=-=`.FIWSEG%75,J,F2*#@AON3#G=TBIU62Z;AZH"#6%WM*LK#(CWTE67-% MA%61P,6R%$*9B^`B1O3S(@ATPN%,R*+I]T@;'AK)G2.MAWA@!+\G!ZQ;H+G0 M=W03#(O(LF1.VG[/,@GSU&C\H:,ZBF'K'\TCUB7LA MQZT@T"L/UU;7_N.5[%/ZJ"0/+WSN1&)2M6/HVN)U'EQ,$I3<@YK] MO62$ M[4C4!&1HRJ%%G1T&B;]*<-`NF3SPF=(Z3PHI\!^AEH/Y8J7R27\VPHU>8V>KV>^"]) M8+()GG3H>`)67UI$ZO7V,HG>.:(@*G;G,P:5%I+H=D6V)TKDR9A(CNZ*`PUX MPL2GKF>I2@0[UQ3R*DOZP+*;[L/UU742[D^N;C,$?W/?W'6Q"T:M`*^$YL&L M)2O:))CIK[_[^.;-IO<7+W4\Y@E53\5S=RI\\+Q`FU;_]>M(U&:[#@\;Y)2X M8T(+=HN$")M&I+/>5AP>.,)PAGSG:9;0;.#NL$-O8/+M1_T7Q7HV9`7]L=,6 M],5+W<670IIJH0W1'SF=M;,I*UC^-%[*-%Y^=&.VRC/DD=?'S/;5]X".?OD% MB0!?^W)'N;%:XF$+7ENG32E,^I;O5T'0,6O$RG]A6]C:FF/Q6N>L+1`MNOQE M6TGW5AU\"#PZ(>-7EYK/.I;WN@![&A;D95$M=6.)6.+Y%>Y:0J?2SDH36AI. M9%+(J_8!FK[LM>]0P=^II?+AZ/""]*1LP9=>FK;?[UJ/)#;PK5?T;[OVDSX^ M68'I=X6^6KD*)N.5]C>LV+FM3+%&&;I-'8NADSKN86M!Q=0`_7LU%2TV[&O# M7E\;DARC001&%JYMOZBEYD3J8B&>2*KH./)LB6^5S!(^MH@B/VD#]]E+U`9U M;I.HT'\!K/X?HBH,@X6FL'>I'+WXKO]1+-=0)R"#?([2?)`GT*Q;"U\#(/U: M(:6!Q!61G3EIO-7OJ9[-B2RF53\RAA9-J-MU#$136Q0)W>/7V)"?A:%QPLH, MZ>!(6*6)*]A*N+A_>FI6SFA<+C!MQ@%-9-31"%+S<'-U\^858:'%L**->4>? MJN$=:B*)F$A]BAL&,I088-DO'H0Y6 MGM5BV9FS^2P.EUXI42U-U7Y]1I/%Q_.+;A4'[VS'.1)P4A25!>_7L*1EE)J8 MUL/OL!OMKT)!3UM/"`!O*),`<53=HRU"F']]V][F;VC[_)O;]GC7OZAGQ8"D M^,(LYP/"9>#&=H@?D%=`*FL793-6)Y:#Y)W=F6 MVFV>9+-VQ_SAW+?_OLU!HM8D@S;T8!I.B9NVLAD;"KR6\C7I,$60*;3_ MLJ.)OEET/?%S:>RY(YWI1LP]%>XI'*,/9K$EJRU9AX2SXK'OX%RT$M4,6MN` MT8@_]GV.E2G^OC3#'LE(K\2RA':(ZV(^XMCI5O&B[[UX:5](.!GXUH*8CPU= M!\<$DR^L>K9-NWE/+0!"O@;)J3DBM-*^B^'5*GM.I+*1E%JY1HU3K@"'H#QC M#*(H:/J/O*`*BZO(N/?"&KROBH?V6S8O%!]P*(%]Y\("O`_<,]Z1Y]ZW']JP`:\S_GO+F8]A,OX7241AZJ_&'UM8CM,VS7VK1 M;C;JI9^(T:9<<"6_2KE^&7W8O;CMP@WVJOO&A@AHKP/D,')1HU*2[O[^X.R/ M!^_.![OO)2&J4:1%9E?1.!=_0+7-[EF#D]C6O,]9;Y#HWNKG>SOG.X,?3P_. M.;WK>;41UZ*+XFHK;C#H\4#]Q1=]?O%B89S3?TFA;" M]HB5_2+KDQSE/4A/J$QX'1+VV&I&W8BO">NI_!##R-XW6QM*/]D]WSK2GE^6/?FLX%QP> ME6!6.C2?@XD*SQ):4.9=PFYE(/U$O'*^X9_K;>/ZDK_=QO-YXC@"Q MX2J$S*)J7WX[,VLOI7:"9_KF7$7\!U#:85Z_[F\P;&4.KU^O(>_./WJ:)]^6 MR@G87=F=*)ZTEGS'PH:G;KZVXM:B\NB!IWMAW\%/5;LCOS(F].^P.\_OMSOT)T\!6LT_;*-6?&#]8S;J M7[RM:GXEZE8\Z4OL1N-4J2T75Q@G.?VP>I]4O$E+[BX1 MZ&QQCR0W6FW^JVZHDF''QOJY1-7"4U=8-W+RM?]L5&W#6+5)#Q3`R5=2<*C'P.2S,4E92L)<24@0KF;X>?T55-# M-OG(]GO=/^ZY)WUY\LX]69-O_(_6^OJ(OX(HMS1LM=;D:E?'.K:+.%5/G:=_ M/C)LTO].K5I?ZTF`4:"?Y8WO$S_LP,F*R0 MM:L'@U'8B6FVS`/10+^Z1H5AR3!%IZM>CJT-Y:B+M9>8[6]81._>L_7K6M3- M5HYY,DI>(<#'F3CI2+,/T=53JA987:B?\NMV0`T#DI7:^]C^EG5Q[8^E:WH7 M2:TN,^;;R4JU;Z'KSM3W5\8C&Y_R),1CMLSSG^V2*WK+?N52*8L/'[6T?!JG M*/<^KOK%"EPXIV1/PGA\V?K]@S87P46!-N!*M3"I+?#MRB!;/T)YG,S64FJU MO,HYOWA5>]HLT&Z(5ROHB:^JT@O7Z-XVI5-26E'_H[ACBK4C(LL(O+BZQ[)W M_3O>K7EF+)L9[;%//X.U_:@\93UQDIL+O4`?V&1;&_Y=%+6S1_'O<=Z\"CGU MJ%E*&14.X=--]XG4TI.Y2QM7P,A[*'%JVV)I@]ZH12M$('B<<7E&"7HQ4@IM M&F2?O/KF14[\/XT&5/;S*S3`5D1:>O"E0)6KV2SSM(FF7%'6I3O#WK;J)!0_ M-;H(V*R^T>BT7O65MUU*U/@Z""]UQ$9E==_8RLJ%^(9O=29>:H_F\M3'F[.\ ML40FVD-07TDP*OO&_*``3TJ"ENM#5>J\M*VJ>M_MY4URU9UJ>22!XRBQ\NF] MJO:!0MY+#K/"1LF[OR"(==0/B8NM#.1!]H/(S2.X*XG0HZ.5PJY#B7;$7A%F M\64LI?LN.'3L"0JG(CS2C$A*O@AX89<]5_702\^-43#NWW%979;TQ)*BV MK,3:*>R]MI>..=N!8>/TW]79?7>D5^&J83E87?NJ_73W=_ZP`:5R8PR7@1_.BW-XKCGWJ\^V-TX3V4;>V MFIO;XDPQ9CD784`*`=\>H<&J"1S"FUE$G=,9UUO@ M6FO/M2QE>\O(H5];?6Y8%;=41IHR`D%F\%,SV^*%*KX:S^.AA@$_\C,Z71$& MV0-;]A9#$+K7S=IINSU;5U+J9RC0;#5FJPIQV7&+@\;>/SK=^N M,]?21`V]O5N=7DHS!2"V6#"L)`7-+`7C?`/-])U?S`Y>(SK\EU^H&\\GQE$2 MMCQJUS@92*N7@-H#K61UHOZ#("&.T97,#FP):*[N^!X@0(#>JM0_T!(/*!49 MAK&H@A=RV;;6F2X7HJ!)N4O1I'`DQ\I*66J]R4!Z"9@LEEEJJ2ABHX:C`3*R M#A8P`/,HGH>UY*)Z(P^FU2SXDZ+8(!=#\ M0=G4X^\)&?\-F*)F)ES+P-Z-9*P%BFW"&W7#:IJZ[K6Z:H""*XAN!YWCQ.:+ M6S^R71L+`%LE^+:YQSR()MX:1%WE):#ZD8P[D-OCPI;DO2^!`M9J=XL7:O^@ M,[^H>J4:]^7MKP[(+9S*)]8@%,&T!^%QG[.XN7JW)!6X%&MMK,/UBKH\*(!A M;FU%/F?_XPOC['V2!#B)D^I`+II+C7:^6Y[O-L@DF8IC@<11*-8EOA?%IO#8 M&7BU%HU-Z1`KK+4:U7Q6LA[8O?'L1M+&N__:P@HG?=LK4>W%36B!IA)#I@/4 MIE/2+1T/%5T9H>RU.EZ9]7C43<;=0JLH]M;;J5W9J36W4VO+=\IC!=A[5V]K M2798+@R#1/!_EJUZ>4Z*JP'I3/BO2NR5DU(X=D[^Y,S"9P\+WV=)<;D7#UY\ M`>U#F_LF`M$/Q(+@O;8Z:MV:7=H:Z=-:,A4-%-LE)>6!'-?-WJ(& M5P'8K>91^@*L5R=]=;56)&G7QGL^NN^")"QWF0K^=1W]FJX3)K?_73 MOBVY\/5/G]__4ZW&),;RO[/MWIKBF1")29MP2)PBG+TJIBILV,":HE20W?+C MDFH\:K^B<,P_@(!))`@(NFJ^BI6&E M/)GZS%BUY#Q+%B>#/)E&)#A=![-67UU3;.UKJP./Y&42,EMM#OGA"VZNP\E$ M\M/XCA7HNZ%"$ M#BTPDB?M1]YTF%05QX8=QUDR#M)BEXD_5E'`2CG>YZ_]ZQNZ6BM!%=+^5[Y7 MM[!DP,ZXL*2]F].XZUK8JFO+`=IX\:]3G_(DOA2YW1XC58W%_U)=4[O!',KY M*YX!'S2]^17I9U,5Y#HF\>@JFJU(F`^8O=0% M;_S,>04I4G:]6QQU_7Q_@W]]#%_9B#==8`C68/W.^B]U@,N3;+FNNQ"QN$F@T1"[:]GCKTZ<5;J-#,V=2 MQ8!;>R7'515!GNDEY]O]'7>B^:N,+2;2]!D*U-$N+M MW>N'FXKCFCN_N?KUNX-WQR()207L9,*77:^]V%@.4"=TW_3Z:QSSLWQI;IYU M(KV6*+NK+=>_%BPA+.7HW0)5K`EQ$MK[1TLHP:0<@XHC;DM4B=V+\>`$QWE*H5Z_XW0H7EL*1%$7]J5.F+D(@1XD],DF=I45&=M8KOP MF!W!UXF-#B]D1>],=DOZ@'E3.J+TEM-7RR[$?I%SS<:Q.QAIX=2KEY06K;/U M]YJ-$IC::70MKWYZ8V]\X^!@F],>XYX]1!&+_T+17+Y<9MK]+57UOL'ZZW6V M=7^U%`BY/O&)^T`P49W!:4,0X0G`!,NU7 M&E[$B*:5-ZT)B2..),*HX21?E^`#@_52F?,;3'^62Q<'HKU\F0MNX[X7W:61 M>LXPL41Q5;JZ,\1B)^'H,O01<*B5G(M!I$A]9G;.=DZ4.O"YUW$XT&[8J_C3 MW5CUM;6>+^0<>V;[8FC=]FVI`R78#.5LG M>FNDFN&MZ%E4M;0NW&H7?',9[X`QU6GT>NM#K7+2ZZUMMHUX2UGHQ924Q MU[NAIE[2-451I*5#]6BHGW4P>]U`9EK75[<(49'1Y&TT"@/@P+7$">"BLS1A M_>?4LU58GX(WTSNB?SQ#]<.2T>VCS11>9I-P(%ANE*#U?^%_"T4V+2FR+GWW M0\;UWYRK5:\4>'8N]S/Y-SBFN-Z([QWG6_>\X@<>A'>>VXVNJPK/X2D^ZV%< M:=C$6I]!>A.^I+96$9O.X(OI#J!'6'L+B(?DAPBD:@ M6@]']:XS+:2`,;V3:,0TX#@L MX2J-1=EIB=QDP;?`6>F\PE">W<9#:6OOY^L`D-8NKPSUFA9.AL>@2WC`0MZC1YYUAOO"DV*Q)2"4),:G-D"G4;KJ M@>]4MK>%8XB.%B'B$1S.+,2JX>'7A4Q\A0#"P<55ZVC_?/#VCVV[E]JI1W0* M@J,?W#]U@JW3"3&D^?!*)<_<)YG*AWLW#^_%B/52"(:#U)2M"!,E_G&G_.`7 M'O53`/KMI2$#RP,"PIN(30J+*ZM(&/<-"%@2R.>I/"6Q[F[[:7W%[+^)B=3G M*DNYLG[G[NS26R:`#H-))(FS)>?:TU)SU;BDZR6;\WS)YIB#V*L;WK8U@,`0 MQGSKUG7LJG%99L.W5O.EZ.ZZZC-HRQ%BNC1ZL6"Z3BA1*OQ`%`4B"**6MTJ\ MM/*U]?;!Z5/$>"8N5N%Y3XR+BX>Q%:_ MM==S`7^.#:J*'3U4_3&=)ED7V@I.R;%"1*)>L=R=.IL&$DTO4GNOOX-*55GA?_8J_%.5/7=FC MV:=<8U;OL>E;7K7FF#\C6$,#-V'A)LJM MA'*8S*Q;,X"H-@MQD6W&Z40B^5C`=YJ/ZY< M/BAZ$&Y%4CBR%3:@!=C`"-,WO_QB$&MY<#+8)>W-=GKBX*HVVN'5//ZD=PHB M(`N@H!5RO16'B&%^Q3`2S\Y\R@LJ"@23D`"]"_I7JQ83O#B+MM=.`=K1!%>! M&5;,\-*W7J9/`W4XAK/;5NUW!0I_VWQ*`VFD1PG5&V*NRL/I;*N`8P93F.:R M<[AM%^;`!5S3J*9RB)*UA#H-P0M1LHI![0D_B%TL3%ZYP&UX%41Q11TJ>^Y] M/B`'NAHZY30#6U*XT<"JQ1A>MS-V`=\$<1P==-N^8Z&G-Z6H'R9^P%)&?YZL MI69,SHIKZT8)Z\U37"M:(H"OS,.9*`"S4M-G]*":U%>\_E6H#2X(BG!%:-&1 MI6[YT"X)`!ZP>4NX)9&O/!DFD-%Q]A"//&`+KVR`]1PVB+E%8Q;8/EW(DQ+/ M*/1)=4):V:OU]&DA([47Y2]7\W1LRU+WV57E7"_UR4 MX5;%H^>Z6IB6'_1:0=G2Z5D28.BJW>,JO.S*(I*4%.8+#L49$<,!,2IN5OT- MH8G+#IB=T9+3_Q5$*9DJWDHPP&1.W)/E4OB7'QB=.>.4Q'C5=WI74&(=8[MW M/.*WA-B5">[2Z5HT7A+XUI=K!Q&@",S4:T'DDMSE$8J+X8G?$.=7BJ.[,]"R M_*&5&;=1@4^GWZM^YF(ROS1+`7L2N[T8#Z-.GD6-;NE%1%#JOA*V\C?1^2*G MHEH/E/+2Z8K\$:\RATW_J[4\UR7DX@;Z M>O\G&PK+Z3_6@V"MF('2>KWFU1:[*@+8V<6<54K$?'.L]X(X%'U<$L7=4Q^1 M6'!T+M7KVQT197FB;!,5KOBE)C3]_%NGF]=,-__:=,]_W70=G_/3`V6"O1M8;Q(3N#S[[+;+:::3A"CZ-70V[:1PFW-53MB4Z%/Z M6VO]\!4:Z&I($-9+.U("&:JD23$#MK#`%<\>K7E..I_"R9^CUJBG/]"9?"9S M/-;O(E)4IQ(NB"OI>;*C-)G-:*IB#0UOPN%#]@-TL7!]V\+MB,W[7(_X M#\E)L'2ZKB@'!-.=7N\ER@]KD&6Q\7+!`P'#A5\Y)V!PD:2THVKP@VO)&R&' ML6HRZ6_@=;95;7M-1SJY7MH4H97^;ILQ?-,85';C'5BF:_X6;3?T14/Y=F<3G74J9`+%TX3T%N8,2`\1RGUV<+R[M__#R>G!#SOG^Z^<\8(MCGI9C7(ZX>50 M=%7"Q,!2=Y=&VZKM\&G_5:-\^9.4NJ7CB$P9*Q'X':Y_K+W>0`?37[3F>,'K M:P=?D\%_Y-#VY:,7\O*##"$0657[C@ M^.3H^/SLP\D)2S,BK:!0`H'J/2`*.A1`'F_*+=*_Z.S>VOF MEZBV"E%`RBK(3=IB?)]G4HR5@#,PG2RR6C@*USY&=,S/PBRM,@C2:W7?&O M+(QH=4>7T,*IBSR-A*26F&OPBZP59="*,9+:=Q>*P7A)YFIK1T<3VNE0<)?- M+NK#2&("=5X2AER-4PGSC9-T*A(FZ6FX>;(8OZS[4I&X63OB-V&\<+^`.B7`?OW@U0 M2?3@;)?O5K!U/%"&-,J&\\3EA'C#T837BQP^]OXN=+KS_OWAA_?G!VVM9."T M0%)KQ1[WID"U@1P[\70+ARH/UW?#+;SJ^<+;DD#M[6JD=I\'X8+ZYUY"##)L M$4Y#^"W7JQ^J090.2I8UN4O]X&SM^!/O3YXD^^%\L>]?[+./1-P-+E19/O-0?'`#]L_+NJG2KFUW MZ6F9#S"V_>Q=5,>F#L.R)DG%O>YZM7*,O<%!,UN3<8[(`P@US&;&D5II-"[" M'K^/I<3#@K$/:"K<[Y/I$#\KA1MQ/=XTZ]AJC_\':.NW$M)#"_[W!)V_.S'] M:I8CK+2B[D#R.]RUY83F!9OP-LY3YNY!BTM[SK4G2\CZ9$,)-A<.5<&XP$X7 MNZ#S*.S*'2.XY77(J,86WM(06U)9X>E3KXG\(E?3J`)?+3UJ/QE-([>8FM4H M$FOLV6]\SQ'!]Z)"B+JI5\BO]"L+1J!/K*P4E MJYX?>[MFY.4]U?B&Z$CV:,T59-4K$!?K5I9"%#B2C6NZAU;\X$]%].A0SXAL MRZC[U]/@AI$\>^,'X"VXL-C7<(=[ZXX4@R6>+UY=O;X@9[*N.*>['JJF3[DG M:N><5)_=]M:RE52#.6H#G-[QE5X7+G M=C"Y-5ENOA6U7.Z@C2\)$>#O]AV@UJ/OQAE ML"S,P`G:7,S0[Y!K"(3%UKG/_3#71;?67+(F3D+ MV=HU_%AA]!Z,%RGK%^$DN;Z;#Y9'E-?_G_G]&N97&Q2B7K'9).`@9N_LT8\'NF4=;U3__D(W)-EQCD:Y:,M"1;]I>O%S!2$IV3]QFI_6M#H_W/KS? M;S81+,_@_L7F.# M-==S(*2MKKABO.:;+?6RRG)M;2[%:*2P,R(].J@GE=UFN(DJS$/;<5OO;RVE M0E76:,VW,A3?-+#,'EYI*;;Q=ND&3A:I8^M$&L1A3A\N#"EV4P)"%MI+2A?Z M=M;UNHM+N0<16&O[7MC&`I3L5>*T!L/V9(2L"RH"2')GG.XNXCV6>A0JV&DM MVWSF^>T28_BY#KU?T1 M88S='PEBT3#O,-VA`\?JT/SW3Z8[-MR37DZHO1$>Z7JSU2OS M$6`)AU>)3.:'_=.S@^.CL_]>X6F?'9YTETU],*"WF.[_]D4,NP@&B_,N*E]- I7IGG^I0.0#3L)N,Q,3C[-`\NNM?1*+_2!_NTX"9V]_\!T2F<&_;5```` ` end From torvalds@transmeta.com Sat Oct 17 03:50:15 1998 Date: Sat Oct 17 03:50:15 1998 From: Linus Torvalds torvalds@transmeta.com Subject: eepro100 1.0.3 patch On Fri, 16 Oct 1998, Mr. James W. Laferriere wrote: > > Hello Linus , Ask your remote fingers (if get a chance) to > look at the link state of the adapter after ifconfig in rc.d > area if the link state light is OFF then get Mr. Beckers > mii-diag.c & compile it up like shown at the bottom of the > file & see if this doesn't bring the link state back ON . I'll look into this, but basically it's a driver deficiency regardless. The driver should make sure that the card is in a sane state: that's what kernel drivers are all about. Maybe the answer in that case is to move parts of mii-diag.c into the driver. Or maybe the answer is that the old v0.36 driver is actually better than the newer drivers when it comes to certain things. Linus From torvalds@transmeta.com Sat Oct 17 04:44:29 1998 Date: Sat Oct 17 04:44:29 1998 From: Linus Torvalds torvalds@transmeta.com Subject: eepro100 1.0.3 patch Ok, I found at least one remaining problem with the newer eepro100 drivers: they reset the thing _twice_. Worse, the second reset is after we have potentially written some specific setup, which then is lost completely. Search for the lines that say outl(0, ioaddr + SCBPort); and only the first one is any good: the others will reset the card without doing the proper state setup. The other problem seems to be due to the newer driver forcing a re-negotiation of the link, which is complete crap, because it ignores the options that the user has given (and that were honoured earlier at bootup). I suspect these two problems explain the bootup failure I saw - they essentially resulted in the new driver ignoring the documented way of forcing it into half-duplex 100Mbps (auto-negotiation doesn't seem to work either, but that may be due to our particular hub, and not due to the driver or the card). Let's see whether it is stable for me once it boots up (knock wood). Donald, please sync with me when I release a 2.1.126. Linus From torvalds@transmeta.com Sat Oct 17 05:22:26 1998 Date: Sat Oct 17 05:22:26 1998 From: Linus Torvalds torvalds@transmeta.com Subject: eepro100 1.0.3 patch Ok, I fixed the eepro100 driver so that I can live with it. I can still get the card to lock up under extreme load, but unlike the 1.02 driver it at least only loses the network, it doesn't crash the whole machine. The kernel itself continues to run, but the link lights go out, and there are no received or sent packets ever after.. And this is under fairly extreme load, with the machine having heavy disk activity, being out of memory and paging and at the same time being bombarded by two other machines on the same 100Mbps subnet with "ping -f". The v0.36 driver held up better, but that may be because I had upped some limits in it. Not crashing is the operative word, and while a problem it's still more acceptable to just lose the link. I still hope somebody finds out why that would happen. I put it on ftp.kernel.org as pre-patch-2.1.126-2.gz, please check it out and tell me whether it works on other peoples machines to a similar degree. Linus From ksi@gu.net Sat Oct 17 13:01:48 1998 Date: Sat Oct 17 13:01:48 1998 From: Serguei Koubouchine ksi@gu.net Subject: eepro100 1.0.3 patch On Sat, 17 Oct 1998, Linus Torvalds wrote: > Donald, Serguei, > could you take a look at this modified eepro100.c version? I'll give it a try on a several VERY heavily loaded servers by monday. The reason of delaying the test until monday is the same as yours - I don't wanna run like hell across the city to repair e.g. a busy mailserver serving 5,000+ users... Sure, I'll stress-test it by Monday. You'll see my report on Tuesday morning. ======================================================================= Serguei Koubouchine aka the Tamer < > The impossible we do immediately. e-mail: ksi@gu.net SK320-RIPE < > Miracles require 24-hour notice. ======================================================================= From babydr@baby-dragons.com Sat Oct 17 14:21:33 1998 Date: Sat Oct 17 14:21:33 1998 From: Mr. James W. Laferriere babydr@baby-dragons.com Subject: eepro100 1.0.3 patch Hello Linus & All, Trying to build a kernel with the eepro100.c you sent to the list fails under linux-2.0.35 & alan's pre-2.0.36-14 patches. With : eepro100.c:62: asm/spinlock.h: No such file of directory Then cascades from there . I take it you are building this under 2.1.125(+your stuff) ? Hth On Sat, 17 Oct 1998, Linus Torvalds wrote: > Ok, I found at least one remaining problem with the newer eepro100 > drivers: they reset the thing _twice_. Worse, the second reset is after we > have potentially written some specific setup, which then is lost > completely. Search for the lines that say > > outl(0, ioaddr + SCBPort); > > and only the first one is any good: the others will reset the card without > doing the proper state setup. > > The other problem seems to be due to the newer driver forcing a > re-negotiation of the link, which is complete crap, because it ignores the > options that the user has given (and that were honoured earlier at > bootup). > > I suspect these two problems explain the bootup failure I saw - they > essentially resulted in the new driver ignoring the documented way of > forcing it into half-duplex 100Mbps (auto-negotiation doesn't seem to work > either, but that may be due to our particular hub, and not due to the > driver or the card). > > Let's see whether it is stable for me once it boots up (knock wood). > > Donald, please sync with me when I release a 2.1.126. > > Linus > , JimL +-----------------------------------------------------------------------+ | James W. Laferriere - Network Engineer - babydr@baby-dragons.com | | System Techniques - 25416 - 22nd S. - Des-Moines, WA 98198 | | Give me VMS -or- Give me Linux -but- only on AXP | +-----------------------------------------------------------------------+ From torvalds@transmeta.com Sat Oct 17 18:16:23 1998 Date: Sat Oct 17 18:16:23 1998 From: Linus Torvalds torvalds@transmeta.com Subject: eepro100 1.0.3 patch On Sat, 17 Oct 1998, Mr. James W. Laferriere wrote: > > Trying to build a kernel with the eepro100.c you sent to the > list fails under linux-2.0.35 & alan's pre-2.0.36-14 patches. > With : It's never going to work with 2.0.x, there's no point in even trying. I should have made that clear, sorry. I also had another hang on my machine once it booted, so I'm starting to get ready to give up on the new driver again until somebody sends me something that seems to work. Linus From chris@ferret.lmh.ox.ac.uk Sat Oct 17 18:53:18 1998 Date: Sat Oct 17 18:53:18 1998 From: Chris Evans chris@ferret.lmh.ox.ac.uk Subject: eepro100 1.0.3 patch On Sat, 17 Oct 1998, Linus Torvalds wrote: > Not crashing is the operative word, and while a problem it's still more > acceptable to just lose the link. I still hope somebody finds out why that > would happen. See my previous message about problems we're having with 3c59x, ne2k and now tulip(!!!) cards. Maybe we have a generic problem with all the net drivers under extreme load. The ne2k driver crashes the machine outright, the tulip driver just loses the link. Sigh. This is under 2.0.x btw. Chris From john.cawley@gnorth.com Sat Oct 17 23:30:38 1998 Date: Sat Oct 17 23:30:38 1998 From: John Cawley john.cawley@gnorth.com Subject: eepro100 1.0.3 patch Linus, >From your discussion on the eepro driver: Thank you for your rigorous standards vis-a-vis the driver. I wouldn't dispute that you have an appropriately personal stake in the quality of the code, and that this is a powerful motivator. On the frequent occasions that I have loaded various distributions, I have always appreciated the fact that eepro driver was available. For that, however, I have silently thanked Donald Becker, not you. You started something wonderful; it would be a shame if you were harder than you needed to be on someone doing the same. Respectfully, John Cawley Linus Torvalds wrote: > > Sender: owner-linux-eepro100@beowulf.gsfc.nasa.gov > Received: from beowulf.gsfc.nasa.gov (beowulf.gsfc.nasa.gov [128.183.38.90]) > by hil-img-9.compuserve.com (8.8.6/8.8.6/2.14) with ESMTP id UAA29727 > for <72733.3224@compuserve.com>; Sat, 17 Oct 1998 20:12:49 -0400 (EDT) > Received: (from majordomo@localhost) > by beowulf.gsfc.nasa.gov (8.8.7/8.8.7) id SAA02075 > for linux-eepro100-list; Sat, 17 Oct 1998 18:16:23 -0400 > Received: from cesdis1.gsfc.nasa.gov (cesdis1.gsfc.nasa.gov [128.183.38.12]) > by beowulf.gsfc.nasa.gov (8.8.7/8.8.7) with ESMTP id SAA02072 > for ; Sat, 17 Oct 1998 18:16:22 -0400 > Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10]) > by cesdis1.gsfc.nasa.gov (8.8.7/8.8.7) with ESMTP id RAA17009; > Sat, 17 Oct 1998 17:21:02 -0400 > Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15]) > by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id PAA16969; > Sat, 17 Oct 1998 15:13:02 -0700 > Received: from penguin.transmeta.com (torvalds@penguin.transmeta.com [10.1.2.202]) > by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id PAA04813; > Sat, 17 Oct 1998 15:16:11 -0700 (PDT) > Received: from localhost (torvalds@localhost) by penguin.transmeta.com (8.8.5/8.7.3) with SMTP id PAA00436; Sat, 17 Oct 1998 15:16:11 -0700 > X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs > Date: Sat, 17 Oct 1998 15:16:11 -0700 (PDT) > From: Linus Torvalds > To: "Mr. James W. Laferriere" > cc: Donald Becker , > linux-eepro100@cesdis1.gsfc.nasa.gov > Subject: Re: eepro100 1.0.3 patch > In-Reply-To: > Message-ID: > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > Sender: owner-linux-eepro100@beowulf.gsfc.nasa.gov > Precedence: bulk > > On Sat, 17 Oct 1998, Mr. James W. Laferriere wrote: > > > > Trying to build a kernel with the eepro100.c you sent to the > > list fails under linux-2.0.35 & alan's pre-2.0.36-14 patches. > > With : > > It's never going to work with 2.0.x, there's no point in even trying. I > should have made that clear, sorry. > > I also had another hang on my machine once it booted, so I'm starting to > get ready to give up on the new driver again until somebody sends me > something that seems to work. > > Linus -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ John D. Cawley Great Northern Consulting Services john.cawley@gnorth.com 1105 Schrock Rd., Suite 500 Consultant Columbus, OH 43229 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From torvalds@transmeta.com Wed Oct 21 18:20:58 1998 Date: Wed Oct 21 18:20:58 1998 From: Linus Torvalds torvalds@transmeta.com Subject: eepro100 1.0.3 patch On Mon, 19 Oct 1998, Donald Becker wrote: > > The chip is reset the second time after doing the self-test: this is > recommended but not required. The only setup done between the first and > second reset is configuring an external 83840A transceiver to avoid an > interaction bug with the i82558. The internal transceiver on the i82558 > needs no special configuration, so the extra reset isn't erasing any > configuration. It makes a difference on my system. I don't know why. With the reset removed it got further but then apparently dies when it gets a transmit timeout. Why it gets that timeout I don't know, though. Linus From tkaley@kaley.net Sat Oct 24 18:39:50 1998 Date: Sat Oct 24 18:39:50 1998 From: Tom Kaley tkaley@kaley.net Subject: etherexpress 100 problem I would appreciate some help with resolving a problem concerning the pro10/100 card. When running "ifconfig eth0 up" the following message displays: SIOCSIFFLAGS:Resource Temporarily unavailable I don't know what is causing this problem or how to resolve it. Any help would be greatly appreciated. Cindi Cauffman cinives@kaley.net From sal@dcs.st-and.ac.uk Sun Oct 25 18:54:37 1998 Date: Sun Oct 25 18:54:37 1998 From: Steve Linton sal@dcs.st-and.ac.uk Subject: etherexpress 100 problem > I would appreciate some help with resolving a problem concerning the > pro10/100 card. > When running "ifconfig eth0 up" the following message displays: > SIOCSIFFLAGS:Resource Temporarily unavailable > Something is using a resource that your card needs. When I had this problem, it was a PCMCIA card on IRQ 11, and I fixed it by changing the PCMCIA config not to use IRQ 11. Try looking at /proc/interrupts Steve From lemmy@eaze.net Tue Oct 27 19:39:53 1998 Date: Tue Oct 27 19:39:53 1998 From: Chris Sterling lemmy@eaze.net Subject: Too much work at interrupt? I've got several Linux servers running on PR440FX boards with SMP running. They have been stable for months now. However, in the last week, I have had 3 out of 6 'crash' on me. Of course, the ones that went down are critical parts of my network, serving email, DNS, and database functions. All hardware is similar: large amounts of 50ns ECC RAM, one or two PPRO 200 CPU's, most recent BIOS rev from Intel, running Slackware Linux 3.5. All kernels are 2.0.35. All plugged into several BayStack 350T switches, all running 100mbps/full duplex. I'm not sure if there is a DoS attack going on when this happens, I'm still tracking down other variables that could cause this. The problem: machine drops off network, but does not dump core, or otherwise 'crash', all are still fine, if accessed from the console. What I know: >From /proc: no IRQ shareing or other odd stuff I noticed. >From syslog: kernel: eth0: Too much work at interrupt, status=0x4050 Physical: The 'link' light goes dark on the switch and the card. Has anyone seen this? I would have asked Donald Becker at ALS, but this only became noticable hours after I returned home. Great talk on Beowulf, BTW. Thanks! -------------------------------- Chris Sterling System Administrator EazeNet lemmy@eaze.net Office: 817-557-3038 Fax: 817-557-3468 From hans-christoph.rohland@sap-ag.de Wed Oct 28 04:06:12 1998 Date: Wed Oct 28 04:06:12 1998 From: Christoph Rohland hans-christoph.rohland@sap-ag.de Subject: Status of 'Transmit timed out' problem? Hi, I did read the mailing list archive about this problem but did not get the last status. There is a new driver in 2.1.126 but I do not know if it fixed the problem (for Linus). I at least have 2.1.126 running on a quad PPro. It is patched to use __PAGE_OFFSET 0x80000000 to use 2GB of RAM and it often stucks with: eth0: Transmit timed out: status 7048 0000 at 7296/7312 command 0003a000. eth0: Trying to restart the transmitter... in an endless loop. I can get it running again by stopping the network, unloading eepro100 module and restarting the network again. The first time I simply did a 'ifconfig eth0 down; ifconfig eth0 up' and the network was reachable again but terribly slow. E.g. ping from another host had response times ~2 seconds (but no losses). The initialisation message of the eepro100 is: OEM i82557/i82558 10/100 Ethernet at 0xf400, 00:A0:C9:F0:0A:BF, IRQ 10. Board assembly 697680-001, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x24c9f043). Receiver lock-up workaround activated. Cheers Christoph From James.Stevens@jrcs.co.uk Wed Oct 28 04:30:20 1998 Date: Wed Oct 28 04:30:20 1998 From: James Stevens James.Stevens@jrcs.co.uk Subject: Too much work at interrupt? Chris Sterling wrote: > > kernel: eth0: Too much work at interrupt, status=0x4050 ...Before you read this e-mail accept that I did not write the driver and I my be wrong in what I say, but I am doing my best to help... I can tell you what this means if it is any help. When the card pulls an interupt the eepro driver will service any jobs the card wants done (e.g. Rx any waiting packets) not just the first one. However, to try and prevent the driver from going into a infinite loop the driver has a hard coded limit on the number of waiting requests that it will service per interupt. This error message means that you have exceeded the maximum number of waiting requests on the card for the one interupt. You could probably safely increase the limit a bit without causing too much trouble. At line 40 in 1.03 of the driver you will find the lines :- /* Maximum events (Rx packets, etc.) to handle at each interrupt. */ static int max_interrupt_work = 20; increase the 20 and see how it goes. James From lemmy@eaze.net Wed Oct 28 10:15:15 1998 Date: Wed Oct 28 10:15:15 1998 From: Chris Sterling lemmy@eaze.net Subject: Too much work at interrupt? I appreciate the help! I'll give that a shot. It looks like I've got 0.99B, but the code for that is the same. I'll try 1.03 if I have any problems with the one I have. Do you know a way to test the setup? The ethernet load has not been very high when this happens. Thanks! -------------------------------- Chris Sterling System Administrator EazeNet lemmy@eaze.net Office: 817-557-3038 Fax: 817-557-3468 On Wed, 28 Oct 1998, James Stevens wrote: > Chris Sterling wrote: > > > > kernel: eth0: Too much work at interrupt, status=0x4050 > > ...Before you read this e-mail accept that I did not write the driver > and I my be wrong in what I say, but I am doing my best to help... > > I can tell you what this means if it is any help. > > When the card pulls an interupt the eepro driver will service any jobs > the card wants done (e.g. Rx any waiting packets) not just the first > one. However, to try and prevent the driver from going into a infinite > loop the driver has a hard coded limit on the number of waiting requests > that it will service per interupt. > > This error message means that you have exceeded the maximum number of > waiting requests on the card for the one interupt. You could probably > safely increase the limit a bit without causing too much trouble. > > At line 40 in 1.03 of the driver you will find the lines :- > > /* Maximum events (Rx packets, etc.) to handle at each interrupt. */ > static int max_interrupt_work = 20; > > increase the 20 and see how it goes. > > James >