On Tue, Oct 11, 2022 at 02:49:09PM -0400, Peter Geis wrote: > On Mon, Oct 10, 2022 at 11:01 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > The bug is the device is unusable in passthrough, this is the only > > > direction as to why. The question is which piece of software is > > > causing it. I figure qemu is the most likely suspect, but they request > > > bugs that are possibly in kvm start here. The cdc-acm driver is the > > > least likely in my mind, as the other device that works also uses it. > > > I just tested removing the other working device and only passing > > > through the suspect device, and it still triggers the bug. So whatever > > > the problem is, it's specific to this one device. > > > > Does anything of interest about the device show up in the virtual > > machine's kernel log? > > Nothing in regards to this no. The device enumerates, but any attempt > to access it triggers the warning on the host only. That's odd. I don't see anything in the usbmon trace corresponding to the warning messages about interface 1. In fact, I don't see anything at all in the trace relating to interface 1. > > You can collect a usbmon trace on the host system to gather more > > information about what the virtual machine is trying to do. Your > > previous post shows that the device is on bus 3, so before starting > > qemu-kvm you would do: > > > > cat /sys/kernel/debug/usb/usbmon/3u >mon.txt > > > > in a separate window. Kill the cat process when the test is over and > > post the output file. > > > > It'll help if you unplug the working device (and in fact as many devices > > on bus 3 as is practical) before running the test, so that the trace > > includes only traffic to the non-working device. > > > > For comparison, you could also acquire a usbmon trace of what happens > > when you try using the device on a real, non-virtual machine. For this > > test you would start the trace before plugging in the device. > > I've attached the requested file, but I have no idea how to read this. > The file consists of the host when the device is plugged in until > enumeration, left to idle for a few moments, then the guest is started > and permitted to claim it. Actually the device was plugged in and enumerated, and then about four seconds later it spontaneously disconnected for a moment. It was enumerated again, and about three minutes after that it looks like the virtual guest started up. The guest reset the device and enumerated it, but did nothing more. In particular, the guest did not try to install configuration 1, which is odd. Or if it did try this, the attempt wasn't visible in the usbmon trace. I'm inclined to agree that the fault appears to lie in qemu-kvm. > No other device is on the bus. In fact one other device was. It identified itself with the strings "PbAcid" and "CPS", but I can't tell more than that. A UPS device, perhaps? 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. Alan Stern
