From mfrank@allot.com Tue Nov 3 10:30:57 1998 Date: Tue Nov 3 10:30:57 1998 From: Michael Frank mfrank@allot.com Subject: Too much work at interrupt I will very happy , if anybody knows what can be the reason of message "Too much work at interrupt, status=0x4050" and system crashes. The interface is configured in promiscuous mode Can it be the simple situation, that there are too much packets in the network and I simply need to increase "max_interrupt_work"? Michael Frank. mfrank@allot.com From rtoller@worldnet.att.net Tue Nov 3 10:45:41 1998 Date: Tue Nov 3 10:45:41 1998 From: Rodrigo Toller rtoller@worldnet.att.net Subject: EISA This is a multi-part message in MIME format. ------=_NextPart_000_0024_01BE0716.66C42C80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I have Ether Express Pro 100 EISA. Is it possible to get it working under Linux ?=20 Thanks in advance Rod ------=_NextPart_000_0024_01BE0716.66C42C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
I have Ether Express Pro 100 EISA. Is it possible to get it=20 working
under Linux ?=20

Thanks in advance
Rod

------=_NextPart_000_0024_01BE0716.66C42C80-- From esj@cs.fiu.edu Tue Nov 3 15:31:57 1998 Date: Tue Nov 3 15:31:57 1998 From: Eric S. Johnson esj@cs.fiu.edu Subject: Why no stats.tx_bytes / stats.rx_bytes Question: Is there some reason the tx_bytes/rx_bytes are not updated by the eepro100 driver? Vortex driver also doesn't count bytes. Tulip does. Would it be a bad thing to add in this count, ifdef'ed for 2.1 kernel? E From becker@cesdis1.gsfc.nasa.gov Tue Nov 3 21:33:21 1998 Date: Tue Nov 3 21:33:21 1998 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: Why no stats.tx_bytes / stats.rx_bytes On Tue, 3 Nov 1998, Eric S. Johnson wrote: > Is there some reason the tx_bytes/rx_bytes are not updated by the eepro100 > driver? No. > Vortex driver also doesn't count bytes. > > Tulip does. > > Would it be a bad thing to add in this count, ifdef'ed for 2.1 kernel? I'll add it at the next update. (Hmmm, I recall adding it before.. I wonder what happened to it..) 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 mfw@datamain.com Wed Nov 4 10:42:49 1998 Date: Wed Nov 4 10:42:49 1998 From: mfw@datamain.com mfw@datamain.com Subject: driver for pro/100? Is there a linux driver for the Intel pro/100? http://www.intel.com/network/doc/1868/index.htm#intelli card? From esj@cs.fiu.edu Wed Nov 4 12:46:18 1998 Date: Wed Nov 4 12:46:18 1998 From: Eric S. Johnson esj@cs.fiu.edu Subject: Why no stats.tx_bytes / stats.rx_bytes This is what I did to my eepro100.c. Its basicly modeled off of what I saw in the tulip driver. Patches against the driver distributed with 2.1.126. Did I get this right? I am not 100% positive that tx_buf_size0 is the right thing. But it looked like it might be.... E *** eepro100.c.orig Tue Oct 20 20:04:29 1998 --- eepro100.c Tue Nov 3 17:23:09 1998 *************** *** 1109,1116 **** --- 1109,1119 ---- break; /* It still hasn 't been processed. */ /* Free the original skb. */ if (sp->tx_skbuff[entry]) { sp->stats.tx_packets++; /* Count only us er packets. */ + #if LINUX_VERSION_CODE > 0x20127 + sp->stats.tx_bytes += sp-> tx_ring[entry] .tx_buf_size0 & 0x7ff; + #endif dev_free_skb(sp->tx_skbuff[entry]); sp->tx_skbuff[entry] = 0; } else if ((sp->tx_ring[entry].status&0x70000) = = CmdNOp << 16) sp->mc_setup_busy = 0; *************** *** 1227,1234 **** --- 1230,1240 ---- } skb->protocol = eth_type_trans(skb, dev); netif_rx(skb); sp->stats.rx_packets++; + #if LINUX_VERSION_CODE > 0x20127 + sp->stats.rx_bytes += pkt_len; + #endif } entry = (++sp->cur_rx) % RX_RING_SIZE; } From becker@cesdis1.gsfc.nasa.gov Wed Nov 4 18:03:36 1998 Date: Wed Nov 4 18:03:36 1998 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: Why no stats.tx_bytes / stats.rx_bytes On Wed, 4 Nov 1998, Eric S. Johnson wrote: > Subject: Re: Why no stats.tx_bytes / stats.rx_bytes > Did I get this right? I am not 100% positive that tx_buf_size0 is the right > thing. But it looked like it might be.... > + #if LINUX_VERSION_CODE > 0x20127 > + sp->stats.tx_bytes += sp-> > tx_ring[entry] > .tx_buf_size0 & 0x7ff; > + #endif ... > + #if LINUX_VERSION_CODE > 0x20127 > + sp->stats.rx_bytes += pkt_len; > + #endif Yes, this is correct. Well, mostly correct: we haven't defined what the tx_bytes/rx_bytes fields should count. We always omit the 4 CRC bytes that are added and stripped by the hardware. You could make an argument that the 12 address bytes, or the 14 address+length/protocol bytes should similarly be omitted. Or perhaps that the 12 bytes address bytes should be omitted, and the 2 bytes should only be omitted when they contain the packet length, but not when they contain the protocol. (Correct by one viewpoint, but ugly and painful.) And should we count pad bytes for too-short packets? (We don't, thus the Rx count might be higher than the link partner's Tx count.) IMNSHO, the above values are reasonable. 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 jfbeam@lacota.interpath.net Thu Nov 5 07:46:02 1998 Date: Thu Nov 5 07:46:02 1998 From: Ricky Beam - Interpath jfbeam@lacota.interpath.net Subject: Why no stats.tx_bytes / stats.rx_bytes On Wed, 4 Nov 1998, Donald Becker wrote: [snip] > Well, mostly correct: we haven't defined what the tx_bytes/rx_bytes fields > should count. IMO, {t,r}x_bytes should count the number of bytes that are flying over the cable - period. > We always omit the 4 CRC bytes that are added and stripped by the hardware. EEPro100's do hardware CRC? Shit, I'm liking these things more and more everyday! (beats the crap out of the 3c905's; of course, a roach squished into an ISA slot makes a better NIC that a 905.) --Ricky From becker@cesdis1.gsfc.nasa.gov Thu Nov 5 10:59:37 1998 Date: Thu Nov 5 10:59:37 1998 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: Why no stats.tx_bytes / stats.rx_bytes On Thu, 5 Nov 1998, Ricky Beam - Interpath wrote: > > Well, mostly correct: we haven't defined what the tx_bytes/rx_bytes fields > > should count. > > IMO, {t,r}x_bytes should count the number of bytes that are flying over the > cable - period. Errmm, including the hidden 8 byte preamble? Probably not. The "correct" count depends on your layering model. Most people use the OSI layering model to describe networks, but OSI doesn't map well to reality? [[ OSI was a mostly-European effort to redefine networking. Like ATM, it was promoted by organizations that had fallen behind or made bad choices and wanted everyone to start from scratch. It was composed of complicated, committee-design protocols that had never been implemented and were horribly broken. Very little of OSI remains today except for the layering model. ]] > > We always omit the 4 CRC bytes that are added and stripped by the hardware. > > EEPro100's do hardware CRC? Shit, I'm liking these things more and more > everyday! (beats the crap out of the 3c905's; of course, a roach squished > into an ISA slot makes a better NIC that a 905.) Every card does hardware CRC. It's UDP/TCP/IP checksumming that's rare. The 3c905B "Cyclone" chip core (but not the previous generations) actually has the best implementation of IP checksumming of any design I've seen. The current EEPro100 has no IP checksumming support at all. One problem with the 3c905B appears to be that 3Com uses the MII transceiver design provided by the fab line the chip is being produced on. This way 3Com can purchase chip production time from whichever fab line is least expensive at the time. But not all of the MII transceiver designs act the same.. 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 Daniel.Veillard@w3.org Sat Nov 7 00:53:07 1998 Date: Sat Nov 7 00:53:07 1998 From: Daniel Veillard Daniel.Veillard@w3.org Subject: Too much work at interrupt Like Michael Frank (mfrank@allot.com), I got this message while load-testing one of our new Web servers. But unlike the previous example, the machine stayed up, I just had to do a /etc/rc.d/init.d/network stop and start to get the machine back online. It's an HP LH Pro, dual PPro200, with 2 EEPro/100, only the first one is used yet and plugged directly to a 100MBps switch (Bay Network) 100MBits detected and full-duplex. I'm using a kernel 2.0.35 patched to version 1.03, the same I started using on our VAResearch servers (Hardware raid), but those servers never showed this message (while they show the "SMP simultaneous entry of an interrupt handler" occasionnaly but apparently without damage on 1.03). Any chance that both are variations of the same 2.0.xx SMP kernel bug ? Shoudl I upgrade to 1.05 ? Should I try to increase the static int max_interrupt_work = 20; increase as suggested in a past mail ? Or is there a way I can help debug this thing before the machines goes into production ? Our servers are all using the EEPro100 and that's the first time I see this, is it just bad luck of something related to some hardware setup ? I had pushed the machine under a double 100MBps ping flood without seeing the error which occured only when starting pushing the HTTP and AFS setup. thanks for any insight, Daniel -- Daniel.Veillard@w3.org | W3C MIT/LCS NE43-344 | Today's Bookmarks : Tel : +1 617 253 5884 | 545 Technology Square | Linux, WWW, rpm2html, Fax : +1 617 258 5999 | Cambridge, MA 02139 USA | badminton, Kaffe, http://www.w3.org/People/W3Cpeople.html#Veillard | HTTP-NG and Amaya. From becker@cesdis1.gsfc.nasa.gov Sat Nov 7 01:23:43 1998 Date: Sat Nov 7 01:23:43 1998 From: Donald Becker becker@cesdis1.gsfc.nasa.gov Subject: Too much work at interrupt On Sat, 7 Nov 1998, Daniel Veillard wrote: > message (while they show the "SMP simultaneous entry of an interrupt handler" > occasionnaly but apparently without damage on 1.03). Try the SMP patch from Loic Prylli http://beowulf.gsfc.nasa.gov/linux/misc/smp-bug.html > Any chance that both are variations of the same 2.0.xx SMP kernel bug ? > Shoudl I upgrade to 1.05 ? Should I try to increase the > static int max_interrupt_work = 20; > increase as suggested in a past mail ? Yes, upgrade if you use multicast. You can increase the max_interrupt_work value when loading the module: echo "options eepro100 max_interrupt_work=40" >> /etc/conf.module > Our servers are all using the EEPro100 and that's the first time I see > this, is it just bad luck of something related to some hardware setup ? > I had pushed the machine under a double 100MBps ping flood without seeing > the error which occured only when starting pushing the HTTP and AFS setup. This is probably occuring because the machine is under high load. If the machine doesn't have real-time responsibilities, increasing the work permitted is safe. 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 Daniel.Veillard@w3.org Sat Nov 7 01:54:51 1998 Date: Sat Nov 7 01:54:51 1998 From: Daniel Veillard Daniel.Veillard@w3.org Subject: Too much work at interrupt Donald, first thanks a lot for your prompt answer (especially at 1:30 A.M :-) > > message (while they show the "SMP simultaneous entry of an interrupt handler" > > occasionnaly but apparently without damage on 1.03). > > Try the SMP patch from Loic Prylli > http://beowulf.gsfc.nasa.gov/linux/misc/smp-bug.html Ok, I have seens it on the SMP list, but there wasn't much feedback. Must be good, otherwise one of the Gods would have expressed disagreement. Applied the patch, recompiling the kernel. I will reboot the test machine tomorrow, but I may not restart the production servers right now ... > > Any chance that both are variations of the same 2.0.xx SMP kernel bug ? > > Shoudl I upgrade to 1.05 ? Should I try to increase the > > static int max_interrupt_work = 20; > > increase as suggested in a past mail ? > > Yes, upgrade if you use multicast. Well, not really. BTW I wasn't able to find 1.05, it's listed on the Web page Changelog but I found only "eepro100.c:v1.03 8/11/98" on the web link or on the FTP server (I may not have searched at the right place though). > You can increase the max_interrupt_work value when loading the module: > echo "options eepro100 max_interrupt_work=40" >> /etc/conf.module This one is real nice, will do that and stop/start the network. Modules are great :-) > This is probably occuring because the machine is under high load. > If the machine doesn't have real-time responsibilities, increasing the work > permitted is safe. Ok, thanks a lot for the explanations/help, Daniel -- Daniel.Veillard@w3.org | W3C MIT/LCS NE43-344 | Today's Bookmarks : Tel : +1 617 253 5884 | 545 Technology Square | Linux, WWW, rpm2html, Fax : +1 617 258 5999 | Cambridge, MA 02139 USA | badminton, Kaffe, http://www.w3.org/People/W3Cpeople.html#Veillard | HTTP-NG and Amaya. From woit@cpw.math.columbia.edu Mon Nov 16 14:17:04 1998 Date: Mon Nov 16 14:17:04 1998 From: Peter Woit woit@cpw.math.columbia.edu Subject: eepro100.c v1.05, SMP, non-modular, won't boot Some data points eepro100.c v1.03, compiled into kernel kernel 2.0.36, SMP works fine eepro100.c v1.05, compiled into kernel kernel 2.0.36, No SMP works fine kernel 2.0.36, SMP won't boot, get the following on the console Uncompressing Linux... ran out of input data --System halted Peter Woit woit@math.columbia.edu 212-854-2642 From nhinze@vt.edu Mon Nov 16 19:18:35 1998 Date: Mon Nov 16 19:18:35 1998 From: Nicolas Hinze nhinze@vt.edu Subject: IBM EtherJet 100/10 PCI Could anybody give me a hand on installing the correct Ehternet driver for my IBM EtherJet PCI 10/100. It's based on an i82557/8 chip (like eepro100). I'm runing the Slackware 3.6 Distribution on an UMSDOS File System. I have the driver version 0.99B and I have no clue how to install a new driver for Linux and how to compile a kernel...and so on.. I just installed linux and I know almost nothing about it and how it works... Bye. Nicolas Hinze eMail : nhinze@iname.com ICQ : 8279346 > -----Original Message----- > From: owner-linux-eepro100@beowulf.gsfc.nasa.gov > [mailto:owner-linux-eepro100@beowulf.gsfc.nasa.gov]On Behalf Of Peter > Woit > Sent: Monday, November 16, 1998 1:13 PM > To: linux-eepro100@cesdis1.gsfc.nasa.gov > Subject: eepro100.c v1.05, SMP, non-modular, won't boot > > > > Some data points > > eepro100.c v1.03, compiled into kernel > > kernel 2.0.36, SMP > works fine > > > eepro100.c v1.05, compiled into kernel > > kernel 2.0.36, No SMP > works fine > > kernel 2.0.36, SMP > won't boot, get the following on the console > > Uncompressing Linux... > > ran out of input data > > --System halted > > > > Peter Woit > woit@math.columbia.edu > 212-854-2642 > From bill@icsd.k12.ny.us Fri Nov 20 16:04:47 1998 Date: Fri Nov 20 16:04:47 1998 From: William_Mahler bill@icsd.k12.ny.us Subject: No subject How do you switch the Eepro100 ethernet card from 10 meg to 100meg. Is it a software switch. I am running Linux 2.029 on a Dell Poweredge4100/200 Bill William R. Mahler Ithaca City School District Ithaca, New York 14850 e-mail wmahler@icsd.k12.ny.us Voice (607) 274-6802 Helpline (607) 274-6800 The Adventures of Rocky & Bullwinkle: Bullwinkle: Hey Rocky, Watch me pull a Rabbit out of my Hat Rocky: Again, That trick never works! Bullwinkle: This time for Sure!! Bullwinkle Pulls lion out of hat and it Roars! Bullwinkle: Darn, wrong hat again! From mephisto@faust.unidial.com Mon Nov 23 12:45:05 1998 Date: Mon Nov 23 12:45:05 1998 From: Lance Heller mephisto@faust.unidial.com Subject: v0.36 works but v0.99c doesn't I've just transitioned my box from RedHat 5.0 to SuSE 5.3. In the process I've discovered that the only eepro100 driver my 1996 vintage Intel EtherExpress Pro/100 adapter will accept is the one provided with RH5.0, i.e. v0.36. To obtain a working network connection I replaced the v0.99c module with a v0.36 module built in the SuSE 5.3 source tree, rmmod the one and insmod the other. The symptom I see is this: The system boots normally, the bootup messages for the adapter are correct, but the instant 'ifconfig' is executed, the activity light for the link at the connecting 10MB hub goes out. Removing then reinserting the module restores the hub connection but only until the next 'ifconfig' at which point it is lost again. 'ifconfig' presents no errors when the interface is brought up and will subsequently report that eth0 is active and correctly configured. /var/log/messages segments for eepro100 v0.99c vs v0.36: Nov 18 23:07:28 faust kernel: eepro100.c:v0.99C 5/31/98 Donald Becker linux-eepro100@cesdis.gsfc.nasa.gov Nov 18 23:07:28 faust kernel: eepro100.c:v0.99C 5/31/98 Donald Becker linux-eepro100@cesdis.gsfc.nasa.gov Nov 18 23:07:28 faust kernel: eth0: Intel EtherExpress Pro 10/100 at 0xe800, 00:A0:C9:19:97:8E, IRQ 9. Nov 18 23:07:28 faust kernel: Board assembly 352509-003, Physical connectors present: RJ45 Nov 18 23:07:28 faust kernel: Primary interface chip DP83840 PHY #1. Nov 18 23:07:28 faust kernel: DP83840 specific setup, setting register 23 to 8462. Nov 18 23:07:28 faust kernel: General self-test: passed. Nov 18 23:07:28 faust kernel: Serial sub-system self-test: passed. Nov 18 23:07:28 faust kernel: Internal registers self-test: passed. Nov 18 23:07:28 faust kernel: ROM checksum self-test: passed (0x49caa8d6). Nov 18 23:07:28 faust kernel: Receiver lock-up workaround activated. Nov 20 23:41:05 faust kernel: eepro100.c:v0.36 10/20/97 Donald Becker linux-eepro100@cesdis.gsfc.nasa.gov Nov 20 23:41:05 faust kernel: eth0: Intel EtherExpress Pro 10/100 at 0xe800, 00:A0:C9:19:97:8E, IRQ 9. Nov 20 23:41:05 faust kernel: Board assembly 352509-003, Physical connectors present: RJ45 Nov 20 23:41:05 faust kernel: Primary interface chip DP83840 PHY #1. Nov 20 23:41:05 faust kernel: DP83840 specific setup, setting register 23 to 8462. Nov 20 23:41:05 faust kernel: General self-test: passed. Nov 20 23:41:05 faust kernel: Serial sub-system self-test: passed. Nov 20 23:41:05 faust kernel: Internal registers self-test: passed. Nov 20 23:41:05 faust kernel: ROM checksum self-test: passed (0x49caa8d6). Nov 20 23:41:05 faust kernel: Receiver lock-up workaround activated. Nov 20 23:41:24 faust kernel: eth0: speedo_open() irq 9. Nov 20 23:41:24 faust kernel: eth0: Done speedo_open(), status 00000090. Please do not hesitate to ask if there is any more I can do. Best regards, Lance ---------------------------------------------------------------------- Lance Heller email: lheller@unidial.com ---------------------------------------------------------------------- From jason.axley@attws.com Mon Nov 23 13:46:57 1998 Date: Mon Nov 23 13:46:57 1998 From: Jason Axley jason.axley@attws.com Subject: v0.36 works but v0.99c doesn't The latest version of the driver is 1.05 and fixed some problems I was having with 0.36 and 0.99. I suggest you go to the Donald's eepro100 site and grab 1.05 from there, compile it, and use it instead to see if your problem goes away (the version linked to on the webpage was 1.03--1.05 was in the 'test' directory or something on the ftp server. Don't know if this is still the case) -Jason On 21 Nov, Lance Heller wrote: > > I've just transitioned my box from RedHat 5.0 to SuSE 5.3. In > the process I've discovered that the only eepro100 driver my 1996 vintage > Intel EtherExpress Pro/100 adapter will accept is the one provided with > RH5.0, i.e. v0.36. To obtain a working network connection I replaced the > v0.99c module with a v0.36 module built in the SuSE 5.3 source tree, rmmod > the one and insmod the other. > > The symptom I see is this: The system boots normally, the bootup messages > for the adapter are correct, but the instant 'ifconfig' is executed, the > activity light for the link at the connecting 10MB hub goes out. Removing > then reinserting the module restores the hub connection but only until the > next 'ifconfig' at which point it is lost again. 'ifconfig' presents no > errors when the interface is brought up and will subsequently report that > eth0 is active and correctly configured. > > /var/log/messages segments for eepro100 v0.99c vs v0.36: > > Nov 18 23:07:28 faust kernel: eepro100.c:v0.99C 5/31/98 Donald Becker > linux-eepro100@cesdis.gsfc.nasa.gov > Nov 18 23:07:28 faust kernel: eepro100.c:v0.99C 5/31/98 Donald Becker > linux-eepro100@cesdis.gsfc.nasa.gov > Nov 18 23:07:28 faust kernel: eth0: Intel EtherExpress Pro 10/100 at 0xe800, > 00:A0:C9:19:97:8E, IRQ 9. > Nov 18 23:07:28 faust kernel: Board assembly 352509-003, Physical connectors > present: RJ45 > Nov 18 23:07:28 faust kernel: Primary interface chip DP83840 PHY #1. > Nov 18 23:07:28 faust kernel: DP83840 specific setup, setting register 23 to > 8462. > Nov 18 23:07:28 faust kernel: General self-test: passed. > Nov 18 23:07:28 faust kernel: Serial sub-system self-test: passed. > Nov 18 23:07:28 faust kernel: Internal registers self-test: passed. > Nov 18 23:07:28 faust kernel: ROM checksum self-test: passed (0x49caa8d6). > Nov 18 23:07:28 faust kernel: Receiver lock-up workaround activated. > > > > Nov 20 23:41:05 faust kernel: eepro100.c:v0.36 10/20/97 Donald Becker > linux-eepro100@cesdis.gsfc.nasa.gov > Nov 20 23:41:05 faust kernel: eth0: Intel EtherExpress Pro 10/100 at 0xe800, > 00:A0:C9:19:97:8E, IRQ 9. > Nov 20 23:41:05 faust kernel: Board assembly 352509-003, Physical connectors > present: RJ45 > Nov 20 23:41:05 faust kernel: Primary interface chip DP83840 PHY #1. > Nov 20 23:41:05 faust kernel: DP83840 specific setup, setting register 23 to > 8462. > Nov 20 23:41:05 faust kernel: General self-test: passed. > Nov 20 23:41:05 faust kernel: Serial sub-system self-test: passed. > Nov 20 23:41:05 faust kernel: Internal registers self-test: passed. > Nov 20 23:41:05 faust kernel: ROM checksum self-test: passed (0x49caa8d6). > Nov 20 23:41:05 faust kernel: Receiver lock-up workaround activated. > Nov 20 23:41:24 faust kernel: eth0: speedo_open() irq 9. > Nov 20 23:41:24 faust kernel: eth0: Done speedo_open(), status 00000090. > > > Please do not hesitate to ask if there is any more I can do. > > > Best regards, > > Lance > > ---------------------------------------------------------------------- > Lance Heller email: lheller@unidial.com > ---------------------------------------------------------------------- > > -- AT&T Wireless Services IT UNIX Security Operations Specialist From Daniel.Veillard@w3.org Mon Nov 23 17:59:20 1998 Date: Mon Nov 23 17:59:20 1998 From: Daniel Veillard Daniel.Veillard@w3.org Subject: v0.36 works but v0.99c doesn't > The latest version of the driver is 1.05 and fixed some problems I was > having with 0.36 and 0.99. I suggest you go to the Donald's eepro100 > site and grab 1.05 from there, compile it, and use it instead to see > if your problem goes away (the version linked to on the webpage was > 1.03--1.05 was in the 'test' directory or something on the ftp server. > Don't know if this is still the case) BTW, I got the following yesterday on rufus.w3.org using a standard 2.0.35 SMP kernel: Nov 22 21:51:52 rufus kernel: eth0: Transmit timed out: status 0090 command 0000. Basically the driver got stuck (first time for 4 months !). And since the driver wasn't compiled as a module, I had to reboot, I upgraded to 2.0.36 + the 1.05 driver as a module. I have been running this SMP combination on 3 other machines for a few days without problems until now. my 2 cents, Daniel -- Daniel.Veillard@w3.org | W3C MIT/LCS NE43-344 | Today's Bookmarks : Tel : +1 617 253 5884 | 545 Technology Square | Linux, WWW, rpm2html, Fax : +1 617 258 5999 | Cambridge, MA 02139 USA | badminton, Kaffe, http://www.w3.org/People/W3Cpeople.html#Veillard | HTTP-NG and Amaya. From oa@spray.fi Tue Nov 24 04:15:31 1998 Date: Tue Nov 24 04:15:31 1998 From: Osma Ahvenlampi oa@spray.fi Subject: AppleTalk crashes EEPro100 on a bonded etherchannel [This post is partially off-topic for both lists, sorry about that. I'm still posting it to both because it's also partially on-topic for both, and will probably be of interest to readers on both lists.. Please adjust reply addresses accordingly.] Hardware: 350MHz P-II with two Intel EEPro100's, connected to a Cisco Catalyst 2924XL on both ports. Software: Linux 2.0.36 with Beowulf channel bonding patch, eepro100 driver versions 0.99B and 1.04 tested. Netatalk 1.4b2+asun2.1.0. Problem: With only one interface enabled and the switch in a standard configuration, the system works normally (after the multicast_filter_limit=3 workaround for the eepro100 bug). Enable both interfaces by running 'ifenslave eth0 eth1' and configuring the switch to use both ports connected to the machine as a port group. Tests with ftp indicate channel bonding is successful (transfer speeds to an NT machine on the same switch jump from 4.8-5.0 MB/s to 7.5MB/s, and concurrent transfers to two NT machines stay in the 5 MB/s range). Start Netatalk. nbprgstr fails to register an AppleTalk address/name for the system until I add a line "eth0 -phase 2" into /etc/atalk/atalkd.conf. After adding it, Netatalk starts normally. This indicates that atalkd can't understand that eth1 is a slave channel. This might have been acceptable, since with modern MacOS, EtherTalk isn't used for more than address lookups (Chooser) anyway.. afpd over TCP/IP probably wouldn't have been a problem on a bonded channel. Still, it is a lacking in Netatalk. However, I soon notice that the machine's entire ethernet layer starts crashing. The error is familiar from the multicast debugging: "kernel: eth0: Transmit timed out: status 0050 command 0000." All network traffic stops for 10-20 seconds, Linux notices something is wrong, resets the ethernet layer, and things work again for a minute or two until the same repeats. Last time this problem turned out to be (a still unresolved?) race condition in the eepro100 driver when the hardware multicast filter was set up for more than 3 addresses (requiring some kind of continuation packet in the configuration). If any (multicast?) packets were received during the multicast configuration, the driver would crash. I've patched my driver on the source level (in case conf.modules configuration options don't propagate correctly to multiple driver instances) to work around the problem by limiting the use of the hardware multicast filter to 3 addresses. With bonded channel, this isn't enough, though. Still, it sure sounds like a race condition. Perhaps some static variable that should be protected by a semaphore or local to a driver instance is getting clobbered when one card is being configured and the other receives traffic? -- Against boredom, even the gods themselves struggle in vain. Osma Ahvenlampi From eschwieb@halcyon.com Tue Nov 24 12:06:45 1998 Date: Tue Nov 24 12:06:45 1998 From: Erik Schwiebert eschwieb@halcyon.com Subject: [netatalk-admins] AppleTalk crashes EEPro100 on a bonded etherchannel At 1:14 AM -0800 11/24/98, Osma Ahvenlampi wrote: >[This post is partially off-topic for both lists, sorry about >that. I'm still posting it to both because it's also partially >on-topic for both, and will probably be of interest to readers >on both lists.. Please adjust reply addresses accordingly.] > >Hardware: 350MHz P-II with two Intel EEPro100's, connected to a Cisco >Catalyst 2924XL on both ports. > >Software: Linux 2.0.36 with Beowulf channel bonding patch, eepro100 >driver versions 0.99B and 1.04 tested. Netatalk 1.4b2+asun2.1.0. > >Problem: > >However, I soon notice that the machine's entire ethernet layer starts >crashing. The error is familiar from the multicast debugging: "kernel: >eth0: Transmit timed out: status 0050 command 0000." All network >traffic stops for 10-20 seconds, Linux notices something is wrong, >resets the ethernet layer, and things work again for a minute or two >until the same repeats. I munched a bunch of text. I'm seeing the same problem in my Linux box with two EEPro 100's. My configuration is slightly different: I have an ADSL coonection on eth0, and an home network on eth1, with IP masquerading to give the home network access to the internet. Every time i enable atalkd, i get a slew of kernel: eth1: Transmit timed out: status 0050 command 0000." messages (sometimes the status is 0090). My internal network is composed of 3 macs and a printer, and i'd like to get the Linux box running netatalk so i can use it as a common file server and temporary backup storage site, since its HD is several times bigger than the HD's in my macs. Schwieb -- Erik Schwiebert http://www.hokusai.com/ From amlai@columbia.edu Tue Nov 24 12:20:45 1998 Date: Tue Nov 24 12:20:45 1998 From: Albert Max Lai amlai@columbia.edu Subject: [netatalk-admins] AppleTalk crashes EEPro100 on a bonded etherchannel On 24 Nov 1998, Osma Ahvenlampi wrote: I have a similar config: dual 350MHz P-II with 1 Intel EEPro100 onboard kernel versions 2.0.35, 2.0.36, 2.0.128 driver versions 1.06 and 0.99B. Netatalk versions 1.4b2+asun2.1.0 and 1.4b2+asun2.0a18.2. I have a similar problem. If I don't set the module option multicast_filter_limit=0, I crash the local network here (router starts resetting my port, I hog all the bandwidth, etc.). When I set that module option under 2.0.35/2.0.36, when xntpd starts up, I get a Transmit timed out and then the ethernet layer gets reset. After that, it works. My guess is that there seems to be something still wrong with the multicast filter. Other than that it seems to work great. > Hardware: 350MHz P-II with two Intel EEPro100's, connected to a Cisco > Catalyst 2924XL on both ports. > Software: Linux 2.0.36 with Beowulf channel bonding patch, eepro100 > driver versions 0.99B and 1.04 tested. Netatalk 1.4b2+asun2.1.0. > Problem: > > With only one interface enabled and the switch in a standard > configuration, the system works normally (after the > multicast_filter_limit=3 workaround for the eepro100 bug). > > However, I soon notice that the machine's entire ethernet layer starts > crashing. The error is familiar from the multicast debugging: "kernel: > eth0: Transmit timed out: status 0050 command 0000." All network > traffic stops for 10-20 seconds, Linux notices something is wrong, > resets the ethernet layer, and things work again for a minute or two > until the same repeats. \\\|||/// | | ( @ @ ) ********************************************oooO****(_)****Oooo********* * Albert Lai SEAS Columbia University * * Residential Computer Consultant * * e-mail: amlai@columbia.edu http://www.columbia.edu/~aml61 * * aml61@columbia.edu http://amlai3.ec.rhno.columbia.edu * * AOL: LaiAlbert@aol.com * * 1018D East Campus * * 411 W 116th St * * New York, NY 10027 .oooO * * Ph: (212)853-4854 ( ) Oooo. * *************************************************\ ( ( )************* \_) ) / (_/ From skkweon@eecs.umich.edu Tue Nov 24 14:44:43 1998 Date: Tue Nov 24 14:44:43 1998 From: Seok-Kyu Kweon skkweon@eecs.umich.edu Subject: How can I change the speed of Ethernet from 100 Mbps tp 10Mbps? How can I change the speed of Ethernet from 100 Mbps tp 10Mbps? Is there anyone who can help with that? I am using eepro100. Thank you. -- ----------------------------------------------------------------- Seok-Kyu Kweon, Ph.D. candidate Real-Time Computing Laboratory Dept. of EECS, Univ. of Michigan, Ann Arbor, MI Tel: (734) 763-6131 Fax: (734) 763-4617 E-mail : skkweon@eecs.umich.edu URL: http://www.eecs.umich.edu/~skkweon ----------------------------------------------------------------- From jathey@home.com Sun Nov 29 15:43:46 1998 Date: Sun Nov 29 15:43:46 1998 From: James Athey jathey@home.com Subject: Installation Woes This is a multi-part message in MIME format. ------=_NextPart_000_000A_01BE1BAE.F353D6D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Sir, I recently downloaded the disk images boot and supp for RH Linux = 5.2, and after checking the HCL for my NIC (Intel EtherExpress PRO/10+) = I started the install. No matter what I do, though, the installer = cannot find my NIC by autoprobing using either the Pro 10 or Pro 100 = driver. I noticed your e-mail address when I hit alt-f4, and since I = didn't know who to ask about this, I thought I'd ask you. I know the = specs of my card (PnP has been disabled) but I don't know how to put = that into the module settings. Thank you for any help you have on this issue. James Athey ------=_NextPart_000_000A_01BE1BAE.F353D6D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Dear = Sir,
    I recently = downloaded the disk=20 images boot and supp for RH Linux 5.2, and after checking the HCL for my = NIC=20 (Intel EtherExpress PRO/10+) I started the install.  No matter what = I do,=20 though, the installer cannot find my NIC by autoprobing using either the = Pro 10=20 or Pro 100 driver.  I noticed your e-mail address when I hit = alt-f4, and=20 since I didn't know who to ask about this, I thought I'd ask you.  = I know=20 the specs of my card (PnP has been disabled) but I don't know how to put = that=20 into the module settings.
    Thank you for any = help you have=20 on this issue.
    James=20 Athey
------=_NextPart_000_000A_01BE1BAE.F353D6D0--