Hello, i do use the driver version to use my network card fully featured. I use and update FreeBSD 14-STABLE regular and do have seen now that the entire system became responsible quite a few times without leaving a trace. However, i do was now able to obtain that may could be the cause: kernel boot file is /boot/kernel/kernel kernel: syslogd: last message repeated 1 times kernel: Fatal trap 12: page fault while in kernel mode kernel: cpuid = 4; apic id = 04 kernel: fault virtual address = 0x10007 kernel: fault code = supervisor read data, page not present kernel: instruction pointer = 0x20:0xffffffff80c91030 kernel: stack pointer = 0x28:0xffffffff8360ed40 kernel: frame pointer = 0x28:0xffffffff8360ed80 kernel: code segment = base rx0, limit 0xfffff, type 0x1b kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 kernel: processor eflags = interrupt enabled, resume, IOPL = 0 kernel: current process = 0 (re0 taskq) kernel: rdi: fffffe00e160e800 rsi: 000000000000ffff rdx: fffff8042943e800 kernel: rcx: fffffe00e160eb90 r8: 00000000000000a3 r9: ffffffffffffffff kernel: rax: 0000000000000000 rbx: fffff800025ea000 rbp: ffffffff8360ed80 kernel: r10: ffffffff8360e324 r11: ffffffff8360e324 r12: 000000000000ffff kernel: r13: fffff8002be82900 r14: 0000000000000000 r15: 0000000000008803 kernel: trap number = 12 kernel: panic: page fault kernel: cpuid = 4 kernel: time = 1761424575 kernel: KDB: stack backtrace: kernel: #0 0xffffffff80bb3bbd at kdb_backtrace+0x5d kernel: #1 0xffffffff80b65411 at vpanic+0x161 kernel: #2 0xffffffff80b652a3 at panic+0x43 kernel: #3 0xffffffff81059d5a at trap_pfault+0x3da kernel: #4 0xffffffff8102fef8 at calltrap+0x8 kernel: #5 0xffffffff82178f05 at re_rxeof+0x2d5 kernel: #6 0xffffffff82169b5a at re_int_task_8125+0xba kernel: #7 0xffffffff80bc9172 at taskqueue_run_locked+0x182 kernel: #8 0xffffffff80bca3c2 at taskqueue_thread_loop+0xc2
re0@pci0:6:0:0: class=0x020000 rev=0x05 hdr=0x00 vendor=0x10ec device=0x8125 subvendor=0x1043 subdevice=0x87d7 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8125 2.5GbE Controller' class = network subclass = ethernet
Have you tried net/realtek-re-kmod instead of net/realtek-re-kmod198?
There is no development being done on this driver. net/realtek-re-kmod is the package being actively maintained; however, that driver does not successfully support checksum offloading on some (but not all) versions of the driver chip. This package has already been proposed for deprecation once, and my role as maintainer is to verify that it continues to compile and run as FreeBSD moves forward from 14.n to 15.0. But it is still around only to support older versions of the hardware (mine is RTL8111/8168/8211/8411).
To the reporter: have you tried the base system if_re driver? I confess I am unable to help with finding this crash and I suggest trying the other available drivers.
Hi Alexander, Can you pls also try net/realtek-rge-kmod? That's an OpenBSD driver ported to FreeBSD and should land in -HEAD soon. It builds on 14.3 too, I have yet to see feedback running if_rge on 14, but it works for me and others on 15.0
It's in the ports tree now, so I'll try it soon.
I have a running system, with if_rge.ko loaded, but I see no definite indication that the rge driver attached to my interface. I have an re0 device listed in pciconf -lv. The base system kernel driver is known to work for extended periods of time, until it doesn't. How can I tell if the rge driver attached?
(In reply to Bernard Spil from comment #5) I can confirm that it works fine on 15 (stable/15-9636482dd8af) [I have upgraded in the meantime of this post] Thank you for your work. rge0: <RTL8125> port 0x4000-0x40ff mem 0xa1700000-0xa170ffff,0xa1710000-0xa1713fff at device 0.0 on pci6 rge0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM> media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
So if I have a device "re0" and no device "rge0", then I'm using the base system driver? Do I have to build a kernel that doesn't have the base system driver in it to allow testing your new one?
(In reply to George Mitchell from comment #9) reading the earlier comments, you have "RTL8111/8168/8211/8411" (which one is it specifically? check `pciconf -lv` output) The new rge(4) is for the 8125/6/7 chips only, so it won't show rge devices for you.
"RTL8111/8168/8211/8411" is literally what pciconf -lv tells me. dmesg is slightly more specific: "RealTek 8168/8111". As it continues to initialize, it creates miibus0, and then confusingly rgephy0, "RTL8251/8153 1000BASE-T media interface".
More specifically: class=0x020000 rev=0x0c hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x1458 subdevice=0xe000