Description of problem: Kernels 2.6.21-1.3143.fc7 and later lock up at boot when run inside Xen full virtualisation. Version-Release number of selected component (if applicable): kernel-2.6.21-1.3143.fc7 and later How reproducible: 100% 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: Boots. Initial analysis indicates that this is a timer problem: details to follow.
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 ... ENABLING IO-APIC IRQs ..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.
Created attachment 155903 [details] Patch from 1.3143 which broke booting on Xen
Created attachment 155904 [details] Boot logs from instrumented kernel up until the hang
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
Created attachment 192991 [details] F7 guest kernel messages with sata "HSM violation" errors F7 kernel messages with the "HSM violation" errors.
(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).
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.
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 information. Closing as INSUFFICIENT_DATA.