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--