Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Apr 2005 17:02:50 +0200 (CEST)
From:      Julien Gabel <jpeg@thilelli.net>
To:        FreeBSD-gnats-submit@FreeBSD.org
Subject:   kern/80005: re(4) network interface _very_ unpredictable working (RTL8169S/8110S Gigabit Ethernet).
Message-ID:  <20050416150250.E71275641F@boboche.thilelli.net>
Resent-Message-ID: <200504161510.j3GFAQac006809@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         80005
>Category:       kern
>Synopsis:       re(4) network interface _very_ unpredictable working (RTL8169S/8110S Gigabit Ethernet).
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Apr 16 15:10:26 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Julien Gabel
>Release:        FreeBSD 5.4-STABLE i386
>Organization:
>Environment:
System: FreeBSD boboche.thilelli.net 5.4-STABLE FreeBSD 5.4-STABLE #0: Fri Apr 15 13:22:32 CEST 2005 root@boboche.thilelli.net:/usr/obj/usr/src/sys/BOBOCHE i386

>Description:

The re(4) network interface is an integrated network gigabit ethernet chip available on my notebook
(clevo D480V).  At least since FreeBSD release RELENG_5_2 i encountered very regular problem to get
to work correctly.  Most of the time, i am unable to use this interface since i can't have the link
up.

Despite the fact that my ethernet card seems correctly handled (ifconfig shows the 're' entry), almost
all the time i boot the machine the state of the media is "no carrier".  So, all services which use
the network fail inevitably (dhcp, ntpdate and ntpd for example in my case).

In order to be able to use the network, sometimes i just must wait some dozens minutes... or totally
reboot and wait some other dozens minutes.  I can't remember of one boot wich went without a hitch.

Here is some (useful?) information:
# pciconf -lv
re0@pci0:10:0:  class=0x020000 card=0x08001558 chip=0x816910ec rev=0x10 hdr=0x00
    vendor   = 'Realtek Semiconductor'
    device   = 'RTL8169 Gigabit Ethernet Adapter'
    class    = network
    subclass = ethernet
=> Note: it seems that the chip revision is correctly recognized here.

# pciconf -r pci0:10:0 0:0xff
816910ec 02b00017 02000010 00004004
00002001 e8005000 00000000 00000000 
00000000 00000000 00000000 08001558
00000000 000000dc 00000000 40200113 
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000
00000000 00000000 00000000 f7c20001 
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000

# ifconfig re0
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
        inet6 fe80::290:f5ff:fe28:cfa8%re0 prefixlen 64 scopeid 0x2
        inet 192.168.1.20 netmask 0xffffff00 broadcast 192.168.1.255
        ether 00:90:f5:28:cf:a8
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
=> Note: here is the status after waiting a long time... or rebooting.

It may be noted that i do not encountered this kind of problem under GNU/Linux (i tested with two
live CDs), NetBSD (1.6.2 through 2.0.2) and Windows Server 2003 Ent-Ed.  Furthermore i am sure of
the link cable since i have used it on another machine without problem, and encountered this same
bad behaviour in three different places with this notebook.

Just for information, i have build and install a -CURRENT FreeBSD system in a relatively recent
past... but without much success as can be seen below:
# uname -a
FreeBSD boboche.thilelli.net 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Wed Mar 23 22:24:26 CET 2005    root at boboche.thilelli.net:/usr/obj/usr/src/sys/BOBOCHE  i386

It doesn't work better (i saw the same _bad_ behaviour) but this time,
the kernel send "more" messages:

# dmesg | egrep "^re0:"
re0: <RealTek 8169S Single-chip Gigabit Ethernet> port 0x2000-0x20ff mem 0xe8005000-0xe80050ff irq 19 at device 10.0 on pci0
re0: Ethernet address: 00:90:f5:28:cf:a8
re0: link state changed to UP
re0: link state changed to DOWN
re0: link state changed to UP
re0: link state changed to DOWN
re0: link state changed to UP
re0: link state changed to DOWN
re0: link state changed to UP
re0: link state changed to DOWN
re0: link state changed to UP
re0: link state changed to DOWN
re0: link state changed to UP

It seems to be the link which is the problem... but i'm not really sure since this hardware works
with other Unix-like systems and because i encountered the same problem in another place (at work).

Note #1: The network card is set up using DHCP, but it does not change anything to set it manually
(or statically via /etc/rc.conf).

Note #2: The default is to use the autonegociation, but it does not change anything to force it to
100baseTX full-duplex (for example).

Note #3: Sometimes, i get the following kernel error message at the console, but that is not always   
the case:
# bzcat /var/log/messages.1.bz2 | grep PHY
Apr  9 21:54:46 boboche kernel: re0: PHY read failed
Apr 11 12:16:44 boboche kernel: re0: PHY read failed
# bzcat /var/log/messages.0.bz2 | grep PHY
Apr 14 09:14:07 boboche kernel: re0: PHY write failed
Apr 14 09:14:11 boboche kernel: re0: PHY write failed

Note #4: The BIOS is up-to-date, and the motherboard has already been changed (because of this
particular problem)... but without success it seems!

>How-To-Repeat:

I can easily reproduce the problem so simply as by restarting the machine.  Sometimes, the problem
appears even after hours of utilisation (not just at boot time, but that is not the more common
case though).

>Fix:
Not known to me.
>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050416150250.E71275641F>