From: Hans de Goede <hdegoede@redhat.com>
To: Shawn Starr <shawn.starr@rogers.com>
Cc: Johannes Stezenbach <js@sig21.net>,
qemu-devel@nongnu.org, gerd@kraxel.org
Subject: Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting
Date: Mon, 08 Oct 2012 23:32:54 +0200 [thread overview]
Message-ID: <50734686.9060004@redhat.com> (raw)
In-Reply-To: <1992746.K6KNzGZOiM@segfault.sh0n.net>
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:
>>
>> <mega snip>
>>
>> > 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
next prev parent reply other threads:[~2012-10-08 21:31 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-19 16:42 [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting Shawn Starr
2012-09-19 16:53 ` Shawn Starr
2012-09-20 15:37 ` Hans de Goede
2012-09-20 19:08 ` Shawn Starr
2012-09-20 23:28 ` Shawn Starr
[not found] ` <6177450.mT8I4ey0nz@segfault.sh0n.net>
2012-09-21 0:04 ` Shawn Starr
2012-09-21 12:19 ` Hans de Goede
2012-09-21 15:39 ` Shawn Starr
2012-09-21 17:35 ` Hans de Goede
2012-09-21 18:46 ` Shawn Starr
2012-09-23 10:03 ` Hans de Goede
2012-09-23 18:00 ` Shawn Starr
2012-09-23 18:20 ` Shawn Starr
2012-09-23 18:52 ` Shawn Starr
2012-09-24 9:52 ` Hans de Goede
2012-09-24 14:24 ` Shawn Starr
2012-09-24 9:50 ` Hans de Goede
2012-09-24 14:20 ` Shawn Starr
2012-09-24 14:36 ` Hans de Goede
2012-09-24 14:38 ` Shawn Starr
2012-10-02 15:26 ` Shawn Starr
2012-10-08 11:27 ` Hans de Goede
2012-10-08 13:01 ` Johannes Stezenbach
2012-10-08 13:51 ` Hans de Goede
2012-10-08 14:49 ` Johannes Stezenbach
2012-10-08 15:03 ` Hans de Goede
2012-10-08 16:11 ` Johannes Stezenbach
2012-10-08 20:10 ` Hans de Goede
2012-10-08 20:18 ` Shawn Starr
2012-10-08 21:32 ` Hans de Goede [this message]
2012-10-08 21:37 ` Shawn Starr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50734686.9060004@redhat.com \
--to=hdegoede@redhat.com \
--cc=gerd@kraxel.org \
--cc=js@sig21.net \
--cc=qemu-devel@nongnu.org \
--cc=shawn.starr@rogers.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.