Date: Wed, 23 Mar 2005 00:27:58 +0100 (CET) From: "Julien Gabel" <jpeg@thilelli.net> To: "Oleg Bulyzhin" <oleg@rinet.ru> Cc: freebsd-hackers@freebsd.org Subject: Re: NIC detected, but won't DHCP or configure. Message-ID: <58390.192.168.1.18.1111534078.squirrel@webmail.thilelli.net> In-Reply-To: <20050323011538.B82878@lath.rinet.ru> References: <c451b0c43b75.c43b75c451b0@uidaho.edu> <200503222351.44698.doconnor@gsoft.com.au> <86mzsvpn31.fsf@xps.des.no> <51345.192.168.1.18.1111522001.squirrel@webmail.thilelli.net> <20050323011538.B82878@lath.rinet.ru>
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. > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?58390.192.168.1.18.1111534078.squirrel>