Toni Mueller wrote at Tue, 16 Feb 2010 11:46:04 +0100:
> Hi,
> 
> On Mon, 15.02.2010 at 18:36:19 +0100, Toni Mueller <supp...@oeko.net> wrote:
>> I'm running into a severe problem, where I'm unsure about the origin.
>> Please feel free to re-assign as appropriate.
> 
>> three of them running Etch, Lenny, and Sid. It currently looks like the
>> Etch and Lenny VMs come up nicely, but the one with Sid hangs with this
>> error:
>>
>> Clocksource tsc unstable (telta = large negative number)

This message is to be expected and it is not harmful at all, kernel
can cope with tsc instability just fine, at least since 2.6.22 or so.

Speaking of Etch, the instability is a bit more important, but the
kernel still can do the right thing (and there should be no such
message printed with Etch because kernel does not have such message
if I remember correctly).

Try booting with different clock sources in guests (with Etch it is
not possible unfortunately, but Lenny+ is ok).  It is clocksource=XXX
on the kernel command line, or /sys/devices/system/clocksource/clocksource0
(can be changed at runtime).  For kvm the best clocksource is kvm-clock
(if the kernel recognizes it anyway, modern kernels does).

And while at it, again, please try the current version, which is
0.12.3+dfsg-4.  Or grab the .deb file from my site.

> I've now created a brand-new virtual machine, installing Unstable, but
> keeping the Lenny kernel. It turns out that the same machine starts ok
> with the Lenny kernel, but hangs with this error using the Sid kernel.

It's only kernel problem.  Ok, kvm+kernel, and since kernel usually
works without kvm it must be a kvm issue.  But clock is something
which is difficult to deal with in this situation.  For one, try
disabling any cpufreq things you may have on the host, and since
you're using Athlon X2, which inherently has unstable tsc (really
unsynced, between cores), the only more-or-less reliable way to
run a kvm guest on such machine is to pin it to a single core.
Or to use kvm-clock, which should work better.

> My current guess is that these components (Sid kernel, qemu-kvm) don't
> play well together, and, given the breakage I see with at least
> OpenBSD, I'm inclined to assume that the problem originates with
> qemu-kvm.
> 
> NB: On the virtual machine, I have the -i486 variants of the respective
> kernels installed. On the virtual machine where I originally reported
> the error for, I had the -i686 kernel variants installed.

Is there any difference between i686 and i484 variants?

Thanks!

/mjt



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to