NIC detected, but won't DHCP or configure.

[Julien Gabel]

>>> Interestingly, i encountered the very same behaviour as explained by
>>> Andrew, with a side note: it works sometimes for me.  Despite the fact
>>> that my ethernet seems correctly handled (ifconfig shows the 're'
>>> entry), almost all the time i boot on my notebook (D480V) the state of
>>> the media is "no carrier".  So, all services which use the network fail
>>> inevitably: dhcp, ntpdate and ntpd.
>>>
>>> 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:
>>>
>>> # uname -a
>>> FreeBSD boboche.thilelli.net 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #1:
>>> Tue Mar 22 20:04:20 CET 2005
>>> root at boboche.thilelli.net:/usr/obj/usr/src/sys/BOBOCHE  i386
>>>
>>> # pciconf -lv
>>> re0 at 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, which is the same as Andrew,
>>> is 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.
>>>
>>> As for Andrew, 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.
>>>
>>> Because of this particular problem, i can't currently use this machine
>>> in a usefull way, so any advice are welcome too ! :) It wants to say i
>>> can test and apply patch(es) without problem, if any.

>> Could you try this patch:
>> http://lists.freebsd.org/pipermail/freebsd-stable/2005-March/013107.html

> Ok, just tried it.  As i can see there is some improvement here, along
> with the following comments:
>
> 1/ When rebooting the system, the bad/old behaviour seems to happen
>    systematically;
>
> 2/ When powered-off then powered-on, the behaviour seems to be more
>    correct.  Nevertheless, i encountered the old problem more than
>    *one* time... roughly ~40% to 50% :(


Just for information, i just build and install a -CURRENT FreeBSD system:

# 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).

Any clue?
-- 
-jpeg.