[Qemu-devel] need help getting a USB audio device to work

[Qemu-devel] need help getting a USB audio device to work

[David S. Ahern]

After weeks of fruitless effort I could use some help getting a USB
audio device to work. I have instrumented the hell out of the guest
driver and uhci code, qemu's linux and uhci code, and the host side usb
code. Near as I can tell data from the device makes its way into qemu
(async_complete shows a urb length equal to the data the host OS
receives from the device), but the data does not appear to make its way
to the guest OS. I have tried a variety of guests -- Fedora 12, RHEL5.3,
and RHEL3U8, and none work.

How do I determine in fact the data pulled into qemu from
ioctl(USBDEVFS_REAPURBNDELAY) is getting pushed to the guest?

Thanks,
-- 
David Ahern

Re: [Qemu-devel] need help getting a USB audio device to work

[David S. Ahern]

On 01/03/2010 11:19 AM, David S. Ahern wrote:
> 
> After weeks of fruitless effort I could use some help getting a USB
> audio device to work. I have instrumented the hell out of the guest
> driver and uhci code, qemu's linux and uhci code, and the host side usb
> code. Near as I can tell data from the device makes its way into qemu
> (async_complete shows a urb length equal to the data the host OS
> receives from the device), but the data does not appear to make its way
> to the guest OS. I have tried a variety of guests -- Fedora 12, RHEL5.3,
> and RHEL3U8, and none work.
> 
> How do I determine in fact the data pulled into qemu from
> ioctl(USBDEVFS_REAPURBNDELAY) is getting pushed to the guest?
> 
> Thanks,

Upon further review the problem appears to be that the TD's are still
active when received in the VM. In the bare metal case the usb-uhci code
shows (my instrumentation in a RHEL3U8 guest):

process_iso @ 36912: urb f74bd03c, mode 0, frame 1191, npkt 5, nerr 0,
status 03000057
  TD @ c8281480, link 8281180, status 20007ff, info c610369: MaxLen=63
DT0 EP=2 Dev=3 PID=( IN  )
    Len=7ff e0
    Link points to TD @ 08281180, Breadth first
TD NOT active (20007ff)
process_iso: 0 len 0 020007ff status 0
  TD @ c82814c0, link 8281200, status 20007ff, info c610369: MaxLen=63
DT0 EP=2 Dev=3 PID=( IN  )
    Len=7ff e0
    Link points to TD @ 08281200, Breadth first
TD NOT active (20007ff)
process_iso: 1 len 0 020007ff status 0
  TD @ c8281500, link 8281180, status 2000059, info c610369: MaxLen=63
DT0 EP=2 Dev=3 PID=( IN  )
    Len=59 e0
    Link points to TD @ 08281180, Breadth first
TD NOT active (2000059)
process_iso: 2 len 90 02000059 status 0
  TD @ c8281540, link 82811c0, status 2000057, info c610369: MaxLen=63
DT0 EP=2 Dev=3 PID=( IN  )
    Len=57 e0
    Link points to TD @ 082811c0, Breadth first
TD NOT active (2000057)
process_iso: 3 len 88 02000057 status 0
  TD @ c82815c0, link 8281180, status 3000057, info c610369: MaxLen=63
DT0 EP=2 Dev=3 PID=( IN  )
    Len=57 e0 IOC
    Link points to TD @ 08281180, Breadth first
TD NOT active (3000057)
process_iso: 4 len 88 03000057 status 0
process_iso: exit 5 (0), transfer length 500 actual len 266


The same case in a VM shows:

process_iso: td still active
  TD @ c1980580, link 1980200, status 3800000, info c610269: MaxLen=63
DT0 EP=2 Dev=2 PID=( IN  )
    Len=00 e0 IOC Active
    Link points to TD @ 01980200, Breadth first
process_urb: type 0
process_iso @ 8376: urb dee5c0f0, mode 0, frame 1033, npkt 5, nerr 0,
status 030007ff
  TD @ c19805c0, link 1980180, status 2800000, info c610269: MaxLen=63
DT0 EP=2 Dev=2 PID=( IN  )
    Len=00 e0 Active
    Link points to TD @ 01980180, Breadth first
TD still active (2000000)- grrr. paranoia!


Does this ring a bell with anyone?

David