[KNOWN ISSUES] USB device passthrough

UPDATE:  I think that the issue with USB devices randomly changing device IDs has been solved.  See this post below:  http://lime-technology.com/forum/index.php?topic=36508.msg339344#msg339344

Two issues still exist:

1.  If a domain is restarted (rather than stop/start), the XML retains the original BUS/DEVICE ID that was injected originally into the XML, but, the USB device is assigned a new DEVICE ID by the host or KVM (not sure which).  If you experience this issue, I believe a suitable workaround is to always stop/start your domains rather than restart.  This should remove the injected address and capture the new one upon start.  BTW...this entire issue very well maybe HW specific as not a lot of people are seeing this.  In fact, I may be the only one but find that hard to believe. 

2.  Passing through more than one USB device with the same VENDOR and PRODUCTS IDs (i.e. 2 flircs in my case) will cause the VM to not start if you identify that device by VENDOR/PRODUCT ID in your XML.  I have not yet found a workaround for this yet since if you hardcode the BUS/DEVICE ID in the XML, a restart or stop/start of the VM will render it useless since the device will obtain a new ID.

-------------------------------------------------------------------

I know that this is a known issue but I wanted to create a thread to discuss and track as this information is scattered.

From the little that I know, some systems have a nasty habit of randomly changing USB device IDs.  I'm not sure if this is a general linux issue, a linux/KVM issue, specific to certain HW and/or BIOS setings or something completely different.

Here is an example of what you would see in the unRAID syslog:

Nov 30 07:49:57 unRAID kernel: usb 8-1: USB disconnect, device number 2
Nov 30 07:49:57 unRAID kernel: usb 8-1: new full-speed USB device number 3 using uhci_hcd

In this particular instance, this is my MCE remote transceiver that is being passed through to an XBMCBuntu VM.  When this happens, the remote becomes inoperable and I have to reboot the VM (sometimes numerous times) to correct.  You can tell if the proper USB device ID is mapped by looking in the WebUI --> KVM --> Devices --> usb_device and comparing to what is being written to the XML for that VM:

usb_device

<device>

  <name>usb_8_1</name>

  <path>/sys/devices/pci0000:00/0000:00:1d.2/usb8/8-1</path>

  <parent>usb_usb8</parent>

  <driver>

    <name>usb</name>

  </driver>

  <capability type='usb_device'>

    <bus>8</bus>

    <device>3</device>

    <product id='0x0011'>eHome Infrared Transceiver</product>

    <vendor id='0x1784'>Topseed Technology Corp.</vendor>

  </capability>

</device>

domain xml

    <hostdev mode='subsystem' type='usb' managed='no'>

      <source>

        <vendor id='0x1784'/>

        <product id='0x0011'/>

        <address bus='8' device='2'/>

      </source>

      <alias name='hostdev0'/>

    </hostdev>

As you can see from the above, the transceiver has been assigned a new device ID but the XML is still mapping to the old one.  I used to think that some type of event triggered the change (like another VM being restarted) but this latest one seems to have just happened randomly.  It is becoming quite a nuisance.  What's worse is that some users could be having this issue and not even really realize it and just think that their VM has hung.

I'm still looking into the use of UDEV rules to sort this out but I'm far from an expert.

John

I'm doing USB passthrough in Xen and have found that I can only do it by device ID.  If I do it by bus, it doesn't work.  Can you just pass the device ID and not include the bus?

I'm doing USB passthrough in Xen and have found that I can only do it by device ID.  If I do it by bus, it doesn't work.  Can you just pass the device ID and not include the bus?

I'm confused.  How can you just pass the DEVICE ID without the BUS ID?  How would it know what BUS the device is on?  Or are you referring to vendor and product IDs?

I'm doing USB passthrough in Xen and have found that I can only do it by device ID.  If I do it by bus, it doesn't work.  Can you just pass the device ID and not include the bus?

 

I'm confused.  How can you just pass the DEVICE ID without the BUS ID?  How would it know what BUS the device is on?  Or are you referring to vendor and product IDs?

Yes.  Just the vendor and product ID.  In Xen it finds the device.  The bus does not need to be passed.

Unfortunately, there are two issues with this...

1.  KVM injects the BUS and DEVICE ID into the XML when the VM is started.

2.  If you have two identical USB devices on the same host (I have 2 flircs), KVM will not start the VM since it wants to inject the BUS/DEVIES IDs into the XML and it's does not which device is the correct one.  If you manually add them to teh XML, this brings us back to the original issue of not being able to hardcode DEVICES IDs in the XML due to them changing randomly on the host.

John

And it happened again...

12 minutes after starting my VM, the USB device was assigned a new DEVICE ID:

Nov 30 08:16:30 unRAID kernel: usb 8-1: reset full-speed USB device number 3 using uhci_hcd
Nov 30 08:16:30 unRAID kernel: vfio-pci 0000:85:00.0: irq 122 for MSI/MSI-X
Nov 30 08:16:30 unRAID kernel: usb 8-1: reset full-speed USB device number 3 using uhci_hcd
Nov 30 08:16:31 unRAID kernel: usb 8-1: reset full-speed USB device number 3 using uhci_hcd
Nov 30 08:16:31 unRAID kernel: usb 8-1: reset full-speed USB device number 3 using uhci_hcd
Nov 30 08:16:33 unRAID kernel: vfio-pci 0000:85:00.1: irq 123 for MSI/MSI-X
Nov 30 08:28:13 unRAID kernel: usb 8-1: USB disconnect, device number 3
Nov 30 08:28:14 unRAID kernel: usb 8-1: new full-speed USB device number 4 using uhci_hcd

Ok.  KVM handles USB devices differently.

OK..I hope I am on to something here.  It looks like I am seeing a trend...every 12 minutes the USB device is being reset:

Nov 30 08:16:31 unRAID kernel: usb 8-1: reset full-speed USB device number 3 using uhci_hcd
Nov 30 08:16:31 unRAID kernel: usb 8-1: reset full-speed USB device number 3 using uhci_hcd
Nov 30 08:16:33 unRAID kernel: vfio-pci 0000:85:00.1: irq 123 for MSI/MSI-X
Nov 30 08:28:13 unRAID kernel: usb 8-1: USB disconnect, device number 3
Nov 30 08:28:14 unRAID kernel: usb 8-1: new full-speed USB device number 4 using uhci_hcd
Nov 30 08:36:09 unRAID kernel: usb 8-1: USB disconnect, device number 4
Nov 30 08:36:10 unRAID kernel: usb 8-1: new full-speed USB device number 5 using uhci_hcd

When I google this, I find references to "usb autosuspend".  I'm wondering if this is what is happening and if there is a way to disable it:

https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=linux+autosuspend+for+usb+device

Time to start playing...

Man I thought I found gold!

I tried what is listed here:  http://computint.blogspot.com/2012/06/disable-auto-suspend-for-all-usb.html

by adding the following to my go script:

for i in /sys/bus/usb/devices/*/power/autosuspend; do echo -1 > $i; done

When I run the cat command to check the setting for autosuspend for each USB device, the go script line appears to have worked:

root@unRAID:~# cat /sys/bus/usb/devices/*/power/autosuspend
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1

But then I saw a USB disconnect in my syslog as usual:

Nov 30 10:10:41 unRAID kernel: br0: port 4(vnet1) entered forwarding state
Nov 30 10:10:42 unRAID kernel: usb 8-1: reset full-speed USB device number 3 using uhci_hcd
Nov 30 10:10:44 unRAID kernel: usb 8-1: reset full-speed USB device number 3 using uhci_hcd
Nov 30 10:10:44 unRAID kernel: vfio-pci 0000:85:00.0: irq 120 for MSI/MSI-X
Nov 30 10:10:44 unRAID kernel: usb 8-1: reset full-speed USB device number 3 using uhci_hcd
Nov 30 10:10:45 unRAID kernel: usb 8-1: reset full-speed USB device number 3 using uhci_hcd
Nov 30 10:10:45 unRAID kernel: usb 8-1: reset full-speed USB device number 3 using uhci_hcd
Nov 30 10:10:47 unRAID kernel: vfio-pci 0000:85:00.1: irq 121 for MSI/MSI-X
Nov 30 10:14:01 unRAID kernel: usb 8-1: USB disconnect, device number 3
Nov 30 10:14:02 unRAID kernel: usb 8-1: new full-speed USB device number 4 using uhci_hcd

I ran the cat command again to check autosuspend setting and it now looks like this:

root@unRAID:~# cat /sys/bus/usb/devices/*/power/autosuspend
-1
-1
-1
2
-1
-1
-1
-1
-1
-1
-1
-1

So, I'm back to square one as it looks like the USB BUS is actually being reset and wiping out the autosuspend changes that my go script was making.

Also, here is a good example of what happens if I click the "restart domain" button in the KVM virtman GUI:

Nov 30 10:51:00 unRAID kernel: usb 6-2: reset low-speed USB device number 2 using uhci_hcd
Nov 30 10:51:01 unRAID kernel: usb 6-2: reset low-speed USB device number 2 using uhci_hcd
Nov 30 10:51:04 unRAID kernel: usb 6-2: reset low-speed USB device number 2 using uhci_hcd
Nov 30 10:51:05 unRAID kernel: usb 6-2: reset low-speed USB device number 2 using uhci_hcd
Nov 30 10:51:13 unRAID kernel: usb 6-2: USB disconnect, device number 2
Nov 30 10:51:14 unRAID kernel: usb 6-2: new low-speed USB device number 3 using uhci_hcd
Nov 30 10:51:15 unRAID kernel: input: flirc.tv flirc as /devices/pci0000:00/0000:00:1d.0/usb6/6-2/6-2:1.0/0003:20A0:0001.0004/input/input8
Nov 30 10:51:15 unRAID kernel: hid-generic 0003:20A0:0001.0004: input,hidraw0: USB HID v1.01 Keyboard [flirc.tv flirc] on usb-0000:00:1d.0-2/input0

Since I did a restart rather than a stop/start, the XML retains the original BUS/DEVICE ID (6:2) but the device itself has now obtained a new BUS/DEVICE ID (6:3).  If I STOP/START the VM, the new BUS/DEVICE ID is written to the XML and the VM is happy.  For this particular scenario,  I wonder if a temporary workaround would be to change the function of the "restart domain" button to do a stop/start rather than a restart if that is even possible.

John

UPDATE:

I'm hoping I may have solved part of my problem.  For the VM that uses the MCE remote transceiver passed through, I use USB-over-Ethernet adapters (as seen here:  http://www.amazon.com/Monoprice-Extender-CAT5E-Connection-150ft/dp/B003L14ZTC/ref=sr_1_1?ie=UTF8&qid=1417615845&sr=8-1&keywords=usb+over+ethernet) with a ~25ft CAT5E run to my TV.  I have removed the adapters and plugged the transceiver directly into the USB port.  An hour later I have not seen a single USB disconnect.  I even rebooted the other XBMCBuntu VM which normally would cause this device to reset but it didn't.

I'll keep an eye on it and see how it does.  If it looks OK, the only outstanding issues would be:

1.  USB devices obtaining a new device ID when the VM they are attched to are restarted.

      - Workaround:  If my theory is true then this can be avoided by changing the "restart domain" button to perform a stop/start of the VM rather than a restart.

2.  The issue of having identical USB devices on the same host (i.e. 2 flircs) still remains.  the only way I know around this one is to hardcode the BUS/DEVICE IDs in the XML.  However, a VM restart (or even a stop/start) would have ill effects as the DEVICE ID would change.

I'll post an inquiry in the virtman plugin thread to see if remapping the "restart domain" button is possible.  If so, lots of testing upcoming. 

John

I'm hoping I may have solved part of my problem.  For the VM that uses the MCE remote transceiver passed through, I use USB-over-Ethernet adapters (as seen here:  http://www.amazon.com/Monoprice-Extender-CAT5E-Connection-150ft/dp/B003L14ZTC/ref=sr_1_1?ie=UTF8&qid=1417615845&sr=8-1&keywords=usb+over+ethernet) with a ~25ft CAT5E run to my TV.  I have removed the adapters and plugged the transceiver directly into the USB port.  An hour later I have not seen a single USB disconnect.  I even rebooted the other XBMCBuntu VM which normally would cause this device to reset but it didn't.

Well, it looks like the USB-Over-Ethernet adapters were the culprit for my random USB disconnects.  I have not seen a single disconnect after a few days.  However, I still needed a solution for long USB runs for my flircs.  I just installed one of these 2 hours ago and have not yet seen a disconnect:  http://www.amazon.com/gp/product/B005LJKEXS/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1

So far so good.  The thing that is interesting is that these devices are seen as their own USB hub:

<device>
  <name>usb_2_1</name>
  <path>/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1</path>
  <parent>usb_usb2</parent>
  <driver>
    <name>usb</name>
  </driver>
  <capability type='usb_device'>
    <bus>2</bus>
    <device>5</device>
    <product id='0x0101'>USB 2.0 Hub</product>
    <vendor id='0x1a40' />
  </capability>
</device>

This is awfully optimistic but I am HOPING that this could be the magic pill that alleviates changing USB device IDs caused by a VM restart.  I'm going to test now while my boys are at daycare and I am "working" from home. 

John

First round of testing complete and saw something interesting...

I could see in my usb_devices that the flirc attached to the active USB cable listed above was assigned BUS 2 DEVICE 6 so I hardcoded  that in my XML:

    <hostdev mode='subsystem' type='usb' managed='no'>

      <source>

        <address bus='2' device='6'/>

      </source>

      <alias name='hostdev0'/>

    </hostdev>

I powered on the VM and the flirc retained DEVICE ID 6:

START DOMAIN

Dec 3 08:41:54 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 08:41:54 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 08:41:55 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 08:41:55 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 08:41:58 unRAID kernel: br0: port 4(vnet1) entered learning state

Dec 3 08:42:10 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 08:42:12 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 08:42:12 unRAID kernel: vfio-pci 0000:85:00.0: irq 62 for MSI/MSI-X

Dec 3 08:42:12 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 08:42:13 unRAID kernel: br0: topology change detected, propagating

Dec 3 08:42:13 unRAID kernel: br0: port 4(vnet1) entered forwarding state

Dec 3 08:42:13 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 08:42:14 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 08:42:16 unRAID kernel: vfio-pci 0000:85:00.1: irq 63 for MSI/MSI-X

Since I had changed the Restart Domain button to perform a "rename-restart", I tried that next and it retained DEVICE ID 6:

RENAME-RESTART DOMAIN

Dec 3 09:20:03 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:20:03 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:20:07 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:20:07 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:20:14 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:20:15 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:20:16 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:20:16 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:20:31 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:20:33 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:20:34 unRAID kernel: vfio-pci 0000:85:00.0: irq 62 for MSI/MSI-X

Dec 3 09:20:34 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:20:35 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:20:36 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:20:38 unRAID kernel: vfio-pci 0000:85:00.1: irq 63 for MSI/MSI-X

I then did a SHUTDOWN DOMAIN and a START DOMAIN and it again retained DEVICE ID 6:

SHUTDOWN DOMAIN & START DOMAIN

Dec 3 09:25:28 unRAID avahi-daemon[1980]: Withdrawing workstation service for vnet1.

Dec 3 09:25:28 unRAID kernel: br0: port 4(vnet1) entered disabled state

Dec 3 09:25:28 unRAID kernel: device vnet1 left promiscuous mode

Dec 3 09:25:28 unRAID kernel: br0: port 4(vnet1) entered disabled state

Dec 3 09:25:28 unRAID kernel: input: flirc.tv flirc as /devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.4/2-1.4:1.0/0003:20A0:0001.0006/input/input10

Dec 3 09:25:28 unRAID kernel: hid-generic 0003:20A0:0001.0006: input,hidraw2: USB HID v1.01 Keyboard [flirc.tv flirc] on usb-0000:00:1d.7-1.4/input0

Dec 3 09:25:52 unRAID kernel: device vnet1 entered promiscuous mode

Dec 3 09:25:52 unRAID kernel: br0: port 4(vnet1) entered listening state

Dec 3 09:25:52 unRAID kernel: br0: port 4(vnet1) entered listening state

Dec 3 09:25:53 unRAID kernel: vfio-pci 0000:85:00.0: enabling device (0400 -> 0403)

Dec 3 09:25:53 unRAID kernel: vfio-pci 0000:85:00.1: enabling device (0400 -> 0402)

Dec 3 09:26:03 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:26:03 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:26:04 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:26:04 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:26:07 unRAID kernel: br0: port 4(vnet1) entered learning state

Dec 3 09:26:18 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:26:19 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:26:20 unRAID kernel: vfio-pci 0000:85:00.0: irq 62 for MSI/MSI-X

Dec 3 09:26:20 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:26:21 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:26:22 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:26:22 unRAID kernel: br0: topology change detected, propagating

Dec 3 09:26:22 unRAID kernel: br0: port 4(vnet1) entered forwarding state

Dec 3 09:26:24 unRAID kernel: vfio-pci 0000:85:00.1: irq 63 for MSI/MSI-X

Here is where is gets interesting...

I now wanted to try a plain RESTART DOMAIN but first I needed to change my XML from "rename-restart" to "restart".  So, I stopped the VM, edited the XML and powered on the VM.  I now saw a "USB disconnect" message and the DEVICE ID changed to 7:

SHUTDOWN DOMAIN & EDIT XML & START DOMAIN

Dec  3 09:28:18 unRAID avahi-daemon[1980]: Withdrawing workstation service for vnet1.

Dec  3 09:28:18 unRAID kernel: br0: port 4(vnet1) entered disabled state

Dec  3 09:28:18 unRAID kernel: device vnet1 left promiscuous mode

Dec  3 09:28:18 unRAID kernel: br0: port 4(vnet1) entered disabled state

Dec  3 09:28:18 unRAID kernel: input: flirc.tv flirc as /devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.4/2-1.4:1.0/0003:20A0:0001.0007/input/input11

Dec  3 09:28:18 unRAID kernel: hid-generic 0003:20A0:0001.0007: input,hidraw2: USB HID v1.01 Keyboard [flirc.tv flirc] on usb-0000:00:1d.7-1.4/input0

Dec 3 09:29:21 unRAID kernel: device vnet1 entered promiscuous mode

Dec 3 09:29:21 unRAID kernel: br0: port 4(vnet1) entered listening state

Dec 3 09:29:21 unRAID kernel: br0: port 4(vnet1) entered listening state

Dec 3 09:29:22 unRAID kernel: vfio-pci 0000:85:00.0: enabling device (0400 -> 0403)

Dec 3 09:29:22 unRAID kernel: vfio-pci 0000:85:00.1: enabling device (0400 -> 0402)

Dec 3 09:29:32 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:29:33 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:29:34 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:29:34 unRAID kernel: usb 2-1.4: reset low-speed USB device number 6 using ehci-pci

Dec 3 09:29:36 unRAID kernel: br0: port 4(vnet1) entered learning state

Dec 3 09:29:49 unRAID kernel: usb 2-1.4: USB disconnect, device number 6

Dec 3 09:29:50 unRAID kernel: usb 2-1.4: new low-speed USB device number 7 using ehci-pci

Dec 3 09:29:50 unRAID kernel: input: flirc.tv flirc as /devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.4/2-1.4:1.0/0003:20A0:0001.0008/input/input12

Dec 3 09:29:50 unRAID kernel: hid-generic 0003:20A0:0001.0008: input,hidraw2: USB HID v1.01 Keyboard [flirc.tv flirc] on usb-0000:00:1d.7-1.4/input0

Dec 3 09:29:51 unRAID kernel: vfio-pci 0000:85:00.0: irq 62 for MSI/MSI-X

Dec 3 09:29:51 unRAID kernel: br0: topology change detected, propagating

Dec 3 09:29:51 unRAID kernel: br0: port 4(vnet1) entered forwarding state

Dec 3 09:29:53 unRAID kernel: vfio-pci 0000:85:00.1: irq 63 for MSI/MSI-X

To finish my testing I now wanted to perform a RESTART DOMAIN.  The DEVICE ID remained 7:

DOMAIN RESTART

Dec 3 09:34:28 unRAID kernel: usb 2-1.4: reset low-speed USB device number 7 using ehci-pci

Dec 3 09:34:28 unRAID kernel: usb 2-1.4: reset low-speed USB device number 7 using ehci-pci

Dec 3 09:34:32 unRAID kernel: usb 2-1.4: reset low-speed USB device number 7 using ehci-pci

Dec 3 09:34:32 unRAID kernel: usb 2-1.4: reset low-speed USB device number 7 using ehci-pci

Dec 3 09:34:40 unRAID kernel: usb 2-1.4: reset low-speed USB device number 7 using ehci-pci

Dec 3 09:34:41 unRAID kernel: usb 2-1.4: reset low-speed USB device number 7 using ehci-pci

Dec 3 09:34:41 unRAID kernel: usb 2-1.4: reset low-speed USB device number 7 using ehci-pci

Dec 3 09:34:42 unRAID kernel: usb 2-1.4: reset low-speed USB device number 7 using ehci-pci

Dec 3 09:34:57 unRAID kernel: usb 2-1.4: reset low-speed USB device number 7 using ehci-pci

Dec 3 09:34:59 unRAID kernel: usb 2-1.4: reset low-speed USB device number 7 using ehci-pci

Dec 3 09:34:59 unRAID kernel: vfio-pci 0000:85:00.0: irq 62 for MSI/MSI-X

Dec 3 09:35:00 unRAID kernel: usb 2-1.4: reset low-speed USB device number 7 using ehci-pci

Dec 3 09:35:01 unRAID kernel: usb 2-1.4: reset low-speed USB device number 7 using ehci-pci

Dec 3 09:35:02 unRAID kernel: usb 2-1.4: reset low-speed USB device number 7 using ehci-pci

Dec 3 09:35:04 unRAID kernel: vfio-pci 0000:85:00.1: irq 63 for MSI/MSI-X

It's a little premature to conclude anything since I only performed one round of testing but right now it looks like editing the XML triggered the USB disconnect.  I am going to go through this test a few more times to see if I get consistent results.  Of course, I imagine all of this goes out the window if I restart the server.  I fully expect that all of the USB devices would revert back to their original DEVICE IDs.  I'm pretty certain that I have seen this but I'll need to test to confirm.

If all of the above remains true, I should be able to use both of my flircs as long as I hardcode the BUS/DEVICE IDs after a server start/restart (so they have both reverted to the original DEVICE IDs) and never again edit the XMLs unless I plan on restarting the server. 

John

I noticed that something strange was happening with usb devices being re numbered as well. I never looked further into it because I ended up passing the entire usb PCI controller to the VM. It was a little involved to figure out which USB ports belonged to which controller (my server has three USB PCI controllers ) but I ended up figuring it out. The first benefit I have noticed is that I can plug a USB flash drive into my USB hub and my already started windows VM loads it. I can post a guide of how to figure out each individual  USB port controller if your interested? I suppose the only downside to this is that I can only have 2 VM's started at the same time (with USB passthrough) due to my server only having 3 USB controllers (1 controller can never be passed through because unRAID has to load)

Hmmm...I didn't think about trying that.  But now that it appears that these active USB cables that I bought are their own hub, it should be easy to do.  Did you need to passthrough the hub AND the device or just the hub?

FYI...this is the device (active USB cable) that I need to passthrough:

<device>
  <name>usb_2_1</name>
  <path>/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1</path>
  <parent>usb_usb2</parent>
  <driver>
    <name>usb</name>
  </driver>
  <capability type='usb_device'>
    <bus>2</bus>
    <device>2</device>
    <product id='0x0101'>USB 2.0 Hub</product>
    <vendor id='0x1a40' />
  </capability>
</device>

Can I just passthrough BUS 2 DEVICE 2?

EDIT:  I tried passing through just BUS 2 DEVICE 2 and I didn't get the flirc.

John

Hmmm...I didn't think about trying that.  But now that it appears that these active USB cables that I bought are their own hub, it should be easy to do.  Did you need to passthrough the hub AND the device or just the hub?

I only passthrough the 1 USB controller (which controls 4 USB ports) and then I put the USB HUB in one of the ports.

I can post a guide of how to figure out each individual  USB port controller if your interested?

[/quote

 

I am very interested in this.  Please write up a quick guide if you don't mind.

 

Thanks!

I can post a guide of how to figure out each individual  USB port controller if your interested?

[/quote

 

I am very interested in this.  Please write up a quick guide if you don't mind.

 

Thanks!

 

Alright I'll put that together later this afternoon. Did you keep your motherboard manual? It's nice to take notes one.

I can post a guide of how to figure out each individual  USB port controller if your interested?

 

I am very interested in this.  Please write up a quick guide if you don't mind.

 

Thanks!

Done:

http://lime-technology.com/forum/index.php?topic=36768.msg341517#msg341517