Bug 842358
Summary: | remote-viewer: USB redirection: Flash drive disconnects after a while | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Milan Barta <mbarta> | ||||
Component: | usbredir | Assignee: | Hans de Goede <hdegoede> | ||||
Status: | CLOSED DUPLICATE | QA Contact: | |||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 7.0 | CC: | herrold, pvine, tpelka | ||||
Target Milestone: | rc | ||||||
Target Release: | 7.0 | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2012-12-14 10:56:17 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Milan Barta
2012-07-23 14:46:28 UTC
2 questions: 1) Are you perhaps using the device in a USB-3 port of the client ? If so can you try using it in a USB-2 port 2) Can you reproduce the problem and attach dmesg from the client machine please? 1) my workstation only has USB2 ports, no USB3. 2) client dmesg: usb 2-1.2: new high speed USB device number 18 using ehci_hcd usb 2-1.2: New USB device found, idVendor=13fe, idProduct=3100 usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-1.2: Product: Patriot Memory usb 2-1.2: Manufacturer: usb 2-1.2: SerialNumber: 0797060899352CF1 usb 2-1.2: configuration #1 chosen from 1 choice scsi33 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 18 usb-storage: waiting for device to settle before scanning usb-storage: device scan complete scsi 33:0:0:0: Direct-Access Patriot Memory PMAP PQ: 0 ANSI: 0 CCS sd 33:0:0:0: Attached scsi generic sg2 type 0 sd 33:0:0:0: [sdb] 15654912 512-byte logical blocks: (8.01 GB/7.46 GiB) sd 33:0:0:0: [sdb] Write Protect is off sd 33:0:0:0: [sdb] Mode Sense: 23 00 00 00 sd 33:0:0:0: [sdb] Assuming drive cache: write through sd 33:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sd 33:0:0:0: [sdb] Assuming drive cache: write through sd 33:0:0:0: [sdb] Attached SCSI removable disk SELinux: initialized (dev sdb1, type vfat), uses genfs_contexts usb 2-1.2: reset high speed USB device number 18 using ehci_hcd usb 2-1.2: reset high speed USB device number 18 using ehci_hcd ... (hundrets of lines like this ...) ... usb 2-1.2: reset high speed USB device number 18 using ehci_hcd usb 2-1.2: device not accepting address 18, error -71 usb 2-1.2: USB disconnect, device number 18 Moving to 7.0 as 6.3 combinations are fine so it is likely the bug is with 7.0. So looking at the dmesg inside both the client and the guest what is happening is: 1) device gets redirected 2) the guest issues a ton of device resets due to some errors while talking to the device 3) after devie reset 1001 and the device goes into some error state and no longer wants to talk to the problem There is little we can do to fix 3, if you keep hitting the device with resets eventually you may do so at a bad time and the firmware may lockup. So the problem to fix here is 2. To fix 2) I will need some more information, can you please try running the RHEL-7 guest with usbredir debugging enabled? To do this you (unfortunately) will need to start qemu manually, since libvirt does not support the debug parameter of the usb-redir device (I'll file a bug for this). Here is an example commandline for running RHEL under qemu-kvm directly from the cmdline: /usr/bin/qemu-kvm -enable-kvm \ -m 1024 -name RHEL-7 \ -drive file=/home/images/rhel7.img,media=disk,index=0 \ -net nic,macaddr=52:54:00:7a:b4:7e,vlan=0,model=virtio,name=virtio.0 -net user,vlan0 \ -vga qxl -spice port=5955,disable-ticketing \ -device virtio-serial -chardev spicevmc,id=vdagent,debug=1,name=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \ -readconfig /home/hans/projects/qemu/docs/ich9-ehci-uhci.cfg \ -chardev spicevmc,name=usbredir,id=usbredirchardev1 \ -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=4 \ -chardev spicevmc,name=usbredir,id=usbredirchardev2 \ -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,debug=4 \ -chardev spicevmc,name=usbredir,id=usbredirchardev3 \ -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3,debug=4 \ -monitor stdio -device intel-hda -device hda-duplex 2> qemu.log Notice you will need to drop ich9-ehci-uhi.cfg somewhere and adjust the -readconfig to point there. You can find the .cfg file here: http://cgit.freedesktop.org/spice/qemu/plain/docs/ich9-ehci-uhci.cfg Then connect to lthe vm with remote-viewer, redirect the troublesome USB-stick, let it run for a while and attach qemu.log here. I've filed bug 844073 for adding support for the debug parameter to libvirt's xml format Created attachment 601145 [details]
qemu log with usbredir debug enabled
Thanks for generating the log, this looks like it may be an issue fixed by a recent upstream fix, can you try with a Fedora-17 client with this version of usbredir installed: ? http://koji.fedoraproject.org/koji/buildinfo?buildID=344919 Tried running Fedora 17 client and the problem doesn't seem to occur anymore. (In reply to comment #9) > Tried running Fedora 17 client and the problem doesn't seem to occur anymore. That is good news, thanks for the info. (In reply to comment #9) > Tried running Fedora 17 client and the problem doesn't seem to occur anymore. Ok, that would make this a duplicate of bug 834560 . *** This bug has been marked as a duplicate of bug 834560 *** |