Created attachment 361989 [details] virtlab17's cpuinfo (from a rhel5.4 kernel) Description of problem: F12 Virt Test Day liveCD failed to boot on Nehalem virtlab machines (virtlab16 -> virtlab18). These are primary devel machines for virtualization support, especially VTd & SRIOV for device assignment. These same machines boot & support RHEL5.4 successfully. Version-Release number of selected component (if applicable): 2.6.31-12.fc12.x86_64 liveCD info: desktop-x86_64-20090915.15.iso How reproducible: Every boot Steps to Reproduce: 1. Install liveCD into DVD tray of 1U machines 2. reboot system if running another OS; or power cycle machine 3. Actual results: (1) When BIOS had Intr. Remapping enabled, the system would generate DMAR fault errors and eventually wedge/hang. (2) When BIOS had Intr. Remapping disabled, the system would try to start the graphical output, but the graphic screen reported no-sync, and nothing came out on the console screen. (a) the serial console would see the POST output, but then generate an odd, unprintable character and then (appear to) hang. Expected results: Boot to the liveCD login page. Additional info: Edited the cmdline and set intel_iommu=off and got the same results as in (2) above.
Created attachment 361990 [details] virtlab17's dmidecode output (from rhel5.4 kernel)
Created attachment 361991 [details] virtlab17's lspci -vvv output
Created attachment 361993 [details] virtlab17 dmesg from a rhel5.4 boot
Created attachment 362151 [details] log from failed boot on Tylersberg-EP platform I believe that the boot failure (not the interrupt remapping issue) is related to the CD/Rom driver and is not a VTd issue. I've attached the serial console log from a boot failure on a Tylersberg-EP machine. Note that the last message before the `No root device found' was: cdrom_id used greatest stack depth: 3240 bytes left This seems to indicate a problem with the CD/Rom.
I see different 'used greatest stack depth' messages on my crashes. it's just a fault helper printk, and it says it still has 3240 bytes space on the stack, so I don't think that's the problem. the i2c fault (looks non-fatal) pts to a possible problem, and this doesn't look good: [drm:radeon_driver_load_kms] *ERROR* Failed to initialize radeon, disabling IOCTL I'm curious if our other faulting systems have radeon graphics or (just) built-in intel graphics.
(In reply to comment #5) > I see different 'used greatest stack depth' messages on my crashes. > it's just a fault helper printk, and it says it still has 3240 bytes > space on the stack, so I don't think that's the problem. > > the i2c fault (looks non-fatal) pts to a possible problem, > and this doesn't look good: > [drm:radeon_driver_load_kms] *ERROR* Failed to initialize radeon, disabling > IOCTL That's bug 524042
Did you try booting to runlevel 3?
I tried booting to single user mode (init=/bin/sh) and it didn't work. The failure occurs long before you get into issues of run level.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping