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" <mar...@alchemy.franken.de> > An: "Stefan Kohl" <free...@go4more.de> > Cc: pyu...@gmail.com, email@example.com > 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@ 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 > > _______________________________________________ > firstname.lastname@example.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" _______________________________________________ email@example.com mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"