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:
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.
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.
I've just got round to testing it on Fedora 19. The behaviour is exactly the same. How do I reopen?
hans, gerd, any thoughts on this?
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
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
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
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
(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.
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.
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.
(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 ?
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?
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
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.
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 >
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.
Is it OK to reopen this, or should I create a new one? I'm on RHEL8, and if I add USB device via virt-manager, it always adds both bus and port. So it's not possible to have only USB ID as selector: <address type='usb' bus='0' port='1'/> Even if I do virsh edit VM, and remove the port, it comes back when I start VM from virt-manager. This happens as I use some logic analyser connected to my host, and running pulseview on guest Fedora 30. I need to do so, as there are no epel packages yet for RHEL8. Pulseview starts by probing the device, which it finds, but then it uploads new FW into analyser device, which reboots and gets new usb bus port. It get's lost from VM. I need to shutdown the VM, and assign the same device using the new port. I tried removing the port from VM xml, but somehow it keeps coming back there. I think it should not, that's the bug part. Or then there should be an option in virt-manager to keep attaching device id from any bus/port it might have (not fixing the usb address.
IMO reopening bugs more than a year old is not recommended even if the root issue appears the same, because code may be completely different. Better to file a new bug and mention the old report in the summary and let devs decide. In this case I suggest filing a rhel8 virt-manager bug and provide 'virt-manager --debug' output when reproducing, and the full VM XML with 'sudo virsh dumpxml $vmname'