Re: [Qemu-devel] Guest OS hangs on usb_add

["David S. Ahern" <daahern@cisco.com>]

On 06/23/10 22:45, TJ wrote:
> 
>> ---------- Forwarded message ----------
>> From: Timothy Jones <one.timothy.jones@gmail.com>
>> Date: Wed, Jun 23, 2010 at 9:07 PM
>> Subject: Guest OS hangs on usb_add
>> To: qemu-devel@nongnu.org
>>
>>
>> With some digging around I found out that the qemu hangs in
>> usb_host_claim_interfaces, which is caused by screwed up usb
>> descriptor. The device reports the following:
>>
>> (gdb) p dev->descr_len
>> $21 = 50
>> (gdb) p /x dev->descr[0]@50
>> $23 = {0x18, 0x1, 0x0, 0x1, 0xff, 0xff, 0xff, 0x8, 0x47, 0x46, 0x0,
>> 0x30, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x9, 0x2, 0x20,
>>  0x0, 0x1, 0x1, 0x0, 0x80, 0x19, 0x9, 0x4, 0x0, 0x0, 0x2, 0xff, 0xff,
>> 0xff, 0x0, 0x7, 0x5, 0x81, 0x2, 0x40, 0x0, 0x0,
>>  0x7, 0x5, 0x3, 0x2, 0x10, 0x0, 0x0}
>>
>> The first 0x18 (Device Descriptor bLength) is supposed to be decimal
>> 18, not hex! According to USB spec, if the device reports size greater
>> than expected, the host is supposed ignore the extra bytes. So qemu
>> behaves correctly here. However, with this length, the following
>> Configuration Descriptor length falls on a 0x0 and so the qemu spins
>> in an endless loop. (This is prolly something that should be detected
>> and reported as error by qemu.)
>>
>> My question is: This 0x18 -- is this something that comes from the
>> device itself (ie, firmware bug)? Or does it come from the USB
>> subsystem?

What kind of device is this?

David