The re(4) network interface is an integrated network gigabit ethernet chip available on my notebook (clevo D480V). At least since FreeBSD release RELENG_5_2 i encountered very regular problem to get to work correctly. Most of the time, i am unable to use this interface since i can't have the link up. Despite the fact that my ethernet card seems correctly handled (ifconfig shows the 're' entry), almost all the time i boot the machine the state of the media is "no carrier". So, all services which use the network fail inevitably (dhcp, ntpdate and ntpd for example in my case). 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: # 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 is correctly 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. 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. Furthermore i am sure of the link cable since i have used it on another machine without problem, and encountered this same bad behaviour in three different places with this notebook. Just for information, i have build and install a -CURRENT FreeBSD system in a relatively recent past... but without much success as can be seen below: # 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). Note #1: The network card is set up using DHCP, but it does not change anything to set it manually (or statically via /etc/rc.conf). Note #2: The default is to use the autonegociation, but it does not change anything to force it to 100baseTX full-duplex (for example). Note #3: Sometimes, i get the following kernel error message at the console, but that is not always the case: # bzcat /var/log/messages.1.bz2 | grep PHY Apr 9 21:54:46 boboche kernel: re0: PHY read failed Apr 11 12:16:44 boboche kernel: re0: PHY read failed # bzcat /var/log/messages.0.bz2 | grep PHY Apr 14 09:14:07 boboche kernel: re0: PHY write failed Apr 14 09:14:11 boboche kernel: re0: PHY write failed Note #4: The BIOS is up-to-date, and the motherboard has already been changed (because of this particular problem)... but without success it seems! Fix: Not known to me. How-To-Repeat: I can easily reproduce the problem so simply as by restarting the machine. Sometimes, the problem appears even after hours of utilisation (not just at boot time, but that is not the more common case though).
Just to note that the problem persist at this time, currently using RELENG_6 permanently. Others report were made, showing that this is not an isolated problem, even though it may not be widely seen. One report said that this may be corrected in -CURRENT, but i don't have the material to test it right now. But if that is right, and since this problem happeared before 5.2 release, it may be a good thing if someone may be test it, trying to MFC fixes before the 6.0 release if any (two years with this same problem seems very long). As asked by Bjoern A. Zeeb on current@[1], follow the PHY/miibus information for re(4): # grep rgephy /var/run/dmesg.boot rgephy0: <RTL8169S/8110S media interface> on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto -- -jpeg. [1] lists.freebsd.org/pipermail/freebsd-current/2005-August/054843.html
> One report said that this may be corrected in -CURRENT, but i don't > have the material to test it right now. Regrettably, I had the opportunity to test running -CURRENT and nothing has changes (built from yesterday), no much success here. $ uname -a FreeBSD boboche.thilelli.net 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sun Oct 23 04:26:04 CEST 2005 root@boboche.thilelli.net:/usr/obj/usr/src/sys/BOBOCHE i386 -- -jpeg.
I can report the same problems with 6.1-PRERELEASE, but in my case, the behaviour appears to only be triggered by a specific event - taking the interface into promisc mode. --- Randi Harper FreeBSD Tsarina sektie@freebsdgirl.com
This is a multi-part message in MIME format. ------=_NextPart_000_010F_01C66E0C.0156B380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm experiencing a similar problem with 6.1RC1 using the chip RTL8139+ The board leds shows there's link and FreeBSD shows no carrier Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-PRERELEASE #0: Thu Mar 2 04:13:56 UTC 2006 sullrich@builder.livebsd.com:/usr/obj.pfSense/usr/src/sys/pfSense.6 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: VIA C3 Nehemiah+RNG+ACE (999.83-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x698 Stepping = 8 Features=0x381b83f<FPU,VME,DE,PSE,TSC,MSR,SEP,MTRR,PGE,CMOV,PAT,MMX,FXSR,SSE> real memory = 520093696 (496 MB) avail memory = 499376128 (476 MB) wlan: mac acl policy registered kbd1 at kbdmux0 ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) npx0: [FAST] npx0: <math processor> on motherboard npx0: INT 16 interface cpu0 on motherboard pcib0: <Host to PCI bridge> pcibus 0 on motherboard pir0: <PCI Interrupt Routing Table: 9 Entries> on motherboard pci0: <PCI bus> on pcib0 agp0: <VIA 862x (CLE266) host to PCI bridge> mem 0xe4000000-0xe7ffffff at device 0.0 on pci0 pcib1: <PCI-PCI bridge> at device 1.0 on pci0 pci1: <PCI bus> on pcib1 pci1: <display, VGA> at device 0.0 (no driver attached) re0: <RealTek 8139C+ 10/100BaseTX> port 0xd000-0xd0ff mem 0xee000000-0xee0000ff irq 5 at device 11.0 on pci0 miibus0: <MII bus> on re0 rlphy0: <RealTek internal media interface> on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re0: Ethernet address: 00:90:0b:05:ab:83 re1: <RealTek 8139C+ 10/100BaseTX> port 0xd400-0xd4ff mem 0xee001000-0xee0010ff irq 12 at device 12.0 on pci0 miibus1: <MII bus> on re1 rlphy1: <RealTek internal media interface> on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re1: Ethernet address: 00:90:0b:05:ab:82 re2: <RealTek 8139C+ 10/100BaseTX> port 0xd800-0xd8ff mem 0xee002000-0xee0020ff irq 10 at device 13.0 on pci0 miibus2: <MII bus> on re2 rlphy2: <RealTek internal media interface> on miibus2 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re2: Ethernet address: 00:90:0b:05:ab:81 re3: <RealTek 8139C+ 10/100BaseTX> port 0xdc00-0xdcff mem 0xee003000-0xee0030ff irq 11 at device 14.0 on pci0 miibus3: <MII bus> on re3 rlphy3: <RealTek internal media interface> on miibus3 rlphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re3: Ethernet address: 00:90:0b:05:ab:80 uhci0: <VIA 83C572 USB controller> port 0xe000-0xe01f irq 5 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: <VIA 83C572 USB controller> on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: <VIA 83C572 USB controller> port 0xe400-0xe41f irq 12 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] usb1: <VIA 83C572 USB controller> on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: <VIA 83C572 USB controller> port 0xe800-0xe81f irq 10 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] usb2: <VIA 83C572 USB controller> on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: <VIA VT6202 USB 2.0 controller> mem 0xee004000-0xee0040ff irq 11 at device 16.3 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: <VIA VT6202 USB 2.0 controller> on ehci0 usb3: USB revision 2.0 uhub3: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered isab0: <PCI-ISA bridge> at device 17.0 on pci0 isa0: <ISA bus> on isab0 atapci0: <VIA 8235 UDMA133 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xec00-0xec0f at device 17.1 on pci0 ata0: <ATA channel 0> on atapci0 ata1: <ATA channel 1> on atapci0 pmtimer0 on isa0 atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0 atkbd0: <AT Keyboard> irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: <Parallel port bus> on ppc0 lpt0: <Printer> on ppbus0 lpt0: Interrupt-driven port ppi0: <Parallel I/O> on ppbus0 sc0: <System console> at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: <PNP0303> can't assign resources (port) speaker0: <PC speaker> at port 0x61 on isa0 unknown: <PNP0c01> can't assign resources (memory) unknown: <PNP0501> can't assign resources (port) unknown: <PNP0400> can't assign resources (port) Timecounter "TSC" frequency 999829509 Hz quality 800 Timecounters tick every 1.000 msec Fast IPsec: Initialized Security Association Processing. ad2: 38204MB <SAMSUNG MP0402H UC100-14> at ata1-master UDMA100 Trying to mount root from ufs:/dev/ad2s1a re3: watchdog timeout re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=18<VLAN_MTU,VLAN_HWTAGGING> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::290:bff:fe05:ab83%re0 prefixlen 64 scopeid 0x1 ether 00:90:0b:05:ab:83 media: Ethernet autoselect (none) re1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500 options=18<VLAN_MTU,VLAN_HWTAGGING> ether 00:90:0b:05:ab:82 media: Ethernet autoselect (none) re2: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500 options=18<VLAN_MTU,VLAN_HWTAGGING> ether 00:90:0b:05:ab:81 media: Ethernet autoselect (none) re3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=18<VLAN_MTU,VLAN_HWTAGGING> inet6 fe80::290:bff:fe05:ab80%re3 prefixlen 64 scopeid 0x4 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:90:0b:05:ab:80 media: Ethernet autoselect (none) lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 pflog0: flags=100<PROMISC> mtu 33208 pfsync0: flags=41<UP,RUNNING> mtu 2020 pfsync: syncdev: lo0 maxupd: 128
State Changed From-To: open->feedback Is it still an issue on RELENG_6/RELENG_7?
Responsible Changed From-To: freebsd-bugs->yongari Grab.
State Changed From-To: feedback->closed Feedback timeout (> 3 months).