If you have an x86 machine that can't boot a rawhide kernel after kernel-2.6.29-0.35.rc1.git4.fc11 (Jan. 13), you may have a buggy BIOS that can't handle the CONFIG_DMAR kernel option.
This kernel option was enabled in Rawhide during May 2008 but caused a lot of machines with buggy BIOSes to lock up at boot, so it was disabled on May 22 2008.
Support has since improved, and it's required for the KVM PCI Device Assignment feature, so it was re-enabled on January 13.
If your system stopped booting after that, try adding "intel_iommu=off" to the boot arguments, and if your system boots after that, please comment on this bug: https://bugzilla.redhat.com/show_bug.cgi?id=481356
If anyone can confirm this bug we'll need to get some information about your system to figure out how to update the blacklist so your machine can boot again.
Thanks,
-w
On Fri, Jan 23, 2009 at 12:59:34PM -0500, Will Woods wrote:
If you have an x86 machine that can't boot a rawhide kernel after kernel-2.6.29-0.35.rc1.git4.fc11 (Jan. 13), you may have a buggy BIOS that can't handle the CONFIG_DMAR kernel option.
This kernel option was enabled in Rawhide during May 2008 but caused a lot of machines with buggy BIOSes to lock up at boot, so it was disabled on May 22 2008.
Support has since improved, and it's required for the KVM PCI Device Assignment feature, so it was re-enabled on January 13.
If your system stopped booting after that, try adding "intel_iommu=off" to the boot arguments, and if your system boots after that, please comment on this bug: https://bugzilla.redhat.com/show_bug.cgi?id=481356
If anyone can confirm this bug we'll need to get some information about your system to figure out how to update the blacklist so your machine can boot again.
Is this something that should be noted on the Fedora 11 Alpha release notes one-sheet for people testing that release? In particular, if we expect a significant amount of testers might see a lag behind current Rawhide that exhibits this weird "won't-boot" behavior, we should say that.
https://fedoraproject.org/wiki/Fedora_11_Alpha_release_notes
On Fri, Jan 23, 2009 at 01:38:30PM -0500, Paul W. Frields wrote:
Is this something that should be noted on the Fedora 11 Alpha release notes one-sheet for people testing that release? In particular, if we expect a significant amount of testers might see a lag behind current Rawhide that exhibits this weird "won't-boot" behavior, we should say that.
If we can jump to the rawhide kernel that will fall out of koji in a few hours then the issue will go away. I've changed the default for intel_iommu to be disabled and require "intel_iommu=on" on the commandline.
I realize this may inconvenience the virt folks using this for passthrough, but sadly because of reported data corruption being possible if io craps out because of the DMAR, I thought it was important to make it opt-in not opt-out. (phew, long run-on sentence...)
cheers, Kyle
2009/1/23 Kyle McMartin kyle@mcmartin.ca:
On Fri, Jan 23, 2009 at 01:38:30PM -0500, Paul W. Frields wrote:
Is this something that should be noted on the Fedora 11 Alpha release notes one-sheet for people testing that release? In particular, if we expect a significant amount of testers might see a lag behind current Rawhide that exhibits this weird "won't-boot" behavior, we should say that.
If we can jump to the rawhide kernel that will fall out of koji in a few hours then the issue will go away. I've changed the default for intel_iommu to be disabled and require "intel_iommu=on" on the commandline.
I realize this may inconvenience the virt folks using this for passthrough, but sadly because of reported data corruption being possible if io craps out because of the DMAR, I thought it was important to make it opt-in not opt-out. (phew, long run-on sentence...)
cheers, Kyle
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
I made a test also for bug 479525 but no go.