This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 862915 - KVM USB passthrough - usb device initiated reset causes device to disappear in guest
KVM USB passthrough - usb device initiated reset causes device to disappear i...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
19
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-03 17:11 EDT by Sean Young
Modified: 2013-08-04 16:01 EDT (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-04 16:01:14 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Send command to IguanaWorks USB device to reset/reboot itself (2.62 KB, text/x-csrc)
2012-10-03 17:11 EDT, Sean Young
no flags Details
usbmon output (9.29 KB, text/plain)
2013-08-01 16:44 EDT, Sean Young
no flags Details

  None (edit)
Description Sean Young 2012-10-03 17:11:06 EDT
Created attachment 621162 [details]
Send command to IguanaWorks USB device to reset/reboot itself

Description of problem:
The IguanaWorks USB IR Transceiver resets itself during flashing of its firmware. If this is done from a kvm guest then the USB device will disappear and the firmware flashing is incomplete.

Version-Release number of selected component (if applicable):
Fedora 17.

How reproducible:
Every time.


Steps to Reproduce:
1. Plug in IguanaWorks USB IR Receiver and add to kvm guest
2. Run either
2a. If you have the iguanaworks software installed, run "igclient --reset" in the VM
2b. Else compile attached igreset and execute ("gcc -o igreset igreset.c -lusb-1.0"
3. After device resets itself it is not longer visible in VM (gone from lsusb).
  
Actual results:
dmesg guest:
[  119.247492] usb 1-2.1: USB disconnect, address 4

dmesg host:
[ 1766.221059] usb 7-1: >reset low-speed USB device number 3 using uhci_hcd
[ 1771.779058] usb 7-1: >reset low-speed USB device number 3 using uhci_hcd
[ 1772.417055] usb 7-1: >reset low-speed USB device number 3 using uhci_hcd
[ 1888.454144] usb 7-1: >USB disconnect, device number 3
[ 1888.712042] usb 7-1: >new low-speed USB device number 4 using uhci_hcd
[ 1888.874144] usb 7-1: >New USB device found, idVendor=1781, idProduct=0938
[ 1888.874149] usb 7-1: >New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1888.874153] usb 7-1: >Product: USB IR Transceiver
[ 1888.874156] usb 7-1: >Manufacturer: IguanaWorks

Expected results:
Device remains visible from VM. This works in VirtualBox.

Additional info:
Comment 1 Fedora End Of Life 2013-07-04 00:14:04 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 2 Cole Robinson 2013-07-11 15:18:38 EDT
Sean, sorry this never received a response. F19 qemu has seen many many USB improvements compared to F17. If you still have an issue on F19, please reopen this bug, and we can go from there.
Comment 3 Sean Young 2013-07-11 17:12:50 EDT
I've just got round to testing it on Fedora 19. The behaviour is exactly the same. How do I reopen?
Comment 4 Cole Robinson 2013-07-11 18:31:40 EDT
hans, gerd, any thoughts on this?
Comment 5 Hans de Goede 2013-07-12 02:28:58 EDT
Sean,

(In reply to Sean Young from comment #3)
> I've just got round to testing it on Fedora 19. The behaviour is exactly the
> same. How do I reopen?

Are you using host redirection, or Spice's network redirection ? What likely happens is that the device in question changes descriptors when it goes into firmware flash mode, so after the reset it gets seen as a new device.

If you're using host redirection then the new device will not get redirected so the guest will not see it.

If you don't know which type of redirection you're using, please describe which stepa (in the gui or on the cmdline) you've taken to redirect the device.

Regards,

Hans
Comment 6 Emiliano 2013-07-12 12:06:35 EDT
Hello,

I am having a very similar behavior in CentOS 6.3 after recently updating.
In my case, it is a cellphone connected to a guest. It was working just fine, and after updating, the connection resets whenever i send a message.

The host is a CentOS 6.3 running KVM, it has a cellphone attached to a usb port, using a usb to serial like cable.
The guest is a CentOS 6.3 running gnokii (smsd).
When I send a message, and gnokii starts dealing with the phone, the host disconnects the usb port and reconnects it to a different location (i.e.: /dev/bus/usb/001/0xx -> /dev/bus/usb/001/0yy).


Regards,

Emiliano
Comment 7 Hans de Goede 2013-07-12 13:54:28 EDT
Hi,

(In reply to Emiliano from comment #6)
> Hello,
> 
> I am having a very similar behavior in CentOS 6.3 after recently updating.
> In my case, it is a cellphone connected to a guest. It was working just
> fine, and after updating, the connection resets whenever i send a message.
> 
> The host is a CentOS 6.3 running KVM, it has a cellphone attached to a usb
> port, using a usb to serial like cable.
> The guest is a CentOS 6.3 running gnokii (smsd).
> When I send a message, and gnokii starts dealing with the phone, the host
> disconnects the usb port and reconnects it to a different location (i.e.:
> /dev/bus/usb/001/0xx -> /dev/bus/usb/001/0yy).

Since there is no guest initiated device reset involved here, this seems completely unrelated. Also please don't use Fedora bugs to discuss CentOS issues, the 2 are miles apart when it comes to the versions of qemu used.

Regards,

Hans
Comment 8 Emiliano 2013-07-12 14:25:57 EDT
sorry, i thought that centos took it's updates from tested fedora packages, and since this is happening since some time ago..
the error happens at certain point in the communication, but you are right, i don't know yet what is doing the soft in the guest side to tell if there's a reset issued
i thought that maybe giving you extra info, and another **possibly** related issue, would be welcome

i will try to solve it myself if i have the time or downgrade and wait, that's what i always did

thanks anyway

Regards,
Emiliano
Comment 9 Sean Young 2013-07-12 15:11:19 EDT
(In reply to Hans de Goede from comment #5)
> Sean,
> 
> (In reply to Sean Young from comment #3)
> > I've just got round to testing it on Fedora 19. The behaviour is exactly the
> > same. How do I reopen?
> 
> Are you using host redirection, or Spice's network redirection ? What likely
> happens is that the device in question changes descriptors when it goes into
> firmware flash mode, so after the reset it gets seen as a new device.

 1633 ?        Sl     0:13 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name debian -S -machine pc-i440fx-1.4,accel=kvm,usb=off -m 1024 -smp 1,sockets=1,cores=1,threads=1 -uuid 713f431f-86c4-8644-a6a9-ad956cdcf84d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/debian.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/var/lib/libvirt/images/debian.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a3:74:b5,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb-host,hostbus=7,hostaddr=3,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7

I guess the important bit is "-device usb-host,hostbus=7,hostaddr=3,id=hostdev0 ". The device is plugged into usb bus 7.

> If you're using host redirection then the new device will not get redirected
> so the guest will not see it.

The device was #3 and became #4 after it reset itself.

[  361.936047] usb 7-1: new low-speed USB device number 4 using uhci_hcd

> If you don't know which type of redirection you're using, please describe
> which stepa (in the gui or on the cmdline) you've taken to redirect the
> device.
> 
> Regards,
> 
> Hans

Please note I am away until the 18th of July.
Comment 10 Hans de Goede 2013-07-12 18:03:51 EDT
Hi,

(In reply to Sean Young from comment #9)
> (In reply to Hans de Goede from comment #5)
> > Sean,
> > 
> > (In reply to Sean Young from comment #3)
> > > I've just got round to testing it on Fedora 19. The behaviour is exactly the
> > > same. How do I reopen?
> > 
> > Are you using host redirection, or Spice's network redirection ? What likely
> > happens is that the device in question changes descriptors when it goes into
> > firmware flash mode, so after the reset it gets seen as a new device.
> 
>  1633 ?        Sl     0:13 /usr/bin/qemu-system-x86_64 -machine accel=kvm
> -name debian -S -machine pc-i440fx-1.4,accel=kvm,usb=off -m 1024 -smp
> 1,sockets=1,cores=1,threads=1 -uuid 713f431f-86c4-8644-a6a9-ad956cdcf84d
> -no-user-config -nodefaults -chardev
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/debian.monitor,server,
> nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc
> -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
> virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive
> file=/var/lib/libvirt/images/debian.img,if=none,id=drive-virtio-disk0,
> format=raw -device
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,
> id=virtio-disk0,bootindex=1 -drive
> if=none,id=drive-ide0-1-0,readonly=on,format=raw -device
> ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev
> tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device
> virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a3:74:b5,bus=pci.0,
> addr=0x3 -chardev pty,id=charserial0 -device
> isa-serial,chardev=charserial0,id=serial0 -chardev
> spicevmc,id=charchannel0,name=vdagent -device
> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,
> name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice
> port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -vga qxl
> -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device
> intel-hda,id=sound0,bus=pci.0,addr=0x4 -device
> hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device
> usb-host,hostbus=7,hostaddr=3,id=hostdev0 -device
> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
> 
> I guess the important bit is "-device
> usb-host,hostbus=7,hostaddr=3,id=hostdev0 ". The device is plugged into usb
> bus 7.
> 
> > If you're using host redirection then the new device will not get redirected
> > so the guest will not see it.
> 
> The device was #3 and became #4 after it reset itself.

Right, I'm not sure if this is possible through virt-manager, but can you try redirecting the device by usb-id ?

And if the id changes after the reset try telling virt-manager to redirect both the old and the new id.
Comment 11 Sean Young 2013-07-13 07:18:21 EDT
I tried with: "-device usb-host,vendorid=0x1781,productid=0x0938,id=hostdev0" and still the device disappears when it resets itself.

Messages in dmesg are still the same.
Comment 12 Hans de Goede 2013-07-13 16:09:05 EDT
(In reply to Sean Young from comment #11)
> I tried with: "-device
> usb-host,vendorid=0x1781,productid=0x0938,id=hostdev0" and still the device
> disappears when it resets itself.
> 
> Messages in dmesg are still the same.

That is weird, when you redirect by ids, the usb-host redirection should see the device as disconnected after the reset, and then start waiting for a new device with the same ids to show up, and when that happens pick up the new one AFAIK.

Gerd is the specialist on host redirection though, Gerd any ideas ?
Comment 13 Gerd Hoffmann 2013-07-22 09:05:00 EDT
There are devices which come back with another device id after uploading the firmware, maybe this is the case here?

Which exact version you are testing with now on f19?
Comment 14 Sean Young 2013-07-22 17:13:36 EDT
This is not one of those devices. The usb pid/vid stay exactly the same. In fact the little attached program only tells the device to reset itself and the issue occurs in this case too.

I'm using the iguanair firmware version 0x0308. I'm using f19 on x86_64.

[sean@triffid ~]$ lsusb
Bus 007 Device 004: ID 1781:0938 Multiple Vendors Iguanaworks USB IR Transceiver

I can try to debug this myself, where should I start looking?

Thanks
Comment 15 Gerd Hoffmann 2013-07-23 07:39:26 EDT
First: any error messages in /var/log/libvirt/qemu/$guest.log ?

If there is nothing:  Tracing could help tracking it down, qemu has a bunch of usb_host_* tracepoints which can be enabled.

You can also trace the usb traffic, one level below (see Documentation/usb/usbmon.txt in the linux source tree), and see whenever there are any significant differences between host and guest talking to the device.
Comment 16 Sean Young 2013-08-01 16:44:03 EDT
Created attachment 781757 [details]
usbmon output

There is no error or anything in /var/log/libvirtd/qemu/$guest.log. I've attached the usbmon output. This is line which resets the device:

06c54180 157.086829 S Io:7:003:2 -:8 4 =
    0000cdff
06c54180 157.095400 C Io:7:003:2 0:8 4 >
Comment 17 Sean Young 2013-08-04 16:01:14 EDT
I've decide to dive into the source code and then realised I cannot reproduce this issue with "-device usb-host,vendorid=0x1781,productid=0x0938,id=hostdev0". Sorry this is bug should have never have been raised. Apologies.

Note You need to log in before you can comment on or make changes to this bug.