Yes. usb is hanky in its newbus integration and always has been.

How did you get this to happen? I know that it can happen in some weird
error scenarios (that I've not been able to reproduce), but just removing the
device is orderly enough...

But it looks like jhb's cleanup may have opened the issue back up, since
usb_detatch_device shouldn't find anything still attached. I'm guessing that
there are devices that are children of this node that are attached and also
somehow devices of the interface?

So interesting crash, but without a lot more data about the usb configuration
and what device is being detached, I can't help you.

Warner

On Sat, May 10, 2025 at 1:36 PM Bjoern A. Zeeb
<bzeeb-li...@lists.zabbadoz.net> wrote:
>
> Hi,
>
> hit this twice when switching an XHCI from ppt0 back to xhci (or vice
> versa ?) on a previous kernel (sorry I hit 4 other panics and I don't
> have more details anymore).  That kernel may have been 3-4 weeks old,
> so may be fixed by now?
>
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 0; apic id = 00
> instruction pointer     = 0x20:0xffffffff80b8d519
> stack pointer           = 0x28:0xfffffe01047d4c80
> frame pointer           = 0x28:0xfffffe01047d4dc0
> 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         = 15 (usbus0)
> rdi: fffffe01047d4c88 rsi: ffffffff80ba9460 rdx: fffffe01047d4d18
> rcx: 0000000000200000  r8: 0000000000000001  r9: 8080808080808080
> rax: 7373616c63627573 rbx: ffffffff81231211 rbp: fffffe01047d4dc0
> r10: fffff8000159d110 r11: ffffcfd1ced1cfd0 r12: fffff80001595580
> r13: 0000000000000000 r14: fffff8000158e700 r15: fffffe01047d4c88
> trap number             = 9
> panic: general protection fault
> cpuid = 0
> time = 1746609904
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01047d4a00
> vpanic() at vpanic+0x136/frame 0xfffffe01047d4b30
> panic() at panic+0x43/frame 0xfffffe01047d4b90
> trap_fatal() at trap_fatal+0x68/frame 0xfffffe01047d4bb0
> calltrap() at calltrap+0x8/frame 0xfffffe01047d4bb0
> --- trap 0x9, rip = 0xffffffff80b8d519, rsp = 0xfffffe01047d4c80, rbp = 
> 0xfffffe01047d4dc0 ---
> device_printf() at device_printf+0x89/frame 0xfffffe01047d4dc0
> usb_detach_device() at usb_detach_device+0xd3/frame 0xfffffe01047d4e00
> usb_unconfigure() at usb_unconfigure+0x83/frame 0xfffffe01047d4e40
> usb_free_device() at usb_free_device+0x15c/frame 0xfffffe01047d4e80
> usb_bus_detach() at usb_bus_detach+0x6e/frame 0xfffffe01047d4eb0
> usb_process() at usb_process+0xc5/frame 0xfffffe01047d4ef0
> fork_exit() at fork_exit+0x7b/frame 0xfffffe01047d4f30
> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe01047d4f30
> --- trap 0x3a8d224b, rip = 0x91722c9d5743a0fe, rsp = 0xc95674b90f67f8da, rbp 
> = 0x84eb42daceb9d67e ---
> KDB: enter: panic
>
>
> --
> Bjoern A. Zeeb                                                     r15:7
>

Reply via email to