Date: Mon, 8 Jan 2001 10:29:43 -0700 (MST) From: George Wood <gwood@georgewood.net> To: "Jeroen C. van Gelderen" <jeroen@vangelderen.org> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Intel PRO/100+ driver or hardware? Message-ID: <Pine.BSF.4.21.0101080959330.43237-100000@new.buzzit.com> In-Reply-To: <128310000.978895262@grolsch.ai>
next in thread | previous in thread | raw e-mail | index | archive | help
I had similar symptoms (with a cheap realtek 10/100 nic card) when one of
the cards was not autonegotiating a full duplex connection with the
switch.
Small transfers and telnet sessions would generally work ok (although they
were much slower than they should have been) unless there was a sudden
burst (i.e. "find /" in a telnet session), at which point the connection
would lock or stall. Sometimes the connection would come back, sometimes
not. My solution on that box was to set the ifconfig "media" to 100baseTX
and "mediaopt" to full-duplex. ("ifconfig -a" had previously indicated
that autoselect was NOT picking 100mbps + full-duplex. Your ifconfig looks
like it is picking 10mbps half-duplex, and you said you were plugged into
a switch, so the situation looks a lot like mine.)
The apparent explanation for the behavior was that for small or slow
transfers, the switch (or nic) buffers would compensate for the inevitable
collisions resulting from a mix of full- and half- duplex, but at some
point the collision rate exceeds available buffers.
Switch (and/or nic) quality may reveal itself here: a good 10/100 switch
would have sufficient buffers to allow lots of large packets to move from
a 100mbps fdx segment to a 10mbps half-duplex segment, but in my case
performance was terrible on the segment with the realtek card until I
forced it to 100 fdx.
On Sun, 7 Jan 2001, Jeroen C. van Gelderen wrote:
> Date: Sun, 07 Jan 2001 15:21:02 -0400
> From: Jeroen C. van Gelderen <jeroen@vangelderen.org>
> To: freebsd-stable@FreeBSD.ORG
> Subject: Intel PRO/100+ driver or hardware?
>
>
> 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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV
> ,PAT,PSE36,MMX,FXSR>
> AMD Features=0xc0400000<AMIE,DSP,3DNow!>
> real memory = 268419072 (262128K bytes)
> avail memory = 258453504 (252396K bytes)
> Preloaded elf kernel "kernel" at 0xc0277000.
> Pentium Pro MTRR support enabled
> npx0: <math processor> on motherboard
> npx0: INT 16 interface
> apm0: <APM BIOS> on motherboard
> apm: found APM BIOS v1.2, connected at v1.2
> pcib0: <Host to PCI bridge> on motherboard
> pci0: <PCI bus> on pcib0
> pcib2: <VIA 82C598MVP (Apollo MVP3) PCI-PCI (AGP) bridge> at device 1.0 on
> pci0
> pci1: <PCI bus> on pcib2
> isab0: <VIA 82C686 PCI-ISA bridge> at device 4.0 on pci0
> isa0: <ISA bus> on isab0
> atapci0: <VIA 82C686 ATA66 controller> port 0xd800-0xd80f at device 4.1 on
> pci0
> ata0: at 0x1f0 irq 14 on atapci0
> ata1: at 0x170 irq 15 on atapci0
> pci0: <VIA 83C572 USB controller> at 4.2 irq 12
> pci0: <VIA 83C572 USB controller> at 4.3 irq 12
> pci0: <SiS 6326 SVGA controller> at 10.0 irq 10
> fxp0: <Intel EtherExpress Pro 10/100B Ethernet> 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: <Host to PCI bridge> on motherboard
> pci2: <PCI bus> on pcib1
> fdc0: <NEC 72065B or clone> 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: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
> atkbd0: <AT Keyboard> irq 1 on atkbdc0
> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
> sc0: <System console> 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: <Parallel port> 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: <Parallel I/O> on ppbus0
> lpt0: <Printer> on ppbus0
> lpt0: Interrupt-driven port
> IP Filter: initialized. Default = pass all, Logging = enabled
> IP Filter: v3.3.8
> ad0: 19470MB <IBM-DJNA-352030> [39560/16/63] at ata0-master using UDMA66
> ad2: 19470MB <IBM-DJNA-352030> [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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 <full-duplex> 100baseTX 10baseT/UTP
> <full-duplex> 10baseT/UTP
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0101080959330.43237-100000>