On Mon, Mar 04, 2024 at 10:19:24PM -0500, Alan Stern wrote: > On Tue, Mar 05, 2024 at 12:52:22AM +0100, Marek Marczykowski-Górecki wrote: > > On Mon, Mar 04, 2024 at 11:46:04PM +0100, Marek Marczykowski-Górecki wrote: > > > Terminology: > > > 1. sys-usb - a VM where USB controller (a PCI device) lives; here > > > usbip-host is attached to the device > > > 2. testvm - target VM where usbip is connected; here vhci-hcd is used > > > 3. qvm-usb - tool that connects the above two (equivalent of > > > userspace part of standard usbip) > > > > > > Specific steps: > > > 1. Connect android phone - at this point it's only in sys-usb > > > 2. Switch its mode to file transfer - observe reconnect in sys-usb > > > 3. Use qvm-usb to attach it to the testvm > > > 4. Call jmtpfs -d /mnt in testvm > > > > Or maybe reset or something is involved here too? > > > > After using qvm-usb to attach _and detach_ the device, it stays bound to > > usbip-host driver (that's intentional). But then, even after re-binding > > back to the "usb" driver, jmtpfs called in sys-usb directly fails the > > same way, including failure to reset. > > > > In fact, even without usbip involved at all, jmtpfs directly in sys-usb > > works only once. The second attempt (without either physically reconnecting > > the phone, or changing its more to "no data transfer" and back to "file > > transfer") fails the same way. After terminating the first instance, I > > see just this logged: > > > > [921332.525210] usb 2-1: reset high-speed USB device number 22 using xhci_hcd > > If something doesn't work when usbip isn't involved, you definitely > shouldn't expect it to work when usbip _is_ involved. With usbip, jmtpfs fails the _first_ time, instead of only the _second_ time. This might be related: maybe the attachment of usbip acts like the first attach? -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Attachment:
signature.asc
Description: PGP signature
