Subject: kern/10358: tlp driver doesn't work in 100baseTX-FDX on DE500-BA
To: None <>
From: Hal Murray <>
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
>Originator:     Hal Murray
>Release:        1.4Z
        Systems Research Center, Compaq Computer Corporation
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


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 netmask 0xffffff00 broadcast

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. 


        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.)