tested this again, with 2.2.0-pre9 ("final"), problem is still present.
Linux machine (P2B-LS, EEpro/100, 10Mbit Hub) floods shared 10BaseT
network with junk packets, nearly killing SCO Unix machine in same
network.
Didn't bother doing further diagnosis on this as already done below, as
nothing seems to have been changed in the eepro100 driver anyway - so all
the relevant stuff should be the same as in my previous mail, attached
below.
I repeat: this is absolutely unbearable for production environment.
gert
----- Forwarded message from Gert Doering <gert@greenie.muc.de> -----
Date: Tue, 5 Jan 1999 21:12:35 +0100
From: Gert Doering <gert@greenie.muc.de>
To: linux-kernel@vger.rutgers.edu
Subject: Re: 2.2.0-pre4 and "pauses" with EEpro/100
X-Mailer: Mutt 0.93.2i
In-Reply-To: <19990105201748.A6682@greenie.muc.de>; from Gert Doering on Tue, Jan 05, 1999 at 08:17:49PM +0100
Hi,
sorry to followup on my own e-mail, but I have new interesting things...:
On Tue, Jan 05, 1999 at 08:17:49PM +0100, Gert Doering wrote:
> just gave 2.2.0-pre4 a test on a machine with an ASUS P2B-LS mainboard
> (Adaptec 7890 and Intel EEpro/100 on board).
[..]
> The Ethernet card is connected to a 10 Mbit 10BaseT HUB.
I just found another problem, which is a lot more severe than this
"hickup" (which hasn't happened again since I wrote my last e-mail).
When the machine is sitting idle, it occasionally seems to send some
kind of "ethernet flood packets" (in lack of a better term). The traffic
LED of the 2.2.0-pre4 machine's port on the 10BaseT hub starts to flicker
like crazy, and my SCO Unix machine in the same network segment slows
down to a crawl - seems to have to process a lot of crazy stuff.
Doing a tcpdump on a third machine ("tcpdump -e -n") shows things like
the following:
21:05:56.297667 0:e0:18:90:84:1b 0:0:c0:8c:6a:a9 0800 98: truncated-ip - 140 bytes missing!106.169.8.0 > 69.0.0.84: (frag 6288:204@8408) [ttl 0]
21:05:56.297667 0:e0:18:90:84:1b 0:0:c0:8c:6a:a9 0800 98: truncated-ip - 140 bytes missing!106.169.8.0 > 69.0.0.84: (frag 6288:204@8408) [ttl 0]
21:05:56.297667 0:e0:18:90:84:1b 0:0:c0:8c:6a:a9 0800 98: truncated-ip - 140 bytes missing!106.169.8.0 > 69.0.0.84: (frag 6288:204@8408) [ttl 0]
21:05:56.297667 0:e0:18:90:84:1b 0:0:c0:8c:6a:a9 0800 98: truncated-ip - 140 bytes missing!106.169.8.0 > 69.0.0.84: (frag 6288:204@8408) [ttl 0]
21:05:56.297667 0:e0:18:90:84:1b 0:0:c0:8c:6a:a9 0806 60: arp-#33819 for proto #224 (144) hardware #1 (24)
21:05:56.297667 0:e0:18:90:84:1b 0:0:c0:8c:6a:a9 0800 98: truncated-ip - 140 bytes missing!106.169.8.0 > 69.0.0.84: (frag 6288:204@8408) [ttl 0]
21:05:56.297667 0:e0:18:90:84:1b 0:0:c0:8c:6a:a9 0800 98: truncated-ip - 140 bytes missing!106.169.8.0 > 69.0.0.84: (frag 6288:204@8408) [ttl 0]
21:05:56.297667 0:e0:18:90:84:1b 0:0:c0:8c:6a:a9 0800 98: truncated-ip - 140 bytes missing!106.169.8.0 > 69.0.0.84: (frag 6288:204@8408) [ttl 0]
21:05:56.307667 0:e0:18:90:84:1b 0:0:c0:8c:6a:a9 0800 98: truncated-ip - 140 bytes missing!106.169.8.0 > 69.0.0.84: (frag 6288:204@8408) [ttl 0]
21:05:56.307667 0:e0:18:90:84:1b 0:0:c0:8c:6a:a9 0806 60: arp-#33819 for proto #224 (144) hardware #1 (24)
21:05:56.307667 0:e0:18:90:84:1b 0:0:c0:8c:6a:a9 0800 98: truncated-ip - 140 bytes missing!106.169.8.0 > 69.0.0.84: (frag 6288:204@8408) [ttl 0]
21:05:56.307667 0:e0:18:90:84:1b 0:0:c0:8c:6a:a9 0806 60: arp-#33819 for proto #224 (144) hardware #1 (24)
... which goes away as soon as I start a "ping linux -> sco" on the Linux
machine...:
21:05:57.387766 0:e0:18:90:84:1b 0:0:c0:8c:6a:a9 0800 98: 193.174.156.69 > 193.174.156.65: icmp: echo request
21:05:57.387766 0:0:c0:8c:6a:a9 0:e0:18:90:84:1b 0800 98: 193.174.156.65 > 193.174.156.69: icmp: echo reply
21:05:58.387865 0:e0:18:90:84:1b 0:0:c0:8c:6a:a9 0800 98: 193.174.156.69 > 193.174.156.65: icmp: echo request
21:05:58.387865 0:0:c0:8c:6a:a9 0:e0:18:90:84:1b 0800 98: 193.174.156.65 > 193.174.156.69: icmp: echo reply
I assumed that maybe something was wrong with auto-sensing 10/100 mbit,
so I built the eepro100 driver as module and loaded it with "options=0xc0",
which made it say:
eth0: Intel EtherExpress Pro 10/100 at 0xb800, 00:E0:18:90:84:1B, IRQ 10.
Board assembly 668081-002, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
Forcing 10Mbs half-duplex operation. <<<<<<
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.
but this didn't change anything.
Resumee: the combination of this board (ASUS P2B-LS), driver (2.2.0-pre4)
and network (10BaseT) is absolutely unusable for a production environment.
Besides this, 2.2.0-pre4 is well-behaving, including SCSI (AHA7890)
and Sound (Jaz16). [Sound not loaded during Ethernet experiments]
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert@greenie.muc.de
fax: +49-89-35655025 gert.doering@physik.tu-muenchen.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/