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" <marius_at_alchemy.franken.de>
> An: "Stefan Kohl" <freebsd_at_go4more.de>
> Cc: pyunyh_at_gmail.com, freebsd-current_at_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 0x2c800000 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_at_ 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_at_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-unsubscribe_at_freebsd.org"