Various problems with re(4) on a PCIe 8168/8111B onboard NIC
pyunyh at gmail.com
Mon Jul 30 05:29:01 UTC 2007
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.
More information about the freebsd-stable