Aw: Re: Re: Re: Realtek 8168/8111 if_re not working in current r295091
Hi Marius, thanks for your time and thoughts in this matter! Unfortunately the chip seems to be seriously broken; I applied the suggested patch re.8168evl.diff from yongari to no avail, I am still getting the same connection error. For the time being I can live with my "phoney" workaround as long as I do not encounter any adverse side-effects, but I hope that it can be properly fixed. Regards, Stefan > Gesendet: Samstag, 13. Februar 2016 um 22:27 Uhr > Von: "Marius Strobl" > An: "Stefan Kohl" > Cc: pyu...@gmail.com, freebsd-current@freebsd.org > Betreff: Re: Re: Re: Realtek 8168/8111 if_re not working in current r295091 > On Sat, Feb 13, 2016 at 09:21:06PM +0100, Stefan Kohl wrote: > > Hi Marius, > > > > I finally got my RT 8168 Ethernet Card (Zotac Ri323) working after > > patching if_re.c (r295601). Contrary to the assumption that > > HWREV_8168E_VL with Chip Rev 0x2c80 should not require RTL8168G > > handling as soon as I expand the sc->rl_flags for the respective > > HWREV and define the (ominous) 8168G_Plus Flag for RL_HWREV_8168E_VL > > the card is functioning correctly. > > My best guess currently is that treating HWREV_8168E_VL as RTL8168G > or later chip - which it simply isn't - serves as workaround by e. g. > resetting parts of the RX/TX MAC configuration, that doesn't make it > an appropriate fix, though. I have a WIP which does a more complete > initialization of Realtek Ethernet MACs, part of which is a workaround > for broken BIOSes and is specific to HWREV_8168E_VL. I suspect that's > the more likely cause for your problem and would also explain why there > was no other such report so far. Currently, 10.3-RELEASE and its show- > stoppers have higher priority for me, though. > > > When broken (without the patch) I got the following tcpdump output: > > > > 19:18:46.299360 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 > > (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], > > length 84 > > Actually, this pretty much confirms the assumption that your problem > is caused by a broken BIOS as the correct workaround for that bug > consists of making the GMAC aware of the MAC address via the driver > in addition to only setting it in the MAC. > Err, wait, IIRC yongari@ had a similar change as far as the broken > BIOS workaround is concerned. You may want to give the following > patch a try instead of treating HWREV_8168E_VL as RTL8168G+ (I don't > know whether that patch applies cleanly to current re(4), though): > https://people.freebsd.org/~yongari/re/re.8168evl.diff > > Marius > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current[https://lists.freebsd.org/mailman/listinfo/freebsd-current] > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Re: Re: Realtek 8168/8111 if_re not working in current r295091
On Sat, Feb 13, 2016 at 09:21:06PM +0100, Stefan Kohl wrote: > Hi Marius, > > I finally got my RT 8168 Ethernet Card (Zotac Ri323) working after > patching if_re.c (r295601). Contrary to the assumption that > HWREV_8168E_VL with Chip Rev 0x2c80 should not require RTL8168G > handling as soon as I expand the sc->rl_flags for the respective > HWREV and define the (ominous) 8168G_Plus Flag for RL_HWREV_8168E_VL > the card is functioning correctly. My best guess currently is that treating HWREV_8168E_VL as RTL8168G or later chip - which it simply isn't - serves as workaround by e. g. resetting parts of the RX/TX MAC configuration, that doesn't make it an appropriate fix, though. I have a WIP which does a more complete initialization of Realtek Ethernet MACs, part of which is a workaround for broken BIOSes and is specific to HWREV_8168E_VL. I suspect that's the more likely cause for your problem and would also explain why there was no other such report so far. Currently, 10.3-RELEASE and its show- stoppers have higher priority for me, though. > When broken (without the patch) I got the following tcpdump output: > > 19:18:46.299360 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 > (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], > length 84 Actually, this pretty much confirms the assumption that your problem is caused by a broken BIOS as the correct workaround for that bug consists of making the GMAC aware of the MAC address via the driver in addition to only setting it in the MAC. Err, wait, IIRC yongari@ had a similar change as far as the broken BIOS workaround is concerned. You may want to give the following patch a try instead of treating HWREV_8168E_VL as RTL8168G+ (I don't know whether that patch applies cleanly to current re(4), though): https://people.freebsd.org/~yongari/re/re.8168evl.diff Marius ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Aw: Re: Re: Realtek 8168/8111 if_re not working in current r295091
Hi Marius, I finally got my RT 8168 Ethernet Card (Zotac Ri323) working after patching if_re.c (r295601). Contrary to the assumption that HWREV_8168E_VL with Chip Rev 0x2c80 should not require RTL8168G handling as soon as I expand the sc->rl_flags for the respective HWREV and define the (ominous) 8168G_Plus Flag for RL_HWREV_8168E_VL the card is functioning correctly. /usr/src/sys/dev/re # svn diff if_re.c Index: if_re.c === --- if_re.c (revision 295601) +++ if_re.c (working copy) @@ -1473,6 +1473,8 @@ RL_FLAG_WOL_MANLINK; break; case RL_HWREV_8168E_VL: + sc->rl_flags |= RL_FLAG_8168G_PLUS; + /* FALLTHROUGH */ case RL_HWREV_8168F: sc->rl_flags |= RL_FLAG_EARLYOFF; /* FALLTHROUGH */ My system: FreeBSD kartal.net.hayat 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r295601: Sat Feb 13 19:11:05 CET 2016 r...@kartal.net.hayat:/usr/obj/usr/src/sys/KARTAL amd64 When broken (without the patch) I got the following tcpdump output: 19:18:46.299360 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 84 Regards, Stefan Gesendet: Freitag, 05. Februar 2016 um 22:29 Uhr Von: "Marius Strobl" An: s@web.de Cc: pyu...@gmail.com, freebsd-current@freebsd.org Betreff: Re: Re: Realtek 8168/8111 if_re not working in current r295091 On Fri, Feb 05, 2016 at 09:04:02PM +0100, s@web.de wrote: > Hi Marius and Pyun, > > actually it is Chip rev. 0x2c80 (I have overlooked that information in my > first post) > > re0: port > 0xe000-0xe0ff mem 0xf0104000-0xf0104fff,0xf010-0xf0103fff irq 19 at > device 0.0 on pci2 > re0: Using 1 MSI-X message > re0: turning off MSI enable bit. > re0: Chip rev. 0x2c80 > re0: MAC rev. 0x0010 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > > Does that help in any way? Thanks Stefan > Unfortunately, it doesn't make a whole lot of sense to me; 0x2c80 translates to RL_HWREV_8168E_VL, which is an older chip that should never have required the handling of RTL8168G and later revisions (or may not actually work when applying it). So r290566 should only make a positive difference, if it changes anyting for that revision all. Did the interface work before r290151, or actually before r281337? Does reverting r290946 and r290566 locally make it work again? Another candidate causing that breakage would be r291676 if the PHY is an RTL8211F one. If you boot verbosely, you'll have a line in the dmesg(8) output with "OUI 0x00e04c" in it. If the "rev." number in that line is 6, you have an RTL8211F. Marius ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
