Date: Thu, 21 Aug 2003 18:35:00 +0200 From: Marco Trentini <mark@remotelab.org> To: Bill Paul <wpaul@FreeBSD.ORG> Cc: Eugene Grosbein <eugen@kuzbass.ru> Subject: Re: rl(4) is broken in STABLE Message-ID: <3F44F4B4.1060304@remotelab.org> In-Reply-To: <20030820230056.768B516A4C0@hub.freebsd.org> References: <20030820230056.768B516A4C0@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Paul wrote: >>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." I have checked two impeached cards on one STABLE (RELENG_4) of the 21 Aug. The cards are: RTL8139D and D-Link DFE-528TX (recognized as one D-Link DFE-530TX+ 10/100BaseTX). Result: the cards work *correctly* (at least on my system). uname -v FreeBSD 4.8-STABLE #0: Thu Aug 21 17:29:19 CEST 2003 root@einstein.lab:/usr/obj/usr/src/sys/EINSTEIN dmesg.boot .... rl0: <D-Link DFE-530TX+ 10/100BaseTX, rev. 8139D/8100B/8100C> port 0xd800-0xd8ff mem 0xd4000000-0xd40000ff irq 11 at device 13.0 on pci0 rl0: Ethernet address: 00:40:05:0d:46:99 miibus0: <MII bus> on rl0 rlphy0: <RealTek internal media interface> on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ... and (RTL8139D) ... rl0: <RealTek 8139 10/100BaseTX, rev. 8139D/8100B/8100C> port 0xd800-0xd8ff mem 0xd4000000-0xd40000ff irq 11 at device 13.0 on pci0 rl0: Ethernet address: 00:08:a1:2a:b4:30 miibus0: <MII bus> on rl0 rlphy0: <RealTek internal media interface> on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ... ifconfig -a rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.168.2 netmask 0xffffff00 broadcast 192.168.168.255 ether 00:40:05:0d:46:99 media: Ethernet autoselect (100baseTX <full-duplex>) status: active lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet 127.0.0.1 netmask 0xff000000 and (RTL8139D) rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.168.2 netmask 0xffffff00 broadcast 192.168.168.255 ether 00:08:a1:2a:b4:30 media: Ethernet autoselect (100baseTX <full-duplex>) status: active lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet 127.0.0.1 netmask 0xff000000 netstat -in Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll rl0 1500 <Link#1> 00:40:05:0d:46:99 671 0 757 0 0 rl0 1500 192.168.168 192.168.168.2 670 - 751 - - lo0 16384 <Link#2> 7 0 7 0 0 lo0 16384 127 127.0.0.1 7 - 7 - - and (RTL8139D) Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll rl0 1500 <Link#1> 00:08:a1:2a:b4:30 5 0 6 0 0 rl0 1500 192.168.168 192.168.168.2 4 - 4 - - lo0 16384 <Link#2> 2 0 2 0 0 lo0 16384 127 127.0.0.1 2 - 2 - - Most likely in the last check I don't use the last revision of the if_rl.c. -- Marco Trentini mark@remotelab.org http://www.remotelab.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F44F4B4.1060304>