NIC detected, but won't DHCP or configure.

[Julien Gabel]

>>>> thanks for the suggestion!  I tried that and it didn't seem to change
>>>> anything: the relevant output of pciconf -lv is still
>>>> none4 at pci10:3:0:  class=0x020000 card=0x09001558 chip=0x816910ec
>>>> rev=0x10 hdr=0x00
>>>>     vendor   = 'Realtek Semiconductor'
>>>>     device   = 'RTL8169 Gigabit Ethernet Adapter'
>>>>     class    = network
>>>>     subclass = ethernet

>>> Andrew, it seems you have a chip revision which isn't currently
>>> supported.  Try applying the attached patch, and see if loading
>>> if_re.ko results in something like this:

>> 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% :(

-- 
-jpeg.