Bug 242088 - Kernel locks up at boot under Xen full virtualisation
Summary: Kernel locks up at boot under Xen full virtualisation
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel-xen   
(Show other bugs)
Version: 7
Hardware: All Linux
Target Milestone: ---
Assignee: Eduardo Habkost
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-01 16:09 UTC by Stephen Tweedie
Modified: 2008-08-02 23:40 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-28 16:19:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch from 1.3143 which broke booting on Xen (1.90 KB, patch)
2007-06-01 16:27 UTC, Stephen Tweedie
no flags Details | Diff
Boot logs from instrumented kernel up until the hang (6.84 KB, text/plain)
2007-06-01 16:28 UTC, Stephen Tweedie
no flags Details
F7 guest kernel messages with sata "HSM violation" errors (11.56 KB, text/plain)
2007-09-11 20:35 UTC, Eduardo Habkost
no flags Details

Description Stephen Tweedie 2007-06-01 16:09:01 UTC
Description of problem:
Kernels 2.6.21-1.3143.fc7 and later lock up at boot when run inside Xen full

Version-Release number of selected component (if applicable):
kernel-2.6.21-1.3143.fc7 and later

How reproducible:

Steps to Reproduce:
1. Boot any F-7 kernel or boot image under Xen full virtualisation.

Actual results:
Kernel hangs after the lines

 pnp: 00:00: iomem range 0x0-0x9ffff could not be reserved
 Time: tsc clocksource has been installed.
 PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
 NET: Registered protocol family 2

Expected results:

Initial analysis indicates that this is a timer problem: details to follow.

Comment 1 Stephen Tweedie 2007-06-01 16:25:44 UTC
I've instrumented the kernel to show when it is changing clocksource (in
clockevents_exchange_device()), and when it is triggering PIT transitions (in
init_pit_timer()).  This shows:

Switching clock from none to pit
Setting PIT mode 1  // SHUTDOWN
Setting PIT mode 2  // PERIODIC, ie. normal operating mode
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
Switching clock from pit to lapic
Setting PIT mode 0  // UNUSED --- this disables irq 0
Switching clock from none to pit
Setting PIT mode 1  // back to SHUTDOWN, irq 0 still disabled
Brought up 1 CPUs

before the hang.  Full logs attached.

Comment 2 Stephen Tweedie 2007-06-01 16:27:36 UTC
Created attachment 155903 [details]
Patch from 1.3143 which broke booting on Xen

Comment 3 Stephen Tweedie 2007-06-01 16:28:09 UTC
Created attachment 155904 [details]
Boot logs from instrumented kernel up until the hang

Comment 4 Eduardo Habkost 2007-09-11 20:31:27 UTC
Stephen: Is it on i686 or x86_64?

On x86_64, on both F-7 and Rawhide hosts using the F-7 DVD, boots go smoothly 
here, until /sbin/init. However, lots of ata "HSM violation" messages appear 
on guest's tty4 after ata_piix is loaded, and the installer don't see any 
CD-ROM driver that can be used to continue the installation.

Exact command used to boot the guest:
virt-install -v -c /dev/cdrom -n f7-64f -r 
500 -f /mnt/common/images/f7-64f-xen.img -s 5 --vnc

Comment 5 Eduardo Habkost 2007-09-11 20:35:43 UTC
Created attachment 192991 [details]
F7 guest kernel messages  with sata "HSM violation" errors

F7 kernel messages with the "HSM violation" errors.

Comment 6 Eduardo Habkost 2007-09-11 20:38:30 UTC
(In reply to comment #4)
> Stephen: Is it on i686 or x86_64?

Duh, just noticed that the patch you attached is on i386 code. So the problem 
I am seeing is an entirely different bug (probably on qemu, I guess).

Comment 7 Christopher Brown 2008-01-09 00:42:12 UTC
I've updated the component to reflect the fact that this looks like a xen issue
(or more broadly a virtualisation one) but it would be good if the reporter
could update this bug to indicate whether they are still having issues with the
latest kernel.

Comment 8 Jon Stanley 2008-02-28 16:19:43 UTC
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received feedback to the
information we have requested above, we will assume the problem was not
reproducible, or has been fixed in one of the updates we have released for the
reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest
update of their distribution, and if this issue turns out to still be
reproducible in the latest update, please reopen this bug with additional


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