Date: Wed, 4 Mar 2015 17:22:37 +0100 From: Luca Pizzamiglio <luca.pizzamiglio@gmail.com> To: "O. Hartmann" <ohartman@zedat.fu-berlin.de> Cc: Ben Perrault <ben.perrault@gmail.com>, freebsd-net@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>, "freebsd-hardware@freebsd.org" <freebsd-hardware@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: [SOLVED] Re: pcie Realtek 8168G issues (re driver)(minnowboard) Message-ID: <CAB88xy-3xHuVscJRwpN65rvTqj7AuKNW3D9=c_VmztXM_J_Qwg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi all, I've managed to get the Realtek 8168g running. It's actually a driver bug, the command register enables rx and tx too early. Apparently, it's OK for many Realtek chips, but not for 3 kind of them, as stated by the Realtek developer, who submitted this patch to Linux (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d6e572911a4cb2b9fcd1c26a38d5317a3971f2fd) I updated the Bugzilla entry https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535 The patch (moving one line, sich!) works on this hardware, but I don't know how much portable it is. Thanks for all your tips. Best regards, Luca Pizzamiglio On Wed, Feb 25, 2015 at 3:59 PM, Luca Pizzamiglio <luca.pizzamiglio@gmail.com> wrote: > Hi, > thanks you all for the replies. > > Unfortunately, the network chip is still not working and I updated the > PR (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535) with the > last tests. > It seems that received packets are not transferred to mbuf or they are > transferred, but later, after the mbuf is already freed; moreover, the > ring entries are written without looping, overwriting and messing up > the whole kernel memory. It looks like a DMA issues, but > > Apparently it seems a hardware error, but using a Linux distro, it works :( > > Has someone maybe any other ideas? In the meanwhile I'll get another > board with the same chip :O > > Best regards, > Luca > > > On Tue, Feb 17, 2015 at 7:31 PM, O. Hartmann > <ohartman@zedat.fu-berlin.de> wrote: >> Am Tue, 17 Feb 2015 18:32:22 +0100 >> Luca Pizzamiglio <luca.pizzamiglio@gmail.com> schrieb: >> >>> Hi Ben, >>> thanks for the tip! tso was already disabled. >>> I tried anyway and unfortunately it crashes as before. >>> >>> I filled a bug report >>> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535) and marius@ >>> is giving me a big help on it. >>> >>> Best regards, >>> Luca >>> >>> On Fri, Feb 13, 2015 at 7:34 PM, Ben Perrault <ben.perrault@gmail.com> wrote: >>> > Luca, >>> > >>> > I've had the same issue with this interface on both PCIe boards and embedded in a >>> > handful of Lenovo products. The one, fairly ugly workaround I've found that makes it >>> > work well enough is disable tso ( i.e. ifconfig re0 down && ifconfig re0 -tso && >>> > ifconfig re0 up ). This also seems to stop the panics under current. >>> > >>> > I'm not sure it will work for you - but it has on everyone of those interfaces I've >>> > dealt with. >>> > >>> > Good luck, >>> > -bp >>> > >>> >> On Feb 13, 2015, at 8:06 AM, Luca Pizzamiglio <luca.pizzamiglio@gmail.com> wrote: >>> >> >>> >> Hi, I'm Luca, >>> >> >>> >> I've some issues using a PCIe Realtek Ethernet board: >>> >> re0@pci0:3:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x0c hdr=0x00 >>> >> vendor = 'Realtek Semiconductor Co., Ltd.' >>> >> device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' >>> >> class = network >>> >> subclass = ethernet >>> >> bar [10] = type I/O Port, range 32, base 0x1000, size 256, enabled >>> >> bar [18] = type Memory, range 64, base 0x90500000, size 4096, enabled >>> >> bar [20] = type Prefetchable Memory, range 64, base 0x90400000, >>> >> size 16384, enabled >>> >> cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 >>> >> cap 05[50] = MSI supports 1 message, 64 bit >>> >> cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1) >>> >> speed 2.5(2.5) ASPM disabled(L0s/L1) >>> >> cap 11[b0] = MSI-X supports 4 messages >>> >> Table in map 0x20[0x0], PBA in map 0x20[0x800] >>> >> cap 03[d0] = VPD >>> >> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected >>> >> ecap 0002[140] = VC 1 max VC0 >>> >> ecap 0003[160] = Serial 1 01000000684ce000 >>> >> ecap 0018[170] = LTR 1 >>> >> >>> >> Rx and Tx don't work. After some minutes the interface is activated I >>> >> get kernel panic. >>> >> I've already tried to disable MSIx and MSI. >>> >> It seems a DMA problem, rx fill the 256 descriptors and the nothing >>> >> else until the panic. netstat -s shows now new packets. >>> >> >>> >> I filled a bug report with more infos: >>> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535 >>> >> >>> >> could someone kindly pointing some ideas? >>> >> >>> >> Best regards, >>> >> Luca >>> >> _______________________________________________ >>> >> freebsd-current@freebsd.org mailing list >>> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> In September 2014 I filed allready a bug acoording to strange behaviour with a Lenovo >> ThinkPad E540 with a Realtek chip: >> >> >> Bug 193743 - RTL8111/8168B PCI Express Gigabit Ethernet >> controller: doesn't work properly, problems getting UP automatically
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAB88xy-3xHuVscJRwpN65rvTqj7AuKNW3D9=c_VmztXM_J_Qwg>