On 09/29/2010 11:59 PM, Michael Tokarev wrote:
30.09.2010 11:55, Michael Tokarev wrote:
29.09.2010 23:26, Arjan Koers wrote:
On 2010-09-29 11:19, Michael Tokarev wrote:
29.09.2010 13:17, Michael Tokarev wrote:
[]
Avi, this is definitely a -stable material, for 2.6.32 (longterm
stable) and 2.6.35.
Er. Please excuse me for the misinformation. It is _not_ for 2.6.32
ofcourse.
I wish you hadn't mentioned 2.6.32. I just tried 2.6.32.23 and it also
hangs. Reverting commit 1345126c761f0360dc108973bf73281d51945bc1
(introduced in 2.6.32.16) makes it boot again.
The kvmclock printk patch doesn't help, but I'll try to figure out
what's wrong.
It works here just fine - both 32- and 64-bit 2.6.32.23 as is,
and both 32- and 64-bit 2.6.35.6 with the printk.time patch
applied.
Ok, I can confirm there's another issue somewhere around this.
After numerous tries I noticed that guests sporadically stops
during bootup - either somewhere in the middle or at the very
end of it. It is definitely not this problem with printk time,
but it appears to be related to kvm-clock still, and smp.
This time, the lockup isn't really a lock up per se - the system
works (fsvo) - it reacts to keyboard, I can scroll up/down the
text console. But it does nothing more, and in particular I've
no idea what it is waiting for. It does not consume host CPU
as the printk.time problem had.
Happens most with 2.6.35.6 32bit guest kernel. I weren't able
to reproduce it with 2.6.35.6 64bit. Does not happen on
2.6.35.3. And happens sporadically on 2.6.32.23 32bit too.
The thing always happens during some module load or other
_kernel_ work. F.e. right now I've 2.6.35.6 32bit kernel
sitting after the login prompt (the Login: is at the middle
of the screen), with a few messages after the login prompt
telling me about various "misc" drivers (floppy, parport,
sg, piix_smbus etc) loaded.
Booting with clocksource=tsc does not expose the problem
so far - at least the most problematic 2.6.35.6 32bit always
booted ok with tsc. But since the issue is intermittent,
one can't be sure it's really pvclock.
/mjt
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
The printk movement is just a bandaid patch, correct? Anything which
does printk before kvmclock is registered could trigger the same bug.
Can you try with printk timing disabled and see if the bug disappears?
Zach
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
