Bug 80005
| Summary: | [re] re(4) network interface _very_ unpredictable working (RTL8169S/8110S Gigabit Ethernet). | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Julien Gabel <jpeg> |
| Component: | kern | Assignee: | Pyun YongHyeon <yongari> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 5.4-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
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). |
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).