On 10/23/14 16:28, Fabian Keil wrote:
A few days ago a couple of usbconfig processed did not exit:

fk@r500 ~ $sudo procstat -kk $(pgrep usbconfig)
   PID    TID COMM             TDNAME           KSTACK
  1624 100781 usbconfig        -                mi_switch+0xe1 sleepq_wait+0x3a 
_sx_xlock_hard+0x522 _sx_xlock+0x5d usbd_enum_lock+0x3a usb_ref_device+0x157 
usb_open+0xbf devfs_open+0x122 VOP_OPEN_APV+0xa1 vn_open_vnode+0x234 
vn_open_cred+0x351 kern_openat+0x26f amd64_syscall+0x3fb Xfast_syscall+0xfb
  1617 100779 usbconfig        -                mi_switch+0xe1 sleepq_wait+0x3a 
_sx_xlock_hard+0x522 _sx_xlock+0x5d usbd_enum_lock+0x3a usb_ref_device+0x157 
usb_open+0xbf devfs_open+0x122 VOP_OPEN_APV+0xa1 vn_open_vnode+0x234 
vn_open_cred+0x351 kern_openat+0x26f amd64_syscall+0x3fb Xfast_syscall+0xfb
  1615 100777 usbconfig        -                mi_switch+0xe1 sleepq_wait+0x3a 
_sx_xlock_hard+0x522 _sx_xlock+0x5d usbd_enum_lock+0x3a usb_ref_device+0x157 
usb_open+0xbf devfs_open+0x122 VOP_OPEN_APV+0xa1 vn_open_vnode+0x234 
vn_open_cred+0x351 kern_openat+0x26f amd64_syscall+0x3fb Xfast_syscall+0xfb
  1601 100774 usbconfig        -                mi_switch+0xe1 
sleepq_timedwait+0x3a _sleep+0x294 pause_sbt+0xd0 usb_pause_mtx+0x85 
usb_ioctl+0x3e7 devfs_ioctl_f+0x13b kern_ioctl+0x3cd sys_ioctl+0x13c 
amd64_syscall+0x3fb Xfast_syscall+0xfb

kldunload umass.ko lead to a panic, dumping didn't work.

Screenshots are available at:
http://www.fabiankeil.de/bilder/freebsd/kernel-panic-r273434-usb/

I've seen locked-up usbconfig processes in the past,
usually after executing a shell function that does:

| usbconfig_output="$(sudo usbconfig -d ${device} add_quirk UQ_MSC_NO_INQUIRY)"
| [... error handling snipped ]
| usbconfig_output="$(sudo usbconfig -d ${device} reset)"

Sometimes the second command seems to mess up the USB system.

Fabian


Hi,

USB detach is synchronous. If for example umass fails to detach, due to reference counts not reaching zero, that might be the root cause. Try to get a backtrace from the "usb_process()" processes using kgdb, and you'll see right away what is going on.

Thank you!

--HPS
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to