Alexander Nasonov wrote: > The crash happened only once. I'm not sure that running with these > will prove anything. I'll try to take steps to reproduce the crash > again before running with these patches.
Got a different crash in usb_transfer_complete. I was playing with RPI2 powered from USB on my computer and connected my computer over uplcom(4). It likely happened because I unplugged uplcom(4) while minicom was still hanging up. It didn't happen immediately, though. I was able to start X and firefox before the kernel crashed. I also replugged power USB a couple of times but it's a very dumb, I'm not sure if plugging it triggers any code in the kernel. I don't know if this crash is related to the first crash. The first crash happened while I was trying to secure yubikey into the slot. Here's dmesg of the second crash: panic: lock error: Mutex: mutex_vector_enter: locking against myself: lock 0xfffffe81163ee370 cpu 3 lwp 0xfffffe8117053b20 cpu3: Begin traceback... vpanic() at netbsd:vpanic+0x140 snprintf() at netbsd:snprintf lockdebug_abort() at netbsd:lockdebug_abort+0x63 mutex_vector_enter() at netbsd:mutex_vector_enter+0x369 ucomwritecb() at netbsd:ucomwritecb+0x22 usb_transfer_complete() at netbsd:usb_transfer_complete+0x149 xhci_abort_xfer() at netbsd:xhci_abort_xfer+0x15d usbd_ar_pipe() at netbsd:usbd_ar_pipe+0x3b usbd_abort_pipe() at netbsd:usbd_abort_pipe+0x27 ucomclose() at netbsd:ucomclose+0x12c spec_close() at netbsd:spec_close+0x11a VOP_CLOSE() at netbsd:VOP_CLOSE+0x33 vn_close() at netbsd:vn_close+0x36 closef() at netbsd:closef+0x54 fd_close() at netbsd:fd_close+0x1ac sys_close() at netbsd:sys_close+0x20 syscall() at netbsd:syscall+0x15b crash> show lock 0xfffffe81163ee370 doesn't show anything because the kernel isn't compiled with LOCKDEBUG. Alex
