* [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
@ 2012-09-19 16:42 Shawn Starr
2012-09-19 16:53 ` Shawn Starr
2012-09-20 15:37 ` Hans de Goede
0 siblings, 2 replies; 31+ messages in thread
From: Shawn Starr @ 2012-09-19 16:42 UTC (permalink / raw)
To: qemu-devel; +Cc: Hans de Goede, gerd
Hello QMU folks,
The latest EHCI patches and or USB redirection ones have caused a regression. Using the (legacy) qemu-kvm git master repository which does
not have these patches (not sure which patch is causing assert specifically yet). Using a Logitech QuickCam Pro 9000 and starting a Windows VM
will crash when the device is detected.
Crash in log:
qemu-kvm: /builddir/build/BUILD/qemu-kvm-1.2.0/hw/usb/hcd-ehci.c:2018: ehci_state_fetchqtd: Assertion `0' failed.
2012-09-19 15:36:04.011+0000: shutting down
I only came to this conclusion after noticing at least in Fedora that 1.2.0-rc1 did not have any of the EHCI and USB redirection patches added. So by using the -rc1 spec
file w/o the patches I can use Qemu/KVM successfully w/ webcam and no asserts.
I have also installed: usbredir-0.5-1.fc18.x86_64
Thanks,
Shawn.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-19 16:42 [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting Shawn Starr
@ 2012-09-19 16:53 ` Shawn Starr
2012-09-20 15:37 ` Hans de Goede
1 sibling, 0 replies; 31+ messages in thread
From: Shawn Starr @ 2012-09-19 16:53 UTC (permalink / raw)
To: qemu-devel; +Cc: Hans de Goede, gerd
On Wednesday, September 19, 2012 12:42:01 PM Shawn Starr wrote:
> Hello QMU folks,
>
Here's the commandline used:
/usr/bin/qemu-kvm -name Windows -S -M pc-1.2 -cpu Penryn,+osxsave,+xsave,
+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,
+acpi,+ds,+vme -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -uuid
41562d70-d0a8-25bc-10ec-a3dc46b3d258 -no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-
shutdown -boot order=dc,menu=on -device ich9-usb-
ehci1,id=usb,bus=pci.0,addr=0x3.0x7 -device ich9-usb-
uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x3 -device
ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x3.0x1 -device
ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x3.0x2 -device
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x8 -device virtio-serial-
pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive
file=/home/spstarr/VMs/Windows.img,if=none,id=drive-
scsi0-0-0-0,format=raw,cache=none -device scsi-hd,bus=scsi0.0,channel=0,scsi-
id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 -drive if=none,id=drive-
scsi0-0-0-1,readonly=on,format=raw,cache=none -device scsi-
cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-
scsi0-0-0-1,id=scsi0-0-0-1 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=23 -
device virtio-net-
pci,netdev=hostnet0,id=net0,mac=52:54:00:cf:06:63,bus=pci.0,addr=0x7 -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=0.0.0.0,disable-ticketing -
vga qxl -global qxl-vga.vram_size=134217728 -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=1,hostaddr=2,id=hostdev0 -
device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
> The latest EHCI patches and or USB redirection ones have caused a
> regression. Using the (legacy) qemu-kvm git master repository which does
> not have these patches (not sure which patch is causing assert specifically
> yet). Using a Logitech QuickCam Pro 9000 and starting a Windows VM will
> crash when the device is detected.
>
> Crash in log:
>
> qemu-kvm: /builddir/build/BUILD/qemu-kvm-1.2.0/hw/usb/hcd-ehci.c:2018:
> ehci_state_fetchqtd: Assertion `0' failed. 2012-09-19 15:36:04.011+0000:
> shutting down
>
> I only came to this conclusion after noticing at least in Fedora that
> 1.2.0-rc1 did not have any of the EHCI and USB redirection patches added.
> So by using the -rc1 spec file w/o the patches I can use Qemu/KVM
> successfully w/ webcam and no asserts.
>
> I have also installed: usbredir-0.5-1.fc18.x86_64
>
> Thanks,
> Shawn.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-19 16:42 [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting Shawn Starr
2012-09-19 16:53 ` Shawn Starr
@ 2012-09-20 15:37 ` Hans de Goede
2012-09-20 19:08 ` Shawn Starr
` (2 more replies)
1 sibling, 3 replies; 31+ messages in thread
From: Hans de Goede @ 2012-09-20 15:37 UTC (permalink / raw)
To: Shawn Starr; +Cc: qemu-devel, gerd
Hi,
On 09/19/2012 06:42 PM, Shawn Starr wrote:
> Hello QMU folks,
>
> The latest EHCI patches and or USB redirection ones have caused a regression. Using the (legacy) qemu-kvm git master repository which does
> not have these patches (not sure which patch is causing assert specifically yet). Using a Logitech QuickCam Pro 9000 and starting a Windows VM
> will crash when the device is detected.
>
> Crash in log:
>
> qemu-kvm: /builddir/build/BUILD/qemu-kvm-1.2.0/hw/usb/hcd-ehci.c:2018: ehci_state_fetchqtd: Assertion `0' failed.
> 2012-09-19 15:36:04.011+0000: shutting down
>
> I only came to this conclusion after noticing at least in Fedora that 1.2.0-rc1 did not have any of the EHCI and USB redirection patches added. So by using the -rc1 spec
> file w/o the patches I can use Qemu/KVM successfully w/ webcam and no asserts.
>
> I have also installed: usbredir-0.5-1.fc18.x86_64
Thanks for reporting this. This is caused by a recent change to
fix a memory leak inside the ehci codes interrupt ep handling, together with:
// TODO Windows does not seem to ever set the MULT field
The above windows bug (not setting the MULT field is against the spec), causes
ehci_state_execute() to exit without even executing the packet once, which
leaves the packet in an uninitialized state. And when fetchqtd then later on sees
there already is a packet in flight for the ep queue, it barfs on it not being
initialized.
I already had looking into the windows MULT issue on my to do, so I've just
bumped it to the top :)
Unfortunately I cannot reproduce what you are seeing even though I do have
a logitech pro 9000 to test with myself. I've tried with both a 32 bits
windows XP as a 32 bits windows 7, what guest OS are you running?
Besides not being able to reproduce I've written what I believe is a fix for
this. I'll post that to the list right after this mail.
Can you test qemu build with the fix added? And please also set the usb-redir
device's debug parameter to 4 and send me the generated qemu log ? This will
allow me to see not only the assert is gone but that also the interrupt ep is
working properly...
To set the debug to 4 use ie:
-device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=4
Do this for all the usb-redir devices on your cmdline!
Regards,
Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-20 15:37 ` Hans de Goede
@ 2012-09-20 19:08 ` Shawn Starr
2012-09-20 23:28 ` Shawn Starr
[not found] ` <6177450.mT8I4ey0nz@segfault.sh0n.net>
2 siblings, 0 replies; 31+ messages in thread
From: Shawn Starr @ 2012-09-20 19:08 UTC (permalink / raw)
To: Hans de Goede; +Cc: qemu-devel, gerd
On Thursday, September 20, 2012 05:37:44 PM Hans de Goede wrote:
> Hi,
>
> Thanks for reporting this. This is caused by a recent change to
> fix a memory leak inside the ehci codes interrupt ep handling, together
> with:
>
> // TODO Windows does not seem to ever set the MULT field
>
> The above windows bug (not setting the MULT field is against the spec),
> causes ehci_state_execute() to exit without even executing the packet once,
> which leaves the packet in an uninitialized state. And when fetchqtd then
> later on sees there already is a packet in flight for the ep queue, it
> barfs on it not being initialized.
>
> I already had looking into the windows MULT issue on my to do, so I've just
> bumped it to the top :)
>
> Unfortunately I cannot reproduce what you are seeing even though I do have
> a logitech pro 9000 to test with myself. I've tried with both a 32 bits
> windows XP as a 32 bits windows 7, what guest OS are you running?
In this case trying Windows 7 64bit. I can trigger this repeatedly.
>
> Besides not being able to reproduce I've written what I believe is a fix for
> this. I'll post that to the list right after this mail.
>
> Can you test qemu build with the fix added? And please also set the
> usb-redir device's debug parameter to 4 and send me the generated qemu log
> ? This will allow me to see not only the assert is gone but that also the
> interrupt ep is working properly...
>
> To set the debug to 4 use ie:
> -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=4
>
> Do this for all the usb-redir devices on your cmdline!
Yes, I will grab your patch and give this a go.
Thanks,
Shawn.
>
> Regards,
>
> Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-20 15:37 ` Hans de Goede
2012-09-20 19:08 ` Shawn Starr
@ 2012-09-20 23:28 ` Shawn Starr
[not found] ` <6177450.mT8I4ey0nz@segfault.sh0n.net>
2 siblings, 0 replies; 31+ messages in thread
From: Shawn Starr @ 2012-09-20 23:28 UTC (permalink / raw)
To: Hans de Goede; +Cc: qemu-devel, gerd
On Thursday, September 20, 2012 05:37:44 PM Hans de Goede wrote:
> Hi,
>
> On 09/19/2012 06:42 PM, Shawn Starr wrote:
> > Hello QMU folks,
> >
> > The latest EHCI patches and or USB redirection ones have caused a
> > regression. Using the (legacy) qemu-kvm git master repository which does
> > not have these patches (not sure which patch is causing assert
> > specifically yet). Using a Logitech QuickCam Pro 9000 and starting a
> > Windows VM will crash when the device is detected.
> >
> > Crash in log:
> >
> > qemu-kvm: /builddir/build/BUILD/qemu-kvm-1.2.0/hw/usb/hcd-ehci.c:2018:
> > ehci_state_fetchqtd: Assertion `0' failed. 2012-09-19 15:36:04.011+0000:
> > shutting down
> >
> > I only came to this conclusion after noticing at least in Fedora that
> > 1.2.0-rc1 did not have any of the EHCI and USB redirection patches added.
> > So by using the -rc1 spec file w/o the patches I can use Qemu/KVM
> > successfully w/ webcam and no asserts.
> >
> > I have also installed: usbredir-0.5-1.fc18.x86_64
>
> Thanks for reporting this. This is caused by a recent change to
> fix a memory leak inside the ehci codes interrupt ep handling, together
> with:
>
> // TODO Windows does not seem to ever set the MULT field
>
> The above windows bug (not setting the MULT field is against the spec),
> causes ehci_state_execute() to exit without even executing the packet once,
> which leaves the packet in an uninitialized state. And when fetchqtd then
> later on sees there already is a packet in flight for the ep queue, it
> barfs on it not being initialized.
>
> I already had looking into the windows MULT issue on my to do, so I've just
> bumped it to the top :)
>
> Unfortunately I cannot reproduce what you are seeing even though I do have
> a logitech pro 9000 to test with myself. I've tried with both a 32 bits
> windows XP as a 32 bits windows 7, what guest OS are you running?
>
> Besides not being able to reproduce I've written what I believe is a fix for
> this. I'll post that to the list right after this mail.
>
> Can you test qemu build with the fix added? And please also set the
> usb-redir device's debug parameter to 4 and send me the generated qemu log
> ? This will allow me to see not only the assert is gone but that also the
> interrupt ep is working properly...
>
> To set the debug to 4 use ie:
> -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=4
>
> Do this for all the usb-redir devices on your cmdline!
>
I did and log shows:
USBDEVFS_SUBMITURB: Cannot allocate memory
Unexpected iso usb result: -3
This is flooding the log when the cam is enabled (black screen) it goes on but
nothing shown
I manually added to libvirt config for the VM to enable usb-redir device
<qemu:commandline>
<qemu:arg value='-chardev'/>
<qemu:arg value='spicevmc,id=charredir0,name=usbredir,debug=4'/>
<qemu:arg value='-device'/>
<qemu:arg value='usb-redir,chardev=charredir0,id=redir0,debug=4'/>
</qemu:commandline>
New command line:
/usr/bin/qemu-kvm -name Windows -S -M pc-1.2 -cpu Penryn,+osxsave,+xsave,
+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,
+acpi,+ds,+vme -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -uuid
41562d70-d0a8-25bc-10ec-a3dc46b3d258 -no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-
shutdown -boot order=dc,menu=on -device ich9-usb-
ehci1,id=usb,bus=pci.0,addr=0x3.0x7 -device ich9-usb-
uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x3 -device
ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x3.0x1 -device
ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x3.0x2 -device
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x8 -device virtio-serial-
pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive
file=/home/spstarr/VMs/Windows.img,if=none,id=drive-
scsi0-0-0-0,format=raw,cache=none -device scsi-hd,bus=scsi0.0,channel=0,scsi-
id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 -drive
file=/home/spstarr/Downloads/virtio-win-0.1-30.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=22,id=hostnet0,vhost=on,vhostfd=23 -device virtio-net-
pci,netdev=hostnet0,id=net0,mac=52:54:00:cf:06:63,bus=pci.0,addr=0x7 -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=0.0.0.0,disable-ticketing -
vga qxl -global qxl-vga.vram_size=134217728 -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=1,hostaddr=4,id=hostdev0 -
device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -chardev
spicevmc,id=charredir0,name=usbredir,debug=4 -device usb-
redir,chardev=charredir0,id=redir0,debug=4
> Regards,
>
> Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
[not found] ` <6177450.mT8I4ey0nz@segfault.sh0n.net>
@ 2012-09-21 0:04 ` Shawn Starr
2012-09-21 12:19 ` Hans de Goede
0 siblings, 1 reply; 31+ messages in thread
From: Shawn Starr @ 2012-09-21 0:04 UTC (permalink / raw)
To: Hans de Goede; +Cc: qemu-devel, gerd
On Thursday, September 20, 2012 07:29:08 PM Shawn Starr wrote:
> On Thursday, September 20, 2012 05:37:44 PM Hans de Goede wrote:
> > Hi,
> >
> > On 09/19/2012 06:42 PM, Shawn Starr wrote:
> > > Hello QMU folks,
> > >
> > > The latest EHCI patches and or USB redirection ones have caused a
> > > regression. Using the (legacy) qemu-kvm git master repository which does
> > > not have these patches (not sure which patch is causing assert
> > > specifically yet). Using a Logitech QuickCam Pro 9000 and starting a
> > > Windows VM will crash when the device is detected.
> > >
> > > Crash in log:
> > >
> > > qemu-kvm: /builddir/build/BUILD/qemu-kvm-1.2.0/hw/usb/hcd-ehci.c:2018:
> > > ehci_state_fetchqtd: Assertion `0' failed. 2012-09-19 15:36:04.011+0000:
> > > shutting down
> > >
> > > I only came to this conclusion after noticing at least in Fedora that
> > > 1.2.0-rc1 did not have any of the EHCI and USB redirection patches
> > > added.
> > > So by using the -rc1 spec file w/o the patches I can use Qemu/KVM
> > > successfully w/ webcam and no asserts.
> > >
> > > I have also installed: usbredir-0.5-1.fc18.x86_64
> >
> > Thanks for reporting this. This is caused by a recent change to
> > fix a memory leak inside the ehci codes interrupt ep handling, together
> >
> > with:
> > // TODO Windows does not seem to ever set the MULT field
> >
> > The above windows bug (not setting the MULT field is against the spec),
> > causes ehci_state_execute() to exit without even executing the packet
> > once,
> > which leaves the packet in an uninitialized state. And when fetchqtd then
> > later on sees there already is a packet in flight for the ep queue, it
> > barfs on it not being initialized.
> >
> > I already had looking into the windows MULT issue on my to do, so I've
> > just
> > bumped it to the top :)
> >
> > Unfortunately I cannot reproduce what you are seeing even though I do have
> > a logitech pro 9000 to test with myself. I've tried with both a 32 bits
> > windows XP as a 32 bits windows 7, what guest OS are you running?
> >
> > Besides not being able to reproduce I've written what I believe is a fix
> > for this. I'll post that to the list right after this mail.
> >
> > Can you test qemu build with the fix added? And please also set the
> > usb-redir device's debug parameter to 4 and send me the generated qemu log
> > ? This will allow me to see not only the assert is gone but that also the
> > interrupt ep is working properly...
> >
> > To set the debug to 4 use ie:
> > -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=4
> >
> > Do this for all the usb-redir devices on your cmdline!
>
> I did and log shows:
>
> USBDEVFS_SUBMITURB: Cannot allocate memory
> Unexpected iso usb result: -3
>
> This is flooding the log when the cam is enabled (black screen) it goes on
> but nothing shown
>
> I manually added to libvirt config for the VM to enable usb-redir device
>
> <qemu:commandline>
> <qemu:arg value='-chardev'/>
> <qemu:arg value='spicevmc,id=charredir0,name=usbredir,debug=4'/>
> <qemu:arg value='-device'/>
> <qemu:arg value='usb-redir,chardev=charredir0,id=redir0,debug=4'/>
> </qemu:commandline>
>
>
> New command line:
>
> /usr/bin/qemu-kvm -name Windows -S -M pc-1.2 -cpu Penryn,+osxsave,+xsave,
> +pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,
> +acpi,+ds,+vme -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -uuid
> 41562d70-d0a8-25bc-10ec-a3dc46b3d258 -no-user-config -nodefaults -chardev
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows.monitor,server,nowa
> it -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-
> shutdown -boot order=dc,menu=on -device ich9-usb-
> ehci1,id=usb,bus=pci.0,addr=0x3.0x7 -device ich9-usb-
> uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x3
> -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x3.0x1
> -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x3.0x2
> -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x8 -device virtio-serial-
> pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive
> file=/home/spstarr/VMs/Windows.img,if=none,id=drive-
> scsi0-0-0-0,format=raw,cache=none -device
> scsi-hd,bus=scsi0.0,channel=0,scsi-
> id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 -drive
> file=/home/spstarr/Downloads/virtio-win-0.1-30.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=22,id=hostnet0,vhost=on,vhostfd=23 -device virtio-net-
> pci,netdev=hostnet0,id=net0,mac=52:54:00:cf:06:63,bus=pci.0,addr=0x7
> -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=0.0.0.0,disable-ticketing
> - vga qxl -global qxl-vga.vram_size=134217728 -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=1,hostaddr=4,id=hostdev0
> - device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -chardev
> spicevmc,id=charredir0,name=usbredir,debug=4 -device usb-
> redir,chardev=charredir0,id=redir0,debug=4
>
In addition, if i disable usb-redirection device the cam works as it did
before (although like before, the video image is upside down in some
applications).
Thanks,
Shawn.
> > Regards,
> >
> > Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-21 0:04 ` Shawn Starr
@ 2012-09-21 12:19 ` Hans de Goede
2012-09-21 15:39 ` Shawn Starr
0 siblings, 1 reply; 31+ messages in thread
From: Hans de Goede @ 2012-09-21 12:19 UTC (permalink / raw)
To: Shawn Starr; +Cc: qemu-devel, gerd
Hi,
On 09/21/2012 02:04 AM, Shawn Starr wrote:
> On Thursday, September 20, 2012 07:29:08 PM Shawn Starr wrote:
>> On Thursday, September 20, 2012 05:37:44 PM Hans de Goede wrote:
>>> Hi,
>>>
>>> On 09/19/2012 06:42 PM, Shawn Starr wrote:
>>>> Hello QMU folks,
>>>>
>>>> The latest EHCI patches and or USB redirection ones have caused a
>>>> regression. Using the (legacy) qemu-kvm git master repository which does
>>>> not have these patches (not sure which patch is causing assert
>>>> specifically yet). Using a Logitech QuickCam Pro 9000 and starting a
>>>> Windows VM will crash when the device is detected.
>>>>
>>>> Crash in log:
>>>>
>>>> qemu-kvm: /builddir/build/BUILD/qemu-kvm-1.2.0/hw/usb/hcd-ehci.c:2018:
>>>> ehci_state_fetchqtd: Assertion `0' failed. 2012-09-19 15:36:04.011+0000:
>>>> shutting down
>>>>
>>>> I only came to this conclusion after noticing at least in Fedora that
>>>> 1.2.0-rc1 did not have any of the EHCI and USB redirection patches
>>>> added.
>>>> So by using the -rc1 spec file w/o the patches I can use Qemu/KVM
>>>> successfully w/ webcam and no asserts.
>>>>
>>>> I have also installed: usbredir-0.5-1.fc18.x86_64
>>>
>>> Thanks for reporting this. This is caused by a recent change to
>>> fix a memory leak inside the ehci codes interrupt ep handling, together
>>>
>>> with:
>>> // TODO Windows does not seem to ever set the MULT field
>>>
>>> The above windows bug (not setting the MULT field is against the spec),
>>> causes ehci_state_execute() to exit without even executing the packet
>>> once,
>>> which leaves the packet in an uninitialized state. And when fetchqtd then
>>> later on sees there already is a packet in flight for the ep queue, it
>>> barfs on it not being initialized.
>>>
>>> I already had looking into the windows MULT issue on my to do, so I've
>>> just
>>> bumped it to the top :)
>>>
>>> Unfortunately I cannot reproduce what you are seeing even though I do have
>>> a logitech pro 9000 to test with myself. I've tried with both a 32 bits
>>> windows XP as a 32 bits windows 7, what guest OS are you running?
>>>
>>> Besides not being able to reproduce I've written what I believe is a fix
>>> for this. I'll post that to the list right after this mail.
>>>
>>> Can you test qemu build with the fix added? And please also set the
>>> usb-redir device's debug parameter to 4 and send me the generated qemu log
>>> ? This will allow me to see not only the assert is gone but that also the
>>> interrupt ep is working properly...
>>>
>>> To set the debug to 4 use ie:
>>> -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=4
>>>
>>> Do this for all the usb-redir devices on your cmdline!
>>
>> I did and log shows:
>>
>> USBDEVFS_SUBMITURB: Cannot allocate memory
>> Unexpected iso usb result: -3
>>
>> This is flooding the log when the cam is enabled (black screen) it goes on
>> but nothing shown
>>
>> I manually added to libvirt config for the VM to enable usb-redir device
>>
>> <qemu:commandline>
>> <qemu:arg value='-chardev'/>
>> <qemu:arg value='spicevmc,id=charredir0,name=usbredir,debug=4'/>
>> <qemu:arg value='-device'/>
>> <qemu:arg value='usb-redir,chardev=charredir0,id=redir0,debug=4'/>
>> </qemu:commandline>
>>
>>
>> New command line:
>>
>> /usr/bin/qemu-kvm -name Windows -S -M pc-1.2 -cpu Penryn,+osxsave,+xsave,
>> +pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,
>> +acpi,+ds,+vme -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -uuid
>> 41562d70-d0a8-25bc-10ec-a3dc46b3d258 -no-user-config -nodefaults -chardev
>> socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows.monitor,server,nowa
>> it -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-
>> shutdown -boot order=dc,menu=on -device ich9-usb-
>> ehci1,id=usb,bus=pci.0,addr=0x3.0x7 -device ich9-usb-
>> uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x3
>> -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x3.0x1
>> -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x3.0x2
>> -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x8 -device virtio-serial-
>> pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive
>> file=/home/spstarr/VMs/Windows.img,if=none,id=drive-
>> scsi0-0-0-0,format=raw,cache=none -device
>> scsi-hd,bus=scsi0.0,channel=0,scsi-
>> id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 -drive
>> file=/home/spstarr/Downloads/virtio-win-0.1-30.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=22,id=hostnet0,vhost=on,vhostfd=23 -device virtio-net-
>> pci,netdev=hostnet0,id=net0,mac=52:54:00:cf:06:63,bus=pci.0,addr=0x7
>> -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=0.0.0.0,disable-ticketing
>> - vga qxl -global qxl-vga.vram_size=134217728 -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=1,hostaddr=4,id=hostdev0
>> - device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -chardev
>> spicevmc,id=charredir0,name=usbredir,debug=4 -device usb-
>> redir,chardev=charredir0,id=redir0,debug=4
>>
Ok, so your using host redirection here, see the device usb-host
> In addition, if i disable usb-redirection device the cam works as it did
> before (although like before, the video image is upside down in some
> applications).
When you say disable the usb-redirection device, do you mean removing
the host redirection, and selecting the cam for redirection in a
spice client (ie remote-viewer) instead, or... ?
Can you please try, disabling host-redirection, then connecting to
the vm with remote-viewer and then selecting the cam from
remote-viewers UI?
Thanks,
Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-21 12:19 ` Hans de Goede
@ 2012-09-21 15:39 ` Shawn Starr
2012-09-21 17:35 ` Hans de Goede
0 siblings, 1 reply; 31+ messages in thread
From: Shawn Starr @ 2012-09-21 15:39 UTC (permalink / raw)
To: Hans de Goede; +Cc: qemu-devel, gerd
On Friday, September 21, 2012 02:19:08 PM Hans de Goede wrote:
> Hi,
<snip>
>
> Ok, so your using host redirection here, see the device usb-host
>
> > In addition, if i disable usb-redirection device the cam works as it did
> > before (although like before, the video image is upside down in some
> > applications).
>
> When you say disable the usb-redirection device, do you mean removing
> the host redirection, and selecting the cam for redirection in a
> spice client (ie remote-viewer) instead, or... ?
>
> Can you please try, disabling host-redirection, then connecting to
> the vm with remote-viewer and then selecting the cam from
> remote-viewers UI?
>
> Thanks,
>
> Hans
Hi Hans,
I am using usb-host and it works. If I keep usb-host and add usb-redirection
it shows those errors. Your patch however did fix using host-usb alone.
I don't have a setup that can let me use usb-redirection unfortunately.
Thanks,
Shawn.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-21 15:39 ` Shawn Starr
@ 2012-09-21 17:35 ` Hans de Goede
2012-09-21 18:46 ` Shawn Starr
0 siblings, 1 reply; 31+ messages in thread
From: Hans de Goede @ 2012-09-21 17:35 UTC (permalink / raw)
To: Shawn Starr; +Cc: qemu-devel, gerd
Hi,
On 09/21/2012 05:39 PM, Shawn Starr wrote:
> On Friday, September 21, 2012 02:19:08 PM Hans de Goede wrote:
>> Hi,
>
> <snip>
>>
>> Ok, so your using host redirection here, see the device usb-host
>>
>>> In addition, if i disable usb-redirection device the cam works as it did
>>> before (although like before, the video image is upside down in some
>>> applications).
>>
>> When you say disable the usb-redirection device, do you mean removing
>> the host redirection, and selecting the cam for redirection in a
>> spice client (ie remote-viewer) instead, or... ?
>>
>> Can you please try, disabling host-redirection, then connecting to
>> the vm with remote-viewer and then selecting the cam from
>> remote-viewers UI?
>>
>> Thanks,
>>
>> Hans
>
> Hi Hans,
>
> I am using usb-host and it works. If I keep usb-host and add usb-redirection
> it shows those errors.
Hmm, this sounds like you are using spice usb-redir too and the 2 are fighting
each other. Which spice-client are you using? And are you plugging in the
device after starting up the vm ?
> Your patch however did fix using host-usb alone.
Good.
> I don't have a setup that can let me use usb-redirection unfortunately.
Why not? Looking at your qemu cmdline you are using spice. Hmm, I guesss you
may want to keep the device redirected when no client is connected?
Anyway, if you could remove the host-redirection temporarily and try with
spice usb-redir and collect logs that would be great. If you don't have
time for that, that is ok too, then I'll consider this issue resolved.
Regards,
Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-21 17:35 ` Hans de Goede
@ 2012-09-21 18:46 ` Shawn Starr
2012-09-23 10:03 ` Hans de Goede
0 siblings, 1 reply; 31+ messages in thread
From: Shawn Starr @ 2012-09-21 18:46 UTC (permalink / raw)
To: Hans de Goede; +Cc: qemu-devel, gerd
On Friday, September 21, 2012 07:35:42 PM Hans de Goede wrote:
> Hi,
>
> On 09/21/2012 05:39 PM, Shawn Starr wrote:
> > On Friday, September 21, 2012 02:19:08 PM Hans de Goede wrote:
> >> Hi,
> >
> > <snip>
> >
> >> Ok, so your using host redirection here, see the device usb-host
> >>
> >>> In addition, if i disable usb-redirection device the cam works as it did
> >>> before (although like before, the video image is upside down in some
> >>> applications).
> >>
> >> When you say disable the usb-redirection device, do you mean removing
> >> the host redirection, and selecting the cam for redirection in a
> >> spice client (ie remote-viewer) instead, or... ?
> >>
> >> Can you please try, disabling host-redirection, then connecting to
> >> the vm with remote-viewer and then selecting the cam from
> >> remote-viewers UI?
> >>
> >> Thanks,
> >>
> >> Hans
> >
> > Hi Hans,
> >
> > I am using usb-host and it works. If I keep usb-host and add
> > usb-redirection it shows those errors.
>
> Hmm, this sounds like you are using spice usb-redir too and the 2 are
> fighting each other. Which spice-client are you using? And are you plugging
> in the device after starting up the vm ?
>
> > Your patch however did fix using host-usb alone.
>
> Good.
>
> > I don't have a setup that can let me use usb-redirection unfortunately.
>
> Why not? Looking at your qemu cmdline you are using spice. Hmm, I guesss you
> may want to keep the device redirected when no client is connected?
>
Using spicec, it doesn't give me an option to connection devices. I assume
usb-redirection for devices *not* on the same machine as the running VM? If
so, that use case I wasn't testing originally (although useful)
> Anyway, if you could remove the host-redirection temporarily and try with
> spice usb-redir and collect logs that would be great. If you don't have
> time for that, that is ok too, then I'll consider this issue resolved.
I consider the issue resolved solely on usb-host issue vs any regressions with
usb-redirection itself which I never used/tried.
However, if someone can point out how you can test this, I can do this also.
Thanks,
Shawn.
>
> Regards,
>
> Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-21 18:46 ` Shawn Starr
@ 2012-09-23 10:03 ` Hans de Goede
2012-09-23 18:00 ` Shawn Starr
0 siblings, 1 reply; 31+ messages in thread
From: Hans de Goede @ 2012-09-23 10:03 UTC (permalink / raw)
To: Shawn Starr; +Cc: qemu-devel, gerd
Hi,
On 09/21/2012 08:46 PM, Shawn Starr wrote:
> On Friday, September 21, 2012 07:35:42 PM Hans de Goede wrote:
>> Hi,
>>
>> On 09/21/2012 05:39 PM, Shawn Starr wrote:
>>> On Friday, September 21, 2012 02:19:08 PM Hans de Goede wrote:
>>>> Hi,
>>>
>>> <snip>
>>>
>>>> Ok, so your using host redirection here, see the device usb-host
>>>>
>>>>> In addition, if i disable usb-redirection device the cam works as it did
>>>>> before (although like before, the video image is upside down in some
>>>>> applications).
>>>>
>>>> When you say disable the usb-redirection device, do you mean removing
>>>> the host redirection, and selecting the cam for redirection in a
>>>> spice client (ie remote-viewer) instead, or... ?
>>>>
>>>> Can you please try, disabling host-redirection, then connecting to
>>>> the vm with remote-viewer and then selecting the cam from
>>>> remote-viewers UI?
>>>>
>>>> Thanks,
>>>>
>>>> Hans
>>>
>>> Hi Hans,
>>>
>>> I am using usb-host and it works. If I keep usb-host and add
>>> usb-redirection it shows those errors.
>>
>> Hmm, this sounds like you are using spice usb-redir too and the 2 are
>> fighting each other. Which spice-client are you using? And are you plugging
>> in the device after starting up the vm ?
>>
>>> Your patch however did fix using host-usb alone.
>>
>> Good.
>>
>>> I don't have a setup that can let me use usb-redirection unfortunately.
>>
>> Why not? Looking at your qemu cmdline you are using spice. Hmm, I guesss you
>> may want to keep the device redirected when no client is connected?
>>
>
> Using spicec, it doesn't give me an option to connection devices.
spicec is deprecated you really should be using remote-viewer instead. That
will give you an option to select devices.
> I assume
> usb-redirection for devices *not* on the same machine as the running VM? If
> so, that use case I wasn't testing originally (although useful)
spice's usbredirection works fine locally too, and it gives you a nice
UI to redirect usb devices, without needing to need usb-ids, etc.
>
>> Anyway, if you could remove the host-redirection temporarily and try with
>> spice usb-redir and collect logs that would be great. If you don't have
>> time for that, that is ok too, then I'll consider this issue resolved.
>
> I consider the issue resolved solely on usb-host issue vs any regressions with
> usb-redirection itself which I never used/tried.
>
> However, if someone can point out how you can test this, I can do this also.
See above :)
Regards,
Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-23 10:03 ` Hans de Goede
@ 2012-09-23 18:00 ` Shawn Starr
2012-09-23 18:20 ` Shawn Starr
0 siblings, 1 reply; 31+ messages in thread
From: Shawn Starr @ 2012-09-23 18:00 UTC (permalink / raw)
To: Hans de Goede; +Cc: qemu-devel, gerd
On Sunday, September 23, 2012 12:03:28 PM Hans de Goede wrote:
> Hi,
>
> On 09/21/2012 08:46 PM, Shawn Starr wrote:
> > On Friday, September 21, 2012 07:35:42 PM Hans de Goede wrote:
> >> Hi,
> >>
> >> On 09/21/2012 05:39 PM, Shawn Starr wrote:
> >>> On Friday, September 21, 2012 02:19:08 PM Hans de Goede wrote:
> >>>> Hi,
> >>>
> >>> <snip>
> >>>
> >>>> Ok, so your using host redirection here, see the device usb-host
> >>>>
> >>>>> In addition, if i disable usb-redirection device the cam works as it
> >>>>> did
> >>>>> before (although like before, the video image is upside down in some
> >>>>> applications).
> >>>>
> >>>> When you say disable the usb-redirection device, do you mean removing
> >>>> the host redirection, and selecting the cam for redirection in a
> >>>> spice client (ie remote-viewer) instead, or... ?
> >>>>
> >>>> Can you please try, disabling host-redirection, then connecting to
> >>>> the vm with remote-viewer and then selecting the cam from
> >>>> remote-viewers UI?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Hans
> >>>
> >>> Hi Hans,
> >>>
> >>> I am using usb-host and it works. If I keep usb-host and add
> >>> usb-redirection it shows those errors.
> >>
> >> Hmm, this sounds like you are using spice usb-redir too and the 2 are
> >> fighting each other. Which spice-client are you using? And are you
> >> plugging
> >> in the device after starting up the vm ?
> >>
> >>> Your patch however did fix using host-usb alone.
> >>
> >> Good.
> >>
> >>> I don't have a setup that can let me use usb-redirection unfortunately.
> >>
> >> Why not? Looking at your qemu cmdline you are using spice. Hmm, I guesss
> >> you may want to keep the device redirected when no client is connected?>
> > Using spicec, it doesn't give me an option to connection devices.
>
> spicec is deprecated you really should be using remote-viewer instead. That
> will give you an option to select devices.
>
I installed virt-viewer (which I didn't know about), however the display is
black (i only see a cursor)
I did attach the USB device with it and debug shows this:
qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
qemu-kvm: usb-redir: attaching high speed device 046d:0990 version 0.8 class
ef
qemu-kvm: usb-redir: reset device
qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 64 id
1071296768
qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1071296768
qemu-kvm: usb-redir: reset device
qemu-kvm: usb-redir: set address 1
qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 18 id
1071296768
qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1071296768
qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 255 id
1071296768
qemu-kvm: usb-redir: ctrl-in status 0 len 255 id 1071296768
qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 1433 id
1071296768
qemu-kvm: usb-redir: ctrl-in status 0 len 1433 id 1071296768
qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x302 index 1033 len 255
id 1071296768
qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1071296768
lsusb info:
--> Bus 001 Device 004: ID 046d:0990 Logitech, Inc. QuickCam Pro 9000
I am having issues with attaching display with spice, but I saw no errors on
attach of USB device, I just am not able test this.
XML:
<qemu:commandline>
<qemu:arg value='-set'/>
<qemu:arg value='device.redir0.debug=4'/>
</qemu:commandline>
QEMU Line:
-chardev spicevmc,id=charredir0,name=usbredir -device usb-
redir,chardev=charredir0,id=redir0 -device virtio-balloon-
pci,id=balloon0,bus=pci.0,addr=0x6 -set device.redir0.debug=4
> > I assume
> >
> > usb-redirection for devices *not* on the same machine as the running VM?
> > If
> > so, that use case I wasn't testing originally (although useful)
>
> spice's usbredirection works fine locally too, and it gives you a nice
> UI to redirect usb devices, without needing to need usb-ids, etc.
>
> >> Anyway, if you could remove the host-redirection temporarily and try with
> >> spice usb-redir and collect logs that would be great. If you don't have
> >> time for that, that is ok too, then I'll consider this issue resolved.
> >
> > I consider the issue resolved solely on usb-host issue vs any regressions
> > with usb-redirection itself which I never used/tried.
> >
> > However, if someone can point out how you can test this, I can do this
> > also.
> See above :)
>
> Regards,
>
> Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-23 18:00 ` Shawn Starr
@ 2012-09-23 18:20 ` Shawn Starr
2012-09-23 18:52 ` Shawn Starr
2012-09-24 9:50 ` Hans de Goede
0 siblings, 2 replies; 31+ messages in thread
From: Shawn Starr @ 2012-09-23 18:20 UTC (permalink / raw)
To: Hans de Goede; +Cc: qemu-devel, gerd
On Sunday, September 23, 2012 02:00:10 PM Shawn Starr wrote:
> On Sunday, September 23, 2012 12:03:28 PM Hans de Goede wrote:
> > Hi,
<snip>
> >
> > spicec is deprecated you really should be using remote-viewer instead.
> > That
> > will give you an option to select devices.
>
<snip this out>
The author of spice-gtk told me to downgrade since seems 0.14 broke, got
things working now, I do see some buffer overflow errors and drops but no
assert triggered.
I have a detailed debug it worked attached via remote-viewer
USB conversation:
qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
qemu-kvm: usb-redir: attaching high speed device 046d:0990 version 0.8 class
ef
qemu-kvm: usb-redir: reset device
qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 64 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
qemu-kvm: usb-redir: reset device
qemu-kvm: usb-redir: set address 1
qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 18 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 255 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 255 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 1433 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 1433 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x302 index 1033 len 255
id 1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 18 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 9 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 9 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 1433 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 1433 id 1072685312
qemu-kvm: usb-redir: set config 1 id 1072685440
qemu-kvm: usb-redir: set config status 0 config 1 id 1072685440
qemu-kvm: usb-redir: set interface 1 alt 0 id 1072685440
qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
qemu-kvm: usb-redir: alt status 0 intf 1 alt 0 id: 1072685440
qemu-kvm: usb-redir: set interface 3 alt 0 id 1072685440
qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
qemu-kvm: usb-redir: alt status 0 intf 3 alt 0 id: 1072685440
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x85 val 0x100 index 1024 len 2 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x86 val 0x100 index 1024 len 1 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 1 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x85 val 0x100 index 1024 len 2 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x84 val 0x100 index 1024 len 4 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x82 val 0x100 index 1024 len 4 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
<snip>
USB conversation during device usage:
... <snip>
qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2 id
1072685440
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x400 index 512 len 2 id
1072685312
qemu-kvm: usb-redir: iso-token-in ep 81, no isop, iso_error: 0
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x400 index 256 len 4 id
1072685312
qemu-kvm: usb-redir: bufpq overflow, dropping packets ep 81
qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
qemu-kvm: usb-redir: bufpq overflow, dropping packets ep 81
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x1400 index 3072 len 1
id 1072685312
<snip>
qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2 id
1072685440
qemu-kvm: usb-redir: iso-token-in ep 81, no isop, iso_error: 0
qemu-kvm: usb-redir: bufpq overflow, dropping packets ep 81
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2 id
1072685440
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2 id
1072685440
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2 id
1072685312
qemu-kvm: usb-redir: iso-token-in ep 81, no isop, iso_error: 0
qemu-kvm: usb-redir: bufpq overflow, dropping packets ep 81
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2 id
1072685440
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x400 index 512 len 2 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x400 index 256 len 4 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x1400 index 3072 len 1
id 1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 1 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2 id
1072685440
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2 id
1072685440
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2 id
1072685440
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2 id
1072685440
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2 id
1072685440
qemu-kvm: usb-redir: iso-token-in ep 81, no isop, iso_error: 0
qemu-kvm: usb-redir: bufpq overflow, dropping packets ep 81
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2 id
1072685440
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2 id
1072685440
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2 id
1072685312
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2 id
1072685440
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2 id
1072685312
[ --- SHUT OFF OF USB DEVICE --- ]
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: set interface 1 alt 0 id 1072685440
qemu-kvm: usb-redir: iso stream stopped ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: received iso packet for non started stream ep 81
qemu-kvm: usb-redir: iso status 0 ep 81 id 0
qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
qemu-kvm: usb-redir: alt status 0 intf 1 alt 0 id: 1072685440
qemu-kvm: usb-redir: ctrl-out type 0x2 req 0x1 val 0x0 index 135 len 0 id
1072685440
qemu-kvm: usb-redir: ctrl-in status 0 len 0 id 1072685440
qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x100 index 3328 len 3 id
1072685440
qemu-kvm: usb-redir: ctrl-in status 0 len 3 id 1072685440
> XML:
>
> <qemu:commandline>
> <qemu:arg value='-set'/>
> <qemu:arg value='device.redir0.debug=4'/>
> </qemu:commandline>
>
> QEMU Line:
>
> -chardev spicevmc,id=charredir0,name=usbredir -device usb-
> redir,chardev=charredir0,id=redir0 -device virtio-balloon-
> pci,id=balloon0,bus=pci.0,addr=0x6 -set device.redir0.debug=4
>
> > > I assume
> > >
> > > usb-redirection for devices *not* on the same machine as the running VM?
> > > If
> > > so, that use case I wasn't testing originally (although useful)
> >
> > spice's usbredirection works fine locally too, and it gives you a nice
> > UI to redirect usb devices, without needing to need usb-ids, etc.
> >
> > >> Anyway, if you could remove the host-redirection temporarily and try
> > >> with
> > >> spice usb-redir and collect logs that would be great. If you don't have
> > >> time for that, that is ok too, then I'll consider this issue resolved.
> > >
> > > I consider the issue resolved solely on usb-host issue vs any
> > > regressions
> > > with usb-redirection itself which I never used/tried.
> > >
> > > However, if someone can point out how you can test this, I can do this
> > > also.
> >
> > See above :)
> >
> > Regards,
> >
> > Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-23 18:20 ` Shawn Starr
@ 2012-09-23 18:52 ` Shawn Starr
2012-09-24 9:52 ` Hans de Goede
2012-09-24 9:50 ` Hans de Goede
1 sibling, 1 reply; 31+ messages in thread
From: Shawn Starr @ 2012-09-23 18:52 UTC (permalink / raw)
To: Hans de Goede; +Cc: qemu-devel, gerd
On Sunday, September 23, 2012 02:20:09 PM Shawn Starr wrote:
> On Sunday, September 23, 2012 02:00:10 PM Shawn Starr wrote:
> > On Sunday, September 23, 2012 12:03:28 PM Hans de Goede wrote:
> > > Hi,
>
> <snip>
>
> > > spicec is deprecated you really should be using remote-viewer instead.
> > > That
> > > will give you an option to select devices.
>
> <snip this out>
>
> The author of spice-gtk told me to downgrade since seems 0.14 broke, got
> things working now, I do see some buffer overflow errors and drops but no
> assert triggered.
>
> I have a detailed debug it worked attached via remote-viewer
>
> USB conversation:
>
> qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
> qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
> qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
> qemu-kvm: usb-redir: attaching high speed device 046d:0990 version 0.8 class
> ef
> qemu-kvm: usb-redir: reset device
> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 64 id
> 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> qemu-kvm: usb-redir: reset device
> qemu-kvm: usb-redir: set address 1
> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 18 id
> 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 255 id
> 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 255 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 1433
> id 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 1433 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x302 index 1033 len 255
> id 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 18 id
> 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 9 id
> 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 9 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 1433
> id 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 1433 id 1072685312
> qemu-kvm: usb-redir: set config 1 id 1072685440
> qemu-kvm: usb-redir: set config status 0 config 1 id 1072685440
> qemu-kvm: usb-redir: set interface 1 alt 0 id 1072685440
> qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
> qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
> qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
> qemu-kvm: usb-redir: alt status 0 intf 1 alt 0 id: 1072685440
> qemu-kvm: usb-redir: set interface 3 alt 0 id 1072685440
> qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
> qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
> qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
> qemu-kvm: usb-redir: alt status 0 intf 3 alt 0 id: 1072685440
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x85 val 0x100 index 1024 len 2
> id 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x86 val 0x100 index 1024 len 1
> id 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 1 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x85 val 0x100 index 1024 len 2
> id 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x84 val 0x100 index 1024 len 4
> id 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x82 val 0x100 index 1024 len 4
> id 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
> <snip>
>
> USB conversation during device usage:
>
>
> ... <snip>
>
> qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2
> id 1072685440
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2
> id 1072685312
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x400 index 512 len 2
> id 1072685312
>
> qemu-kvm: usb-redir: iso-token-in ep 81, no isop, iso_error: 0
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x400 index 256 len 4
> id 1072685312
>
> qemu-kvm: usb-redir: bufpq overflow, dropping packets ep 81
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
>
> qemu-kvm: usb-redir: bufpq overflow, dropping packets ep 81
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x1400 index 3072 len 1
> id 1072685312
>
>
> <snip>
>
>
> qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2
> id 1072685440
>
> qemu-kvm: usb-redir: iso-token-in ep 81, no isop, iso_error: 0
>
> qemu-kvm: usb-redir: bufpq overflow, dropping packets ep 81
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2
> id 1072685312
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
>
> qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2
> id 1072685440
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2
> id 1072685312
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
>
> qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2
> id 1072685440
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2
> id 1072685312
>
> qemu-kvm: usb-redir: iso-token-in ep 81, no isop, iso_error: 0
>
> qemu-kvm: usb-redir: bufpq overflow, dropping packets ep 81
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
>
> qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2
> id 1072685440
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2
> id 1072685312
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x400 index 512 len 2
> id 1072685312
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x400 index 256 len 4
> id 1072685312
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x1400 index 3072 len 1
> id 1072685312
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 1 id 1072685312
>
> qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2
> id 1072685440
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2
> id 1072685312
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
>
> qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2
> id 1072685440
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2
> id 1072685312
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
>
> qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2
> id 1072685440
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2
> id 1072685312
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
>
> qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2
> id 1072685440
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2
> id 1072685312
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
>
> qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2
> id 1072685440
>
> qemu-kvm: usb-redir: iso-token-in ep 81, no isop, iso_error: 0
>
> qemu-kvm: usb-redir: bufpq overflow, dropping packets ep 81
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2
> id 1072685312
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
>
> qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2
> id 1072685440
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2
> id 1072685312
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
>
> qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2
> id 1072685440
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2
> id 1072685312
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
>
> qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x500 index 2560 len 2
> id 1072685440
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
>
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x81 val 0x600 index 2560 len 2
> id 1072685312
>
> [ --- SHUT OFF OF USB DEVICE --- ]
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
>
> qemu-kvm: usb-redir: set interface 1 alt 0 id 1072685440
>
> qemu-kvm: usb-redir: iso stream stopped ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: received iso packet for non started stream ep 81
>
> qemu-kvm: usb-redir: iso status 0 ep 81 id 0
>
> qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
>
> qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
>
> qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
>
> qemu-kvm: usb-redir: alt status 0 intf 1 alt 0 id: 1072685440
>
> qemu-kvm: usb-redir: ctrl-out type 0x2 req 0x1 val 0x0 index 135 len 0 id
> 1072685440
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 0 id 1072685440
>
> qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x100 index 3328 len 3
> id 1072685440
>
> qemu-kvm: usb-redir: ctrl-in status 0 len 3 id 1072685440
>
> > XML:
> > <qemu:commandline>
> >
> > <qemu:arg value='-set'/>
> > <qemu:arg value='device.redir0.debug=4'/>
> >
> > </qemu:commandline>
> >
> > QEMU Line:
> >
> > -chardev spicevmc,id=charredir0,name=usbredir -device usb-
> > redir,chardev=charredir0,id=redir0 -device virtio-balloon-
> > pci,id=balloon0,bus=pci.0,addr=0x6 -set device.redir0.debug=4
> >
<snip>
I see why there are USB errors, I am seeing corrupt video frames with webcam
attached via spice-usbredirection, this is not seen with host-usb attachment.
with spice/usb-redirection it can't seem to keep up with the packets,
freezes/drops them.
Let me know what else you'd like me to do debug / test, I'll be glad to help
out.
Thanks,
Shawn.
> > > Regards,
> > >
> > > Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-23 18:20 ` Shawn Starr
2012-09-23 18:52 ` Shawn Starr
@ 2012-09-24 9:50 ` Hans de Goede
2012-09-24 14:20 ` Shawn Starr
1 sibling, 1 reply; 31+ messages in thread
From: Hans de Goede @ 2012-09-24 9:50 UTC (permalink / raw)
To: Shawn Starr; +Cc: qemu-devel, gerd
Hi,
On 09/23/2012 08:20 PM, Shawn Starr wrote:
> On Sunday, September 23, 2012 02:00:10 PM Shawn Starr wrote:
>> On Sunday, September 23, 2012 12:03:28 PM Hans de Goede wrote:
>>> Hi,
> <snip>
>>>
>>> spicec is deprecated you really should be using remote-viewer instead.
>>> That
>>> will give you an option to select devices.
>>
>
> <snip this out>
>
> The author of spice-gtk told me to downgrade since seems 0.14 broke, got
> things working now, I do see some buffer overflow errors and drops but no
> assert triggered.
>
> I have a detailed debug it worked attached via remote-viewer
>
> USB conversation:
>
> qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
> qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
> qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
> qemu-kvm: usb-redir: attaching high speed device 046d:0990 version 0.8 class
> ef
> qemu-kvm: usb-redir: reset device
> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 64 id
> 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> qemu-kvm: usb-redir: reset device
> qemu-kvm: usb-redir: set address 1
> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 18 id
> 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 255 id
> 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 255 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 1433 id
> 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 1433 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x302 index 1033 len 255
> id 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 18 id
> 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 9 id
> 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 9 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 1433 id
> 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 1433 id 1072685312
> qemu-kvm: usb-redir: set config 1 id 1072685440
> qemu-kvm: usb-redir: set config status 0 config 1 id 1072685440
> qemu-kvm: usb-redir: set interface 1 alt 0 id 1072685440
> qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
> qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
> qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
> qemu-kvm: usb-redir: alt status 0 intf 1 alt 0 id: 1072685440
> qemu-kvm: usb-redir: set interface 3 alt 0 id 1072685440
> qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
> qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
> qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
> qemu-kvm: usb-redir: alt status 0 intf 3 alt 0 id: 1072685440
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x85 val 0x100 index 1024 len 2 id
> 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x86 val 0x100 index 1024 len 1 id
> 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 1 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x85 val 0x100 index 1024 len 2 id
> 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x84 val 0x100 index 1024 len 4 id
> 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x82 val 0x100 index 1024 len 4 id
> 1072685312
> qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
> <snip>
>
> USB conversation during device usage:
>
>
> ... <snip>
>
Hmm, no messages like these ones:
qemu-system-x86_64: usb-redir: interrupt-in status 0 ep 87 len 9 id 1
qemu-system-x86_64: usb-redir: interrupt-token-in ep 87 status 0 len 9
?
Those are the ones I'm looking for as they indicate that my patch not only
fixes the assert, but that windows is actually getting interrupt packets
from the camera ...
Regards,
Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-23 18:52 ` Shawn Starr
@ 2012-09-24 9:52 ` Hans de Goede
2012-09-24 14:24 ` Shawn Starr
0 siblings, 1 reply; 31+ messages in thread
From: Hans de Goede @ 2012-09-24 9:52 UTC (permalink / raw)
To: Shawn Starr; +Cc: qemu-devel, gerd
Hi,
On 09/23/2012 08:52 PM, Shawn Starr wrote:
> I see why there are USB errors, I am seeing corrupt video frames with webcam
> attached via spice-usbredirection, this is not seen with host-usb attachment.
What errors exactly are you talking about I did not notice any error messages
in your logs.
> with spice/usb-redirection it can't seem to keep up with the packets,
> freezes/drops them.
You are running Fedora-18, right? Can you please try using either kernel
3.6.0-0.rc6.git0.1.fc18.x86_64 or an F-17 kernel, most Fedora 18 kernels
have various debugging options enabled causing significant additional
latencies in the network stack.
Also watch top and see you're not maxing out your CPU ...
Regards,
Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-24 9:50 ` Hans de Goede
@ 2012-09-24 14:20 ` Shawn Starr
2012-09-24 14:36 ` Hans de Goede
0 siblings, 1 reply; 31+ messages in thread
From: Shawn Starr @ 2012-09-24 14:20 UTC (permalink / raw)
To: Hans de Goede; +Cc: qemu-devel, gerd
On Monday, September 24, 2012 11:50:26 AM Hans de Goede wrote:
> Hi,
>
> On 09/23/2012 08:20 PM, Shawn Starr wrote:
> > On Sunday, September 23, 2012 02:00:10 PM Shawn Starr wrote:
> >> On Sunday, September 23, 2012 12:03:28 PM Hans de Goede wrote:
> >>> Hi,
> >
> > <snip>
> >
> >>> spicec is deprecated you really should be using remote-viewer instead.
> >>> That
> >>> will give you an option to select devices.
> >
> > <snip this out>
> >
> > The author of spice-gtk told me to downgrade since seems 0.14 broke, got
> > things working now, I do see some buffer overflow errors and drops but no
> > assert triggered.
> >
> > I have a detailed debug it worked attached via remote-viewer
> >
> > USB conversation:
> >
> > qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
> > qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
> > qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
> > qemu-kvm: usb-redir: attaching high speed device 046d:0990 version 0.8
> > class ef
> > qemu-kvm: usb-redir: reset device
> > qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 64
> > id
> > 1072685312
> > qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> > qemu-kvm: usb-redir: reset device
> > qemu-kvm: usb-redir: set address 1
> > qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 18
> > id
> > 1072685312
> > qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> > qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 255
> > id 1072685312
> > qemu-kvm: usb-redir: ctrl-in status 0 len 255 id 1072685312
> > qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 1433
> > id 1072685312
> > qemu-kvm: usb-redir: ctrl-in status 0 len 1433 id 1072685312
> > qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x302 index 1033 len
> > 255 id 1072685312
> > qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> > qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 18
> > id
> > 1072685312
> > qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> > qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 9 id
> > 1072685312
> > qemu-kvm: usb-redir: ctrl-in status 0 len 9 id 1072685312
> > qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 1433
> > id 1072685312
> > qemu-kvm: usb-redir: ctrl-in status 0 len 1433 id 1072685312
> > qemu-kvm: usb-redir: set config 1 id 1072685440
> > qemu-kvm: usb-redir: set config status 0 config 1 id 1072685440
> > qemu-kvm: usb-redir: set interface 1 alt 0 id 1072685440
> > qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
> > qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
> > qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
> > qemu-kvm: usb-redir: alt status 0 intf 1 alt 0 id: 1072685440
> > qemu-kvm: usb-redir: set interface 3 alt 0 id 1072685440
> > qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
> > qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
> > qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
> > qemu-kvm: usb-redir: alt status 0 intf 3 alt 0 id: 1072685440
> > qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x85 val 0x100 index 1024 len
> > 2 id 1072685312
> > qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
> > qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x86 val 0x100 index 1024 len
> > 1 id 1072685312
> > qemu-kvm: usb-redir: ctrl-in status 0 len 1 id 1072685312
> > qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x85 val 0x100 index 1024 len
> > 2 id 1072685312
> > qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
> > qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x84 val 0x100 index 1024 len
> > 4 id 1072685312
> > qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
> > qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x82 val 0x100 index 1024 len
> > 4 id 1072685312
> > qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
> > <snip>
> >
> > USB conversation during device usage:
> >
> >
> > ... <snip>
>
> Hmm, no messages like these ones:
>
> qemu-system-x86_64: usb-redir: interrupt-in status 0 ep 87 len 9 id 1
>
> qemu-system-x86_64: usb-redir: interrupt-token-in ep 87 status 0 len 9
>
> ?
>
Only see that once in the conversation
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
qemu-kvm: usb-redir: set interface 3 alt 0 id 1072685440
qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
qemu-kvm: usb-redir: alt status 0 intf 3 alt 0 id: 1072685440
___ qemu-kvm: usb-redir: interrupt-in status 0 ep 87 len 6 id 0
___ qemu-kvm: usb-redir: interrupt-token-in ep 87 status 0 len 6
qemu-kvm: usb-redir: ctrl-out type 0x21 req 0x1 val 0x200 index 1282 len 2 id
1072685440
qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685440
> Those are the ones I'm looking for as they indicate that my patch not only
> fixes the assert, but that windows is actually getting interrupt packets
> from the camera ...
>
> Regards,
>
> Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-24 9:52 ` Hans de Goede
@ 2012-09-24 14:24 ` Shawn Starr
0 siblings, 0 replies; 31+ messages in thread
From: Shawn Starr @ 2012-09-24 14:24 UTC (permalink / raw)
To: Hans de Goede; +Cc: qemu-devel, gerd
On Monday, September 24, 2012 11:52:36 AM Hans de Goede wrote:
> Hi,
>
> On 09/23/2012 08:52 PM, Shawn Starr wrote:
> > I see why there are USB errors, I am seeing corrupt video frames with
> > webcam attached via spice-usbredirection, this is not seen with host-usb
> > attachment.
> What errors exactly are you talking about I did not notice any error
> messages in your logs.
>
buffer overflows, not errors however
bufpq overflow, dropping packets ep 81
> > with spice/usb-redirection it can't seem to keep up with the packets,
> > freezes/drops them.
>
> You are running Fedora-18, right? Can you please try using either kernel
> 3.6.0-0.rc6.git0.1.fc18.x86_64 or an F-17 kernel, most Fedora 18 kernels
> have various debugging options enabled causing significant additional
> latencies in the network stack.
>
Linux segfault.sh0n.net 3.6.0-0.rc6.git0.1.fc18.x86_64 #1 SMP Mon Sep 17
13:16:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Yes, I am running the last non-debug kernel, but frames would freeze, or you
would get some interlaced with other frames, not really usable.
> Also watch top and see you're not maxing out your CPU ...
This I would need to try again to confirm that.
>
> Regards,
>
> Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-24 14:20 ` Shawn Starr
@ 2012-09-24 14:36 ` Hans de Goede
2012-09-24 14:38 ` Shawn Starr
0 siblings, 1 reply; 31+ messages in thread
From: Hans de Goede @ 2012-09-24 14:36 UTC (permalink / raw)
To: Shawn Starr; +Cc: qemu-devel, gerd
Hi,
On 09/24/2012 04:20 PM, Shawn Starr wrote:
> On Monday, September 24, 2012 11:50:26 AM Hans de Goede wrote:
>> Hi,
>>
>> On 09/23/2012 08:20 PM, Shawn Starr wrote:
>>> On Sunday, September 23, 2012 02:00:10 PM Shawn Starr wrote:
>>>> On Sunday, September 23, 2012 12:03:28 PM Hans de Goede wrote:
>>>>> Hi,
>>>
>>> <snip>
>>>
>>>>> spicec is deprecated you really should be using remote-viewer instead.
>>>>> That
>>>>> will give you an option to select devices.
>>>
>>> <snip this out>
>>>
>>> The author of spice-gtk told me to downgrade since seems 0.14 broke, got
>>> things working now, I do see some buffer overflow errors and drops but no
>>> assert triggered.
>>>
>>> I have a detailed debug it worked attached via remote-viewer
>>>
>>> USB conversation:
>>>
>>> qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
>>> qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
>>> qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
>>> qemu-kvm: usb-redir: attaching high speed device 046d:0990 version 0.8
>>> class ef
>>> qemu-kvm: usb-redir: reset device
>>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 64
>>> id
>>> 1072685312
>>> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
>>> qemu-kvm: usb-redir: reset device
>>> qemu-kvm: usb-redir: set address 1
>>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 18
>>> id
>>> 1072685312
>>> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
>>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 255
>>> id 1072685312
>>> qemu-kvm: usb-redir: ctrl-in status 0 len 255 id 1072685312
>>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 1433
>>> id 1072685312
>>> qemu-kvm: usb-redir: ctrl-in status 0 len 1433 id 1072685312
>>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x302 index 1033 len
>>> 255 id 1072685312
>>> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
>>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 18
>>> id
>>> 1072685312
>>> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
>>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 9 id
>>> 1072685312
>>> qemu-kvm: usb-redir: ctrl-in status 0 len 9 id 1072685312
>>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 1433
>>> id 1072685312
>>> qemu-kvm: usb-redir: ctrl-in status 0 len 1433 id 1072685312
>>> qemu-kvm: usb-redir: set config 1 id 1072685440
>>> qemu-kvm: usb-redir: set config status 0 config 1 id 1072685440
>>> qemu-kvm: usb-redir: set interface 1 alt 0 id 1072685440
>>> qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
>>> qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
>>> qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
>>> qemu-kvm: usb-redir: alt status 0 intf 1 alt 0 id: 1072685440
>>> qemu-kvm: usb-redir: set interface 3 alt 0 id 1072685440
>>> qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
>>> qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
>>> qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
>>> qemu-kvm: usb-redir: alt status 0 intf 3 alt 0 id: 1072685440
>>> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x85 val 0x100 index 1024 len
>>> 2 id 1072685312
>>> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
>>> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x86 val 0x100 index 1024 len
>>> 1 id 1072685312
>>> qemu-kvm: usb-redir: ctrl-in status 0 len 1 id 1072685312
>>> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x85 val 0x100 index 1024 len
>>> 2 id 1072685312
>>> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
>>> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x84 val 0x100 index 1024 len
>>> 4 id 1072685312
>>> qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
>>> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x82 val 0x100 index 1024 len
>>> 4 id 1072685312
>>> qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
>>> <snip>
>>>
>>> USB conversation during device usage:
>>>
>>>
>>> ... <snip>
>>
>> Hmm, no messages like these ones:
>>
>> qemu-system-x86_64: usb-redir: interrupt-in status 0 ep 87 len 9 id 1
>>
>> qemu-system-x86_64: usb-redir: interrupt-token-in ep 87 status 0 len 9
>>
>> ?
>>
>
> Only see that once in the conversation
Hmm, also while streaming ? Well once does indicate interrupt endpoints are working,
but I would expect this to happen more often.
Regards,
Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-24 14:36 ` Hans de Goede
@ 2012-09-24 14:38 ` Shawn Starr
2012-10-02 15:26 ` Shawn Starr
0 siblings, 1 reply; 31+ messages in thread
From: Shawn Starr @ 2012-09-24 14:38 UTC (permalink / raw)
To: Hans de Goede; +Cc: qemu-devel, gerd
On Monday, September 24, 2012 04:36:15 PM Hans de Goede wrote:
> Hi,
>
> On 09/24/2012 04:20 PM, Shawn Starr wrote:
> > On Monday, September 24, 2012 11:50:26 AM Hans de Goede wrote:
> >> Hi,
> >>
> >> On 09/23/2012 08:20 PM, Shawn Starr wrote:
> >>> On Sunday, September 23, 2012 02:00:10 PM Shawn Starr wrote:
> >>>> On Sunday, September 23, 2012 12:03:28 PM Hans de Goede wrote:
> >>>>> Hi,
> >>>
> >>> <snip>
> >>>
> >>>>> spicec is deprecated you really should be using remote-viewer instead.
> >>>>> That
> >>>>> will give you an option to select devices.
> >>>
> >>> <snip this out>
> >>>
> >>> The author of spice-gtk told me to downgrade since seems 0.14 broke, got
> >>> things working now, I do see some buffer overflow errors and drops but
> >>> no
> >>> assert triggered.
> >>>
> >>> I have a detailed debug it worked attached via remote-viewer
> >>>
> >>> USB conversation:
> >>>
> >>> qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
> >>> qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
> >>> qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
> >>> qemu-kvm: usb-redir: attaching high speed device 046d:0990 version 0.8
> >>> class ef
> >>> qemu-kvm: usb-redir: reset device
> >>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 64
> >>> id
> >>> 1072685312
> >>> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> >>> qemu-kvm: usb-redir: reset device
> >>> qemu-kvm: usb-redir: set address 1
> >>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 18
> >>> id
> >>> 1072685312
> >>> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len
> >>> 255
> >>> id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-in status 0 len 255 id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len
> >>> 1433
> >>> id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-in status 0 len 1433 id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x302 index 1033 len
> >>> 255 id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len 18
> >>> id
> >>> 1072685312
> >>> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len 9
> >>> id
> >>> 1072685312
> >>> qemu-kvm: usb-redir: ctrl-in status 0 len 9 id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len
> >>> 1433
> >>> id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-in status 0 len 1433 id 1072685312
> >>> qemu-kvm: usb-redir: set config 1 id 1072685440
> >>> qemu-kvm: usb-redir: set config status 0 config 1 id 1072685440
> >>> qemu-kvm: usb-redir: set interface 1 alt 0 id 1072685440
> >>> qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
> >>> qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
> >>> qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
> >>> qemu-kvm: usb-redir: alt status 0 intf 1 alt 0 id: 1072685440
> >>> qemu-kvm: usb-redir: set interface 3 alt 0 id 1072685440
> >>> qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
> >>> qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
> >>> qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
> >>> qemu-kvm: usb-redir: alt status 0 intf 3 alt 0 id: 1072685440
> >>> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x85 val 0x100 index 1024
> >>> len
> >>> 2 id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x86 val 0x100 index 1024
> >>> len
> >>> 1 id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-in status 0 len 1 id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x85 val 0x100 index 1024
> >>> len
> >>> 2 id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x84 val 0x100 index 1024
> >>> len
> >>> 4 id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x82 val 0x100 index 1024
> >>> len
> >>> 4 id 1072685312
> >>> qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
> >>> <snip>
> >>>
> >>> USB conversation during device usage:
> >>>
> >>>
> >>> ... <snip>
> >>
> >> Hmm, no messages like these ones:
> >>
> >> qemu-system-x86_64: usb-redir: interrupt-in status 0 ep 87 len 9 id 1
> >>
> >> qemu-system-x86_64: usb-redir: interrupt-token-in ep 87 status 0 len 9
> >>
> >> ?
> >
> > Only see that once in the conversation
>
> Hmm, also while streaming ? Well once does indicate interrupt endpoints are
> working, but I would expect this to happen more often.
>
Yes, I saw this once, i was using the QuickCam app to make a picture but just
let it run showing the video but only saw that once in the log I have.
> Regards,
>
> Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-09-24 14:38 ` Shawn Starr
@ 2012-10-02 15:26 ` Shawn Starr
2012-10-08 11:27 ` Hans de Goede
0 siblings, 1 reply; 31+ messages in thread
From: Shawn Starr @ 2012-10-02 15:26 UTC (permalink / raw)
To: Hans de Goede; +Cc: qemu-devel, gerd
On Monday, September 24, 2012 10:38:57 AM Shawn Starr wrote:
> On Monday, September 24, 2012 04:36:15 PM Hans de Goede wrote:
> > Hi,
> >
Hello,
Reopening this issue with usb-host stalling now
ehci warning: guest updated active QH
USBDEVFS_DISCARDURB: Invalid argument
USBDEVFS_DISCARDURB: Invalid argument
husb: leaking iso urbs because of discard failure
Now with qemu-XXX-1.2.0-12.fc18.x86_64
if I have webcam open, it will stall and not resume. This is with usb-host
directly.
Shall I enable debugging again?
Thanks,
Shawn.
> > On 09/24/2012 04:20 PM, Shawn Starr wrote:
> > > On Monday, September 24, 2012 11:50:26 AM Hans de Goede wrote:
> > >> Hi,
> > >>
> > >> On 09/23/2012 08:20 PM, Shawn Starr wrote:
> > >>> On Sunday, September 23, 2012 02:00:10 PM Shawn Starr wrote:
> > >>>> On Sunday, September 23, 2012 12:03:28 PM Hans de Goede wrote:
> > >>>>> Hi,
> > >>>
> > >>> <snip>
> > >>>
> > >>>>> spicec is deprecated you really should be using remote-viewer
> > >>>>> instead.
> > >>>>> That
> > >>>>> will give you an option to select devices.
> > >>>
> > >>> <snip this out>
> > >>>
> > >>> The author of spice-gtk told me to downgrade since seems 0.14 broke,
> > >>> got
> > >>> things working now, I do see some buffer overflow errors and drops but
> > >>> no
> > >>> assert triggered.
> > >>>
> > >>> I have a detailed debug it worked attached via remote-viewer
> > >>>
> > >>> USB conversation:
> > >>>
> > >>> qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
> > >>> qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
> > >>> qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
> > >>> qemu-kvm: usb-redir: attaching high speed device 046d:0990 version 0.8
> > >>> class ef
> > >>> qemu-kvm: usb-redir: reset device
> > >>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len
> > >>> 64
> > >>> id
> > >>> 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> > >>> qemu-kvm: usb-redir: reset device
> > >>> qemu-kvm: usb-redir: set address 1
> > >>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len
> > >>> 18
> > >>> id
> > >>> 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len
> > >>> 255
> > >>> id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-in status 0 len 255 id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len
> > >>> 1433
> > >>> id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-in status 0 len 1433 id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x302 index 1033
> > >>> len
> > >>> 255 id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x100 index 0 len
> > >>> 18
> > >>> id
> > >>> 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-in status 0 len 18 id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len
> > >>> 9
> > >>> id
> > >>> 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-in status 0 len 9 id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-out type 0x80 req 0x6 val 0x200 index 0 len
> > >>> 1433
> > >>> id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-in status 0 len 1433 id 1072685312
> > >>> qemu-kvm: usb-redir: set config 1 id 1072685440
> > >>> qemu-kvm: usb-redir: set config status 0 config 1 id 1072685440
> > >>> qemu-kvm: usb-redir: set interface 1 alt 0 id 1072685440
> > >>> qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
> > >>> qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
> > >>> qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
> > >>> qemu-kvm: usb-redir: alt status 0 intf 1 alt 0 id: 1072685440
> > >>> qemu-kvm: usb-redir: set interface 3 alt 0 id 1072685440
> > >>> qemu-kvm: usb-redir: ep: 00 type: 0 interface: 0
> > >>> qemu-kvm: usb-redir: ep: 80 type: 0 interface: 0
> > >>> qemu-kvm: usb-redir: ep: 87 type: 3 interface: 0
> > >>> qemu-kvm: usb-redir: alt status 0 intf 3 alt 0 id: 1072685440
> > >>> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x85 val 0x100 index 1024
> > >>> len
> > >>> 2 id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x86 val 0x100 index 1024
> > >>> len
> > >>> 1 id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-in status 0 len 1 id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x85 val 0x100 index 1024
> > >>> len
> > >>> 2 id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-in status 0 len 2 id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x84 val 0x100 index 1024
> > >>> len
> > >>> 4 id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-out type 0xa1 req 0x82 val 0x100 index 1024
> > >>> len
> > >>> 4 id 1072685312
> > >>> qemu-kvm: usb-redir: ctrl-in status 0 len 4 id 1072685312
> > >>> <snip>
> > >>>
> > >>> USB conversation during device usage:
> > >>>
> > >>>
> > >>> ... <snip>
> > >>
> > >> Hmm, no messages like these ones:
> > >>
> > >> qemu-system-x86_64: usb-redir: interrupt-in status 0 ep 87 len 9 id 1
> > >>
> > >> qemu-system-x86_64: usb-redir: interrupt-token-in ep 87 status 0 len 9
> > >>
> > >> ?
> > >
> > > Only see that once in the conversation
> >
> > Hmm, also while streaming ? Well once does indicate interrupt endpoints
> > are
> > working, but I would expect this to happen more often.
>
> Yes, I saw this once, i was using the QuickCam app to make a picture but
> just let it run showing the video but only saw that once in the log I have.
> > Regards,
> >
> > Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-10-02 15:26 ` Shawn Starr
@ 2012-10-08 11:27 ` Hans de Goede
2012-10-08 13:01 ` Johannes Stezenbach
0 siblings, 1 reply; 31+ messages in thread
From: Hans de Goede @ 2012-10-08 11:27 UTC (permalink / raw)
To: Shawn Starr; +Cc: qemu-devel, gerd
Hi,
On 10/02/2012 05:26 PM, Shawn Starr wrote:
> On Monday, September 24, 2012 10:38:57 AM Shawn Starr wrote:
>> On Monday, September 24, 2012 04:36:15 PM Hans de Goede wrote:
>>> Hi,
>>>
>
> Hello,
>
> Reopening this issue with usb-host stalling now
>
> ehci warning: guest updated active QH
> USBDEVFS_DISCARDURB: Invalid argument
> USBDEVFS_DISCARDURB: Invalid argument
> husb: leaking iso urbs because of discard failure
>
>
> Now with qemu-XXX-1.2.0-12.fc18.x86_64
>
> if I have webcam open, it will stall and not resume. This is with usb-host
> directly.
>
> Shall I enable debugging again?
Hmm, this likely is caused by too high latencies in your system,
which are caused in turn I believe by you running an F-18 kernel which
has various debugging options enabled inside the kernel which can
cause significant latencies. I've spend 1.5 days tracing this very
same issue down in the past. So please first of all make sure that you're
running a kernel without debugging options enabled, either the latest
F-18 build from koji:
http://koji.fedoraproject.org/koji/buildinfo?buildID=358570
or an F-17 kernel, almost all the F-18 "rc" kernels have debugging enabled
and thus cause significant latency issues.
If you can reproduce this with a kernel without the debugging options,
then we can investigate this further.
Regards,
Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-10-08 11:27 ` Hans de Goede
@ 2012-10-08 13:01 ` Johannes Stezenbach
2012-10-08 13:51 ` Hans de Goede
0 siblings, 1 reply; 31+ messages in thread
From: Johannes Stezenbach @ 2012-10-08 13:01 UTC (permalink / raw)
To: Hans de Goede; +Cc: Shawn Starr, qemu-devel, gerd
Hi Hans,
On Mon, Oct 08, 2012 at 01:27:28PM +0200, Hans de Goede wrote:
> On 10/02/2012 05:26 PM, Shawn Starr wrote:
> >
> >Reopening this issue with usb-host stalling now
> >
> >ehci warning: guest updated active QH
> >USBDEVFS_DISCARDURB: Invalid argument
> >USBDEVFS_DISCARDURB: Invalid argument
> >husb: leaking iso urbs because of discard failure
> >
> >
> >Now with qemu-XXX-1.2.0-12.fc18.x86_64
> >
> >if I have webcam open, it will stall and not resume. This is with usb-host
> >directly.
> >
> >Shall I enable debugging again?
>
> Hmm, this likely is caused by too high latencies in your system,
> which are caused in turn I believe by you running an F-18 kernel which
> has various debugging options enabled inside the kernel which can
> cause significant latencies. I've spend 1.5 days tracing this very
> same issue down in the past. So please first of all make sure that you're
> running a kernel without debugging options enabled, either the latest
> F-18 build from koji:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=358570
>
> or an F-17 kernel, almost all the F-18 "rc" kernels have debugging enabled
> and thus cause significant latency issues.
>
> If you can reproduce this with a kernel without the debugging options,
> then we can investigate this further.
By changing the kernel, don't you just make the issue harder to reproduce?
I mean Linux isn't real-time so any kernel can show latency spikes
and it's a show-stopper if iso transfers stall instead of just
dropping some packets.
There will always be a race between the call to USBDEVFS_DISCARDURB
and the URB completing. IMHO the handling in usb_host_stop_n_free_iso()
is buggy. How about dropping the "killed" and "free" variables and
calling async_complete() and g_free() unconditionally?
Johannes
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-10-08 13:01 ` Johannes Stezenbach
@ 2012-10-08 13:51 ` Hans de Goede
2012-10-08 14:49 ` Johannes Stezenbach
0 siblings, 1 reply; 31+ messages in thread
From: Hans de Goede @ 2012-10-08 13:51 UTC (permalink / raw)
To: Johannes Stezenbach; +Cc: Shawn Starr, qemu-devel, gerd
Hi,
On 10/08/2012 03:01 PM, Johannes Stezenbach wrote:
> Hi Hans,
>
> On Mon, Oct 08, 2012 at 01:27:28PM +0200, Hans de Goede wrote:
>> On 10/02/2012 05:26 PM, Shawn Starr wrote:
>>>
>>> Reopening this issue with usb-host stalling now
>>>
>>> ehci warning: guest updated active QH
>>> USBDEVFS_DISCARDURB: Invalid argument
>>> USBDEVFS_DISCARDURB: Invalid argument
>>> husb: leaking iso urbs because of discard failure
>>>
>>>
>>> Now with qemu-XXX-1.2.0-12.fc18.x86_64
>>>
>>> if I have webcam open, it will stall and not resume. This is with usb-host
>>> directly.
>>>
>>> Shall I enable debugging again?
>>
>> Hmm, this likely is caused by too high latencies in your system,
>> which are caused in turn I believe by you running an F-18 kernel which
>> has various debugging options enabled inside the kernel which can
>> cause significant latencies. I've spend 1.5 days tracing this very
>> same issue down in the past. So please first of all make sure that you're
>> running a kernel without debugging options enabled, either the latest
>> F-18 build from koji:
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=358570
>>
>> or an F-17 kernel, almost all the F-18 "rc" kernels have debugging enabled
>> and thus cause significant latency issues.
>>
>> If you can reproduce this with a kernel without the debugging options,
>> then we can investigate this further.
>
> By changing the kernel, don't you just make the issue harder to reproduce?
> I mean Linux isn't real-time so any kernel can show latency spikes
> and it's a show-stopper if iso transfers stall instead of just
> dropping some packets.
>
> There will always be a race between the call to USBDEVFS_DISCARDURB
> and the URB completing. IMHO the handling in usb_host_stop_n_free_iso()
> is buggy. How about dropping the "killed" and "free" variables and
> calling async_complete() and g_free() unconditionally?
This race is well known already handled correctly, the real problem is the
"ehci warning: guest updated active QH" message, which most likely indicates
that the guest has hit the doorbell (IAAD) in the EHCI controller, and then
has not gotten an IAA interrupt within
a certain amount of time triggering its IAAD watchdog (some real EHCI
hardware is broken wrt delivering IAA interrupt) causing us to not see
an unlinked qh as unlinked, and then later on triggering the
"warning: guest updated active QH" message.
This is unavoidable when we get too large latencies, the ehci hardware
simple was not designed to be virtualized, anything but actually.
Regards,
Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-10-08 13:51 ` Hans de Goede
@ 2012-10-08 14:49 ` Johannes Stezenbach
2012-10-08 15:03 ` Hans de Goede
0 siblings, 1 reply; 31+ messages in thread
From: Johannes Stezenbach @ 2012-10-08 14:49 UTC (permalink / raw)
To: Hans de Goede; +Cc: Shawn Starr, qemu-devel, gerd
Hi,
On Mon, Oct 08, 2012 at 03:51:08PM +0200, Hans de Goede wrote:
> On 10/08/2012 03:01 PM, Johannes Stezenbach wrote:
> >
> >There will always be a race between the call to USBDEVFS_DISCARDURB
> >and the URB completing. IMHO the handling in usb_host_stop_n_free_iso()
> >is buggy. How about dropping the "killed" and "free" variables and
> >calling async_complete() and g_free() unconditionally?
>
> This race is well known already handled correctly,
You mean the message about "leaking iso urbs" is wrong?
(since it will be freed later in async_completem right?)
> the real problem is the
> "ehci warning: guest updated active QH" message, which most likely indicates
> that the guest has hit the doorbell (IAAD) in the EHCI controller, and then
> has not gotten an IAA interrupt within
> a certain amount of time triggering its IAAD watchdog (some real EHCI
> hardware is broken wrt delivering IAA interrupt) causing us to not see
> an unlinked qh as unlinked, and then later on triggering the
> "warning: guest updated active QH" message.
>
> This is unavoidable when we get too large latencies, the ehci hardware
> simple was not designed to be virtualized, anything but actually.
OK, thanks for this explanation.
I haven't much clue about qemu but isn't the issue that qemu
delivers timer irqs to the guest (for EHCI_HRTIMER_IAA_WATCHDOG) while
failing to handle the IAAD -> IAA interrupt generation?
(via qemu_bh_schedule -> ehci_advance_async_state -> ehci_raise_irq,
why does ehci_raise_irq() not call ehci_update_irq() for USBSTS_IAA?)
If that cannot be fixed, have you tried talking to the Linux
EHCI driver maintainer if the EHCI_HRTIMER_IAA_WATCHDOG
timeout (10ms) can be increased or skipped entirely for non-broken hw?
(Linux commit 26f953fd884ea4879 suggests it's only for VIA chips)
Thanks,
Johannes
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-10-08 14:49 ` Johannes Stezenbach
@ 2012-10-08 15:03 ` Hans de Goede
2012-10-08 16:11 ` Johannes Stezenbach
0 siblings, 1 reply; 31+ messages in thread
From: Hans de Goede @ 2012-10-08 15:03 UTC (permalink / raw)
To: Johannes Stezenbach; +Cc: Shawn Starr, qemu-devel, gerd
Hi,
On 10/08/2012 04:49 PM, Johannes Stezenbach wrote:
> Hi,
>
> On Mon, Oct 08, 2012 at 03:51:08PM +0200, Hans de Goede wrote:
>> On 10/08/2012 03:01 PM, Johannes Stezenbach wrote:
>>>
>>> There will always be a race between the call to USBDEVFS_DISCARDURB
>>> and the URB completing. IMHO the handling in usb_host_stop_n_free_iso()
>>> is buggy. How about dropping the "killed" and "free" variables and
>>> calling async_complete() and g_free() unconditionally?
>>
>> This race is well known already handled correctly,
>
> You mean the message about "leaking iso urbs" is wrong?
> (since it will be freed later in async_completem right?)
>
Hmm, ah this is about iso urbs, not about regular async urbs. Sorry, then I'm
not sure if the code is correct. I'm not that familiar with the host-linux
code, as I work on and use the usb-redir code mostly.
>> the real problem is the
>> "ehci warning: guest updated active QH" message, which most likely indicates
>> that the guest has hit the doorbell (IAAD) in the EHCI controller, and then
>> has not gotten an IAA interrupt within
>> a certain amount of time triggering its IAAD watchdog (some real EHCI
>> hardware is broken wrt delivering IAA interrupt) causing us to not see
>> an unlinked qh as unlinked, and then later on triggering the
>> "warning: guest updated active QH" message.
>>
>> This is unavoidable when we get too large latencies, the ehci hardware
>> simple was not designed to be virtualized, anything but actually.
>
> OK, thanks for this explanation.
> I haven't much clue about qemu but isn't the issue that qemu
> delivers timer irqs to the guest (for EHCI_HRTIMER_IAA_WATCHDOG) while
> failing to handle the IAAD -> IAA interrupt generation?
> (via qemu_bh_schedule -> ehci_advance_async_state -> ehci_raise_irq,
> why does ehci_raise_irq() not call ehci_update_irq() for USBSTS_IAA?)
We need to throttle the interrupt generation inside ehci both per
the spec, and because otherwise we may trigger:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=361aabf395e4a23cf554cf4ec0c0c6963b8beb01
Which is present in all but the very latest linux kernels.
> If that cannot be fixed, have you tried talking to the Linux
> EHCI driver maintainer if the EHCI_HRTIMER_IAA_WATCHDOG
> timeout (10ms) can be increased or skipped entirely for non-broken hw?
> (Linux commit 26f953fd884ea4879 suggests it's only for VIA chips)
AFAIK Shawn is using a windows guest, so the fact that he is seeing
the "ehci warning: guest updated active QH" warning, suggests that
windows is using a watchdog too, also the messages about cancelling
the isoc stream suggest that windows is actively stopping the stream
from the webcam, at which point there is little the redir code
can do to recover. This could be caused by timeouts caused by the
latency spikes from the debug kernel...
We do our best to make the whole usb-redir code and ehci emulation as
proof as possible against latency spikes, and some of the patches
from my latest patchset may help there, but in the end, esp. for
isoc devices, the code will always be sensitive to too large latencies.
Regards,
Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-10-08 15:03 ` Hans de Goede
@ 2012-10-08 16:11 ` Johannes Stezenbach
2012-10-08 20:10 ` Hans de Goede
0 siblings, 1 reply; 31+ messages in thread
From: Johannes Stezenbach @ 2012-10-08 16:11 UTC (permalink / raw)
To: Hans de Goede; +Cc: Shawn Starr, qemu-devel, gerd
Hi,
On Mon, Oct 08, 2012 at 05:03:24PM +0200, Hans de Goede wrote:
> On 10/08/2012 04:49 PM, Johannes Stezenbach wrote:
> >On Mon, Oct 08, 2012 at 03:51:08PM +0200, Hans de Goede wrote:
> >>the real problem is the
> >>"ehci warning: guest updated active QH" message, which most likely indicates
> >>that the guest has hit the doorbell (IAAD) in the EHCI controller, and then
> >>has not gotten an IAA interrupt within
> >>a certain amount of time triggering its IAAD watchdog (some real EHCI
> >>hardware is broken wrt delivering IAA interrupt) causing us to not see
> >>an unlinked qh as unlinked, and then later on triggering the
> >>"warning: guest updated active QH" message.
> >>
> >>This is unavoidable when we get too large latencies, the ehci hardware
> >>simple was not designed to be virtualized, anything but actually.
> >
> >OK, thanks for this explanation.
> >I haven't much clue about qemu but isn't the issue that qemu
> >delivers timer irqs to the guest (for EHCI_HRTIMER_IAA_WATCHDOG) while
> >failing to handle the IAAD -> IAA interrupt generation?
> >(via qemu_bh_schedule -> ehci_advance_async_state -> ehci_raise_irq,
> >why does ehci_raise_irq() not call ehci_update_irq() for USBSTS_IAA?)
>
> We need to throttle the interrupt generation inside ehci both per
> the spec, and because otherwise we may trigger:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=361aabf395e4a23cf554cf4ec0c0c6963b8beb01
>
> Which is present in all but the very latest linux kernels.
Not nice :-(
> We do our best to make the whole usb-redir code and ehci emulation as
> proof as possible against latency spikes, and some of the patches
> from my latest patchset may help there, but in the end, esp. for
> isoc devices, the code will always be sensitive to too large latencies.
OK, I read up on the EHCI interrupt threshold and found how
ehci_frame_timer() calls ehci_commit_irq(). I agree it is
hard to fix. I wonder if it would be sufficient if qemu would
guarantee ehci_frame_timer() runs before sending the timer irq
that triggers the IAA timeout, but I guess it depends on what the
guest processes first. I also wonder if this is not a generic problem
for all emulated hw if the driver uses some timeout?
Thanks
Johannes
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-10-08 16:11 ` Johannes Stezenbach
@ 2012-10-08 20:10 ` Hans de Goede
2012-10-08 20:18 ` Shawn Starr
0 siblings, 1 reply; 31+ messages in thread
From: Hans de Goede @ 2012-10-08 20:10 UTC (permalink / raw)
To: Johannes Stezenbach; +Cc: Shawn Starr, qemu-devel, gerd
Hi,
On 10/08/2012 06:11 PM, Johannes Stezenbach wrote:
<mega snip>
> I also wonder if this is not a generic problem
> for all emulated hw if the driver uses some timeout?
Yes it likely is, because the emulated timer interrupt will
try to make up for time lost when the vm was not running
(in either hypervisor or guest mode), while as hw emulation
code which has been pre-empted for what ever reason my
simply need some more actual running time before it can
complete the task as hand, at which point the timeout
will trigger sooner then the hw emulation can handle the
task ...
Note that with the EHCI emulation we also can have the
2 (guest and hw-emulation time) get out of sync in the
other way. When we got behind in processing frames
on the periodic schedule compared to "real-time" we would
catch up too fast, causing the guest to see large
jumps in the frindex register, which it does not like.
So all of this really is a precarious balancing act, and
to get back to the subject of the thread, the latency
spikes some of the kernels debugging options can cause,
can upset the balance...
Regards,
Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-10-08 20:10 ` Hans de Goede
@ 2012-10-08 20:18 ` Shawn Starr
2012-10-08 21:32 ` Hans de Goede
0 siblings, 1 reply; 31+ messages in thread
From: Shawn Starr @ 2012-10-08 20:18 UTC (permalink / raw)
To: Hans de Goede; +Cc: Johannes Stezenbach, qemu-devel, gerd
On Monday, October 08, 2012 10:10:49 PM Hans de Goede wrote:
> Hi,
>
> On 10/08/2012 06:11 PM, Johannes Stezenbach wrote:
>
> <mega snip>
>
> > I also wonder if this is not a generic problem
> >
> > for all emulated hw if the driver uses some timeout?
>
> Yes it likely is, because the emulated timer interrupt will
> try to make up for time lost when the vm was not running
> (in either hypervisor or guest mode), while as hw emulation
> code which has been pre-empted for what ever reason my
> simply need some more actual running time before it can
> complete the task as hand, at which point the timeout
> will trigger sooner then the hw emulation can handle the
> task ...
>
> Note that with the EHCI emulation we also can have the
> 2 (guest and hw-emulation time) get out of sync in the
> other way. When we got behind in processing frames
> on the periodic schedule compared to "real-time" we would
> catch up too fast, causing the guest to see large
> jumps in the frindex register, which it does not like.
>
> So all of this really is a precarious balancing act, and
> to get back to the subject of the thread, the latency
> spikes some of the kernels debugging options can cause,
> can upset the balance...
>
Hello folks,
I am using a non-debug kernel (because debug kernels are seriously sluggish).
I may elect to get kernel-3.6.0-3.fc18 or kernel-3.6.1-1.fc18 from koji also
since 3.6 is final now.
Currently using: 3.6.0-0.rc7.git0.1.fc18.x86_64
Thanks,
Shawn.
> Regards,
>
> Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-10-08 20:18 ` Shawn Starr
@ 2012-10-08 21:32 ` Hans de Goede
2012-10-08 21:37 ` Shawn Starr
0 siblings, 1 reply; 31+ messages in thread
From: Hans de Goede @ 2012-10-08 21:32 UTC (permalink / raw)
To: Shawn Starr; +Cc: Johannes Stezenbach, qemu-devel, gerd
Hi,
On 10/08/2012 10:18 PM, Shawn Starr wrote:
> On Monday, October 08, 2012 10:10:49 PM Hans de Goede wrote:
>> Hi,
>>
>> On 10/08/2012 06:11 PM, Johannes Stezenbach wrote:
>>
>> <mega snip>
>>
>> > I also wonder if this is not a generic problem
>>>
>>> for all emulated hw if the driver uses some timeout?
>>
>> Yes it likely is, because the emulated timer interrupt will
>> try to make up for time lost when the vm was not running
>> (in either hypervisor or guest mode), while as hw emulation
>> code which has been pre-empted for what ever reason my
>> simply need some more actual running time before it can
>> complete the task as hand, at which point the timeout
>> will trigger sooner then the hw emulation can handle the
>> task ...
>>
>> Note that with the EHCI emulation we also can have the
>> 2 (guest and hw-emulation time) get out of sync in the
>> other way. When we got behind in processing frames
>> on the periodic schedule compared to "real-time" we would
>> catch up too fast, causing the guest to see large
>> jumps in the frindex register, which it does not like.
>>
>> So all of this really is a precarious balancing act, and
>> to get back to the subject of the thread, the latency
>> spikes some of the kernels debugging options can cause,
>> can upset the balance...
>>
>
> Hello folks,
>
> I am using a non-debug kernel (because debug kernels are seriously sluggish).
> I may elect to get kernel-3.6.0-3.fc18 or kernel-3.6.1-1.fc18 from koji also
> since 3.6 is final now.
>
> Currently using: 3.6.0-0.rc7.git0.1.fc18.x86_64
Hmm, so were you using this at the time you hit the bug you reported
earlier too ? And can you reproduce that bug or was it a one
time occurence ?
Regards,
Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
2012-10-08 21:32 ` Hans de Goede
@ 2012-10-08 21:37 ` Shawn Starr
0 siblings, 0 replies; 31+ messages in thread
From: Shawn Starr @ 2012-10-08 21:37 UTC (permalink / raw)
To: Hans de Goede; +Cc: Johannes Stezenbach, qemu-devel, gerd
On Monday, October 08, 2012 11:32:54 PM Hans de Goede wrote:
> Hi,
>
> On 10/08/2012 10:18 PM, Shawn Starr wrote:
> > On Monday, October 08, 2012 10:10:49 PM Hans de Goede wrote:
> >> Hi,
> >>
> >> On 10/08/2012 06:11 PM, Johannes Stezenbach wrote:
> >>
> >> <mega snip>
> >>
> >> > I also wonder if this is not a generic problem
> >>>
> >>> for all emulated hw if the driver uses some timeout?
> >>
> >> Yes it likely is, because the emulated timer interrupt will
> >> try to make up for time lost when the vm was not running
> >> (in either hypervisor or guest mode), while as hw emulation
> >> code which has been pre-empted for what ever reason my
> >> simply need some more actual running time before it can
> >> complete the task as hand, at which point the timeout
> >> will trigger sooner then the hw emulation can handle the
> >> task ...
> >>
> >> Note that with the EHCI emulation we also can have the
> >> 2 (guest and hw-emulation time) get out of sync in the
> >> other way. When we got behind in processing frames
> >> on the periodic schedule compared to "real-time" we would
> >> catch up too fast, causing the guest to see large
> >> jumps in the frindex register, which it does not like.
> >>
> >> So all of this really is a precarious balancing act, and
> >> to get back to the subject of the thread, the latency
> >> spikes some of the kernels debugging options can cause,
> >> can upset the balance...
> >
> > Hello folks,
> >
> > I am using a non-debug kernel (because debug kernels are seriously
> > sluggish). I may elect to get kernel-3.6.0-3.fc18 or kernel-3.6.1-1.fc18
> > from koji also since 3.6 is final now.
> >
> > Currently using: 3.6.0-0.rc7.git0.1.fc18.x86_64
>
> Hmm, so were you using this at the time you hit the bug you reported
> earlier too ? And can you reproduce that bug or was it a one
> time occurence ?
>
Need to retry, I triggered this with yahoo IM client in VM. I'll just go to
3.6.1 and try this again this week. When I did trigger this with
3.6.0-0.rc7.git0.1.fc18, it was repeatable.
Thanks,
Shawn.
> Regards,
>
> Hans
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2012-10-08 21:37 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-19 16:42 [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting Shawn Starr
2012-09-19 16:53 ` Shawn Starr
2012-09-20 15:37 ` Hans de Goede
2012-09-20 19:08 ` Shawn Starr
2012-09-20 23:28 ` Shawn Starr
[not found] ` <6177450.mT8I4ey0nz@segfault.sh0n.net>
2012-09-21 0:04 ` Shawn Starr
2012-09-21 12:19 ` Hans de Goede
2012-09-21 15:39 ` Shawn Starr
2012-09-21 17:35 ` Hans de Goede
2012-09-21 18:46 ` Shawn Starr
2012-09-23 10:03 ` Hans de Goede
2012-09-23 18:00 ` Shawn Starr
2012-09-23 18:20 ` Shawn Starr
2012-09-23 18:52 ` Shawn Starr
2012-09-24 9:52 ` Hans de Goede
2012-09-24 14:24 ` Shawn Starr
2012-09-24 9:50 ` Hans de Goede
2012-09-24 14:20 ` Shawn Starr
2012-09-24 14:36 ` Hans de Goede
2012-09-24 14:38 ` Shawn Starr
2012-10-02 15:26 ` Shawn Starr
2012-10-08 11:27 ` Hans de Goede
2012-10-08 13:01 ` Johannes Stezenbach
2012-10-08 13:51 ` Hans de Goede
2012-10-08 14:49 ` Johannes Stezenbach
2012-10-08 15:03 ` Hans de Goede
2012-10-08 16:11 ` Johannes Stezenbach
2012-10-08 20:10 ` Hans de Goede
2012-10-08 20:18 ` Shawn Starr
2012-10-08 21:32 ` Hans de Goede
2012-10-08 21:37 ` Shawn Starr
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).