Date: Sun, 14 Feb 2016 00:09:09 +0100 From: "Stefan Kohl" <freebsd@go4more.de> To: "Marius Strobl" <marius@alchemy.franken.de> Cc: freebsd-current@freebsd.org Subject: Aw: Re: Re: Re: Realtek 8168/8111 if_re not working in current r295091 Message-ID: <trinity-068b82b2-75a4-45f8-84c4-d4c4d4265745-1455404949539@3capp-1and1-bs02> In-Reply-To: <20160213212720.GH15359@alchemy.franken.de> References: <trinity-abb68349-1869-4b8c-801b-254057609ec8-1454529421824@3capp-webde-bap08> <20160204005132.GA1181@michelle.fasterthan.co.kr> <trinity-5e50b480-a0ec-4575-9d20-ee627a61cdbd-1454702642706@3capp-webde-bs04> <20160205212912.GI15359@alchemy.franken.de> <trinity-a49eae45-5e3d-4266-85b3-879e0fa63602-1455394866661@3capp-1and1-bs02>, <20160213212720.GH15359@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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@alchemy.franken.de> > An: "Stefan Kohl" <freebsd@go4more.de> > Cc: pyunyh@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 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 > > _______________________________________________ > 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-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?trinity-068b82b2-75a4-45f8-84c4-d4c4d4265745-1455404949539>