Bug 980415
| Summary: | libusbx: error [_open_sysfs_attr] open /sys/bus/usb/devices/4-1/bConfigurationValue failed ret=-1 errno=2 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Sibiao Luo <sluo> | ||||
| Component: | qemu-kvm | Assignee: | Gerd Hoffmann <kraxel> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 7.0 | CC: | acathrow, chayang, hdegoede, hhuang, juli, juzhang, knoel, kraxel, mazhang, michen, qzhang, rhod, sluo, virt-maint, xfu | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | qemu-kvm-1.5.3-15.el7 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-06-13 13:02:26 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
Sibiao Luo
2013-07-02 10:18:59 UTC
My whole qemu-kvm command line:
# /usr/libexec/qemu-kvm -M q35 -cpu SandyBridge -enable-kvm -m 4096 -smp 4,sockets=2,cores=2,threads=1 -no-kvm-pit-reinjection -name sluo -uuid 355a2475-4e03-4cdd-bf7b-5d6a59edaa61 -rtc base=localtime,clock=host,driftfix=slew -device pci-bridge,bus=pcie.0,id=bridge1,chassis_nr=1,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0,bus=bridge1,addr=0x4 -chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait -device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port1 -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait -device virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port2 -drive file=/home/RHEL-7.0-20130628.0-Server-x86_64.qcow3,if=none,id=drive-system-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop,serial="QEMU-DISK1" -device virtio-scsi-pci,num_queues=4,id=scsi0,bus=bridge1,addr=0x5 -device scsi-hd,bus=scsi0.0,drive=drive-system-disk,id=system-disk,bootindex=1 -device virtio-balloon-pci,id=ballooning,bus=bridge1,addr=0x6 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -netdev tap,id=hostnet0,vhost=on,queues=4,script=/etc/qemu-ifup -device virtio-net-pci,mq=on,vectors=17,netdev=hostnet0,id=virtio-net-pci0,mac=08:2e:5f:0a:0d:b1,bus=bridge1,addr=0x7,bootindex=2 -k en-us -boot menu=on -qmp tcp:0:4444,server,nowait -serial unix:/tmp/ttyS0,server,nowait -vnc :1 -spice port=5931,disable-ticketing -monitor stdio -device nec-usb-xhci,id=xhci0,addr=0x8 -device usb-host,hostbus=4,hostaddr=3,id=usb-stick,bus=xhci0.0
(qemu) info usb
Device 0.0, Port 1, Speed 5000 Mb/s, Product
(qemu) info usbhost
Bus 1, Addr 4, Port 1.3.1, Speed 1.5 Mb/s
Class 00: USB device 0557:2213, CS-1734A V4.2.414
(qemu) xhci: FIXME: endpoint stopped w/ xfers running, data might be lost
libusbx: error [_open_sysfs_attr] open /sys/bus/usb/devices/4-1/bConfigurationValue failed ret=-1 errno=2
xhci_port_write: ignore pls write (old 5, new 5)
xhci_port_write: ignore pls write (old 5, new 5)
Gerd, The "libusbx: error [_open_sysfs_attr] open /sys/bus/usb/devices/4-1/bConfigurationValue failed ret=-1 errno=2" matches up with this in the host dmesg: [ 853.275774] xhci_hcd 0000:02:00.0: Timeout while waiting for address device command [ 853.476912] usb 4-1: device not accepting address 3, error -62 [ 854.013323] usb 4-1: USB disconnect, device number 3 errno -2 is ENOENT, which is unsurprising after a device disconnect. I see 2 separate possible issues here: 1) The xhci emulation + passthrough is somehow confusing the device 2) The usb-stick in question does not like being reset, and when the host kernel usb-stack tries to re-assign the usb-stick's address after reset it fails. 2. happens from time to time, so maybe we need to add a no-reset flag to the usb-host device, at a minimum it would be useful to rule out the reset causing issues in cases like this. Note this clearly is not a libusbx bug, moving back to qemu-kvm. Device init trace: usb_host_reset dev 10:15 usb_host_req_control dev 10:15, packet 0x7fad633d8820, req 0x5, value 1, index 0 usb_host_set_address dev 10:15, address 1 usb_host_req_emulated dev 10:15, packet 0x7fad633d8820, status 0 usb_host_req_control dev 10:15, packet 0x7fad5c018960, req 0x8006, value 256, index 0 usb_host_req_complete dev 10:15, packet 0x7fad5c018960, status 0, length 8 usb_host_req_control dev 10:15, packet 0x7fad5c018a50, req 0x8006, value 256, index 0 usb_host_req_complete dev 10:15, packet 0x7fad5c018a50, status 0, length 18 usb_host_req_control dev 10:15, packet 0x7fad5c018b40, req 0x8006, value 3840, index 0 usb_host_req_complete dev 10:15, packet 0x7fad5c018b40, status 0, length 5 usb_host_req_control dev 10:15, packet 0x7fad5c018c30, req 0x8006, value 3840, index 0 usb_host_req_complete dev 10:15, packet 0x7fad5c018c30, status 0, length 22 usb_host_req_control dev 10:15, packet 0x7fad5c018d20, req 0x8006, value 512, index 0 usb_host_req_complete dev 10:15, packet 0x7fad5c018d20, status 0, length 44 usb_host_req_control dev 10:15, packet 0x7fad5c018e10, req 0x8006, value 771, index 1033 usb_host_req_complete dev 10:15, packet 0x7fad5c018e10, status 0, length 22 usb_host_req_control dev 10:15, packet 0x7fad5c018f00, req 0x9, value 1, index 0 usb_host_set_config dev 10:15, config 1 usb_host_detach_kernel dev 10:15, if 0 usb_host_claim_interface dev 10:15, config 1, if 0 usb_host_parse_config dev 10:15, value 1, active 1 usb_host_parse_interface dev 10:15, num 0, alt 0, active 1 usb_host_parse_endpoint dev 10:15, ep 2, out, bulk, active 1 usb_host_parse_endpoint dev 10:15, ep 1, in, bulk, active 1 usb_host_req_emulated dev 10:15, packet 0x7fad5c018f00, status 0 usb_host_req_data dev 10:15, packet 0x7fad5c076d80, in 0, ep 2, size 31 usb_host_req_complete dev 10:15, packet 0x7fad5c076d80, status -5, length 31 Everything looks normal, except for the first data request failing for some reason. Doesn't happen every time. This failed requests makes the guest reset the device, and after resetting everything works fine. At least with my stick. Sibiao's stick seems to crash + stop responding instead. Ignoring reset requests isn't really an option IMHO, the guest must be able to put the device into a known state somehow. So I think the question is why does the first data request fail? (In reply to Gerd Hoffmann from comment #3) > So I think the question is why does the first data request fail? Can you try doing: export LIBUSB_DEBUG=5 Before starting qemu and see if libusb's debugging output sheds any alight on this (it would good to know the actual errno the kernel returns when things fail). usb_host_req_data dev 10:19, packet 0x7fcaf8007b50, in 0, ep 2, size 31 libusbx: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 31 libusbx: debug [libusb_handle_events_timeout_completed] doing our own event handling libusbx: debug [handle_events] poll() 3 fds with timeout in 0ms libusbx: debug [handle_events] poll() returned 1 libusbx: debug [reap_for_handle] urb type=3 status=-71 transferred=0 libusbx: debug [handle_bulk_completion] handling completion status -71 of bulk urb 1/1 libusbx: debug [handle_bulk_completion] low level error -71 libusbx: debug [disarm_timerfd] libusbx: debug [usbi_handle_transfer_completion] transfer 0x7fcaf8011b28 has callback 0x7fcb210ec230 usb_host_req_complete dev 10:19, packet 0x7fcaf8007b50, status -5, length 31 error 71 is EPROTO, which according to linux/Documentation/usb/error-codes.txt means:
-EPROTO (*, **) a) bitstuff error
b) no response packet received within the
prescribed bus turn-around time
c) unknown USB error
(*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate
hardware problems such as bad devices (including firmware) or cables.
(**) This is also one of several codes that different kinds of host
controller use to indicate a transfer has failed because of device
disconnect. In the interval before the hub driver starts disconnect
processing, devices may receive such fault reports for every request.
So not really helpful. Could it be as simple as a bad cable / dirty connector ?
No cable involved. No hub involved. It's a usb3 stick plugged directly into a xhci root port. Also in case an error happens it is always the first guest-initiated data transfer. In case of a connector issue it wouldn't be *that* deterministic. Created attachment 796364 [details]
full usbmon log
In usbmon it looks like this:
ffff880211b20240 3134102234 S Bo:4:003:2 -115 31 = 55534243 01000000 24000000 80000612 00000024 00000000 00000000 000000
ffff880211b20240 3134105557 C Bo:4:003:2 -71 0
(-71 == EPROTO)
No more clues :(
On the host: unplug device from xhci, plug into ehci, restart guest -> problem disappears. So it seems to be something in the host kernel xhci driver. Seems to be gone in latest upstream qemu. I suspect the changed reset handling could have improved things here. /me goes cherry-pick usb-host bugfixes ... Kicked scratch build: http://brewweb.devel.redhat.com/brew/taskinfo?taskID=6526760 please test. (In reply to Gerd Hoffmann from comment #11) > Kicked scratch build: > http://brewweb.devel.redhat.com/brew/taskinfo?taskID=6526760 > please test. Retest this bug, using scratch build: http://brewweb.devel.redhat.com/brew/taskinfo?taskID=6526760 Version: qemu-kvm-1.5.3-13.el7.bz980415.1.x86_64 Steps as the comments 0. The command line as the followings: <cli>: # /usr/libexec/qemu-kvm -M q35 -cpu SandyBridge -enable-kvm -m 4096 -smp 4,sockets=2,cores=2,threads=1 -no-kvm-pit-reinjection \ -netdev tap,id=hostnet0,vhost=on,queues=4,script=/etc/qemu-ifup \ -device virtio-net-pci,mq=on,vectors=17,netdev=hostnet0,id=virtio-net-pci0,mac=24:be:05:14:0d:82,addr=0x17,bootindex=2 \ -k en-us -boot menu=on,reboot-timeout=-1,strict=on -qmp tcp:0:4445,server,nowait -serial unix:/tmp/ttyS0,server,nowait -vnc :3 -spice port=5932,disable-ticketing -vga qxl -monitor stdio -monitor tcp:0:7445,server,nowait -monitor unix:/tmp/monitor1,server,nowait \ -drive file=/home/rhel7base.qcow2_v3,if=none,id=drive-system-disk,cache=writeback \ -device virtio-scsi-pci,id=scsi0,ioeventfd=off \ -device scsi-hd,bus=scsi0.0,drive=drive-system-disk,id=disk,bootindex=0,physical_block_size=4096,logical_block_size=512 \ -device nec-usb-xhci,id=xhci0 -device usb-host,hostbus=6,hostaddr=4,id=usb-stick --------- Before boot qemu-kvm, lsusb in host: # lsusb Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 003 Device 002: ID 0557:7000 ATEN International Co., Ltd Hub Bus 006 Device 004: ID 1516:6221 CompUSA Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 003: ID 0557:2213 ATEN International Co., Ltd CS682 2-Port USB 2.0 DVI KVM Switch ----- Inside guest can use this usb3.0 stick correctly(Test via shell script: test.sh), and lsusb result is correctly, too. ---------- # cat test.sh #! /bin/sh umount /mnt mount /dev/sdb /mnt sleep 3 dd if=/dev/urandom of=/mnt/urandom bs=1M count=10 md5sum /mnt/urandom > /tmp/juli md5_before=`awk '{print $1}' /tmp/juli` #echo 'juli'$md5_before'juli' cp /mnt/urandom /home/ md5sum /home/urandom > /tmp/juli_1 md5_later=`awk '{print $1}' /tmp/juli_1` #echo $md5_later if [ "$md5_before" == "$md5_later" ]; then echo "Two md5 is the same, bug is verified." else echo "Two md5 different. Have problems!!!" fi ------- # lsusb Bus 002 Device 002: ID 1516:6221 CompUSA Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub ----- After shutdown guest, then check the usb3.0 stick in the host again. Host can use this stick as normal. No kernel dmesg error about usb3.0. # lsusb Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 003 Device 002: ID 0557:7000 ATEN International Co., Ltd Hub Bus 006 Device 004: ID 1516:6221 CompUSA Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 003: ID 0557:2213 ATEN International Co., Ltd CS682 2-Port USB 2.0 DVI KVM Switch ----- Do above steps for 10 times, the results are all correct. Based on above retest, this bug has been verified. Thank you. Best Regards, Jun Li patches posted. Fix included in qemu-kvm-1.5.3-15.el7 Try reproduce this bug with qemu-kvm-1.5.1-2.el7.x86_64, but got qemu-kvm core dumped.
Host:
qemu-kvm-1.5.1-2.el7.x86_64
kernel-3.10.0-64.el7.x86_64
Guest:
RHEL7-64
cli:
gdb --args /usr/libexec/qemu-kvm \
-M pc \
-cpu SandyBridge \
-m 4G \
-smp 4,sockets=2,cores=2,threads=1,maxcpus=16 \
-enable-kvm \
-name rhel7-64 \
-uuid 990ea161-6b67-47b2-b803-19fb01d30d12 \
-smbios type=1,manufacturer='Red Hat',product='RHEV Hypervisor',version=el6,serial=koTUXQrb,uuid=feebc8fd-f8b0-4e75-abc3-e63fcdb67170 \
-k en-us \
-rtc base=localtime,clock=host,driftfix=slew \
-nodefaults \
-monitor stdio \
-qmp tcp:0:6666,server,nowait \
-boot menu=on \
-bios /usr/share/seabios/bios.bin \
-vga qxl \
-spice port=5900,disable-ticketing \
-chardev socket,id=seabioslog,path=/tmp/seabios,server,nowait \
-device isa-debugcon,chardev=seabioslog,iobase=0x402 \
-monitor unix:/tmp/guest-sock,server,nowait \
-drive file=/mnt/rhel7-64.raw,if=none,id=drive-ide0-0-1,format=raw,cache=none,aio=threads \
-device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=0 \
-device virtio-balloon-pci,id=balloon0 \
-device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0 \
-chardev file,id=channel1,path=/home/helloworld1.txt \
-device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial0.0,id=port1,nr=1 \
-chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmp,server,nowait \
-mon chardev=qmp_id_qmpmonitor1,mode=control \
-device nec-usb-xhci,id=xhci0 \
-device usb-host,hostbus=6,hostaddr=2,id=usb-stick,bus=xhci0.0 \
Result:
qemu-kvm core dumped.
(qemu)
(qemu) [Thread 0x7fffdb7fe700 (LWP 4623) exited]
[New Thread 0x7fffdb7fe700 (LWP 4627)]
libusbx: error [_open_sysfs_attr] open /sys/bus/usb/devices/6-1/bConfigurationValue failed ret=-1 errno=2
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffebdab700 (LWP 4617)]
xhci_reset_ep (epid=<optimized out>, slotid=1, xhci=0x7fffe8338010) at hw/usb/hcd-xhci.c:1435
1435 if (!dev) {
Missing separate debuginfos, use: debuginfo-install alsa-lib-1.0.27.2-1.el7.x86_64 celt051-0.5.1.3-6.el7.x86_64 cyrus-sasl-lib-2.1.26-13.el7.x86_64 cyrus-sasl-md5-2.1.26-13.el7.x86_64 cyrus-sasl-plain-2.1.26-13.el7.x86_64 dbus-libs-1.6.12-6.el7.x86_64 flac-libs-1.3.0-2.el7.x86_64 glib2-2.36.3-2.el7.x86_64 glibc-2.17-40.el7.x86_64 gmp-5.1.1-3.el7.x86_64 gnutls-3.1.16-1.el7.x86_64 gsm-1.0.13-9.el7.x86_64 json-c-0.11-1.el7.x86_64 keyutils-libs-1.5.8-1.el7.x86_64 krb5-libs-1.11.3-37.el7.x86_64 libICE-1.0.8-5.el7.x86_64 libSM-1.2.1-5.el7.x86_64 libX11-1.6.0-1.el7.x86_64 libXau-1.0.8-1.el7.x86_64 libXext-1.3.2-1.el7.x86_64 libXi-1.7.2-1.el7.x86_64 libXtst-1.2.2-1.el7.x86_64 libaio-0.3.109-10.el7.x86_64 libasyncns-0.8-5.el7.x86_64 libattr-2.4.46-10.el7.x86_64 libcap-2.22-6.el7.x86_64 libcom_err-1.42.8-2.el7.x86_64 libdb-5.3.21-14.el7.x86_64 libgcc-4.8.2-7.el7.x86_64 libgcrypt-1.5.3-1.el7.x86_64 libgpg-error-1.12-1.el7.x86_64 libiscsi-1.7.0-6.el7.x86_64 libjpeg-turbo-1.2.90-3.el7.x86_64 libogg-1.3.0-5.el7.x86_64 libpng-1.5.13-2.el7.x86_64 libseccomp-2.1.1-0.el7.x86_64 libselinux-2.2.1-2.el7.x86_64 libsndfile-1.0.25-7.el7.x86_64 libtasn1-3.3-1.el7.x86_64 libusbx-1.0.15-2.el7.x86_64 libuuid-2.23.2-7.el7.x86_64 libvorbis-1.3.3-4.el7.x86_64 libxcb-1.9-3.el7.x86_64 nettle-2.6-3.el7.x86_64 nspr-4.10.2-2.el7.x86_64 nss-3.15.3-2.el7.x86_64 nss-softokn-freebl-3.15.3-1.el7.x86_64 nss-util-3.15.3-1.el7.x86_64 openssl-libs-1.0.1e-25.el7.x86_64 p11-kit-0.18.7-2.el7.x86_64 pcre-8.32-8.el7.x86_64 pixman-0.30.0-1.el7.x86_64 pulseaudio-libs-3.0-11.el7.x86_64 tcp_wrappers-libs-7.6-75.el7.x86_64 usbredir-0.6-5.el7.x86_64 xz-libs-5.1.2-5alpha.el7.x86_64 zlib-1.2.7-10.el7.x86_64
(gdb) bt
#0 xhci_reset_ep (epid=<optimized out>, slotid=1, xhci=0x7fffe8338010) at hw/usb/hcd-xhci.c:1435
#1 xhci_process_commands (xhci=0x7fffe8338010) at hw/usb/hcd-xhci.c:2528
#2 0x0000555555785c62 in access_with_adjusted_size (addr=addr@entry=0, value=value@entry=0x7fffebdaaa40,
size=size@entry=4, access_size_min=<optimized out>, access_size_max=<optimized out>,
access=access@entry=0x555555786220 <memory_region_write_accessor>, opaque=opaque@entry=0x7fffe8338a30)
at /usr/src/debug/qemu-1.5.1/memory.c:364
#3 0x000055555578abfb in memory_region_dispatch_write (size=4, data=0, addr=0, mr=0x7fffe8338a30)
at /usr/src/debug/qemu-1.5.1/memory.c:916
#4 io_mem_write (mr=0x7fffe8338a30, addr=0, val=<optimized out>, size=4) at /usr/src/debug/qemu-1.5.1/memory.c:1597
#5 0x0000555555785c62 in access_with_adjusted_size (addr=addr@entry=0, value=value@entry=0x7fffebdaaaf0,
size=size@entry=4, access_size_min=<optimized out>, access_size_max=<optimized out>,
access=access@entry=0x555555786220 <memory_region_write_accessor>, opaque=opaque@entry=0x7fffe0006a60)
at /usr/src/debug/qemu-1.5.1/memory.c:364
#6 0x000055555578abfb in memory_region_dispatch_write (size=4, data=0, addr=0, mr=0x7fffe0006a60)
at /usr/src/debug/qemu-1.5.1/memory.c:916
#7 io_mem_write (mr=0x7fffe0006a60, addr=0, val=<optimized out>, size=size@entry=4)
at /usr/src/debug/qemu-1.5.1/memory.c:1597
#8 0x00005555557391dd in address_space_rw (as=as@entry=0x55555644dfc0 <address_space_memory>, addr=4227932160,
buf=buf@entry=0x7ffff7ff0028 "", len=4, is_write=true) at /usr/src/debug/qemu-1.5.1/exec.c:1916
#9 0x00005555557392d5 in cpu_physical_memory_rw (addr=<optimized out>, buf=buf@entry=0x7ffff7ff0028 "",
len=<optimized out>, is_write=<optimized out>) at /usr/src/debug/qemu-1.5.1/exec.c:1998
#10 0x00005555557846f5 in kvm_cpu_exec (env=env@entry=0x5555564e9b20) at /usr/src/debug/qemu-1.5.1/kvm-all.c:1643
#11 0x000055555572fdd5 in qemu_kvm_cpu_thread_fn (arg=0x5555564e9b20) at /usr/src/debug/qemu-1.5.1/cpus.c:759
#12 0x00007ffff625cde3 in start_thread () from /lib64/libpthread.so.0
#13 0x00007ffff39e226d in clone () from /lib64/libc.so.6
Host dmesg:
[57212.824027] kvm [4611]: vcpu0 unhandled rdmsr: 0xe7
[57218.089466] xhci_hcd 0000:03:00.0: Timeout while waiting for address device command
[57222.260168] xhci_hcd 0000:03:00.0: Signal while waiting for address device command
[57222.469368] usb 6-1: device not accepting address 2, error -62
[57222.979828] usb 6-1: USB disconnect, device number 2
[57222.985475] xhci_hcd 0000:03:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88020ef8a000
[57222.995340] xhci_hcd 0000:03:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88020ef8a040
Confirm with sluo the command line and test scenario is the same, downgrade to qemu-kvm-1.5.1-1.el7.x86_64, also got qemu-kvm core dumped, as sluo mentioned he just hit twice, not easy reproduce this bug, so update the latest qemu-kvm and kernel package for verify this bug. Host: qemu-kvm-1.5.3-31.el7.x86_64 qemu-img-1.5.3-31.el7.x86_64 qemu-kvm-tools-1.5.3-31.el7.x86_64 qemu-kvm-common-1.5.3-31.el7.x86_64 qemu-kvm-debuginfo-1.5.3-31.el7.x86_64 kernel-3.10.0-66.el7.x86_64 seabios-1.7.2.2-6.el7.x86_64 Guest: kernel-3.10.0-64.el7.x86_64 Steps: 1 boot vm with: gdb --args /usr/libexec/qemu-kvm \ -M pc \ -cpu SandyBridge \ -m 4G \ -smp 4,sockets=2,cores=2,threads=1,maxcpus=16 \ -enable-kvm \ -name rhel7-64 \ -uuid 990ea161-6b67-47b2-b803-19fb01d30d12 \ -smbios type=1,manufacturer='Red Hat',product='RHEV Hypervisor',version=el6,serial=koTUXQrb,uuid=feebc8fd-f8b0-4e75-abc3-e63fcdb67170 \ -k en-us \ -rtc base=localtime,clock=host,driftfix=slew \ -nodefaults \ -monitor stdio \ -qmp tcp:0:6666,server,nowait \ -boot menu=on \ -bios /usr/share/seabios/bios.bin \ -vga qxl \ -spice port=5900,disable-ticketing \ -chardev socket,id=seabioslog,path=/tmp/seabios,server,nowait \ -device isa-debugcon,chardev=seabioslog,iobase=0x402 \ -monitor unix:/tmp/guest-sock,server,nowait \ -drive file=/mnt/rhel7-64.raw,if=none,id=drive-ide0-0-1,format=raw,cache=none,aio=threads \ -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=0 \ -device virtio-balloon-pci,id=balloon0 \ -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0 \ -chardev file,id=channel1,path=/home/helloworld1.txt \ -device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial0.0,id=port1,nr=1 \ -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmp,server,nowait \ -mon chardev=qmp_id_qmpmonitor1,mode=control \ -device nec-usb-xhci,id=xhci0 \ -device usb-host,hostbus=6,hostaddr=2,id=usb-stick,bus=xhci0.0 \ Result: qemu-kvm works well, format usb storage in guest and read/write data, guest works well, reboot and shutdown guest normal with usb. So this bug has been fixed. This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request. |