Re: 2.6.35-rc1 regression with pvclock and smp guests

[Zachary Amsden <zamsden@redhat.com>]

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@vger.kernel.org
> 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