[9fans] Crash on reboot (in KVM)

[9fans] Crash on reboot (in KVM)

[Matěj Cepl]

Hi,

I have installed (with a kind help of anth_x on #plan9) Plan 9
from http://plan9.bell-labs.com/plan9/download.html in the 
KVM/libvirt virtual machine on my RHEL-7. Everything went 
smoothly except when restarting the virtual machine after 
finishing the installation, the system crashes. The only 
information I am able to provide is this screenshot 
http://mcepl.fedorapeople.org/tmp/Screenshot_glenda_2015-01-03_18_24_15.png 
Any ideas, what's wrong?

Best,

Matěj

Re: [9fans] Crash on reboot (in KVM)

[erik quanstrom]

On Sat Jan  3 10:38:05 PST 2015, mcepl@cepl.eu wrote:
> Hi,
>
> I have installed (with a kind help of anth_x on #plan9) Plan 9
> from http://plan9.bell-labs.com/plan9/download.html in the
> KVM/libvirt virtual machine on my RHEL-7. Everything went
> smoothly except when restarting the virtual machine after
> finishing the installation, the system crashes. The only
> information I am able to provide is this screenshot
> http://mcepl.fedorapeople.org/tmp/Screenshot_glenda_2015-01-03_18_24_15.png
> Any ideas, what's wrong?


yes.  i saw this when i first got my hands on a westmere processor.
but for a completely different reason.  in my case the westmere was too
fast for this guestimation.  in this case, the cpu is apparently too slow.

the kernel's algorithm for calibrating delay loops thinks it
has failed.  it has detected a 1GHz lapic clock, but just a 300MHz
cpu clock using the AAM-loop method in i8253.c;/^guesscpuhz

i'm not a kvm expert, but i imagine that this machine's kvm passed
through the TSC clock, but is time-slicing, or heavily emulating this
loop, and thus put the code into a condition that doesn't happen
on real hardware.

so one solution (if possible) would be to make the cpu seem faster
to the guest by by pinning it to a core, or increasing its timeslice to
100%.

alternately, having kvm emulate a slower tsc, or having kvm not
set the havetsc bit might work.  i don't know if either are possible.
(see devarch.c:/^cpuidentify)

hacking the timing loop to not mix its metaphores between the i8253
and the lapic/tsc clock would be a little more graceful fix.

finally, you might the 9atom usb image and 64-bit kernel, which does
not use the i8253 timer at all.

- erik