Date: Mon, 27 Oct 2014 23:14:54 -0400 From: Mason Loring Bliss <mason@blisses.org> To: Yonghyeon PYUN <pyunyh@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Very bad Realtek problems Message-ID: <20141028031454.GQ17150@blisses.org> In-Reply-To: <20141028015020.GB1054@michelle.fasterthan.com> References: <20141027195124.GI17150@blisses.org> <20141028015020.GB1054@michelle.fasterthan.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 28, 2014 at 10:50:20AM +0900, Yonghyeon PYUN wrote: > But the RX frame alignment error normally indicates cabling issue or > speed/duplex mismatches with link partner. Hm. I don't think it's a cabling issue since the only thing changing between working (Linux) and flaky (FreeBSD) is the software. If there's a speed/duplex mismatch with a link partner... Well. FreeBSD: media: Ethernet autoselect <flowcontrol> (1000baseT <full-duplex,flowcontrol,rxpause,txpause>) On the Linux side - the link partner: negotiated 1000baseT-FD flow-control, link ok > Please don't manually set media types for 1000baseT. It will result in > speed/duplex mismatches and other issues. Probably this is the main reason > why you see RX alignment errors. No, I was seeing those before the idea of forcing a toggle of media types came up. > You should always stick to auto-negotiation with 1000baseT(Flow control can > be set though). Manual media configuration is to workaround buggy link > partners. The only reason I'm doing it now is to force the interface to work again without ifconfig re0 down / ifconfig re0 up, which was breaking connections completely. I really don't want to do it at all. Some connections still break, although rsync can ride it out. > Data sheet for RealTek controller is not publicly available. Linux uses > firmwares for every RealTek controllers. I vaguely guess it may be PHY DSP > fixups but I don't have any detailed information for the firmwares. On the other side I don't load firmware - it wants to but I don't have the firmware available to be loaded: [ 20.347757] r8169 0000:03:00.0: firmware: agent aborted loading rtl_nic/rtl8168f-1.fw (not found?) [ 20.348164] r8169 0000:03:00.0: eth0: unable to load firmware patch rtl_nic/rtl8168f-1.fw (-2) I'd be happy to use the firmware under FreeBSD if that's an option. > Currently re(4) heavily relies on power on default settings since no > detailed register configuration is not available. Some register > configurations made in Windows can survive from warm boot. I'll try after sending this. I haven't cold-booted this system for... months? I don't remember. I run Windows for a game maybe once every week or two at the moment. > When you notice re(4) is locked up, > - does H/W MAC counters still increase? > - does interrupt still get generated for TX/RX? > - could you narrow down which part of MAC(TX or RX) is in stuck > condition? I'm sorry for the excessive hand-holding needed, but I'm not sure how to find this stuff out. Prior to my finding out about 'sysctl dev.re.0.stats=1' last week I was completely at a loss. If you could tell me how to generate this information I'd be absolutely happy to supply it. Can I dig it out of sysctl? There's not a lot there about re0: # sysctl -a | grep '\.re\.' dev.re.%parent: dev.re.0.%desc: RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet dev.re.0.%driver: re dev.re.0.%location: slot=0 function=0 handle=\_SB_.PCI0.PCEA.RLAN dev.re.0.%pnpinfo: vendor=0x10ec device=0x8168 subvendor=0x1043 subdevice=0x8432 class=0x020000 dev.re.0.%parent: pci2 dev.re.0.stats: -1 dev.re.0.wake: 0 Thanks in advance for instructions - I'll collect whatever is needed. I'm going to do a cold boot now, setting no particular options, and see how things go. -- Love is a snowmobile racing across the tundra and then suddenly it flips over, pinning you underneath. At night, the ice weasels come.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141028031454.GQ17150>