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/