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 Thanks, Shawn. > Regards, > > Hans
