Bug 980415 - libusbx: error [_open_sysfs_attr] open /sys/bus/usb/devices/4-1/bConfigurationValue failed ret=-1 errno=2
libusbx: error [_open_sysfs_attr] open /sys/bus/usb/devices/4-1/bConfiguratio...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
7.0
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Gerd Hoffmann
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-02 06:18 EDT by Sibiao Luo
Modified: 2014-06-17 23:30 EDT (History)
15 users (show)

See Also:
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 09:02:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
full usbmon log (119.31 KB, text/plain)
2013-09-11 09:25 EDT, Gerd Hoffmann
no flags Details

  None (edit)
Description Sibiao Luo 2013-07-02 06:18:59 EDT
Description of problem:
same scenario to bug 980377, but different result, maybe not the same issue, so file a new bug to tracing it.
pathrough USB3.0 stick to guest var xhci controller, the guest can't get the usb3.0 stick successfully, and there are a 'libusbx: error [_open_sysfs_attr] open /sys/bus/usb/devices/4-1/bConfigurationValue failed ret=-1 errno=2' error appear in HMP monitor.

Version-Release number of selected component (if applicable):
host info:
3.10.0-0.rc7.64.el7.x86_64
qemu-kvm-1.5.1-1.el7.x86_64
guest info:
3.10.0-0.rc7.64.el7.x86_64

How reproducible:
only hit 2 times.

Steps to Reproduce:
1.insert a usb3.0 stick to host var physically XHCI controller.
2.get the bus and addr of usb3.0 stick info.
# lsusb
Bus 004 Device 003: ID 1516:6221 CompUSA 
3.pathrough USB3.0 stick to guest var xhci controller and check it in guest.
# /usr/libexec/qemu-kvm -M q35 -cpu SandyBridge -enable-kvm -m 4096 -smp 4,sockets=2,cores=2,threads=1 -no-kvm-pit-reinjection...-device nec-usb-xhci,id=xhci0,addr=0x8 -device usb-host,hostbus=4,hostaddr=3,id=usb-stick,bus=xhci0.0
4.shutdown guest and check the host dmesg.

Actual results:
after step 1, got the host dmesg as following.
# dmesg 
[  594.505246] usb 4-1: new SuperSpeed USB device number 3 using xhci_hcd
[  594.517523] usb 4-1: Parent hub missing LPM exit latency info.  Power management will be impacted.
[  594.519753] usb 4-1: New USB device found, idVendor=1516, idProduct=6221
[  594.519758] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  594.519761] usb 4-1: SerialNumber: ā
[  594.520673] usb-storage 4-1:1.0: USB Mass Storage device detected
[  594.520776] scsi7 : usb-storage 4-1:1.0
[  595.526092] scsi 7:0:0:0: Direct-Access                               1.00 PQ: 0 ANSI: 6
[  595.526399] sd 7:0:0:0: Attached scsi generic sg2 type 0
[  595.526644] sd 7:0:0:0: [sdb] 30867456 512-byte logical blocks: (15.8 GB/14.7 GiB)
[  595.526768] sd 7:0:0:0: [sdb] Write Protect is off
[  595.526770] sd 7:0:0:0: [sdb] Mode Sense: 2f 00 00 00
[  595.526890] sd 7:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[  595.528923]  sdb: unknown partition table
[  595.529587] sd 7:0:0:0: [sdb] Attached SCSI removable disk

after step 3, guest boot up successfully but did not find the usb3.0 in guest, and there are some error output in HMP monitor.
(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)

And i check the host dmesg:
# dmesg
[  804.832738] device tap0 entered promiscuous mode
[  804.832790] switch: port 2(tap0) entered forwarding state
[  804.832796] switch: port 2(tap0) entered forwarding state
[  814.086239] kvm [2091]: vcpu0 unhandled rdmsr: 0x345
[  814.100344] kvm_set_msr_common: 118 callbacks suppressed
[  814.100346] kvm [2091]: vcpu0 unhandled wrmsr: 0x680 data 0
[  814.105929] kvm [2091]: vcpu0 unhandled wrmsr: 0x6c0 data 0
[  814.111540] kvm [2091]: vcpu0 unhandled wrmsr: 0x681 data 0
[  814.117133] kvm [2091]: vcpu0 unhandled wrmsr: 0x6c1 data 0
[  814.122726] kvm [2091]: vcpu0 unhandled wrmsr: 0x682 data 0
[  814.128318] kvm [2091]: vcpu0 unhandled wrmsr: 0x6c2 data 0
[  814.133911] kvm [2091]: vcpu0 unhandled wrmsr: 0x683 data 0
[  814.139499] kvm [2091]: vcpu0 unhandled wrmsr: 0x6c3 data 0
[  814.145072] kvm [2091]: vcpu0 unhandled wrmsr: 0x684 data 0
[  814.150657] kvm [2091]: vcpu0 unhandled wrmsr: 0x6c4 data 0
[  814.675958] kvm [2091]: vcpu1 unhandled rdmsr: 0xe8
[  814.680866] kvm [2091]: vcpu1 unhandled rdmsr: 0xe7
[  814.685766] kvm [2091]: vcpu1 unhandled rdmsr: 0xce
[  814.691008] kvm [2091]: vcpu1 unhandled rdmsr: 0xce
[  848.071189] xhci_hcd 0000:02:00.0: Timeout while waiting for address device command
[  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
[  854.013422] xhci_hcd 0000:02:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff880203a43780
[  854.013426] xhci_hcd 0000:02:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff880203a437c0
[  854.127463] xhci_hcd 0000:02:00.0: Bad Slot ID 2
[  854.127467] xhci_hcd 0000:02:00.0: Could not allocate xHCI USB device data structures
[  854.127472] hub 4-0:1.0: couldn't allocate port 1 usb_device
[  967.265900] switch: port 2(tap0) entered disabled state

after step 4, check the host dmesg.
# dmesg
[  967.266009] device tap0 left promiscuous mode
[  967.266016] switch: port 2(tap0) entered disabled state

Expected results:
it can passthrough the usb3.0 stick to guest and guest can get the disk succesfully.

Additional info:
Comment 1 Sibiao Luo 2013-07-02 06:22:02 EDT
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)
Comment 2 Hans de Goede 2013-07-26 11:12:51 EDT
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.
Comment 3 Gerd Hoffmann 2013-07-31 06:26:37 EDT
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?
Comment 4 Hans de Goede 2013-07-31 10:55:36 EDT
(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).
Comment 5 Gerd Hoffmann 2013-07-31 11:33:22 EDT
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
Comment 6 Hans de Goede 2013-07-31 11:49:20 EDT
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 ?
Comment 7 Gerd Hoffmann 2013-08-01 02:55:32 EDT
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.
Comment 8 Gerd Hoffmann 2013-09-11 09:25:34 EDT
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 :(
Comment 9 Gerd Hoffmann 2013-09-11 09:46:57 EDT
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.
Comment 10 Gerd Hoffmann 2013-11-05 06:18:43 EST
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 ...
Comment 11 Gerd Hoffmann 2013-11-05 06:46:19 EST
Kicked scratch build:
http://brewweb.devel.redhat.com/brew/taskinfo?taskID=6526760
please test.
Comment 12 Jun Li 2013-11-06 02:07:08 EST
(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
Comment 13 Gerd Hoffmann 2013-11-06 07:17:51 EST
patches posted.
Comment 14 Miroslav Rezanina 2013-11-07 03:25:15 EST
Fix included in qemu-kvm-1.5.3-15.el7
Comment 16 mazhang 2014-01-06 21:59:26 EST
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
Comment 17 mazhang 2014-01-06 22:39:34 EST
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.
Comment 19 Ludek Smid 2014-06-13 09:02:26 EDT
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.

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