From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M3rcG-0000j6-TC for qemu-devel@nongnu.org; Tue, 12 May 2009 09:01:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M3rcB-0000hL-Vy for qemu-devel@nongnu.org; Tue, 12 May 2009 09:01:52 -0400 Received: from [199.232.76.173] (port=37361 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M3rcB-0000hF-JK for qemu-devel@nongnu.org; Tue, 12 May 2009 09:01:47 -0400 Received: from mail-fx0-f219.google.com ([209.85.220.219]:51535) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M3rcA-0002sj-OH for qemu-devel@nongnu.org; Tue, 12 May 2009 09:01:46 -0400 Received: by fxm19 with SMTP id 19so3066053fxm.34 for ; Tue, 12 May 2009 06:01:45 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1242132812.2106.8.camel@localhost.localdomain> References: <1240874133.28148.62.camel@x41.thuisdomein> <1242120767.7568.18.camel@localhost.localdomain> <1295ed070905120536n50ace3fdx9903034ab339159a@mail.gmail.com> <1242132812.2106.8.camel@localhost.localdomain> Date: Tue, 12 May 2009 16:01:45 +0300 Message-ID: <1295ed070905120601s4c3c94e8g5e198b6b7a993636@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH] EHCI emulation module for review From: Pantelis Koukousoulas 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: Paul Bolle Cc: Mark Burkley , qemu-devel@nongnu.org > See my message of (about) two weeks ago about all the things I needed to > do to get to a patch that actually applied, compiled without (qemu's > default) warnings and didn't segfault immediately. > > If you still have trouble to get it to work against the current master > branch (or do not feel like manually correcting the patch) I could post > what worked for me (where worked means: at least doesn't segfault > immediately, but will run into issues sooner or later ...). The problem could be that we have different definitions of "working". What happened in my case was that the patch applied and compiled (after some trivial messing around) and there were no segfaults. The controller saw the devices in the windows guest, but could not complete the driver registration process, so it eventually gave up and windows returned the "I could not make this hardware work" message. It looks like the reason for this failure was that some URBs did not really make it to the device (or back) but I didn't have the time to investigate more thoroughly yet. Did you get it to run all the way to devices working normally? Cheers, Pantelis