Date: Tue, 22 Mar 2005 21:06:41 +0100 (CET) From: "Julien Gabel" <jpeg@thilelli.net> To: freebsd-hackers@freebsd.org Subject: Re: NIC detected, but won't DHCP or configure. Message-ID: <51345.192.168.1.18.1111522001.squirrel@webmail.thilelli.net> In-Reply-To: <86mzsvpn31.fsf@xps.des.no> References: <c451b0c43b75.c43b75c451b0@uidaho.edu> <200503222351.44698.doconnor@gsoft.com.au> <86mzsvpn31.fsf@xps.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
>> thanks for the suggestion! I tried that and it didn't seem to change
>> anything: the relevant output of pciconf -lv is still
>> none4@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@boboche.thilelli.net:/usr/obj/usr/src/sys/BOBOCHE i386
# 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, 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.
Thanks,
--
-jpeg.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51345.192.168.1.18.1111522001.squirrel>