Re: usb audio device troubles
Hi Eric, On 03-12-14 16:39, Eric S. Johansson wrote: On 12/3/2014 3:52 AM, Hans de Goede wrote: Eric are you using usb-host redirection, or Spice's usb network redir ? This little bit of time this morning learning about spice and the network redirection. It worked for about half an hour and then failed in the same way the host redirection failed. The audio device would appear for a while, I would try to use it and then it would disappear. The spice model has some very nice features and that I could, in theory, have a working speech recognition engine somewhere on my air quotescloud/air quotes and then be able to use it via spice on any desktop I happen to be located in front of. it would also work nicely with my original idea of putting a working KVM virtual machine on and an e-sata SSD external drive and be able to bring my working speech recognition environment with me without having cart a laptop. I hope you can see that this could be generalized into a nicely portable accessibility solution where the accessibility environment moves with the disabled user and removes the need to make every machine have user specific accessibility software and configuration. Yes, it does impose a requirement the KVM runs everywhere but, we know that's the future anyway so why fight it :-) Anyway, I think if we can solve this USB audio device problem then I'll be very happy and can make further progress towards my goal. Thank you so very much for the help so far and I hope we can fix this USB problem. To further figure out what is going on when the usb device disconnects we will need some logs. For starters lets look at the spice-client side, before starting virt-manager or virt-viewer do the following in the terminal: export LIBUSB_DEBUG=4 And then start the application from the terminal like e.g. this: virt-manager virt-man.log Then do what you want to do with the usb headset until it disconnects, and once it has disconnected quit and attach the generated virt-man.log file to your next mail. Regards, Hans p.s. Below are instructions to gather logs on the qemu side. I do not need those right now, first lets do the client side logs, but since I've already looked up the instructions I thought it would be good to put them in this mail: Standard the libvirt qemu logs under: /var/log/libvirt/qemu/vm-name.log Should contain some minimal usb logging. If native usb is properly setup and a client connects which supports native usb, one would expect messages like this to show up there: qemu-system-x86_64: usbredirparser: Peer version: spice-gtk 0.21, using 64-bits ids If a message like the above does not show up then there is a problem with the vm config, and further more detailed debugging is not going to help. If you're debugging problems with a certain device it may be helpful to enable more verbose logging of usb traffic inside qemu, to do this, the vm's libvirt xml file needs to be edited like this: domain type='qemu' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0' ... devices ... /devices qemu:commandline qemu:arg value='-set'/ qemu:arg value='device.usbredir0.debug=4'/ /qemu:commandline /domain Note the first line needs to be changed and the qemu:commandline section is new. If there are more usbredir devices inside the xml (usually there are) then additional -set device.usbredir1.debug=4, etc. arguments must be added, ie: qemu:commandline qemu:arg value='-set'/ qemu:arg value='device.usbredir0.debug=4'/ qemu:arg value='-set'/ qemu:arg value='device.usbredir1.debug=4'/ /qemu:commandline Note this kind of detailed logging is only useful when a certain device fails, if no devices work at all there usual is a general configuration problem. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb audio device troubles
Hi all, On 12/02/2014 01:43 PM, Paolo Bonzini wrote: On 02/12/2014 13:16, Eric S. Johansson wrote: I got win7 installed, virtio devices working and took forever to trickle in updates because of a w7 bug update manager bug that take up all cpu resources. now I got DNS 13 installed but I'm getting no audio. I pass throught the usb audio device (logitech h800 USB 046d:0a29) and it is seen as a device in windows. then I hear the headset sync-up beeps and the device vanishes from windows. pointers as to what I should look at next? Adding back Hans and Gerd... Eric are you using usb-host redirection, or Spice's usb network redir ? If you do not know, please describe how (which ui-elements / cmdline) you are redirecting the device. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb audio device troubles
Hi, On 12/03/2014 09:31 AM, Eric S. Johansson wrote: On 12/3/2014 3:21 AM, Hans de Goede wrote: Hi all, On 12/02/2014 01:43 PM, Paolo Bonzini wrote: On 02/12/2014 13:16, Eric S. Johansson wrote: I got win7 installed, virtio devices working and took forever to trickle in updates because of a w7 bug update manager bug that take up all cpu resources. now I got DNS 13 installed but I'm getting no audio. I pass throught the usb audio device (logitech h800 USB 046d:0a29) and it is seen as a device in windows. then I hear the headset sync-up beeps and the device vanishes from windows. pointers as to what I should look at next? Adding back Hans and Gerd... Eric are you using usb-host redirection, or Spice's usb network redir ? Host redirection I assume. It was from the collection of devices UI and I added the device to pass through from the list of host USB devices. Ok, then Gerd is probably the best person to help you further. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: can I make this work… (Foundation for accessibility project)
Hi, On 11/18/2014 02:50 PM, Paolo Bonzini wrote: On 18/11/2014 07:48, Eric S. Johansson wrote: I'm trying to figure out ways of making it possible to drive Linux from Windows speech recognition (NaturallySpeaking). The goal is a system where Windows runs in a virtual machine (Linux host), audio is passed through from a USB headset to the Windows environment. And the output of the recognition engine is piped through some magic back to the Linux host. the hardest part of all of this without question is getting clean uninterrupted audio from the USB device all the way through to the Windows virtual machine. virtual box, VMware fail mostly in delivering reliable audio to the virtual machine. I expect KVM to not work right with regards to getting clean audio/real-time USB but I'm asking in case I'm wrong. if it doesn't work or can't work yet, what would it take to make it possible for clean audio to be passed through to a guest? I'm adding two people who might know. kvm's usb pass-through should be able to handle this without any issues (other then some latency), it uses special buffering for isochronous usb packets, which should take care of usb audio working. I've never tested audio recording, but audio playback and video recording (webcams) work, so I expect audio recording to be fine. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb-ehci: Fix an assert whenever isoc transfers are used
hcd-ehci.c is missing an usb_packet_init() call for the ipacket UsbPacket it uses for isoc transfers, triggering an assert (taking the entire vm down) in usb_packet_setup as soon as any isoc transfers are done by a high speed USB device. Signed-off-by: Hans de Goede hdego...@redhat.com --- hw/usb/hcd-ehci.c |1 + 1 file changed, 1 insertion(+) diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c index e759c99..eaa3ddd 100644 --- a/hw/usb/hcd-ehci.c +++ b/hw/usb/hcd-ehci.c @@ -2300,6 +2300,7 @@ static int usb_ehci_initfn(PCIDevice *dev) s-frame_timer = qemu_new_timer_ns(vm_clock, ehci_frame_timer, s); QTAILQ_INIT(s-aqueues); QTAILQ_INIT(s-pqueues); +usb_packet_init(s-ipacket); qemu_register_reset(ehci_reset, s); -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB: 2 bug-fixes, for master *and* for stable-1.1
Here are USB 2 bug-fixes, please also cherry-pick these into the stable-1.1 branch, esp. the second one as that fixes an easily triggerable assert. Note these patches are against 1.1.0, not against master, but they are relevant for, and should apply to, master too. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb-redir: Correctly handle the usb_redir_babble usbredir status
Signed-off-by: Hans de Goede hdego...@redhat.com --- hw/usb/redirect.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c index 5f55d78..c6358c0 100644 --- a/hw/usb/redirect.c +++ b/hw/usb/redirect.c @@ -1058,6 +1058,8 @@ static int usbredir_handle_status(USBRedirDevice *dev, case usb_redir_inval: WARNING(got invalid param error from usb-host?\n); return USB_RET_NAK; +case usb_redir_babble: +return USB_RET_BABBLE; case usb_redir_ioerror: case usb_redir_timeout: default: -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ehci: Kick async schedule on wakeup in the non companion case
Commit 0f588df8b3688b00e77aabaa32e26ece5f19bd39, added code
to ehci_wakeup to kick the async schedule on wakeup, but the else
was positioned wrong making it trigger for devices which are routed
to the companion rather then to the ehci controller itself.
This patch fixes this. Note that the programming style with using the
return at the end of the companion block matches how the companion case
is handled in the other ports ops, and is done this way for consistency.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
hw/usb/hcd-ehci.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c
index 401ccec..b68a8ce 100644
--- a/hw/usb/hcd-ehci.c
+++ b/hw/usb/hcd-ehci.c
@@ -852,10 +852,11 @@ static void ehci_wakeup(USBPort *port)
USBPort *companion = s-companion_ports[port-index];
if (companion-ops-wakeup) {
companion-ops-wakeup(companion);
-} else {
-qemu_bh_schedule(s-async_bh);
}
+return;
}
+
+qemu_bh_schedule(s-async_bh);
}
static int ehci_register_companion(USBBus *bus, USBPort *ports[],
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
qemu hangs until a signal is delivered when running Fedora 14 i386 with -smp 2
Hi All, It took me a while to figure the below out, I hope it gives some clues into the problem I'm seeing. I'm running qemu compiled from git from the following repo: http://cgit.freedesktop.org/spice/qemu/ From the spice.v20 branch. So this is basically qemu HEAD (not qemu-kvm but plain qemu), with spice patches added. I can reproduce this without the use of the spice vga device however! When I start Fedora 14 i386 inside a qemu vm with the following cmdline: qemu-system-x86_64 -enable-kvm -cpu host \ -m 1024 -name F14 -smp 2 \ -drive file=/mnt/rhel6_x86_64/images/f14-i386.qcow2,if=virtio,media=disk \ -net nic,macaddr=52:54:00:7a:b4:7d,vlan=0,model=virtio,name=virtio.0 -net tap,vlan=0 \ -monitor stdio And then: -wait till it has booted into gdm -switch to tty2 using sendkey ctrl+alt+f2 from the monitor -login as root -run the following: while true; fortune; sleep 1; done; -wait (10 minutes or so at a maximum at my machine) -note qemu cpu load goes to 100% all of a sudden, monitor is dead, ctrl+alt+1 to go to serial console is dead, guest is dead -attach a debugger, see it is executing guest instructions (doing kvm_ioctl), also if you let it hang long enough you will get BUG: soft lockup in dmesg (once you unstuck it) -detach, hang is gone everything works again, entered monitor commands during the hang are executed, etc. Alternatively sending SIGCHLD to the qemu process also unstucks qemu + the guest. Removing -smp 2 from the cmdline makes this go away. So any ideas what this can be? Thanks Regards, Hans p.s. Please keep me in the CC I'm not on the list. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu hangs until a signal is delivered when running Fedora 14 i386 with -smp 2
Hi, On 10/15/2010 05:58 PM, Gerd Hoffmann wrote: Hi, will get BUG: soft lockup in dmesg (once you unstuck it) Removing -smp 2 from the cmdline makes this go away. The guests soft lookup stacktrace hints it is the remote tlb flush in the execve path causing this. The fpaste is expired meanwhile though. Hans, can you send one of those stack traces to the list please? Attached is the dmesg output of an F14 i386 guest, which got stuck as described twice (the 2 back-traces are at the end). Regards, Hans [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.35.6-39.fc14.i686 (mockbu...@x86-13.phx2.fedoraproject.org) (gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) ) #1 SMP Fri Oct 8 16:20:30 UTC 2010 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009dc00 (usable) [0.00] BIOS-e820: 0009dc00 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3fffd000 (usable) [0.00] BIOS-e820: 3fffd000 - 4000 (reserved) [0.00] BIOS-e820: fffc - 0001 (reserved) [0.00] Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel! [0.00] DMI 2.4 present. [0.00] e820 update range: - 1000 (usable) == (reserved) [0.00] e820 remove range: 000a - 0010 (usable) [0.00] last_pfn = 0x3fffd max_arch_pfn = 0x10 [0.00] MTRR default type: write-back [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00E000 mask FFE000 uncachable [0.00] 1 disabled [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x0, new 0x7010600070106 [0.00] initial memory mapped : 0 - 0100 [0.00] found SMP MP-table at [c00fdbd0] fdbd0 [0.00] init_memory_mapping: -36ffe000 [0.00] 00 - 40 page 4k [0.00] 40 - 0036c0 page 2M [0.00] 0036c0 - 0036ffe000 page 4k [0.00] kernel direct mapping tables up to 36ffe000 @ 7000-e000 [0.00] RAMDISK: 3e225000 - 3fff [0.00] Allocated new RAMDISK: 00c2f000 - 029f9a2d [0.00] Move RAMDISK from 3e225000 - 3ffefa2c to 00c2f000 - 029f9a2c [0.00] ACPI: RSDP 000fdb80 00014 (v00 BOCHS ) [0.00] ACPI: RSDT 3fffde10 00034 (v01 BOCHS BXPCRSDT 0001 BXPC 0001) [0.00] ACPI: FACP 3e40 00074 (v01 BOCHS BXPCFACP 0001 BXPC 0001) [0.00] ACPI: DSDT 3fffdfd0 01E22 (v01 BXPC BXDSDT 0001 INTL 20090123) [0.00] ACPI: FACS 3e00 00040 [0.00] ACPI: SSDT 3fffdf80 00044 (v01 BOCHS BXPCSSDT 0001 BXPC 0001) [0.00] ACPI: APIC 3fffde90 0007A (v01 BOCHS BXPCAPIC 0001 BXPC 0001) [0.00] ACPI: HPET 3fffde50 00038 (v01 BOCHS BXPCHPET 0001 BXPC 0001) [0.00] ACPI: Local APIC address 0xfee0 [0.00] 143MB HIGHMEM available. [0.00] 879MB LOWMEM available. [0.00] mapped low ram: 0 - 36ffe000 [0.00] low ram: 0 - 36ffe000 [0.00] node 0 low ram: - 36ffe000 [0.00] node 0 bootmap b000 - 00011e00 [0.00] (12/32 early reservations) == bootmem [00 - 0036ffe000] [0.00] #0 [001000 - 002000]EX TRAMPOLINE == [001000 - 002000] [0.00] #1 [40 - c298c0]TEXT DATA BSS == [40 - c298c0] [0.00] #2 [c2a000 - c2e049] BRK == [c2a000 - c2e049] [0.00] #3 [09dc00 - 0fdbd0]BIOS reserved == [09dc00 - 0fdbd0] [0.00] #4 [0fdbd0 - 0fdbe0] MP-table mpf == [0fdbd0 - 0fdbe0] [0.00] #5 [0fdce4 - 10]BIOS reserved == [0fdce4 - 10] [0.00] #6 [0fdbe0 - 0fdce4] MP-table mpc == [0fdbe0 - 0fdce4] [0.00] #7 [002000 - 003000] TRAMPOLINE == [002000 - 003000] [0.00] #8 [003000 - 007000] ACPI WAKEUP == [003000 - 007000] [0.00] #9 [007000 - 00b000] PGTABLE == [007000 - 00b000] [0.00] #10 [c2f000 - 00029fa000] NEW RAMDISK == [c2f000 - 00029fa000] [0.00] #11 [00b000 - 012000] BOOTMAP == [00b000 - 012000] [0.00] kvm-clock: Using msrs 12 and 11 [
PATCH: virtio_console: Fix poll blocking even though there is data to read
Hi All, I found this while working on a Linux agent for spice, the symptom I was seeing was select blocking on the spice vdagent virtio serial port even though there were messages queued up there. I found this while working on a Linux agent for spice, the symptom I was seeing was select blocking on the spice vdagent virtio serial port even though there were messages queued up there. virtio_console's port_fops_poll checks port-inbuf != NULL to determine if read won't block. However if an application reads enough bytes from inbuf through port_fops_read, to empty the current port-inbuf, port-inbuf will be NULL even though there may be buffers left in the virtqueue. This causes poll() to block even though there is data to be read, this patch fixes this by using the alredy defined will_read_block utility function instead of the port-inbuf != NULL check. Signed-off-By: Hans de Goede hdego...@redhat.com Regards, Hans Subject: virtio_console: Fix poll blocking even though there is data to read From: Hans de Goede hdego...@redhat.com I found this while working on a Linux agent for spice, the symptom I was seeing was select blocking on the spice vdagent virtio serial port even though there were messages queued up there. virtio_console's port_fops_poll checks port-inbuf != NULL to determine if read won't block. However if an application reads enough bytes from inbuf through port_fops_read, to empty the current port-inbuf, port-inbuf will be NULL even though there may be buffers left in the virtqueue. This causes poll() to block even though there is data to be read, this patch fixes this by using the alredy defined will_read_block utility function instead of the port-inbuf != NULL check. Signed-off-By: Hans de Goede hdego...@redhat.com diff -up linux-2.6.35.x86_64/drivers/char/virtio_console.c~ linux-2.6.35.x86_64/drivers/char/virtio_console.c --- linux-2.6.35.x86_64/drivers/char/virtio_console.c~ 2010-08-02 00:11:14.0 +0200 +++ linux-2.6.35.x86_64/drivers/char/virtio_console.c 2010-09-15 13:39:29.043505000 +0200 @@ -642,7 +642,7 @@ static unsigned int port_fops_poll(struc poll_wait(filp, port-waitqueue, wait); ret = 0; - if (port-inbuf) + if (!will_read_block(port)) ret |= POLLIN | POLLRDNORM; if (!will_write_block(port)) ret |= POLLOUT;
Re: PATCH: virtio_console: Fix poll blocking even though there is data to read
Hi, On 09/15/2010 03:25 PM, Amit Shah wrote: On (Wed) Sep 15 2010 [15:04:53], Hans de Goede wrote: Hi All, I found this while working on a Linux agent for spice, the symptom I was seeing was select blocking on the spice vdagent virtio serial port even though there were messages queued up there. I found this while working on a Linux agent for spice, the symptom I was seeing was select blocking on the spice vdagent virtio serial port even though there were messages queued up there. virtio_console's port_fops_poll checks port-inbuf != NULL to determine if read won't block. However if an application reads enough bytes from inbuf through port_fops_read, to empty the current port-inbuf, port-inbuf will be NULL even though there may be buffers left in the virtqueue. This causes poll() to block even though there is data to be read, this patch fixes this by using the alredy defined will_read_block utility function instead of the port-inbuf != NULL check. Signed-off-By: Hans de Goedehdego...@redhat.com Regards, Hans diff -up linux-2.6.35.x86_64/drivers/char/virtio_console.c~ linux-2.6.35.x86_64/drivers/char/virtio_console.c --- linux-2.6.35.x86_64/drivers/char/virtio_console.c~ 2010-08-02 00:11:14.0 +0200 +++ linux-2.6.35.x86_64/drivers/char/virtio_console.c 2010-09-15 13:39:29.043505000 +0200 @@ -642,7 +642,7 @@ static unsigned int port_fops_poll(struc poll_wait(filp,port-waitqueue, wait); ret = 0; - if (port-inbuf) + if (!will_read_block(port)) Looks correct, but this should be if (port_has_data(port)) instead. That certainly works for me (as in will still fix the bug I'm hitting), but quoting from man 2 select: Three independent sets of file descriptors are watched. Those listed in readfds will be watched to see if characters become available for reading (more precisely, to see if a read will not block; in particu‐ lar, a file descriptor is also ready on end-of-file) Notice the a file descriptor is also ready on end-of-file, and port_fops_read treats the host not being connected as eof (it returns 0 in that case). So from an API pov I'm not sure what is correct. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH: virtio_console: Fix poll blocking even though there is data to read
Hi, On 09/15/2010 03:46 PM, Amit Shah wrote: On (Wed) Sep 15 2010 [15:37:21], Hans de Goede wrote: --- linux-2.6.35.x86_64/drivers/char/virtio_console.c~ 2010-08-02 00:11:14.0 +0200 +++ linux-2.6.35.x86_64/drivers/char/virtio_console.c 2010-09-15 13:39:29.043505000 +0200 @@ -642,7 +642,7 @@ static unsigned int port_fops_poll(struc poll_wait(filp,port-waitqueue, wait); ret = 0; - if (port-inbuf) + if (!will_read_block(port)) Looks correct, but this should be if (port_has_data(port)) instead. That certainly works for me (as in will still fix the bug I'm hitting), but quoting from man 2 select: Three independent sets of file descriptors are watched. Those listed in readfds will be watched to see if characters become available for reading (more precisely, to see if a read will not block; in particu‐ lar, a file descriptor is also ready on end-of-file) Notice the a file descriptor is also ready on end-of-file, and port_fops_read treats the host not being connected as eof (it returns 0 in that case). So from an API pov I'm not sure what is correct. poll(2) says: POLLIN There is data to read. That makes it simple. Also, we also set POLLHUP in case the host is disconnected, so if host is not connected while there's data to read, we'll get POLLIN|POLLHUP in revents, and further reads will be blocked. Ah, I completely missed the POLLHUP getting set thingie. I guess that will get used by the kernel to also not block if any fds have it said in select's readfds argument. One new patch coming up! Regards, Hans -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
