From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43813) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLKvH-00063Z-B6 for qemu-devel@nongnu.org; Mon, 08 Oct 2012 17:31:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLKvE-000712-R1 for qemu-devel@nongnu.org; Mon, 08 Oct 2012 17:31:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11882) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLKvE-00070s-I9 for qemu-devel@nongnu.org; Mon, 08 Oct 2012 17:31:32 -0400 Message-ID: <50734686.9060004@redhat.com> Date: Mon, 08 Oct 2012 23:32:54 +0200 From: Hans de Goede MIME-Version: 1.0 References: <3321480.8UDes0xfFC@segfault.sh0n.net> <20121008161155.GA618@sig21.net> <50733349.8060807@redhat.com> <1992746.K6KNzGZOiM@segfault.sh0n.net> In-Reply-To: <1992746.K6KNzGZOiM@segfault.sh0n.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Shawn Starr Cc: Johannes Stezenbach , qemu-devel@nongnu.org, gerd@kraxel.org Hi, On 10/08/2012 10:18 PM, Shawn Starr wrote: > On Monday, October 08, 2012 10:10:49 PM Hans de Goede wrote: >> Hi, >> >> On 10/08/2012 06:11 PM, Johannes Stezenbach wrote: >> >> >> >> > I also wonder if this is not a generic problem >>> >>> for all emulated hw if the driver uses some timeout? >> >> Yes it likely is, because the emulated timer interrupt will >> try to make up for time lost when the vm was not running >> (in either hypervisor or guest mode), while as hw emulation >> code which has been pre-empted for what ever reason my >> simply need some more actual running time before it can >> complete the task as hand, at which point the timeout >> will trigger sooner then the hw emulation can handle the >> task ... >> >> Note that with the EHCI emulation we also can have the >> 2 (guest and hw-emulation time) get out of sync in the >> other way. When we got behind in processing frames >> on the periodic schedule compared to "real-time" we would >> catch up too fast, causing the guest to see large >> jumps in the frindex register, which it does not like. >> >> So all of this really is a precarious balancing act, and >> to get back to the subject of the thread, the latency >> spikes some of the kernels debugging options can cause, >> can upset the balance... >> > > Hello folks, > > I am using a non-debug kernel (because debug kernels are seriously sluggish). > I may elect to get kernel-3.6.0-3.fc18 or kernel-3.6.1-1.fc18 from koji also > since 3.6 is final now. > > Currently using: 3.6.0-0.rc7.git0.1.fc18.x86_64 Hmm, so were you using this at the time you hit the bug you reported earlier too ? And can you reproduce that bug or was it a one time occurence ? Regards, Hans