Bug 890320 - [abrt] qemu-system-x86-1.2.2-1.fc18: ehci_set_state: Process /usr/bin/qemu-kvm was killed by signal 11 (SIGSEGV)
Summary: [abrt] qemu-system-x86-1.2.2-1.fc18: ehci_set_state: Process /usr/bin/qemu-kv...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 18
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:f5d6c09c845bfd65e35bb2e5105...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-26 11:11 UTC by Tim Knowles
Modified: 2013-04-18 02:28 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-18 02:28:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: backtrace (35.80 KB, text/plain)
2012-12-26 11:11 UTC, Tim Knowles
no flags Details
File: build_ids (3.72 KB, text/plain)
2012-12-26 11:11 UTC, Tim Knowles
no flags Details
File: cgroup (283 bytes, text/plain)
2012-12-26 11:11 UTC, Tim Knowles
no flags Details
File: core_backtrace (573 bytes, text/plain)
2012-12-26 11:11 UTC, Tim Knowles
no flags Details
File: dso_list (7.94 KB, text/plain)
2012-12-26 11:11 UTC, Tim Knowles
no flags Details
File: environ (85 bytes, text/plain)
2012-12-26 11:11 UTC, Tim Knowles
no flags Details
File: limits (1.29 KB, text/plain)
2012-12-26 11:11 UTC, Tim Knowles
no flags Details
File: maps (48.34 KB, text/plain)
2012-12-26 11:11 UTC, Tim Knowles
no flags Details
File: open_fds (4.60 KB, text/plain)
2012-12-26 11:11 UTC, Tim Knowles
no flags Details
File: proc_pid_status (914 bytes, text/plain)
2012-12-26 11:12 UTC, Tim Knowles
no flags Details
File: var_log_messages (7.78 KB, text/plain)
2012-12-26 11:12 UTC, Tim Knowles
no flags Details
lsusb.log (20.67 KB, text/x-log)
2013-04-05 14:40 UTC, Tim Knowles
no flags Details
libvirt log (812.74 KB, text/x-log)
2013-04-07 21:08 UTC, Tim Knowles
no flags Details

Description Tim Knowles 2012-12-26 11:11:34 UTC
Description of problem:
Hi Guys,

I have had this qemu-kvm segfault 7 times over the last 3 days since migrating from F16 to the F18 beta.  I am getting it only in the 2 VM's that have a Nova-T USB2 stick passed through to them.  The third VM which does need any USB devices has worked without an issue over this time.

The first VM is an Ubuntu 12.04 64bit instance running MythTV.  It has run on the same host (F16 + virt-preview) for the last 9 months without issue.  The new VM is Ubuntu 12.10 64bit running TVheadend.  

The steps below are from the last crash which occured in the Ubuntu 12.10 VM. 

1) Power off then power on the host
2) Start guest VM (ubuntu 12.10) with a single Hauupage Nova-T USB 2 stick passed through to the guest
3) In the guest start watching/recording TV with TVheadend
4) Guest becomes unresponsive
5) libvirt guest log shows "
EHCI: Warning packet completed but not processed
2012-12-26 10:45:20.341+0000: shutting down"
6) dmesg shows a segfault in qemu-kvm:
"[  185.436111] qemu-kvm[2353]: segfault at b2e ip 00007fe5bf7b09a5 sp 00007fff4b252460 error 6 in qemu-kvm[7fe5bf62f000+3b9000]"


Version-Release number of selected component:
qemu-system-x86-1.2.2-1.fc18

Additional info:
backtrace_rating: 4
cmdline:        /usr/bin/qemu-kvm -name hera -S -M pc-1.0 -cpu Nehalem,+rdtscp,+pdcm,+xtpr,+tm2,+est,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -enable-kvm -m 2048 -smp 1,sockets=1,cores=1,threads=1 -uuid bdb11a67-4bb6-88b2-3b8a-d8104a6d0249 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/hera.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x9.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x9 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x9.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x9.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive file=/mnt/hera-os_a.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/mnt/hera-swap_a.qcow2,if=none,id=drive-virtio-disk1,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/mnt/hera-home_a.qcow2,if=none,id=drive-virtio-disk2,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk2,id=virtio-disk2 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/var/lib/libvirt/images/ubuntu-12.10-desktop-amd64.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw,cache=none -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=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:f7:19:01,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 -spice port=5901,addr=0.0.0.0,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -device usb-host,hostbus=1,hostaddr=3,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8
crash_function: ehci_set_state
executable:     /usr/bin/qemu-kvm
kernel:         3.6.11-3.fc18.x86_64
remote_result:  NOTFOUND
uid:            107

Truncated backtrace:
Thread no. 1 (9 frames)
 #0 ehci_set_state at /usr/src/debug/qemu-kvm-1.2.0/hw/usb/hcd-ehci.c:628
 #1 ehci_free_packet at /usr/src/debug/qemu-kvm-1.2.0/hw/usb/hcd-ehci.c:760
 #2 ehci_cancel_queue at /usr/src/debug/qemu-kvm-1.2.0/hw/usb/hcd-ehci.c:808
 #3 ehci_free_queue at /usr/src/debug/qemu-kvm-1.2.0/hw/usb/hcd-ehci.c:831
 #4 ehci_queues_rip_unseen at /usr/src/debug/qemu-kvm-1.2.0/hw/usb/hcd-ehci.c:880
 #5 ehci_advance_async_state at /usr/src/debug/qemu-kvm-1.2.0/hw/usb/hcd-ehci.c:2347
 #7 qemu_bh_poll at async.c:71
 #8 main_loop_wait at main-loop.c:506
 #9 main_loop at /usr/src/debug/qemu-kvm-1.2.0/vl.c:1643

Comment 1 Tim Knowles 2012-12-26 11:11:41 UTC
Created attachment 669191 [details]
File: backtrace

Comment 2 Tim Knowles 2012-12-26 11:11:44 UTC
Created attachment 669192 [details]
File: build_ids

Comment 3 Tim Knowles 2012-12-26 11:11:46 UTC
Created attachment 669193 [details]
File: cgroup

Comment 4 Tim Knowles 2012-12-26 11:11:48 UTC
Created attachment 669194 [details]
File: core_backtrace

Comment 5 Tim Knowles 2012-12-26 11:11:50 UTC
Created attachment 669195 [details]
File: dso_list

Comment 6 Tim Knowles 2012-12-26 11:11:52 UTC
Created attachment 669196 [details]
File: environ

Comment 7 Tim Knowles 2012-12-26 11:11:54 UTC
Created attachment 669197 [details]
File: limits

Comment 8 Tim Knowles 2012-12-26 11:11:57 UTC
Created attachment 669198 [details]
File: maps

Comment 9 Tim Knowles 2012-12-26 11:11:59 UTC
Created attachment 669199 [details]
File: open_fds

Comment 10 Tim Knowles 2012-12-26 11:12:01 UTC
Created attachment 669200 [details]
File: proc_pid_status

Comment 11 Tim Knowles 2012-12-26 11:12:03 UTC
Created attachment 669201 [details]
File: var_log_messages

Comment 12 Cole Robinson 2013-04-01 18:37:26 UTC
Tim, can you still reproduce with latest F18 bits?

Hans, anything stick out here? code is probably crufty compared to qemu.git, but we are carrying a patch of yours that touches this area (it's also in 1.2.2 stable):

http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0171-ehci-Don-t-set-seen-to-0-when-removing-unseen-queue-.patch?h=f18

Comment 13 Hans de Goede 2013-04-03 09:29:44 UTC
Hi,

(In reply to comment #12)
> Hans, anything stick out here? code is probably crufty compared to qemu.git,
> but we are carrying a patch of yours that touches this area (it's also in
> 1.2.2 stable):

Ah, yes, this is a known and fixed upstream issue. Tim is hitting an exotic error handling path (which is why the "EHCI: Warning packet completed but not processed" warning is there). And in this path there is a use-after-free issue. In Tim's setup the moon seems to be aligned just right as he is hitting that path repeatedly...

I've just started an updated qemu-build for F-18 which includes the upstream fix for this as well as a related fix for another error in the same error-handling-path.

Tim, can you please give the new qemu build a try once the updates-system posts a notice about it being available here?

Thanks & Regards,

Hans

Comment 14 Fedora Update System 2013-04-03 09:59:07 UTC
qemu-1.2.2-9.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/qemu-1.2.2-9.fc18

Comment 15 Tim Knowles 2013-04-04 18:10:34 UTC
I've updated to 1.2.2-9 after getting the rpm's directly from 

http://kojipkgs.fedoraproject.org//packages/qemu/1.2.2/9.fc18/x86_64

Unfortunately I still have a problem.  The segfault has gone but the VM still crashes and reports this in the libvirt logs

EHCI: Warning packet completed but not processed
qemu-kvm: /builddir/build/BUILD/qemu-kvm-1.2.0/hw/usb/hcd-ehci.c:2159: ehci_state_executing: Assertion `p->qtdaddr == q->qtdaddr' failed.

Comment 16 Fedora Update System 2013-04-04 23:56:38 UTC
Package qemu-1.2.2-9.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing qemu-1.2.2-9.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-4817/qemu-1.2.2-9.fc18
then log in and leave karma (feedback).

Comment 17 Hans de Goede 2013-04-05 11:53:15 UTC
Hi Tim,

(In reply to comment #15)
> I've updated to 1.2.2-9 after getting the rpm's directly from 
> 
> http://kojipkgs.fedoraproject.org//packages/qemu/1.2.2/9.fc18/x86_64
> 
> Unfortunately I still have a problem.  The segfault has gone but the VM
> still crashes and reports this in the libvirt logs
> 
> EHCI: Warning packet completed but not processed
> qemu-kvm: /builddir/build/BUILD/qemu-kvm-1.2.0/hw/usb/hcd-ehci.c:2159:
> ehci_state_executing: Assertion `p->qtdaddr == q->qtdaddr' failed.

Hmm, that what supposed to be fixed by the second patch I included...

I've a theory as to why this is still happening. But in order to fix this properly
I need to have a better grasp of what is happening exactly.

So I've done a scratch build with a patch which fixes this with "a big hammer"
and adds some debug logging to figure out what exactly is going on.

Can you please give this build a try:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5217715

And then do whatever you do to make the vms crash. They should no longer
crash, instead the qemu log file should get lines like this:
EHCI: Freeing abnormal completed packet async ....

These lines should be between 2 lines like this:
EHCI: Start freeing queue for ep XX
EHCI: Freeing abnormal completed packet async ....
EHCI: Freeing abnormal completed packet async ....
EHCI: Freeing abnormal completed packet async ....
EHCI: Done freeing queue for ep XX

Once you've some of these in your logs, please copy and paste them here, please include the surrounding EHCI: Start freeing queue for ep XX / EHCI: Done freeing queue for ep XX lines as I also want to know how these are grouped together.

Besides that I'll need some more info from you:

1) We're talking about these USB devices, correct? :
http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-T-USB2

2) Are these device plugged into USB-2 or USB-3 ports?

3) Can you please on the host with these devices run: "lsusb -v > lsusb.log" and attach lsusb.log here?

Thanks,

Hans

Comment 18 Tim Knowles 2013-04-05 14:40:26 UTC
Created attachment 731920 [details]
lsusb.log

lsusb.log

Comment 19 Tim Knowles 2013-04-05 14:54:07 UTC
Hi Hans,

Debug logs from the scratch build copy & pasted below

1) It's this device:
http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-T-Stick

Kindly note I have two of these USB sticks and both of them cause the issue.  I also get this issue on two different hosts, a Dell Studio XPS 435MT (ICH10) desktop and a Dell M65 (ICH7) laptop.


2) USB2


3) See attached file lsusb.log


debug logs
==========

EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 1
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 02
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 0
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 0
EHCI: Done freeing queue for ep 02
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 1
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 1
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 1
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 02
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 0
EHCI: Done freeing queue for ep 02
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 1
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 1
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 1
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 1
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 1
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 1
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 1
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 1
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 1
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 1
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Freeing abnormal completed packet async 2 status -6 dir in queue-halt 1
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02

Comment 20 Hans de Goede 2013-04-06 13:25:50 UTC
Hi Tim,

Thanks for all the info. I'm afraid the condition which I believe triggers the bug has not happened in the logs you've pasted in comment #19, my bad.

I'm looking for log messages with the: "EHCI: Freeing abnormal completed packet " ... blocks
in there, where async is 3, not 2 as in your logs.

async being 3 is what triggered the (now disabled) "EHCI: Warning packet completed but not processed" messages. My patch disables the special handling of that scenario, but it should still trigger with the patched qemu, which should result in log messages where async is 3.

Thanks,

Hans

Comment 21 Tim Knowles 2013-04-07 10:14:28 UTC
Hi Hans - This morning I've captured 4 occurrences of the "async 3" error in the libvirt logs.  I've copied & pasted one of the four occurrences below.  Is that enough info?


EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 02
EHCI: Freeing abnormal completed packet async 3 status 20480 dir in queue-halt 0
EHCI: Done freeing queue for ep 02
EHCI: Start freeing queue for ep 02
EHCI: Done freeing queue for ep 02
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00
EHCI: Start freeing queue for ep 00
EHCI: Done freeing queue for ep 00

Comment 22 Joshua Roys 2013-04-07 18:22:27 UTC
Using qemu 1.2.2-9 I am also seeing
qemu-kvm: /builddir/build/BUILD/qemu-kvm-1.2.0/hw/usb/hcd-ehci.c:2159: ehci_state_executing: Assertion `p->qtdaddr == q->qtdaddr' failed.

I'm writing a kernel driver for a USB wireless device, so me seeing this crash is probably partially my fault.

I can test with your scratch build too if you need more data.

Comment 23 Hans de Goede 2013-04-07 20:34:50 UTC
(In reply to comment #21)
> Hi Hans - This morning I've captured 4 occurrences of the "async 3" error in
> the libvirt logs.  I've copied & pasted one of the four occurrences below. 
> Is that enough info?

Thanks! Unfortunately the on you copy pasted explains the crash you were initially seeing but not the assert you reported with the "fixed" build. Are there any occurrences where there are more
then 1 "async 3" messages in a single block (so between a "Start freeing queue" and "Done freeing queue" message?

Also if any of the other 4 occurrences looks different in any way can you paste those here too?

Thanks,

Hans

Comment 24 Hans de Goede 2013-04-07 20:36:28 UTC
Hi Joshua,

(In reply to comment #22)
> Using qemu 1.2.2-9 I am also seeing
> qemu-kvm: /builddir/build/BUILD/qemu-kvm-1.2.0/hw/usb/hcd-ehci.c:2159:
> ehci_state_executing: Assertion `p->qtdaddr == q->qtdaddr' failed.
> 
> I'm writing a kernel driver for a USB wireless device, so me seeing this
> crash is probably partially my fault.

No, your driver may be doing something weird, but that assert should never be triggerable from the guest.

> I can test with your scratch build too if you need more data.

Yes please test with the scratch build and collect some logs.

Thanks,

Hans

Comment 25 Tim Knowles 2013-04-07 21:08:47 UTC
Created attachment 732429 [details]
libvirt log

Comment 26 Hans de Goede 2013-04-07 21:21:11 UTC
Hi Tim,

(In reply to comment #25)
> Created attachment 732429 [details]
> libvirt log

Thanks,

I've found an entry in the log which explains why the assert is triggering. Still not entirely clear what exactly is happening to trigger this though, that is something for me to think about tomorrow. One last question are you using spice's usb redirection (so the file -> usb device selection menu in virt-viewer / remote-viewer) or are you using host usb redirection (so the add/remove hardware function from the details view in virt-manager) ?

Regards,

hans

Comment 27 Tim Knowles 2013-04-07 21:37:43 UTC
Hi Hans,

I'm using host usb redirection using the add/remove hardware functionality in virt-manager.  I've copied the libvirt xml below.


<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh edit fedora18
or other application using the libvirt API.
-->

<domain type='kvm'>
  <name>fedora18</name>
  <uuid>9bc5de80-5146-de35-b261-18754ea97f2e</uuid>
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>786432</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc-1.2'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <cpu mode='custom' match='exact'>
    <model fallback='allow'>core2duo</model>
    <vendor>Intel</vendor>
    <feature policy='require' name='pbe'/>
    <feature policy='require' name='tm2'/>
    <feature policy='require' name='est'/>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='dtes64'/>
    <feature policy='require' name='ht'/>
    <feature policy='require' name='ds'/>
    <feature policy='require' name='lahf_lm'/>
    <feature policy='require' name='tm'/>
    <feature policy='require' name='cx16'/>
    <feature policy='require' name='vmx'/>
    <feature policy='require' name='ds_cpl'/>
    <feature policy='require' name='pdcm'/>
    <feature policy='require' name='xtpr'/>
    <feature policy='require' name='acpi'/>
  </cpu>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' io='native'/>
      <source file='/var/lib/libvirt/images/fedora18.img'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </disk>
    <disk type='block' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x2'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:64:ca:34'/>
      <source network='network1'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
</console>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <graphics type='spice' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
    <video>
      <model type='qxl' vram='65536' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x2040'/>
        <product id='0x7070'/>
      </source>
    </hostdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </memballoon>
  </devices>
</domain>

Comment 28 Hans de Goede 2013-04-08 13:23:57 UTC
Hi Tim,

(In reply to comment #27)
> Hi Hans,
> 
> I'm using host usb redirection using the add/remove hardware functionality
> in virt-manager.  I've copied the libvirt xml below.

Thanks, I think I've figured out what is going on, and written a proper fix, can you give please this version a try: http://koji.fedoraproject.org/koji/taskinfo?taskID=5225880

This contains what I intend to be the official fix for this, but before I push a new Fedora update with this fix I would first like to get some feedback on it,

Thanks,

Hans

Comment 29 Tim Knowles 2013-04-08 20:26:22 UTC
(In reply to comment #28)
Hi Hans,

> (In reply to comment #27)
> > Hi Hans,
> > 
> > I'm using host usb redirection using the add/remove hardware functionality
> > in virt-manager.  I've copied the libvirt xml below.
> 
> Thanks, I think I've figured out what is going on, and written a proper fix,
> can you give please this version a try:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5225880
> 
> This contains what I intend to be the official fix for this, but before I
> push a new Fedora update with this fix I would first like to get some
> feedback on it,

I've tested it and can confirm the issue as originally reported no longer occurs :-)   I also no longer get the assertion I reported in comment 15.

I am getting this in the log:

EHCI: Dropping completed packet from halted in ep 02

It seems to be at the same frequency as I was getting the "async 3" message so I'm assuming this is part of the fix and it's simply logging the fact it's had to take some corrective action.  If you need me to do anything else please let me know.

Many thanks 

Tim

Comment 30 Hans de Goede 2013-04-08 21:41:50 UTC
Hi Tim,

(In reply to comment #29)
> I've tested it and can confirm the issue as originally reported no longer
> occurs :-)   I also no longer get the assertion I reported in comment 15.

Good!

> I am getting this in the log:
> 
> EHCI: Dropping completed packet from halted in ep 02
> 
> It seems to be at the same frequency as I was getting the "async 3" message
> so I'm assuming this is part of the fix and it's simply logging the fact
> it's had to take some corrective action.

Correct, the condition your setup is triggering is special and rare enough that it warrants a log message, so that if later a similar situation occurs where things don't work in some way I know where to look :)

Thanks for the testing, you can expect an official build with the final fix you've tested soon.

Regards,

Hans

Comment 31 Fedora Update System 2013-04-09 06:22:07 UTC
qemu-1.2.2-10.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/qemu-1.2.2-10.fc18

Comment 32 Fedora Update System 2013-04-18 02:28:58 UTC
qemu-1.2.2-10.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.


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