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

2010-01-04 Thread 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 0357
  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 259, info c610369: MaxLen=63
DT0 EP=2 Dev=3 PID=( IN  )
Len=59 e0
Link points to TD @ 08281180, Breadth first
TD NOT active (259)
process_iso: 2 len 90 0259 status 0
  TD @ c8281540, link 82811c0, status 257, info c610369: MaxLen=63
DT0 EP=2 Dev=3 PID=( IN  )
Len=57 e0
Link points to TD @ 082811c0, Breadth first
TD NOT active (257)
process_iso: 3 len 88 0257 status 0
  TD @ c82815c0, link 8281180, status 357, 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 (357)
process_iso: 4 len 88 0357 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 380, 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 280, 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 (200)- grrr. paranoia!


Does this ring a bell with anyone?

David




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

2010-01-03 Thread 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