[SOLVED] Re: pcie Realtek 8168G issues (re driver)(minnowboard)

[Luca Pizzamiglio]

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 at 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 at zedat.fu-berlin.de> wrote:
>> Am Tue, 17 Feb 2015 18:32:22 +0100
>> Luca Pizzamiglio <luca.pizzamiglio at 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 at 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 at gmail.com> wrote:
>>> >>
>>> >> Hi, I'm Luca,
>>> >>
>>> >> I've some issues using a PCIe Realtek Ethernet board:
>>> >> re0 at 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 at freebsd.org mailing list
>>> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>>> _______________________________________________
>>> freebsd-current at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe at 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