On 07/31/2010 06:36 AM, Arjan Koers wrote:
On 2010-07-31 13:53, Arjan Koers wrote:
The kernel boots successfully when CONFIG_PRINTK_TIME is not set.
The problem occurs when this message is printed:
[ 0.016000] kvm-clock: cpu 1, msr 0:1511c01, secondary cpu clock
When I disable that printk, the kernel boots with
CONFIG_PRINTK_TIME=y
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -131,8 +131,8 @@ static int kvm_register_clock(char *txt)
int low, high;
low = (int)__pa(&per_cpu(hv_clock, cpu)) | 1;
high = ((u64)__pa(&per_cpu(hv_clock, cpu))>> 32);
- printk(KERN_INFO "kvm-clock: cpu %d, msr %x:%x, %s\n",
- cpu, high, low, txt);
+ /*printk(KERN_INFO "kvm-clock: cpu %d, msr %x:%x, %s\n",
+ cpu, high, low, txt);*/
return native_write_msr_safe(msr_kvm_system_time, low, high);
}
So the problem appears to be that the clock of the second CPU
is used too soon (or that clock setup should finish earlier).
That's almost hilarious. The printk from setting up the kvm clock is
invoking the kvm clock before it is setup.
There's no reason other printks couldn't do the same thing, however. I
think it's safest to keep an initialized flag and check for it before
attempting to return a meaningful value.
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
