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
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
On Tue, Feb 17, 2015 at 7:31 PM, O. Hartmann
> Am Tue, 17 Feb 2015 18:32:22 +0100
> Luca Pizzamiglio <luca.pizzamig...@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,
>> On Fri, Feb 13, 2015 at 7:34 PM, Ben Perrault <ben.perra...@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.pizzamig...@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  = type I/O Port, range 32, base 0x1000, size 256, enabled
>> >> bar  = type Memory, range 64, base 0x90500000, size 4096, enabled
>> >> bar  = type Prefetchable Memory, range 64, base 0x90400000,
>> >> size 16384, enabled
>> >> cap 01 = powerspec 3 supports D0 D1 D2 D3 current D0
>> >> cap 05 = MSI supports 1 message, 64 bit
>> >> cap 10 = 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 = AER 1 0 fatal 0 non-fatal 0 corrected
>> >> ecap 0002 = VC 1 max VC0
>> >> ecap 0003 = Serial 1 01000000684ce000
>> >> ecap 0018 = 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
>> >> _______________________________________________
>> >> email@example.com mailing list
>> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>> firstname.lastname@example.org mailing list
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@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
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"