Subject: kern/10358: tlp driver doesn't work in 100baseTX-FDX on DE500-BA
To: None <gnats-bugs@gnats.netbsd.org>
From: Hal Murray <murray@pa.dec.com>
List: netbsd-bugs
Date: 06/13/2000 20:05:13
>Number: 10358
>Category: kern
>Synopsis: tlp driver doesn't work in 100baseTX-FDX on DE500-BA
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Jun 13 20:06:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator: Hal Murray
>Release: 1.4Z
>Organization:
Systems Research Center, Compaq Computer Corporation
>Environment:
Alpha or i386
System: NetBSD mckinley 1.4Z NetBSD 1.4Z (MIATA) #4: Fri Jun 9 04:01:32 PDT 2000
murray@mckinley:/usr/src/sys/arch/alpha/compile/MIATA alpha
>Description:
The DE500-BA has a 21143. I can't get it to work in full duplex
on either Alpha or i386. (Half duplex works as expected.)
The DE500-AA has a 21140A and DP83840. It works correctly, both
full and half. (Only tested on Alpha.)
The motherboards on Miatas and XP1000s also have 21143s. They work
correctly both full and half.
From dmesg:
tlp0 at pci0 dev 14 function 0: DECchip 21143 Ethernet, pass 3.0
tlp0: interrupting at irq 11
tlp0: DEC DE500-BA, Ethernet address 00:00:f8:06:e2:76
tlp0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX
From ifconfig -a:
tlp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:00:f8:06:e2:76
media: Ethernet 100baseTX full-duplex
status: active
inet 10.0.20.46 netmask 0xffffff00 broadcast 10.0.20.255
From netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Colls
tlp0 1500 <Link> 00:00:f8:06:e2:76 248132430 0 499549142 0 10166759
I started with a point-point link between (almost) identical systems.
TCP generally acts like it's running on a half duplex link.
When I inserted a Linksys switch, the LEDs indicate that it's running
in half-duplex mode.
I'm not sure the link is cleanly running in half duplex mode. With
the right message lengths, some TCP tests take 200 ms and I haven't
seen that when running through a hub.
>How-To-Repeat:
A simple TCP test that fills the link will provoke collisions.
The acks coming back are enough to cause them.
Two jobs running ping -f -s 20000 xxx will also cause them.
(One pinger may not be enough. It depends on your hardware.)
>Fix:
??
>Release-Note:
>Audit-Trail:
>Unformatted: