Bug 481356 - kernel-2.6.29-0.35.rc1.git4.fc11 and later won't boot (CONFIG_DMAR + buggy BIOS)
Summary: kernel-2.6.29-0.35.rc1.git4.fc11 and later won't boot (CONFIG_DMAR + buggy BIOS)
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F11Blocker, F11FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2009-01-23 17:52 UTC by Will Woods
Modified: 2011-06-09 11:08 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-02-22 20:54:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Will Woods 2009-01-23 17:52:40 UTC
The CONFIG_DMAR kernel option, when enabled, can cause x86 machines with buggy BIOSes to refuse to boot.

This config option is required by the KVM PCI Device Assignment feature of Fedora 11 (https://fedoraproject.org/wiki/Features/KVM_PCI_Device_Assignment) and it was (re-)enabled January 13, with kernel kernel-2.6.29-0.35.rc1.git4.fc11. 

If your system fails to boot with that kernel (or any later kernel), try adding "intel_iommu=off" to the boot commandline. If the system boots successfully after that, it is affected by this bug.

If your system is affected by this bug, please add a comment listing the system manufacturer and model. Make sure you're added to the CC list, as we'll need to collect some information from your machine to add it to the kernel blacklist so that it can boot without needing special boot-time arguments.

Comment 1 Tom London 2009-01-23 18:04:46 UTC
This sounds related to https://bugzilla.redhat.com/show_bug.cgi?id=479996

My system (Thinkpad X200) booted, but had problems afterwards, including FS corruption.

I "fixed" this by disabling VT-d in the BIOS.

Something else I should do?

Comment 2 Kyle McMartin 2009-01-23 18:57:46 UTC
I've disabled this by default in rawhide. Enable it with "intel_iommu=on" until the data corruption by default issues get worked out.

cheers, Kyle

Comment 3 Frank Murphy 2009-01-27 07:58:49 UTC
May have something similar, but think I placed it in the wrong bugzilla.

https://bugzilla.redhat.com/show_bug.cgi?id=480667#c11 (c12,13)

Comment 4 Mace Moneta 2009-02-17 04:00:02 UTC
I'm having this problem, and have to boot with "intel_iommu=off".  The system is a Supermicro C2SEA motherboard, 8GB RAM, Intel G45/X4500HD:

http://www.smolts.org/client/show/pub_21f31cf1-2c1b-4e8a-860b-01f9d5a43910

Comment 5 Will Woods 2009-02-17 20:30:04 UTC
(In reply to comment #4)
> I'm having this problem, and have to boot with "intel_iommu=off".  The system
> is a Supermicro C2SEA motherboard, 8GB RAM, Intel G45/X4500HD:

This option was re-enabled in kernel-2.6.29-0.118.rc5.fc11; what kernel version are you using?

Comment 6 Mace Moneta 2009-02-17 22:28:56 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > I'm having this problem, and have to boot with "intel_iommu=off".  The system
> > is a Supermicro C2SEA motherboard, 8GB RAM, Intel G45/X4500HD:
> 
> This option was re-enabled in kernel-2.6.29-0.118.rc5.fc11; what kernel version
> are you using?

I'm now running 2.6.29-0.124.rc5.fc11.x86_64 and I don't need to boot with "intel_iommu=off" anymore.

Comment 7 Kyle McMartin 2009-02-22 20:54:39 UTC
It looks like all the issues resulting from intel_iommu are worked out now. (There may still be lingering issues from the DMA API debugging patchset, but those are seperate issues.) Closing this bug now.


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