At the moment I'm suspecting that this is a kernel bug, NOT
a qemu bug.

qemu 6.3 + kernel 6.3 => fails
qemu 6.2 + kernel 6.3 => fails
qemu 6.2 + kernel 6.2 => ok
qemu 6.3 + kernel 6.2 => ok

Notice the common factor is that the -221 kernel from 6.2
is OK, whereas the -262 kernel from 6.3 fails.

Choice of qemu seems to make no difference.

[qemu 6.2 == -209, qemu 6.3 == -280
kernel 6.2 == -221, kernel 6.3 == -262]

So now I'm going to bisect the 6.2 -> 6.3 kernels.

Can reproduce this issue with qemu-kvm-0.12.1.2-2.272.el6.x86_64 on kernel 2.6.32-265.el6.x86_64, mark qa_ack first since this issue is against qemu-kvm now. if this issue is changed to other component,please free to remove qa_ack
Please note: run libguest in guest not host. I am not sure run libguest in guest is common scenerio.

Results:
guest crash and can find 
 [    0.000000] Fast TSC calibration failed
 [    0.000000] TSC: Unable to calibrate against PIT
[    0.000000] TSC: No reference (HPET/PMTIMER) available
[    0.000000] Marking TSC unstable due to could not calculate TSC khz
[    0.006999] Calibrating delay loop... 261.63 BogoMIPS (lpj=130816)
[    0.019999] pid_max: default: 32768 minimum: 301

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

(In reply to comment #3)
> So now I'm going to bisect the [...] kernels.

Actually I went back a very long way to try to find a kernel
which didn't print

[    0.000000] Fast TSC calibration failed
[    0.000000] TSC: Unable to calibrate against PIT
[    0.000000] TSC: No reference (HPET/PMTIMER) available
[    0.000000] Marking TSC unstable due to could not calculate TSC khz

during boot, and I didn't find one (looked all the way back
in rhel6 git to January 2010).  Note that these old kernels
did not fail to boot (ie. did not suffer from bug 813413).

So essentially TSC has always been unstable in RHEL 6, but
we didn't notice because we don't really care about clocks.
We only noticed it when this caused a divide by zero (bug 813413)
and the kernel itself completely stopped working.

However I'm still keen to fix this.

I suspect the problem is that we're passing `qemu-kvm -nodefaults'
option which is disabling all other timer sources that the
kernel could use.  Therefore it'd be good if someone could look
at the previous comment and tell us what qemu options / kernel
command line options we should be using.

> [C]an this BZ be closed?

Yes .. although:

(a) non-KVM virtio-clock would be nice, because:

(b) TCG / nested virt *is* important to us:

Nested virtualization is used by customers and supported by
Red Hat right now.  The ability to use virtualization for mere
convenience or confinement is important now and only going to
get more important in future.