Date: Mon, 30 Jul 2007 14:03:54 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Laurens Timmermans <laurens@timkapel.nl> Cc: freebsd-stable@freebsd.org, Michael Nottebrock <lofi@freebsd.org> Subject: Re: Various problems with re(4) on a PCIe 8168/8111B onboard NIC Message-ID: <20070730050354.GB88265@cdnetworks.co.kr> In-Reply-To: <46ACFD01.1030406@timkapel.nl> References: <200707292113.01023.lofi@freebsd.org> <46ACFD01.1030406@timkapel.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
--bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jul 29, 2007 at 10:48:01PM +0200, Laurens Timmermans wrote: > Michael Nottebrock schreef: > >After recently updating the windows drivers (I dual-boot Windows XP on the > >machine the NIC is in), I hit this problem: > >http://gentoo-wiki.com/HARDWARE_RTL8168#Troubleshooting which affects > >re(4) like it does the Linux drivers described in the above link. > > > > I also noticed this and the workaround as explained in the gentoo-wiki > works. > > >I already wrote the Realtek technical support about it since their "own" > >FreeBSD driver (a hacked rl(4) that does not support any of the chip's > >advanced features) does not manage to power up the PHY on its own either - > >neither does the motherboard's BIOS when trying to netboot. > > > > I have done the exact same thing and was surprised to receive a > response. Attached to this response was a beta-version of their (rl) > driver. After a quick test it seemed to have fixed the problem. > I have been trying to fix the issue in re(4) by looking at the changes > in the beta-driver but have not had any success so far (due to lack of > knowledge i guess). > I put the beta driver up here: > http://www.timkapel.nl/~laurens/rtl_bsd_drv_v174beta3.tgz > Thanks for reporting. I don't have these hardware models so I couldn't verify the issue. After reading the vendor's code I've made attached patch. I don't know whether it works or not, it's just guess work. The PHY registers used in the patch are reserved one in my datasheet, so I don't know what it really does on the hardware. Btw, according to vendor's driver it seems that there are newer hardware revisions marked as 8168C and 8168CP. These models seems to need special handling in PHY area. All datasheet I got shows them as reserved ones. :-( > >The other problem is that I have at least two applications misbehaving > >when rxcsum/txcsum is enabled: > > > >- The Linux Second Life client (yes, yes, I know, but it is nice for > >showing off GLX and it is really really good at generating network > >traffic) will cease to receive data after about a minute or so - turning > >off rcxsum/txcsum will mend it on the spot. > > > >- A Fedora Core 4 running in Qemu, networked with bridge(4) and tap(4), > >cannot receive an ip address via DHCP. Interestingly, this even occurs if > >rxcsum/txcsum was already turned off before launching Qemu - to make it > >work, I have to cycle rxcsum/txcsum once. Might be related to promiscuous > >mode. > > > >I realise that both of these make awful test cases, but so far they are > >the only applications I found to expose those problems. > > > >This is on FreeBSD kiste 6.2-STABLE FreeBSD 6.2-STABLE #4: Sat Jul 28 > >14:11:23 CEST 2007 root@:/usr/obj/usr/src/sys/KISTE-SMP i386. The > >kernel sources are up to date as of 2007-07-27. > > > >The NIC is re0: <RealTek 8168/8111B PCIe Gigabit Ethernet> port > >0xd800-0xd8ff mem 0xfbfff000-0xfbffffff irq 36 at device 0.0 on pci3 / > >re0@pci3:0:0: class=0x020000 card=0x81681849 chip=0x816810ec rev=0x01 > >hdr=0x00. > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Regards, Pyun YongHyeon --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="re.power.patch" Index: if_re.c =================================================================== RCS file: /home/ncvs/src/sys/dev/re/if_re.c,v retrieving revision 1.93 diff -u -r1.93 if_re.c --- if_re.c 27 Jul 2007 00:43:12 -0000 1.93 +++ if_re.c 30 Jul 2007 04:43:25 -0000 @@ -180,6 +180,10 @@ "RealTek 8168/8111B PCIe Gigabit Ethernet" }, { RT_VENDORID, RT_DEVICEID_8168, RL_HWREV_8168_SPIN2, "RealTek 8168/8111B PCIe Gigabit Ethernet" }, + { RT_VENDORID, RT_DEVICEID_8168, RL_HWREV_8168_SPIN3, + "RealTek 8168/8111B PCIe Gigabit Ethernet" }, + { RT_VENDORID, RT_DEVICEID_8168, RL_HWREV_8168_SPIN3P, + "RealTek 8168/8111B PCIe Gigabit Ethernet" }, { RT_VENDORID, RT_DEVICEID_8169, RL_HWREV_8169, "RealTek 8169 Gigabit Ethernet" }, { RT_VENDORID, RT_DEVICEID_8169, RL_HWREV_8169S, @@ -221,6 +225,10 @@ { RL_HWREV_8100E, RL_8169, "8100E"}, { RL_HWREV_8101E, RL_8169, "8101E"}, { RL_HWREV_8168_SPIN2, RL_8169, "8168"}, +#ifdef notyet + { RL_HWREV_8168_SPIN3, RL_8169, "8168C"}, + { RL_HWREV_8168_SPIN3P, RL_8169, "8168CP"}, +#endif { 0, 0, NULL } }; @@ -677,13 +685,20 @@ hwrev = CSR_READ_4(sc, RL_TXCFG) & RL_TXCFG_HWREV; - if (hwrev == RL_HWREV_8100E || hwrev == RL_HWREV_8101E || - hwrev == RL_HWREV_8168_SPIN1 || hwrev == RL_HWREV_8168_SPIN2) { + switch (hwrev) { + case RL_HWREV_8100E: + case RL_HWREV_8101E: + case RL_HWREV_8168_SPIN1: + case RL_HWREV_8168_SPIN2: + case RL_HWREV_8168_SPIN3: + case RL_HWREV_8168_SPIN3P: CSR_WRITE_4(sc, RL_MAR0, bswap32(hashes[1])); CSR_WRITE_4(sc, RL_MAR4, bswap32(hashes[0])); - } else { + break; + default: CSR_WRITE_4(sc, RL_MAR0, hashes[0]); CSR_WRITE_4(sc, RL_MAR4, hashes[1]); + break; } } @@ -1246,6 +1261,23 @@ hw_rev++; } + if (hw_rev->rl_desc == NULL) { + device_printf(dev, "unknown H/W revision: %08x\n", hwrev); + error = ENXIO; + goto fail; + } + + if (hwrev == RL_HWREV_8168_SPIN3 || hwrev == RL_HWREV_8168_SPIN3P) { + uint8_t v; + + /* Undocumented, RealTek FreeBSD driver. */ + v = pci_read_config(dev, 0x79, 1); + v &= ~0x70; + v |= 0x50; + pci_write_config(dev, RL_PCI_PWRMGMTCTRL, v, 1); + pci_write_config(dev, 0x80, 0, 1); + } + sc->rl_eewidth = RL_9356_ADDR_LEN; re_read_eeprom(sc, (caddr_t)&re_did, 0, 1); if (re_did != 0x8129) @@ -1300,6 +1332,28 @@ goto fail; } + /* Take PHY out of power down mode. */ + if (sc->rl_type == RL_8169) { + uint32_t rev; + + rev = CSR_READ_4(sc, RL_TXCFG); + /* HWVERID 0, 1 and 2 : bit26-30, bit23 */ + rev &= 0x7c800000; + if (rev != 0) { + /* RTL8169S single chip */ + switch (rev) { + case RL_HWREV_8169_8110SB: + case RL_HWREV_8169_8110SC: + case RL_HWREV_8168_SPIN2: + case RL_HWREV_8168_SPIN3: + case RL_HWREV_8168_SPIN3P: + re_gmii_writereg(dev, 1, 0x1f, 0); + re_gmii_writereg(dev, 1, 0x0e, 0); + break; + } + } + } + ifp->if_softc = sc; if_initname(ifp, device_get_name(dev), device_get_unit(dev)); ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; Index: ../../pci/if_rlreg.h =================================================================== RCS file: /home/ncvs/src/sys/pci/if_rlreg.h,v retrieving revision 1.67 diff -u -r1.67 if_rlreg.h --- ../../pci/if_rlreg.h 24 Jul 2007 01:24:03 -0000 1.67 +++ ../../pci/if_rlreg.h 30 Jul 2007 04:43:25 -0000 @@ -156,6 +156,8 @@ #define RL_HWREV_8100E 0x30800000 #define RL_HWREV_8101E 0x34000000 #define RL_HWREV_8168_SPIN2 0x38000000 +#define RL_HWREV_8168_SPIN3 0x3c000000 +#define RL_HWREV_8168_SPIN3P 0x3c800000 #define RL_HWREV_8139 0x60000000 #define RL_HWREV_8139A 0x70000000 #define RL_HWREV_8139AG 0x70800000 @@ -983,7 +985,7 @@ #define RL_PSTATE_MASK 0x0003 #define RL_PSTATE_D0 0x0000 -#define RL_PSTATE_D1 0x0002 +#define RL_PSTATE_D1 0x0001 #define RL_PSTATE_D2 0x0002 #define RL_PSTATE_D3 0x0003 #define RL_PME_EN 0x0010 --bg08WKrSYDhXBjb5--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070730050354.GB88265>