From owner-freebsd-stable@FreeBSD.ORG Wed Aug 20 16:00:56 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 768B516A4C0; Wed, 20 Aug 2003 16:00:56 -0700 (PDT) In-Reply-To: <3F434321.CB90570D@kuzbass.ru> from Eugene Grosbein at "Aug 20, 2003 05:45:05 pm" To: eugen@kuzbass.ru (Eugene Grosbein) Date: Wed, 20 Aug 2003 16:00:56 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20030820230056.768B516A4C0@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: mark@remotelab.org cc: stable@FreeBSD.ORG Subject: Re: rl(4) is broken in STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 23:00:56 -0000 > Bill Paul wrote: > > > Aw come on guys! Give me a hint here! I can't even find this > > mysterious PR that was allegedly filed! Since you don't know the number, > > I've finally got the number of this PR. > Look: http://www.freebsd.org/cgi/query-pr.cgi?pr=55727 > > Eugene Grosbein > You didn't provide enough information. Unfortunately, the only way to diagnose this properly is with tcpdump: # tcpdump -n -e -i rl0 (or rl1, or whatever) Look at the incoming packets, see if they appear sane. If there are no packets at all, then you need to report this as well. Also, you should show me what "ifconfig -a" says. Note: don't just tell me that it "looks normal." I need to see the raw data to interpret it myself. You should also check netstat -in to see if the input/output packet and error counts are increasing. Checking the transmit side requires running tcopdump on a remote host. (Running tcpdump locally only shows you packets going into the TX routine of the driver. You can't actually tell that the frames have made it onto the wire unless you scan from another machine.) The 8139D isn't treated in any special way. Other people have reported that 'normal' 8139 NICs work again. (The commit on August 18th fixed the problem I introduced on August 17th.) I don't have one of these cards, so I'm relying on you people to provide detailed information. All of the other 8139 cards I've tested seem to work, however I only have cards with the original 8139 and 8139A chips. The code path for the 8139D should be the same as for all the others. The only ones that are different are the 8139C+ and the 8169. There's a slim chance the D-Link card is being mis-identified, but to know that for sure, it NEED you to show me the output of "ifconfig -a." -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= "If stupidity were a handicap, you'd have the best parking spot." =============================================================================