Various problems with re(4) on a PCIe 8168/8111B onboard NIC

[Pyun YongHyeon]

On Sun, Jul 29, 2007 at 01:27:36PM -0700, Kent Stewart wrote:
 > 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 at 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.
 > 

You should not see the watdog errors on re(4).
If you still see the watchdog timeout errors, please let me know. 

-- 
Regards,
Pyun YongHyeon