From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=41186 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1ORg8g-0006nK-P0
	for qemu-devel@nongnu.org; Thu, 24 Jun 2010 02:42:19 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <armbru@redhat.com>) id 1ORg8e-0008H6-UG
	for qemu-devel@nongnu.org; Thu, 24 Jun 2010 02:42:18 -0400
Received: from mx1.redhat.com ([209.132.183.28]:1027)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <armbru@redhat.com>) id 1ORg8e-0008Gx-ML
	for qemu-devel@nongnu.org; Thu, 24 Jun 2010 02:42:16 -0400
From: Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] Guest OS hangs on usb_add
References: <AANLkTinTVOqbrlyGCwWiD_PrttYyud_EkpMbzCK2wE_O@mail.gmail.com>
	<AANLkTila1csfbLt6z-02JriSo1z_7DvK1vylgxn7_kI2@mail.gmail.com>
Date: Thu, 24 Jun 2010 08:42:11 +0200
In-Reply-To: <AANLkTila1csfbLt6z-02JriSo1z_7DvK1vylgxn7_kI2@mail.gmail.com>
	(Timothy Jones's message of "Wed, 23 Jun 2010 21:07:54 -0400")
Message-ID: <m37hlpc4os.fsf@blackfin.pond.sub.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Timothy Jones <one.timothy.jones@gmail.com>
Cc: qemu-devel@nongnu.org

Timothy Jones <one.timothy.jones@gmail.com> writes:

> 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.)

Yup.

> 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?

It's been a while since I hacked USB, but IIRC it's from the device.

> I don't mind writing a small patch to make descriptor parsing a bit
> more intelligent, but I am very unfamiliar with the code, so I might
> botch things up. Or is the above data sufficient for one of the devs
> to take a look at the code and improve it?

A botched up patch is often a pretty effective way to get somebody to
fix the thing correctly.