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_at_ >> 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 automaticallyReceived on Wed Feb 25 2015 - 14:00:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:55 UTC