Bug 439266

Created attachment 299380 [details]
dmesg output

Created attachment 299381 [details]
output from xm dmesg

Isn't it this the problem?

powernow-k8: Your BIOS does not provide _PSS objects.  PowerNow! does not work
on SMP systems without _PSS objects.  Complain to your BIOS vendor.

see https://bugzilla.redhat.com/show_bug.cgi?id=435321#c3

Might be solved by BIOS upgrade.

Is it seen on bare metal?

No, that shouldn't be the problem.  That's basically a message from the powernow
driver saying it can't load because it can't figure out the power topology of
the system.  So powernow is just refusing to initialize.

Now, the problem certainly *could* be a BIOS problem, but I don't have any data
to back that up either way.

Chris Lalancette

When the bare metal kernel is running, cpuinfo reports the correct frequency. It
could still be a BIOS issue if the HV derives the clock in a way that is
different from the bare metal kernel.  I often see this message when powernow is
disabled in the BIOS. I currently do have powernow disabled in the BIOS.  

The BIOS is the BIOS from Tyan as it was required to support quad-core.

Do anyone know whether is it somehow related to bug 435321? Or at least to
cpuspeed? My impression is that those two issues are not related.

More like bug 428710. On that one we saw the Hypervisor correctly determine the
cpu speed itself but due to a bad calibration, cause dom0 to get it wrong and
thus the 'time went backwards' messages resulted. It would be interesting to
know the same workaround has an effect. Adding a dom0_mem=512M boot arg to the
Xen hypervisor. What this does is delay the start time of dom0, and gives the
hypervisor a chance to recalibrate the clock and that usually makes dom0 happy.
Can you try that test?

rebooted with the following:
        kernel /xen.gz-2.6.18-84.el5 dom0_mem=512M
        module /vmlinuz-2.6.18-84.el5xen ro root=LABEL=/1

And this produced the correct clock frequency. this does only leave you with
512M of RAM, so I guess I need the fix for this BZ first.

Thanks. It only limits dom0 to 512M, the rest of the memory is available for
guests, which is normally what is desired. But this was not intended to suggest
you need to run this way. It was to see if the problem was similar to bug 428710
and indeed it seems to be.

Jeffrey, where might this system be located?  Could you also
provide the cpu core revisions and the BIOS version in use?
Have you found this problem only on the above single machine or
have you been able to reproduce it elsewhere on another 4 socket
AMD quad-core Tyan TX46 MB?

I am trying to secure another system and also figure out how to get them so that
there is vpn access.  Currently they live in my garage.

(In reply to comment #11)
> I am trying to secure another system and also figure out how to get them so that
> there is vpn access.  Currently they live in my garage.

Jeffrey, any update on this case or additional information you can
provide relative to my query (comment #10) above?

I updated the BIOS on the TX46 (a 4985 board) to 2.03 and the clock now reports
correctly. This can be closed.

Closing as per comment #13.

[including some e-mail context here for possible future
reference]

That's a little bizarre.  Reason being is the CPU frequency
calculation is being done via two methods.  One by Xen
for the sole purpose of printing the CPU freq during Xen
boot and the second method to publish such to the guest
OSes -- the initial value of which is in error and is being
displayed during guest boot.  My concern is we may still
have an oddity in the latter calculation potentially being
masked now by the new BIOS.

That said I don't see how a BIOS would affect what we're
finding as if the CPU clocks are stable early on I don't
know what might cause them to be unstable after the initial
Xen calculation is correctly completing.  I suppose the
BIOS could be getting control and mucking with the master
clock but that seems unlikely short of some type of
frequency scaling operation.