Re: kern/18414: tlp driver can "collect" ~10 packets in 1.6 before sending them

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/18414; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/18414: tlp driver can "collect" ~10 packets in 1.6 before 
sending them
Date: Mon, 10 Mar 2008 08:14:35 +0000

 Oh, no.
 
 I had this problem years ago, tracked it down, wrote up what was going
 on... and then forgot about it, so it never got fixed. Later on when I
 found the writeup again, I searched the PR database without finding
 anything, concluded nobody else had the same kind of weirdly mangled
 tulip I did (which isn't entirely implausible) and let it slide.
 Several times, actually. I just found it this time completely by
 accident.
 
 Ironically, the writeup is dated the same day as this PR. Here goes:
 
    I built a current kernel again for my home box last night, and the
    tulip driver still doesn't go.
 
    It produces the curious symptom that, if ping is running, once
    every ten seconds a burst of packets gets through.
 
    The card is an 82C115 pass 2.5, and, as far as I can tell, probes
    and attaches correctly.
 
    What seems to be happening is that the link autonegotiation never
    completes. In tlp_2114x_nway_status (around line 5250 of tulip.c,
    version 1.119), it checks to see if autonegotiation is enabled, and
    if so, does this:
 
                if ((siastat & SIASTAT_ANS) != SIASTAT_ANS_FLPGOOD) {
                        /* Erg, still trying, I guess... */
                        mii->mii_media_active |= IFM_NONE;
                        return;
                }
 
    My card seems to always remain "still trying" forever. This means that
    it never gets to the code that raises IFM_ACTIVE in mii_media_status,
    which correspondingly means that TULIPF_LINK_UP never gets raised
    either, which causes tlp_start to abort near the top.
 
    (It sends occasionally anyway, because the test that causes tlp_start
    to abort only operates if the send queue is less than ten packets
    long. The driver then transmits even though it thinks it doesn't have
    link, which may or may not be a problem in its own right.)
 
    Turning off the autonegotiation bit (SIATXRX_ANE) during card
    initialization doesn't appear to work, or maybe I did it wrong, but
    bypassing the entire autonegotiation branch of code in
    tlp_2114x_nway_status seems to make everything run more or less ok.
 
    This is presumably not the correct solution, but hopefully someone who
    actually knows the hardware can take over from this point. (I'd be
    happy to run further experiments.)
 
 
 I do still have (and use) the card and can post the hack I've been
 carrying for the last five years if anyone wants it.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost