Bug 249966
| Summary: | USB config SX lock | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Bjoern A. Zeeb <bz> |
| Component: | usb | Assignee: | freebsd-usb (Nobody) <usb> |
| Status: | New --- | ||
| Severity: | Affects Only Me | CC: | darius, dinoex, emaste, hselasky, imp |
| Priority: | --- | ||
| Version: | CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Bjoern A. Zeeb
2020-09-28 22:28:28 UTC
I don't suppose you ever got to the bottom of this? I see a similar thing with a USB HD. This may be related to missing support for so-called USB4. The output from: procstat -akk | grep -i usb May be helpful. If this is a USB disk, then it may also be a refcount leak in the CAM layer in FreeBSD. Yes looks like CAM is stuck: [cain 18:48] >sudo procstat -akk | grep -i usb 15 100468 usb usbus0 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100469 usb usbus0 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100470 usb usbus0 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100471 usb usbus0 mi_switch+0xc2 _sleep+0x1fc cam_sim_free+0x80 umass_detach+0x13a device_detach+0x175 device_delete_child+0x15 usb_detach_device+0x16f usb_unconfigure+0x2b usb_free_device+0x11d uhub_detach+0x9b device_detach+0x175 device_delete_child+0x15 usb_detach_device+0x16f usb_unconfigure+0x2b usbd_set_config_index+0x53 usb_bus_suspend+0xa5 usb_bus_reset+0x4d usb_process+0x100 15 100472 usb usbus0 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100474 usb usbus1 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100475 usb usbus1 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100476 usb usbus1 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100477 usb usbus1 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100478 usb usbus1 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100480 usb usbus2 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100481 usb usbus2 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100482 usb usbus2 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100483 usb usbus2 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100484 usb usbus2 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100488 usb usbus3 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100489 usb usbus3 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100490 usb usbus3 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100491 usb usbus3 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 100492 usb usbus3 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe 15 102528 usb urndis0 mi_switch+0xc2 _cv_wait+0x113 usb_process+0xc1 fork_exit+0x7e fork_trampoline+0xe Adding Warner: Looks like there are still issues with CAM refcounts. Daniel: What does "uname -a" say? --HPS uname -a: FreeBSD cain.gsoft.com.au 13.1-RELEASE-p6 FreeBSD 13.1-RELEASE-p6 GENERIC amd64 Can you try a 13-stable kernel? Is this reproducible? --HPS (In reply to Hans Petter Selasky from comment #4) > Looks like there are still issues with CAM refcounts. Not as far as I know. I've not seen any ref count leaks in CAM in a long time that weren't related to "stuttering" devices that came and went many times quickly over the course of a few seconds. So this is Though sleeping in cam_free_sim() suggests that somebody hasn't kept proper book somewhere... Or that somehow we've missed a wakeup on the sim from cam_sim_release... If this is reproducible, I have some basic debugging tools that we can use with kgdb to look at the state of CAM to see if this problem is caught by one of the checks I have. I don't have exact steps to reproduce it but it happens pretty reliably so I can try any debugging suggestions you have. |