[Bug 272117] bnxt: kernel crash with sysctl and jumbo frames
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 272117] bnxt: kernel crash with sysctl and jumbo frames"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 272117] bnxt: kernel crash with sysctl and jumbo frames"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 272117] bnxt: kernel crash with sysctl and jumbo frames"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 272117] bnxt: kernel crash with sysctl and jumbo frames"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 21 Jun 2023 01:21:57 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272117 Bug ID: 272117 Summary: bnxt: kernel crash with sysctl and jumbo frames Product: Base System Version: 13.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: asomers@FreeBSD.org I can reliably crash the kernel just by doing "sysctl dev.bnxt.0" if the interface has been configured with jumbo frames. It seems that the trigger is whether the interface has ever been configured with jumbo frames, not whether it currently uses them. If I boot with jumbo frames, then do "ifconfig lagg0 mtu 1500", I can still trigger the panic. This happens on a custom kernel build based on 13.1-RELEASE. /etc/rc.conf: ifconfig_bnxt0="up" ifconfig_bnxt3="up" cloned_interfaces="lagg0" ifconfig_lagg0="laggproto lacp -lacp_fast_timeout 10.2.172.79/23 laggport bnxt0 laggport bnxt3" vlans_lagg0="173" ifconfig_lagg0_173="10.2.174.79/23" defaultrouter="10.2.172.1" Steps to Reproduce: ================== $ sysctl dev.bnxt.0 ... dev.bnxt.0.iflib.txq00.cpu: 0 <PANIC> Stack trace: ============ Fatal trap 12: page fault while in kernel mode cpuid = 21; apic id = 8a fault virtual address = 0xc00000148 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80d6dffb stack pointer = 0x28:0xfffffe0d24c4ea90 frame pointer = 0x28:0xfffffe0d24c4ebd0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 3220 (sysctl) trap number = 12 panic: page fault cpuid = 21 time = 1687302737 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0d24c4e850 vpanic() at vpanic+0x17f/frame 0xfffffe0d24c4e8a0 panic() at panic+0x43/frame 0xfffffe0d24c4e900 trap_fatal() at trap_fatal+0x385/frame 0xfffffe0d24c4e960 trap_pfault() at trap_pfault+0x4f/frame 0xfffffe0d24c4e9c0 calltrap() at calltrap+0x8/frame 0xfffffe0d24c4e9c0 --- trap 0xc, rip = 0xffffffff80d6dffb, rsp = 0xfffffe0d24c4ea90, rbp = 0xfffffe0d24c4ebd0 --- mp_ndesc_handler() at mp_ndesc_handler+0x7b/frame 0xfffffe0d24c4ebd0 sysctl_root_handler_locked() at sysctl_root_handler_locked+0x90/frame 0xfffffe0d24c4ec20 sysctl_root() at sysctl_root+0x271/frame 0xfffffe0d24c4eca0 userland_sysctl() at userland_sysctl+0x173/frame 0xfffffe0d24c4ed50 sys___sysctl() at sys___sysctl+0x5c/frame 0xfffffe0d24c4ee00 amd64_syscall() at amd64_syscall+0x775/frame 0xfffffe0d24c4ef30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0d24c4ef30 --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8011a11ca, rsp = 0x7fffffffc5a8, rbp = 0x7fffffffc5e0 --- KDB: enter: panic From GDB, it seems that the sysctl that triggers the panic is dev.bnxt.0.iflib.override_nrxds. And in mp_ndesc_handler, the value of ctx->ifc_sctx is 0xc00000000 , which doesn't look right, because it ought to be a pointer. -- You are receiving this mail because: You are the assignee for the bug.