Bug 814231 - TSC calibration fails with QEMU TCG
TSC calibration fails with QEMU TCG
Status: CLOSED DEFERRED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity unspecified
: rc
: 7.0
Assigned To: Marcelo Tosatti
Virtualization Bugs
: Regression
Depends On:
Blocks: 813271 813413 1005011
  Show dependency treegraph
 
Reported: 2012-04-19 08:25 EDT by Richard W.M. Jones
Modified: 2013-09-05 22:49 EDT (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 813413
Environment:
Last Closed: 2012-04-25 18:21:01 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Comment 3 Richard W.M. Jones 2012-04-19 11:51:48 EDT
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.
Comment 4 juzhang 2012-04-20 04:21:32 EDT
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
Comment 5 RHEL Product and Program Management 2012-04-22 03:30:02 EDT
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.
Comment 8 Richard W.M. Jones 2012-04-24 10:10:07 EDT
(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.
Comment 13 Richard W.M. Jones 2012-04-24 17:57:26 EDT
> [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.

Note You need to log in before you can comment on or make changes to this bug.