guest needs to boot with clock=acpi_pm (older AMD freq scaling issues)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Fix Released
|
Wishlist
|
Unassigned | ||
qemu-kvm (Ubuntu) |
Fix Released
|
Low
|
Unassigned | ||
Jaunty |
Won't Fix
|
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\
rt_sigaction(
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 |
Changed in kvm (Ubuntu Jaunty): | |
status: | In Progress → Fix Committed |
summary: |
- guest needs to boot with clock=acpi_pm + guest needs to boot with clock=acpi_pm (older AMD freq scaling issues) |
Changed in kvm (Ubuntu): | |
importance: | High → Medium |
importance: | Medium → Low |
tags: | added: iso-testing |
affects: | kvm (Ubuntu) → qemu-kvm (Ubuntu) |
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.