The rtl_bsd_drv from alexdupre

rtl_bsd_drv's Introduction

=================================================================================
=  Realtek 8169S/8169SB/8169SC/8168B/8168C/8168CP/8168D/8168DP/8168E/8168F      =
=  8168FB/8168G/818GU/8168H/8168EP/8411/8168FP                                  =
=  8101E/8102E/8103E/8401/8105E/8106E/8402                                      =
=  8125 Driver                                                                  =
=  for FreeBSD v4.x/5.x/6.x/7.x/8.x/9.x/10.x/11.x/12.x/13.x                     =
=================================================================================

This is the official FreeBSD driver from Realtek Semiconductor corp. with a few
patches to improve stability and performance under high load.

The first issue is the unconditional use of the 9k jumbo clusters regardless of
the configured MTU. After sufficient fragmentation of the physical memory, new
allocations are impossible and the machine hangs in contigmalloc() looping for
rx ring mbuf refill, and other processes get stuck in a lock cascade for the
`re` driver lock. This patched driver adds the `hw.re.max_rx_mbuf_sz` tunable
to decrease the rx mbuf size.

The second issue is that multiple `re` devices share the same task queue for
processing interrupts, and the interrupt handler always sync the device's TX/RX
buffers, regardless of whether the corresponding interrupt bit is set. This
patched driver creates a new task queue per device and checks the set bits.

rtl_bsd_drv's People

Contributors

Stargazers

Watchers

rtl_bsd_drv's Issues

Frequent panics with v1.97

I've noticed some major instability with version 1.97 that rendered my system almost unusable. I added the details to an existing bug that seems to already be filed for this issue.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267704#c10

I'm reporting this again here since this was the link mentioned in the ports Makefile, and given that the kernel panic's are 1.97 specific it seemed appropriate to track things here too.

The most common panic is:

panic: Memory modified after free 0xfffff802d0430800(256) val=deadf5ee @ 0xfffff802d0430808

cpuid = 18
time = 1673024801
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0108c22620
vpanic() at vpanic+0x151/frame 0xfffffe0108c22670
panic() at panic+0x43/frame 0xfffffe0108c226d0
trash_ctor() at trash_ctor+0x49/frame 0xfffffe0108c226e0
item_ctor() at item_ctor+0x108/frame 0xfffffe0108c22730
tcp_default_output() at tcp_default_output+0x127d/frame 0xfffffe0108c22920
tcp_output() at tcp_output+0x34/frame 0xfffffe0108c22940
tcp_do_segment() at tcp_do_segment+0x25e1/frame 0xfffffe0108c22a30
tcp_input_with_port() at tcp_input_with_port+0x114b/frame 0xfffffe0108c22b80
tcp_input() at tcp_input+0xb/frame 0xfffffe0108c22b90
ip_input() at ip_input+0x26c/frame 0xfffffe0108c22bf0
netisr_dispatch_src() at netisr_dispatch_src+0xaf/frame 0xfffffe0108c22c50
ether_demux() at ether_demux+0x162/frame 0xfffffe0108c22c80
ether_nh_input() at ether_nh_input+0x402/frame 0xfffffe0108c22ce0
netisr_dispatch_src() at netisr_dispatch_src+0xaf/frame 0xfffffe0108c22d40
ether_input() at ether_input+0x99/frame 0xfffffe0108c22da0
re_rxeof() at re_rxeof+0x442/frame 0xfffffe0108c22e00
re_int_task_8125() at re_int_task_8125+0x137/frame 0xfffffe0108c22e40
taskqueue_run_locked() at taskqueue_run_locked+0xaa/frame 0xfffffe0108c22ec0
taskqueue_thread_loop() at taskqueue_thread_loop+0xc2/frame 0xfffffe0108c22ef0
fork_exit() at fork_exit+0x80/frame 0xfffffe0108c22f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0108c22f30

As I mentioned in the bug, it seems that there is a use after free issue with a region of memory allocated from UMA.

Version 196.04 works fine on my system.

Recommend Projects