Date: Wed, 23 Mar 2005 23:06:02 +0100 (CET) From: "Julien Gabel" <jpeg@thilelli.net> To: freebsd-hackers@freebsd.org Subject: NIC detected, but won't DHCP or configure. Message-ID: <53636.192.168.1.18.1111615562.squirrel@webmail.thilelli.net>
next in thread | raw e-mail | index | archive | help
>>> 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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53636.192.168.1.18.1111615562.squirrel>