On Sat, Oct 15, 2022 at 9:33 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Sat, Oct 15, 2022 at 08:36:19PM -0400, Peter Geis wrote: > > On Wed, Oct 12, 2022 at 5:14 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > There's one other thing you might try, although I'm not sure that it > > > will provide any useful new information. Instead of collecting a > > > usbmon trace, collect a usbfs snoop log. Before starting qemu, do: > > > > > > echo 1 >/sys/module/usbcore/parameters/usbfs_snoop > > > > > > This will cause the accesses performed via usbfs, including those > > > performed by the qemu process, to be printed in the kernel log. (Not > > > all of the accesses, but the more important ones.) Let's see what shows > > > up. > > > > So I built and tested the newest version of QEMU, and it exhibits the > > same issue. I've also captured the log as requested and attached it > > here. > > Here's what appears to be the relevant parts of the log. > > > [93190.933026] usb 3-6.2: opened by process 149607: rpc-libvirtd > > [93191.006429] usb 3-6.2: opened by process 149605: qemu-system-x86 > > The device is opened by proces 194605, which is probably the main qemu > process (or the main one in charge of USB I/O). I assume this is the > process which goes ahead with initialization and enumeration, because > there are no indications of other processes opening the device. > > > [93195.712484] usb 3-6.2: usbdev_do_ioctl: RESET > > [93195.892482] usb 3-6.2: reset full-speed USB device number 70 using xhci_hcd > > [93196.095050] cdc_acm 3-6.2:1.0: ttyACM0: USB ACM device > > As part of initialization, qemu resets the device and its interfaces > then get claimed by the cdc_acm driver on the host. This may be the > problem; there's no indication in the log that cdc_acm ever releases > those interfaces. > > > [93196.482584] usb 3-6.2: usbdev_do_ioctl: SUBMITURB > > [93196.482589] usb 3-6.2: usbfs: process 149617 (CPU 3/KVM) did not claim interface 0 before use > > [93209.729484] usb 3-6.2: usbdev_do_ioctl: SUBMITURB > > [93209.729489] usb 3-6.2: usbfs: process 149616 (CPU 2/KVM) did not claim interface 0 before use > > [93209.729574] usb 3-6.2: usbdev_do_ioctl: CLEAR_HALT > > [93209.729577] usb 3-6.2: usbfs: process 149617 (CPU 3/KVM) did not claim interface 1 before use > > [93209.729632] usb 3-6.2: usbdev_do_ioctl: SUBMITURB > > [93209.729635] usb 3-6.2: usbfs: process 149614 (CPU 0/KVM) did not claim interface 0 before use > > Unforunately these warning messages don't indicate directly whether > the attempts to use the interfaces were successful. But it's clear > that something went wrong with those URB submissions because the snoop > log doesn't include the contents of the URBs or their results. > > My guess is that the attempts failed because the interfaces were > already claimed by cdc_acm in the host. I would expect qemu to unbind > cdc_acm when it starts up, but apparently it doesn't. And there are > no CLAIM_PORT messages in the log. > > Perhaps it will help if you do the unbind by hand before starting > qemu. Try doing: > > echo 3-6.2:1.0 >/sys/bus/usb/drivers/cdc_acm/unbind > echo 3-6.2:1.1 >/sys/bus/usb/drivers/cdc_acm/unbind > > Or better yet, blacklist the cdc_acm driver on the host if you can. Good Afternoon, Thanks, blacklisting cdc_acm stopped usbfs from failing to claim it again. Unfortunately I ran into another issue, where KVM/QEMU doesn't claim the USB device again after the device resets. I've encountered this before with other devices and there doesn't seem to be a way to resolve it yet. It seems that my issue with this device was a different manifestation of the same problem, and there currently isn't a fix for that. Thank you for your assistance. Very Respectfully, Peter > > Alan Stern
