guest needs to boot with clock=acpi_pm (older AMD freq scaling issues)

Bug #361754 reported by Daniel Holbach on 2009-04-15
46
This bug affects 5 people
Affects Status Importance Assigned to Milestone
QEMU
Wishlist
Unassigned
qemu-kvm (Ubuntu)
Low
Unassigned
Jaunty
High
Unassigned

Bug Description

Binary package hint: kvm

On a Jaunty RC amd64 host (using kvm_amd), I tried a few amd64 dvd test installations. First with 500m of memory in the guest, later on with -m 1000.

Installs hung (no mouse movement, etc.) at various stages in the process. strace of kvm showed things like:

read(15, "\16\0\0\0\0\0\0\0\376\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 128) = 128
rt_sigaction(SIGALRM, NULL, {0x4091f0, ~[KILL STOP RTMIN RT_1], SA_RESTORER, 0x7ff18c3ef080}, 8) = 0
write(5, "\0"..., 1) = 1
read(15, 0x7fff95457690, 128) = -1 EAGAIN (Resource temporarily unavailable)
read(11, 0x259ba24, 4096) = -1 EAGAIN (Resource temporarily unavailable)
select(12, [11], NULL, NULL, {0, 0}) = 0 (Timeout)
select(16, [4 7 13 15], [], [], {1, 0}) = 1 (in [4], left {0, 999996})
read(4, "\0"..., 512) = 1
read(4, 0x7fff95457520, 512) = -1 EAGAIN (Resource temporarily unavailable)
timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0
timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 30000000}}, NULL) = 0
select(16, [4 7 13 15], [], [], {1, 0}) = 1 (in [15], left {0, 970000})

Only booting the guest with clock=acpi_pm reliably solved the problem.

summary: - host needs to boot with clock=acpi_pm
+ guest needs to boot with clock=acpi_pm
Changed in kvm (Ubuntu):
assignee: nobody → Dustin Kirkland (kirkland)
importance: Undecided → High
status: New → Triaged
Changed in kvm (Ubuntu):
milestone: none → ubuntu-9.04
status: Triaged → In Progress
Steve Langasek (vorlon) on 2009-04-16
Changed in kvm (Ubuntu Jaunty):
status: In Progress → Fix Committed

I'm concerned about the possible side-effects of this change, so have not accepted the kvm upload yet from the queue. I think there needs to be further evidence of why this fix is safe, or else defer to SRU; changed the milestone accordingly.

Changed in kvm (Ubuntu Jaunty):
milestone: ubuntu-9.04 → jaunty-updates
status: Fix Committed → In Progress

Try adding no-kvmclock to the guest kernel command line. If that addresses the problem, I'd suggest removing CONFIG_KVM_CLOCK from the guest kernel. There have been some lurking problems with kvm clock.

Thierry Carrez (ttx) wrote :

I've been hitting this one as well. I usually add clocksource=acpi_pm to solve it. I'll try no-kvmclock and report success/failure.

poelzi (poelzi) wrote :

I had problems until i disabled cpufreq on the host. kvm has problems with that

Dustin Kirkland  (kirkland) wrote :

The issue is that some amd platforms (pre-Barcelona) are not able to have guests that use the tsc as a clock source.

Either:
 a) Hosts with these processors should disable cpu frequency scaling, or
 b) Guests should use clock=acpi_pm

We could add a check to the kvm or qemu binary to check if cpu frequency scaling is enabled and throw an error. Even this is imperfect, though, as you could still screw yourself if you enable it after the vm starts.

I'm forward this upstream to see what they think.

:-Dustin

Changed in qemu:
importance: Undecided → Wishlist
status: New → Confirmed
Dustin Kirkland  (kirkland) wrote :

Okay, so thinking about this so more, here's how I propose solving this...

 * Modify the kvm init script to check if your CPU is a buggy (cat /proc/cpuinfo, AMD processor, cpu family < 16), then cpu-frequency scaling should be turned off

:-Dustin

Changed in kvm (Ubuntu):
status: In Progress → Triaged
Changed in kvm (Ubuntu Jaunty):
status: In Progress → Triaged
Changed in kvm (Ubuntu):
milestone: jaunty-updates → none
summary: - guest needs to boot with clock=acpi_pm
+ guest needs to boot with clock=acpi_pm (older AMD freq scaling issues)
Thierry Carrez (ttx) wrote :

\o/ cpu family : 15
FYI running with no-kvmclock (as suggested by Anthony in comment 2) also seems to work around the issue.

Dustin: running guests with clocksource=acpi_pm is also a valid solution for those who don't want to throw out freqscaling completely (I am one of those), so I suggest the init script check (if it is blocking and not just a warning) could be optionally disabled by a YES_I_KNOW_I_NEED_TO_ADD_CLOCKSOURCE_ACPI_PM="yes" /etc/default/kvm setting ?

Thierry-

Yes, I agree (as I'm the owner of 4+ effected AMD cpu's on which I
don't want to lose frequency scaling)...

:-Dustin

If no-kvmclock helps, it's possible to disable this in the host kernel.

Dustin Kirkland  (kirkland) wrote :

On Tue, Jun 23, 2009 at 7:30 PM, Anthony Liguori<email address hidden> wrote:
> If no-kvmclock helps, it's possible to disable this in the host kernel.

Anthony-

What's the downside of no-kvmclock, if we decided to make this a
default in the Ubuntu server kernel?

:-Dustin

Dustin Kirkland wrote:
> On Tue, Jun 23, 2009 at 7:30 PM, Anthony Liguori<email address hidden> wrote:
>
>> If no-kvmclock helps, it's possible to disable this in the host kernel.
>>
>
> Anthony-
>
> What's the downside of no-kvmclock, if we decided to make this a
> default in the Ubuntu server kernel?
>
> :-Dustin
>

Assuming it worked? Potentially greater time drift in the guest.

Regards,

Anthony Liguori

On Wed, Jun 24, 2009 at 10:38 AM, Anthony Liguori<email address hidden> wrote:
> Assuming it worked?  Potentially greater time drift in the guest.

Can that be helped with NTP in the guest?

:-Dustin

Dustin Kirkland  (kirkland) wrote :

Can anyone reproduce this problem in karmic's qemu-kvm-0.11? Marking incomplete. Please confirm if you still experience this issue there.

I'm marking won't fix against Jaunty. I don't think this rises to SRU, since there are multiple workarounds.

:-Dustin

Changed in kvm (Ubuntu):
status: Triaged → Fix Released
status: Fix Released → Incomplete
Changed in kvm (Ubuntu Jaunty):
status: Triaged → Won't Fix
Changed in kvm (Ubuntu):
importance: High → Medium
importance: Medium → Low
Dustin Kirkland  (kirkland) wrote :

Thierry, Daniel, can you reproduce this?

:-Dustin

Thierry Carrez (ttx) wrote :

My recent karmic ISO testings (using default kernel parameters) didn't hang... I'll disable no-kvmclock in my guests and let you know if I can reproduce it with current qemu-kvm.

Daniel Holbach (dholbach) wrote :

AFAICT it's all good now.

Dustin Kirkland  (kirkland) wrote :

Thanks, Daniel.

Thierry, I'm marking 'fix released'. Please reopen with 'confirmed', if you can reproduce this on the latest Karmic qemu-kvm.

:-Dustin

Changed in kvm (Ubuntu):
status: Incomplete → Fix Released
tags: added: iso-testing

I am marking this as 'confirmed' as I can reproduce the problem with the latest qemu-kvm package. Turning off cpu frequency scaling is a valid workaround for me, but the clock on the guests drift a lot whenever I forget to change the governor.

$ LANG=C apt-cache policy qemu-kvm
qemu-kvm:
  Installed: 0.11.0-0ubuntu6.3
  Candidate: 0.11.0-0ubuntu6.3
  Version table:
 *** 0.11.0-0ubuntu6.3 0
        500 http://archive.ubuntu.com karmic-updates/main Packages
        100 /var/lib/dpkg/status
     0.11.0-0ubuntu6 0
        500 http://archive.ubuntu.com karmic/main Packages

Changed in kvm (Ubuntu):
status: Fix Released → Confirmed
affects: kvm (Ubuntu) → qemu-kvm (Ubuntu)
Dustin Kirkland  (kirkland) wrote :

I'm unassigning myself this bug, as I haven't found the time to fix it, and I personally haven't hit this bug in a very long time. Leaving the bug open, and I would be happy to review/sponsor/upload a fix if someone else submits a patch.

Changed in qemu-kvm (Ubuntu Jaunty):
assignee: Dustin Kirkland (kirkland) → nobody
Changed in qemu-kvm (Ubuntu):
assignee: Dustin Kirkland (kirkland) → nobody
Dustin Kirkland  (kirkland) wrote :

Daniel-

You opened this bug... Have you experienced this problem on Lucid (or Karmic) or any time recently?

Thierry-

You originally confirmed it. Can you confirm it again against Lucid?

Dustin Kirkland  (kirkland) wrote :

Sorry, read a bit further down and I see that both Thierry and Daniel are reporting Success with recent Ubuntu. Closing for now. Please reopen if this is still an issue. Thanks!

Changed in qemu-kvm (Ubuntu):
status: Confirmed → Fix Released
Changed in qemu:
status: Confirmed → Fix Released

Hallo Dustin,

i reported this bug too for Hardy. Its gone with karmic.

Reagrds, Kurt

Am 02.03.2010 00:36, schrieb Dustin Kirkland:
> Daniel-
>
> You opened this bug... Have you experienced this problem on Lucid (or
> Karmic) or any time recently?
>
> Thierry-
>
> You originally confirmed it. Can you confirm it again against Lucid?
>
>

--
Kurt Harders
PiN GmbH
Leimbacher Str. 36
42281 Wuppertal

T +49 202 2 50 11 64
F +49 202 2 50 11 65
M +49 171 8 36 82 33

Geschäftsführer:
Kurt Harders und Andre Dressler

Eingetragen beim AG Wuppertal
HRB 9102
USt.ID DE 186029298

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers