From owner-freebsd-stable Mon Jan 8 8:18:15 2001 Delivered-To: freebsd-stable@freebsd.org Received: from digital.csudsu.com (digital.csudsu.com [209.249.57.102]) by hub.freebsd.org (Postfix) with ESMTP id E159B37B6A4 for ; Mon, 8 Jan 2001 08:17:39 -0800 (PST) Received: by digital.csudsu.com (Postfix, from userid 1000) id A0A6622E01; Mon, 8 Jan 2001 08:17:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by digital.csudsu.com (Postfix) with ESMTP id 919571F001; Mon, 8 Jan 2001 08:17:44 -0800 (PST) Date: Mon, 8 Jan 2001 08:17:44 -0800 (PST) From: Stefan Molnar To: "Jeroen C. van Gelderen" Cc: Subject: Re: Intel PRO/100+ driver or hardware? In-Reply-To: <128310000.978895262@grolsch.ai> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have noticed that the eepro does not like some hubs/switches. I have a netgear 8 port 10mb switch, and the eepro just goes to a crawl with the same things you see. I have tried over a dozen eepro cards (had this switch for almost 2 years), and countless ethernet cables. I bought a 4 port hub, connected the xover to the swtitch and the eepro on the hub, and bamf, those problems went away. The tulip cards that most of the eepros replaced worked very happly. Stefaq On Sun, 7 Jan 2001, Jeroen C. van Gelderen wrote: > > I hope this isn't too off-topic for this list but I'm experiencing a rather > strange problem. I've been searching the various mailing lists and websites > for information but to no avail. I've included all information that I know > to extract. I may miss some because I've tried a lot of different things in > the past 24 hours :-( I'm keeping the machines around in the exact same > configuration so I can extract more data if needed... > > I have two identical machines (Asus/Athlon with Intel PRO/100+ NICs). For > the record, one machine is running a recent 4-STABLE and one is running and > older 4.0-STABLE. I've tried a recent 4-STABLE kernel on both though, so I > don't think this difference is significant. > > I noticed my problem when I tried to upgrade the 4.0-STABLE box with an NFS > installworld. It would consistently hang after a short while. Further > investigation showed that *every* TCP connection to or from this box stalls > after transferring somewhere between 1MB and 20MB of data. (Tested with > NFS, scp, etc). As the machine is handling small transactions most of the > time I hadn't noticed this, until now :-( > > I tried to reproduce the problem on the 4.2-STABLE box wihtout sucess, > until I finally realized that the problematic box is connected to a hub(10) > and the 4.2-STABLE box to a switch (10/100). Either box has it's TCP > connections stalled when connected to the hub and not when connected to the > switch. > > I'd normally expect the hub to be dud, except that only machines with Intel > PRO/100+ NICs seem to have a problem with it. None of the other machines > that are connected to the hub are be affected. > > Moreover, a tcpdump on both sides of a stalled TCP connection seems to > indicate that no packets get lost. I do an scp on hayek (problematic > machine) to fetch a file from keynes. It looks like hayek simply stops > responding to incoming packets and the TCP connection stalls until keynes > gives up and sends RST. > > I've stuck both tcpdumps for > hayek# scp me@keynes.ai:./bla.tgz /dev/null > at > http://vangelderen.org/~gelderen/tcpdump-hayek (problematic machine) > http://vangelderen.org/~gelderen/tcpdump-keynes (has the file) > > If someone with a clue could have a look over them? I'm sure some netstat > information could be useful but I don't know which bits to include. > > My tentative conclusion is that the Intel NICs don't work with my hub, even > though they should. As my hub seems to work with other cards, I'm > suspecting an Intel PRO/100+ specific problem. I can't determine whether it > is a hardware or a software problem though :-( > > Anybody care to point out the obvious bits I've missed? > > TIA, > Jeroen > > ====8<====8<====8<====8<====8<====8<====8<====8<==== > > FreeBSD hayek.ai 4.0-STABLE FreeBSD 4.0-STABLE #0: Fri Jun 9 18:49:08 AST > 2000 gelderen@hayek.ai:/usr/src/sys/compile/ISSUER i386 > > > Copyright (c) 1992-2000 The FreeBSD Project. > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > FreeBSD 4.0-STABLE #0: Fri Jun 9 18:49:08 AST 2000 > gelderen@hayek.ai:/usr/src/sys/compile/ISSUER > Timecounter "i8254" frequency 1193182 Hz > CPU: AMD Athlon(tm) Processor (650.03-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x621 Stepping = 1 > > Features=0x183f9ff ,PAT,PSE36,MMX,FXSR> > AMD Features=0xc0400000 > real memory = 268419072 (262128K bytes) > avail memory = 258453504 (252396K bytes) > Preloaded elf kernel "kernel" at 0xc0277000. > Pentium Pro MTRR support enabled > npx0: on motherboard > npx0: INT 16 interface > apm0: on motherboard > apm: found APM BIOS v1.2, connected at v1.2 > pcib0: on motherboard > pci0: on pcib0 > pcib2: at device 1.0 on > pci0 > pci1: on pcib2 > isab0: at device 4.0 on pci0 > isa0: on isab0 > atapci0: port 0xd800-0xd80f at device 4.1 on > pci0 > ata0: at 0x1f0 irq 14 on atapci0 > ata1: at 0x170 irq 15 on atapci0 > pci0: at 4.2 irq 12 > pci0: at 4.3 irq 12 > pci0: at 10.0 irq 10 > fxp0: port 0xa000-0xa03f mem > 0xe1800000-0xe18fffff,0xe2000000-0xe2000fff irq 11 at device 12.0 on pci0 > fxp0: Ethernet address 00:d0:b7:74:87:2b > pcib1: on motherboard > pci2: on pcib1 > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > sc0: on isa0 > sc0: VGA <16 virtual consoles, flags=0x200> > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/8 bytes threshold > ppi0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > IP Filter: initialized. Default = pass all, Logging = enabled > IP Filter: v3.3.8 > ad0: 19470MB [39560/16/63] at ata0-master using UDMA66 > ad2: 19470MB [39560/16/63] at ata1-master using UDMA33 > Mounting root from ufs:/dev/ad0s1a > vinum: loaded > vinum: reading configuration from /dev/ad2s1h > vinum: updating configuration from /dev/ad2s1f > vinum: updating configuration from /dev/ad2s1g > vinum: updating configuration from /dev/ad2s1e > vinum: updating configuration from /dev/ad0s1h > vinum: updating configuration from /dev/ad0s1g > vinum: updating configuration from /dev/ad0s1f > vinum: updating configuration from /dev/ad0s1e > > ====8<====8<====8<====8<====8<====8<====8<====8<==== > > fxp0: flags=8843 mtu 1500 > inet 209.88.68.42 netmask 0xffffff00 broadcast 209.88.68.255 > ether 00:d0:b7:74:87:2b > media: autoselect (10baseT/UTP) status: active > supported media: autoselect 100baseTX 100baseTX 10baseT/UTP > 10baseT/UTP > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > > ====8<====8<====8<====8<====8<====8<====8<====8<==== > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message