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
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
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@
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
Hi, I'm Luca,
I've some issues using a PCIe Realtek Ethernet board:
re0@pci0:3:0:0: class=0x02 card=0x012310ec chip=0x816810ec rev=0x0c hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
class = network
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
