speed mismatch trying to attach usb device to guest vm

Bug #1815588 reported by Eero Aaltonen
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
New
Undecided
Unassigned
linux (Ubuntu)
Incomplete
Undecided
Unassigned

Bug Description

Distro: 18.04.02, just recently upgraded from 16.04
MachineType: LENOVO 20J7S02N00

All of the machines USB ports are USB 3.0

I added the USB drive from virt-managers UI. Trying to start the guest vm results in:

Error starting domain: internal error: process exited while connecting to monitor: 2019-02-12T11:12:16.334471Z qemu-system-x86_64: -device usb-host,hostbus=2,hostaddr=2,id=hostdev0,bus=usb.0,port=1: Warning: speed mismatch trying to attach usb device "Porsche Desktop" (super speed) to bus "usb.0", port "1" (full+high speed)
2019-02-12T11:12:16.485645Z qemu-system-x86_64: -device usb-host,hostbus=2,hostaddr=2,id=hostdev0,bus=usb.0,port=1: failed to open host usb device 2:2

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 125, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 82, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1508, in startup
    self._backend.create()
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 1062, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error: process exited while connecting to monitor: 2019-02-12T11:12:16.334471Z qemu-system-x86_64: -device usb-host,hostbus=2,hostaddr=2,id=hostdev0,bus=usb.0,port=1: Warning: speed mismatch trying to attach usb device "Porsche Desktop" (super speed) to bus "usb.0", port "1" (full+high speed)
2019-02-12T11:12:16.485645Z qemu-system-x86_64: -device usb-host,hostbus=2,hostaddr=2,id=hostdev0,bus=usb.0,port=1: failed to open host usb device 2:2

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Eero sorry that you are still affected by issues on your usb passthrough.
But I read that at least the upgrade got you further for bug 1814061.

For the error I see here I at least have an idea what it could be.
I need to grab some HW from my basement after lunch for a test - stay tuned ... :-)

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Thanks for upgrading to 18.04 now I can use my system as is for the same tests.

At least the warning is about a USB 3 device being attached to a slower (virtual) USB hub.
The default virt-manager/libvirt usb controller is piix3-uhci which is USB 2.0
The controller type can be changed thou, but one step at a time

I fetched my USB 3.0 thumbdrive and will do the same pass-through you are struggling with.

With the default uhci controller in the host and passing through the USB 3 drive it works immediately (it is attached). But I get some complains later on about usb resets.
  usb 2-1: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd

The guest shows "normal" "usb 1-1: New USB device found" ...
And finds the device.

Next I tried a USB 2.0 thumbdrive.
That works as well - even without the bus reset warnings.

Lets switch the USB controller type if it gets even better for the USB 3.0 thumbdrive.
(Needs shutdown/start of the guest after changing to USB 3 in the virt-manager UI)
BTW what virt-manager calls "USB 3" is in libvirt really "nec-xhci" and I see a USB 3.0 root hub in my guest.

Note - I found that the reset message on the host seem to be normal and ok, it targets all "siblings" on the same bus tier as the device that was just removed from the host.

Attaching USB 2 device - works and appears in the guest
Attaching USB 3 device - works and is "slotted" into the USB 3.0 port

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

For your comparison here a screenshot with the devices passed through.

I did -not- hit the issues you had which is good for me but bad for helping you.
I'd think that you can avoid:
  Warning: speed mismatch trying to attach usb device "Porsche Desktop" (super speed) to bus "usb.0", port "1" (full+high speed)
By setting the USB controller to a USB 3.0 type.

But I wonder why you still get issues accessing the device at all.
qemu-system-x86_64: -device usb-host,hostbus=2,hostaddr=2,id=hostdev0,bus=usb.0,port=1: failed to open host usb device

My guest log shows nothing like that :-/
But give the USB 3 controller a try on your side, it will help a bit even though I can't promise how much.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hmm, I had one more idea.
I used hot plug all the time (adding the device in virt-manager while the guest is up), I know that some security handling for apparmor and DAC are different between hotplug and starting with it.

Let me try to start with the device attached (but using USB 3 controller) ...
Sorry, still just works for me - was worth a try :-/

I know we have gathered a lot of logs in the former bug, but we are now on 18.04 so lets give it another chance.

Please:
- enable libvirt debugging as instructed before
- start your guest with a USB 3.0 controller but without the USB storage drive passed through
- set your host to watch "dmesg -w"
- start a "tail -f" on the libvirtd log
- now attach the USB device in virt-manager
- add a few newlines to both logs
- then detach the USB device in virt-manager

Does this work?
If not please provide both logs (copy and paste from the two consoles) along with a "virsh dumpxml <guestname>" - maybe with the combination of those three we can find what is different.

Other recommendations:
- IIRC this is a windows guest, for the sake of trying how about an Ubuntu guest?
- Any non "Fast USB 3 storage" devices around - how about passing through a secondary mouse or something like that - does that work?

Changed in libvirt (Ubuntu):
status: New → Incomplete
Revision history for this message
Eero Aaltonen (ejn) wrote :

I tested with a USB 3.0 thumb drive and adding that works to the guest works perfectly.

Here's a shortened lsusb:
Bus 002 Device 002: ID 0951:1666 Kingston Technology DataTraveler G4
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 007: ID 059f:106e LaCie, Ltd Porsche Design Desktop Drive
.
.
.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

So the Kingston in the USB 3 HUB works, but trying to add the older USB 2 drive to the guest fails.

The laptop is new, and has only USB 3.0 ports as far as I can tell.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Thanks for your feedback Eero,
I have tested USB 2/3 drives on USB 2/3 hubs now - it is not that in in general a combo of these would fail.

Lets continue to brainstorm what could be the issue ...
I hear from you that your Failing Device is the "Porsche Design Desktop Drive" and that you say is USB 2.0 in comment #6.
But your error thinks it is USB 3.0, maybe there is an issue around that being correctly detected?:
  Warning: speed mismatch trying to attach usb device "Porsche Desktop" (super speed) to bus "usb.0", port "1" (full+high speed)

Super Speed = USB 3

What does "sudo lsusb -v -d 059f:106e" on the host show?
Does the host detect it as USB 2 or 3?

---

Further we might want/need to focus on the actual error being "failed to open host usb device 2:2", but you said there are no apparmor Denies anymore. So why is it failing then?
Not recommended in general, but for a try you might set the user your guests are executed at to root to check if this might be a "normal" ownership/permission issue of some of your device nodes vs the libvirt-qemu user that you have. See configs user/group in /etc/libvirt/qemu.conf
I'd never keep it that way, but it is sometimes the easiest way to check for permission issues.

Furthermore you might check the group memberships of libvirt-qemu:
 $ id libvirt-qemu

---

Finally I really want to know which access exactly is failing.
After the guest is up (without the USB device yet).
Set up an strace to the open calls like:
  $ sudo strace -e 'trace=/.*open.*' -p <PID-of-qmeu>
Then in the UI hit the "attach USB" and report what was traced

And just to be sure - check dmesg once more if there really is not Denial.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for libvirt (Ubuntu) because there has been no activity for 60 days.]

Changed in libvirt (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Eero Aaltonen (ejn) wrote :
Download full text (4.1 KiB)

I think I was wrong about the USB speed. I can't find a specific model number, but the Manufacturer seems to state USB 3.0 for all the drives I looked at. The host also identifies it as USB 3.0.

1. Redirecting USB while guest is running
=========================================
I tested of redirecting the USB drive from_
"Virtual Machine" → "Redirect USB device". Here's logs from journalctl

Oct 25 13:24:26 hostname kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
Oct 25 13:24:26 hostname udisksd[1183]: Cleaning up mount point /media/eja/2TB-1Partition (device 8:2 no longer exists)
Oct 25 13:24:26 hostname ntfs-3g[18245]: Unmounting /dev/sda2 (2TB-1Partition)
Oct 25 13:24:26 hostname ntfs-3g[18245]: Failed to sync device /dev/sda2: Input/output error
Oct 25 13:24:26 hostname kernel: print_req_error: I/O error, dev sda, sector 0
Oct 25 13:24:26 hostname ntfs-3g[18245]: Failed to close volume /dev/sda2: Input/output error
Oct 25 13:24:26 hostname kernel: sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Oct 25 13:24:26 hostname upowerd[1473]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.2/2-4.2:1.0
Oct 25 13:24:26 hostname kernel: usb 2-4.2: reset SuperSpeed USB device number 4 using xhci_hcd
Oct 25 13:24:26 hostname upowerd[1473]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.2/2-4.2:1.0
Oct 25 13:24:26 hostname upowerd[1473]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.2/2-4.2:1.0
Oct 25 13:24:26 hostname upowerd[1473]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.2/2-4.2:1.0
Oct 25 13:24:27 hostname upowerd[1473]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.2/2-4.2:1.0

Reading that, I get the impression of a logical error occurring.
1. USB device disappears
2. IO error because the drive is no longer there
3. Reset of the USB device because of the error.

lsbusb --tree gives following output for the drive

/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 5000M
    |__ Port 4: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usbfs, 5000M

2. Attaching USB after guest shutdown and restart
=================================================
After this I get the same traceback as in the original description.

dmesg -h however does hint of missing privileges

[14447.800647] device vnet0 entered promiscuous mode
[14447.800796] br0: port 2(vnet0) entered blocking state
[14447.800797] br0: port 2(vnet0) entered forwarding state
[14447.800847] audit: type=1400 audit(1572001070.392:1304): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/sys/devices/virtual/net/br0/type" pid=1196 comm="sssd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[14447.800986] audit: type=1400 audit(1572001070.392:1305): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/sys/devices/virtual/net/vnet0/type" pid=1196 comm="sssd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[14447.801034] audit: type=1400 audit(1572001070.392:1306): apparmor="ALLOWED" operat...

Read more...

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Interesting ordering in #1.
It seems the "Failed to sync" lets an I/O hang which is then later reported failed.
But you could unmount & unbind the device cleanly on the host before you hot-add it to the guest.
Then for case #1 none of the errors should appear I'd hope.
Do you want to give that a try Erro?

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Oh my bad, Erro should clearly have been Eero but failed to match the right character count.

Revision history for this message
Eero Aaltonen (ejn) wrote :

I could swear I already tested this for 1. Redirecting USB while guest is running), but this time it worked. Thanks for the suggestion @paelzer

I unmounted both partitions and then redirected. Here's the journalctl output:

Oct 28 15:24:38 hostname udisksd[1229]: Cleaning up mount point /media/user/2TB-1Partition (device 8:2 is not mounted)
Oct 28 15:24:38 hostname ntfs-3g[31458]: Unmounting /dev/sda2 (2TB-1Partition)
Oct 28 15:24:38 hostname udisksd[1229]: Unmounted /dev/sda2 on behalf of uid 1000
Oct 28 15:24:43 hostname udisksd[1229]: Cleaning up mount point /media/user/LACIE SETUP (device 8:1 is not mounted)
Oct 28 15:24:43 hostname systemd[1]: Stopping Clean the /media/user/LACIE SETUP mount point...
Oct 28 15:24:43 hostname systemd[1]: Stopped Clean the /media/user/LACIE SETUP mount point.
Oct 28 15:24:43 hostname udisksd[1229]: Unmounted /dev/sda1 on behalf of uid 1000
Oct 28 15:25:03 hostname kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
Oct 28 15:25:03 hostname kernel: sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Oct 28 15:25:03 hostname upowerd[1520]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.4/1-3.4.2/1-3.4.2:1.0
Oct 28 15:25:03 hostname kernel: usb 1-3.4.2: reset high-speed USB device number 11 using xhci_hcd
Oct 28 15:25:03 hostname upowerd[1520]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.4/1-3.4.2/1-3.4.2:1.0
Oct 28 15:25:03 hostname upowerd[1520]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.4/1-3.4.2/1-3.4.2:1.0
Oct 28 15:25:03 hostname upowerd[1520]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.4/1-3.4.2/1-3.4.2:1.0

If this is repeatable, then it solves my immediate problem. Perhaps they can also identify some usability improvement in the SW stack in the future.

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Just a reminder that this bug has expired. If anyone still thinks there is an issue, then please reopen it.

Revision history for this message
David Mortals (davidmortals) wrote :

This issue still exist in Ubuntu 20.02 5.4.0-18-generic (28 Mar 2020).

For the one who still struggling this is a workaround works for me.

My UAS USB3 external storage: Bus 002 Device 003: ID 152d:0583 JMicron Technology Corp. / JMicron USA Technology Corp. JEYI External

The warning message in dmesg:
[ 5895.913004] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)

if this usb is passed to qemu/kvm vm, dmesg will shows and the vm hangs(can not boot):
[ 6971.972846] sd 1:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK

Disable the UAS for this device will fix this, and also you lost the TRIM/DISCARD ability for this device.

sudo modprobe -rv uas;sleep 1;sudo modprobe -v usb-storage quirks=357d:7788:u,152d:0583:u;sudo modprobe -v uas

source: https://unix.stackexchange.com/questions/239782/connection-problem-with-usb3-external-storage-on-linux-uas-driver-problem

Changed in libvirt (Ubuntu):
status: Expired → New
Revision history for this message
Bryce Harrington (bryce) wrote :

Thanks for reopening so it can be looked at again, I've subscribed canonical-server to do so.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Thanks David, so it might be issues with special HW types.
I'm glad you identified quirks to loas uas with to mitigate the issue - this might help others being affected.

But until I have a local reproducer to debug in-depth I'm not sure I can do more on the libvirt side (and even then no promises if it ends up to be very HW/FW specific).

I'll add a kernel tasks just in case this might be known over there from the USB storage POV.

tags: added: bot-stop-nagginf
tags: added: bot-stop-nagging
removed: bot-stop-nagginf
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1815588

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.