From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60807 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ORqgx-0005oS-FA for qemu-devel@nongnu.org; Thu, 24 Jun 2010 13:58:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ORqgv-00016e-MG for qemu-devel@nongnu.org; Thu, 24 Jun 2010 13:58:23 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]:44445) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ORqgv-0000yP-H3 for qemu-devel@nongnu.org; Thu, 24 Jun 2010 13:58:21 -0400 Message-ID: <4C239CF0.4040901@cisco.com> Date: Thu, 24 Jun 2010 11:59:12 -0600 From: "David S. Ahern" MIME-Version: 1.0 Subject: Re: [Qemu-devel] Guest OS hangs on usb_add References: <4C22E300.5020109@gmail.com> In-Reply-To: <4C22E300.5020109@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: TJ Cc: qemu-devel@nongnu.org On 06/23/10 22:45, TJ wrote: > >> ---------- Forwarded message ---------- >> From: Timothy Jones >> 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