Marcelo Tosatti wrote: > On Wed, Feb 27, 2008 at 11:12:03AM +0100, Farkas Levente wrote: > >>> You can workaround these problems by using a different, less problematic >>> clocksource such as acpipm, until the TSC/migration issues are fully >>> resolved. >>> >>> Add "clocksource=acpi_pm" to the kernel options. >>> >> than just quck question we use the noapic kernel option for the guest (i >> don't remember why but there was some problem without it about half year >> ago). do i still have to use the noapic option for the kernel? (i hope >> somebody remember the reason:-) >> > > Apparently dsahern found that the noapic option fixed or alleviated > rtl8139 problems under high traffic: > > https://sourceforge.net/tracker/index.php?func=detail&aid=1802082&group_id=180599&atid=893831 > >
I've just run several hours with noapic to confirm. > I don't know details of the problem or why noapic made a difference. > Seems to point the finger at the ioapic code. Could be because the load is lower with pic, though. I've looked at the ioapic locking and it seems fine. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
