freebsd stable - Jul 2007 - Various problems with re(4) on a PCIe 8168/8111B onboard NIC

After recently updating the windows drivers (I dual-boot Windows XP on the 
machine the NIC is in), I hit this problem: 
http://gentoo-wiki.com/HARDWARE_RTL8168#Troubleshooting which affects re(4) 
like it does the Linux drivers described in the above link. 

I already wrote the Realtek technical support about it since their
"own"
FreeBSD driver (a hacked rl(4) that does not support any of the chip's 
advanced features) does not manage to power up the PHY on its own either - 
neither does the motherboard's BIOS when trying to netboot.

The other problem is that I have at least two applications misbehaving when 
rxcsum/txcsum is enabled: 

- The Linux Second Life client (yes, yes, I know, but it is nice for showing 
off GLX and it is really really good at generating network traffic) will 
cease to receive data after about a minute or so - turning off rcxsum/txcsum 
will mend it on the spot.

- A Fedora Core 4 running in Qemu, networked with bridge(4) and tap(4), cannot 
receive an ip address via DHCP. Interestingly, this even occurs if 
rxcsum/txcsum was already turned off before launching Qemu - to make it work, 
I have to cycle rxcsum/txcsum once. Might be related to promiscuous mode.

I realise that both of these make awful test cases, but so far they are the 
only applications I found to expose those problems.

This is on FreeBSD kiste 6.2-STABLE FreeBSD 6.2-STABLE #4: Sat Jul 28 14:11:23 
CEST 2007     root@:/usr/obj/usr/src/sys/KISTE-SMP  i386. The kernel sources 
are up to date as of 2007-07-27.

The NIC is re0: <RealTek 8168/8111B PCIe Gigabit Ethernet> port
0xd800-0xd8ff
mem 0xfbfff000-0xfbffffff irq 36 at device 0.0 on pci3 / re0@pci3:0:0: 
class=0x020000 card=0x81681849 chip=0x816810ec rev=0x01 hdr=0x00.

-- 
   ,_,   | Michael Nottebrock               | lofi@freebsd.org
 (/^ ^\) | FreeBSD - The Power to Serve     | http://www.freebsd.org
   \u/   | K Desktop Environment on FreeBSD | http://freebsd.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20070729/609dc58a/attachment.pgp

On Sunday, 29. July 2007, Kent Stewart wrote:
>
> Have you looked at /var/log/messages? I would be surprised if you have
> not had a number of
>
> Jul 27 00:55:32 ruby kernel: re0: watchdog timeout
> Jul 27 00:55:32 ruby kernel: re0: link state changed to DOWN
> Jul 27 00:55:35 ruby kernel: re0: link state changed to UP
In fact I have and I haven't had any such messages (except link down/up when
I
switched rxcsum/txcsum, but that is expected - no watchdog timeouts at all). 
I also should mention that the interface never completely goes dead either.
> People have complained a long time ago and basically given up on getting
> it fixed.
I saw that yongari@ has been busy trying to brush up re(4) recently, that's 
why I thought I'd pipe up. :)


Cheers,
-- 
   ,_,   | Michael Nottebrock               | lofi@freebsd.org
 (/^ ^\) | FreeBSD - The Power to Serve     | http://www.freebsd.org
   \u/   | K Desktop Environment on FreeBSD | http://freebsd.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20070729/f58aae7b/attachment.pgp

On Sunday 29 July 2007, Michael Nottebrock wrote:
> After recently updating the windows drivers (I dual-boot Windows XP
> on the machine the NIC is in), I hit this problem:
> http://gentoo-wiki.com/HARDWARE_RTL8168#Troubleshooting which affects
> re(4) like it does the Linux drivers described in the above link.
>
> I already wrote the Realtek technical support about it since their
> "own" FreeBSD driver (a hacked rl(4) that does not support any of
the
> chip's advanced features) does not manage to power up the PHY on its
> own either - neither does the motherboard's BIOS when trying to
> netboot.
>
> The other problem is that I have at least two applications
> misbehaving when rxcsum/txcsum is enabled:
>
> - The Linux Second Life client (yes, yes, I know, but it is nice for
> showing off GLX and it is really really good at generating network
> traffic) will cease to receive data after about a minute or so -
> turning off rcxsum/txcsum will mend it on the spot.
>
> - A Fedora Core 4 running in Qemu, networked with bridge(4) and
> tap(4), cannot receive an ip address via DHCP. Interestingly, this
> even occurs if rxcsum/txcsum was already turned off before launching
> Qemu - to make it work, I have to cycle rxcsum/txcsum once. Might be
> related to promiscuous mode.
>
> I realise that both of these make awful test cases, but so far they
> are the only applications I found to expose those problems.
>
> This is on FreeBSD kiste 6.2-STABLE FreeBSD 6.2-STABLE #4: Sat Jul 28
> 14:11:23 CEST 2007     root@:/usr/obj/usr/src/sys/KISTE-SMP  i386.
> The kernel sources are up to date as of 2007-07-27.
>
> The NIC is re0: <RealTek 8168/8111B PCIe Gigabit Ethernet> port
> 0xd800-0xd8ff mem 0xfbfff000-0xfbffffff irq 36 at device 0.0 on pci3
> / re0@pci3:0:0: class=0x020000 card=0x81681849 chip=0x816810ec
> rev=0x01 hdr=0x00.
Have you looked at /var/log/messages? I would be surprised if you have 
not had a number of 

Jul 27 00:55:32 ruby kernel: re0: watchdog timeout
Jul 27 00:55:32 ruby kernel: re0: link state changed to DOWN
Jul 27 00:55:35 ruby kernel: re0: link state changed to UP

People have complained a long time ago and basically given up on getting 
it fixed.

Kent

-- 
Kent Stewart
Richland, WA

http://www.soyandina.com/ "I am Andean project".
http://users.owt.com/kstewart/index.html

Michael Nottebrock schreef:
> After recently updating the windows drivers (I dual-boot Windows XP on the 
> machine the NIC is in), I hit this problem: 
> http://gentoo-wiki.com/HARDWARE_RTL8168#Troubleshooting which affects re(4)
> like it does the Linux drivers described in the above link. 
> 
I also noticed this and the workaround as explained in the gentoo-wiki 
works.
> I already wrote the Realtek technical support about it since their
"own"
> FreeBSD driver (a hacked rl(4) that does not support any of the chip's 
> advanced features) does not manage to power up the PHY on its own either - 
> neither does the motherboard's BIOS when trying to netboot.
> 
I have done the exact same thing and was surprised to receive a 
response. Attached to this response was a beta-version of their (rl) 
driver. After a quick test it seemed to have fixed the problem.
I have been trying to fix the issue in re(4) by looking at the changes 
in the beta-driver but have not had any success so far (due to lack of 
knowledge i guess).
I put the beta driver up here: 
http://www.timkapel.nl/~laurens/rtl_bsd_drv_v174beta3.tgz
> The other problem is that I have at least two applications misbehaving when
> rxcsum/txcsum is enabled: 
> 
> - The Linux Second Life client (yes, yes, I know, but it is nice for
showing
> off GLX and it is really really good at generating network traffic) will 
> cease to receive data after about a minute or so - turning off
rcxsum/txcsum
> will mend it on the spot.
> 
> - A Fedora Core 4 running in Qemu, networked with bridge(4) and tap(4),
cannot
> receive an ip address via DHCP. Interestingly, this even occurs if 
> rxcsum/txcsum was already turned off before launching Qemu - to make it
work,
> I have to cycle rxcsum/txcsum once. Might be related to promiscuous mode.
> 
> I realise that both of these make awful test cases, but so far they are the
> only applications I found to expose those problems.
> 
> This is on FreeBSD kiste 6.2-STABLE FreeBSD 6.2-STABLE #4: Sat Jul 28
14:11:23
> CEST 2007     root@:/usr/obj/usr/src/sys/KISTE-SMP  i386. The kernel
sources
> are up to date as of 2007-07-27.
> 
> The NIC is re0: <RealTek 8168/8111B PCIe Gigabit Ethernet> port
0xd800-0xd8ff
> mem 0xfbfff000-0xfbffffff irq 36 at device 0.0 on pci3 / re0@pci3:0:0: 
> class=0x020000 card=0x81681849 chip=0x816810ec rev=0x01 hdr=0x00.
>