Bug 1013641 - RHEL-5.9 loops in early boot stages, taking all CPU
RHEL-5.9 loops in early boot stages, taking all CPU
Status: CLOSED DUPLICATE of bug 967652
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
20
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-30 09:49 EDT by Jiri Popelka
Modified: 2013-11-29 06:24 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-29 06:24:54 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screenshot (18.63 KB, image/png)
2013-09-30 09:49 EDT, Jiri Popelka
no flags Details
/var/log/libvirt/qemu/$vmname.log (18.87 KB, text/plain)
2013-10-02 05:48 EDT, Jiri Popelka
no flags Details
virsh dumpxml $vmname (2.06 KB, application/xml)
2013-10-02 05:49 EDT, Jiri Popelka
no flags Details
/proc/cpuinfo (3.08 KB, text/plain)
2013-11-01 13:25 EDT, Jiri Popelka
no flags Details

  None (edit)
Description Jiri Popelka 2013-09-30 09:49:48 EDT
Created attachment 805216 [details]
screenshot

Description of problem:
This is F20 x86_64 constantly updated since Alpha-RC1.
It's the first time I tried to run my old RHEL-5.9 image (was working in F19) on F20 so I can't tell whether it's been caused with some update or it's like this since the initial install.

Version-Release number of selected component (if applicable):
qemu-system-x86-1.6.0-8.fc20.x86_64
libvirt-1.1.2-4.fc20.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Try to install (or run already installed image) RHEL-5.9 x86_64

Actual results:
The guest machine loops in early boot stages, taking 100% CPU.
See screenshot.
Comment 1 Cole Robinson 2013-10-01 10:35:19 EDT
Does rmmod kvm_intel && modprobe kvm_intel emulate_invalid_guest=0  make any difference? If so, please dup this to 1012119
Comment 2 Jiri Popelka 2013-10-01 11:50:51 EDT
That does not seem to make any difference.
Comment 3 Cole Robinson 2013-10-01 11:52:18 EDT
Can you provide the guest XML (sudo virsh dumpxml $vmname) and /var/log/libvirt/qemu/$vmname.log
Comment 4 Jiri Popelka 2013-10-02 05:48:47 EDT
Created attachment 806350 [details]
/var/log/libvirt/qemu/$vmname.log
Comment 5 Jiri Popelka 2013-10-02 05:49:28 EDT
Created attachment 806351 [details]
virsh dumpxml $vmname
Comment 6 Cole Robinson 2013-10-31 17:03:55 EDT
Jiri, if you 'sudo virsh edit $vmname' and change <domain type> to qemu, does the guest boot? (albeit very slowly)
Comment 7 Jiri Popelka 2013-11-01 04:33:01 EDT
Yes, with <domain type='qemu'> it boots (very slowly).
Comment 8 Cole Robinson 2013-11-01 09:40:49 EDT
Jiri, can you provide /proc/cpuinfo?
Also, please try kernel 3.12 from rawhide, on the host machine.

Gleb, Paolo, ideas for further debugging?
Comment 9 Jiri Popelka 2013-11-01 13:25:00 EDT
Created attachment 818372 [details]
/proc/cpuinfo

(In reply to Cole Robinson from comment #8)
> Jiri, can you provide /proc/cpuinfo?

attached

> Also, please try kernel 3.12 from rawhide, on the host machine.

3.12.0-0.rc7.git2.1.fc21.x86_64 makes no change
Comment 10 Cole Robinson 2013-11-17 14:18:30 EST
There's a kernel bug tracking similar issues:

https://bugzilla.redhat.com/show_bug.cgi?id=967652

The 3.13 kernels in rawhide have the referenced patch. Jan, can you give the latest rawhide kernel a spin as well?

If that kernel fixes the boot issues, we can dup this to the kernel bug.
Comment 11 Jiri Popelka 2013-11-18 06:23:44 EST
3.13.0-0.rc0.git5.1.fc21.x86_64 doesn't seem to fix it.
Comment 12 Cole Robinson 2013-11-19 14:46:06 EST
Okay, to summarize:

- RHEL5.9 guest
- Started fine on F19, seems to loop endlessly on f20
- 3.13 kernel from rawhide doesn't help
- Running without KVM _does_ make things work
- Host cpuinfo and guest commandline are in previous comments

Paolo, Gleb, any ideas what else to debug here?
Comment 13 Paolo Bonzini 2013-11-20 11:01:16 EST
Jiri, even with a newer kernel it will take a few minutes to boot.
Comment 14 Jiri Popelka 2013-11-20 11:13:44 EST
Yes, with <domain type='qemu'> the boot takes many minutes.
With <domain type='kvm'> it stucks on https://bugzilla.redhat.com/attachment.cgi?id=805216 even with rawhide's 3.12 and 3.13.
Comment 15 Cole Robinson 2013-11-20 12:13:09 EST
FWIW that graphical corruption should be fixed by latest spice-gtk queued for F20, but it shouldn't affect this issue.
Comment 16 Paolo Bonzini 2013-11-27 07:18:26 EST
With <domain type='kvm'> it will be stuck for several minutes and then proceed at normal speed.
Comment 17 Jiri Popelka 2013-11-28 05:08:04 EST
(In reply to Cole Robinson from comment #15)
> FWIW that graphical corruption should be fixed by latest spice-gtk queued
> for F20, but it shouldn't affect this issue.

I don't see that red patterns anymore.

(In reply to Paolo Bonzini from comment #16)
> With <domain type='kvm'> it will be stuck for several minutes and then
> proceed at normal speed.

I left it running for 15 minutes, but no progress.
Comment 18 Jiri Popelka 2013-11-28 05:09:04 EST
(In reply to Jiri Popelka from comment #17)
> I left it running for 15 minutes, but no progress.

With kernel-3.13.0-0.rc1.git3.1.fc21.x86_64
Comment 19 Jiri Popelka 2013-11-28 05:12:12 EST
And a moment after I posted the previous comment it started to boot :-D
at what seems to be normal speed.
Comment 20 Jiri Popelka 2013-11-28 05:57:13 EST
And after updating guest from RHEL-5.9 to RHEL-5.10 (kernel-2.6.18-371) everything's OK even with host's 3.11.9-300.fc20
Comment 21 Paolo Bonzini 2013-11-29 06:24:54 EST
Thanks Jirka.

*** This bug has been marked as a duplicate of bug 967652 ***

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