On 07/07/2010 08:15 AM, Glauber Costa wrote:
quoted text
> On Wed, Jul 07, 2010 at 04:33:39PM +0200, Peter Palfrader wrote:
>    
>> On Wed, 07 Jul 2010, Glauber Costa wrote:
>>
>>      
>>>> 2.6.32.16 fails to boot on my KVM domains using qemu-kvm 0.11.1.
>>>>
>>>> Bisecting between 2.6.32.14 which worked and .16 turned up this commit
>>>> as the first culprit[0].
>>>>
>>>> The host is still running 2.6.32.14 and has 8 cores on 2 CPUs.  The
>>>> single-cpu KVM domain hangs just after printing 'Write protecting the
>>>> kernel read-only data: 9492k'[1].   On a successful boot this line would
>>>> usually be followed by 'INIT: version 2.86 booting'.
>>>>
>>>> A 2.6.32.16 with this patch reverted boots fine.
>>>>
>>>> If there's any info you need please just ask.
>>>>          
>>      
>>> if you boot with another clocksource, and then switch to kvmclock with the machine already
>>> running, do you see anything strange or suspicious?
>>>        
>> Booting with various clocksource=xxx kernel parameters does not change
>> the behaviour at all, i.e. the boot still hangs.
>>      
> wow, it is really weird then.
>
> that patch shouldn't affect anything outside the pvclock realm.
>    

Unless you added data which is mistakenly in read-only section, I can't 
see how it would affect anything either.  Of course, you have changed 
the data and text size, it is possible this triggered another bug.

What exact section does the per-cpu pvclock data fall into?  It's 
read-only in the kernel, but writeable from the hypervisor.

Also, did this patch arrive before or after the pvclock reboot bugfix?  
Because if the hypervisor is still writing the pvclock page, 
clocksource=xxx would not change that behavior without that fix.

Zach
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/