Bug 481356

Summary: kernel-2.6.29-0.35.rc1.git4.fc11 and later won't boot (CONFIG_DMAR + buggy BIOS)
Product: [Fedora] Fedora Reporter: Will Woods <wwoods>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: rawhideCC: kent.liu, kernel-maint, kmcmartin, luyu, moneta.mace, quintela, selinux, sysoutfran
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-22 20:54:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 446452    

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.