This option seems to causes way to many issues, it is being investigated by Intel's chipset team for months now and we still don't have any outcome.
The results so far are "black screen when starting X", "system hangs when using GL", "system does not resume".
The patch adds an intel_iommu=igfx_on option, which makes it opt in, rather than opt out.
Signed-off-by: Adel Gadllah adel.gadllah@gmail.com --- Documentation/kernel-parameters.txt | 11 +++++------ drivers/pci/intel-iommu.c | 9 +++++---- 2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index e7848a0..9914485 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -992,12 +992,11 @@ and is between 256 and 4096 characters. It is defined in the file Enable intel iommu driver. off Disable intel iommu driver. - igfx_off [Default Off] - By default, gfx is mapped as normal device. If a gfx - device has a dedicated DMAR unit, the DMAR unit is - bypassed by not enabling DMAR with this option. In - this case, gfx device will use physical address for - DMA. + igfx_on [Default Off] + By default, the gfx's DMAR unit is bypassed by not enabling + DMAR with this option. So the gfx device will use physical + address for DMA. When this option is enabled it the gfx is + mapped as normal device. forcedac [x86_64] With this option iommu will not optimize to look for io virtual address below 32 bit forcing dual diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c index 4173125..8f36786 100644 --- a/drivers/pci/intel-iommu.c +++ b/drivers/pci/intel-iommu.c @@ -340,7 +340,8 @@ int dmar_disabled = 0; int dmar_disabled = 1; #endif /*CONFIG_DMAR_DEFAULT_ON*/
-static int __initdata dmar_map_gfx = 1; +/* disabled by default; causes way to many issues */ +static int __initdata dmar_map_gfx = 0; static int dmar_forcedac; static int intel_iommu_strict;
@@ -361,10 +362,10 @@ static int __init intel_iommu_setup(char *str) } else if (!strncmp(str, "off", 3)) { dmar_disabled = 1; printk(KERN_INFO "Intel-IOMMU: disabled\n"); - } else if (!strncmp(str, "igfx_off", 8)) { - dmar_map_gfx = 0; + } else if (!strncmp(str, "igfx_on", 7)) { + dmar_map_gfx = 1; printk(KERN_INFO - "Intel-IOMMU: disable GFX device mapping\n"); + "Intel-IOMMU: enabled GFX device mapping\n"); } else if (!strncmp(str, "forcedac", 8)) { printk(KERN_INFO "Intel-IOMMU: Forcing DAC for PCI devices\n");
On Sat, 2010-04-17 at 12:36 +0200, drago01 wrote:
This option seems to causes way to many issues, it is being investigated by Intel's chipset team for months now and we still don't have any outcome.
The results so far are "black screen when starting X", "system hangs when using GL", "system does not resume".
The patch adds an intel_iommu=igfx_on option, which makes it opt in, rather than opt out.
Signed-off-by: Adel Gadllah adel.gadllah@gmail.com
Applied (with trivial __initdata fix), thanks. I hate to band-aid things like this, but it's better than crashing.
- ajax
On Mon, 2010-04-19 at 09:46 -0400, Adam Jackson wrote:
Applied (with trivial __initdata fix), thanks. I hate to band-aid things like this, but it's better than crashing.
It's not _just_ one or the other, surely? There's always the option of actually looking at the problem and fixing it.
Why is the AGP driver using the host bridge (0000:00:00.0) as the PCI device when setting up its DMA mappings? That seems wrong.
Fix that, and the issue (at least the RHEL6 one which is the only one anybody seems to have done me the courtesy of showing to me) probably ought to go away.
Don't just paper over driver bugs with crappy band-aids like this. Gr.
On Sat, 2010-04-17 at 12:36 +0200, drago01 wrote:
This option seems to causes way to many issues, it is being investigated by Intel's chipset team for months now and we still don't have any outcome.
That's bollocks. There was a problem on older chipsets which was never fully diagnosed; but we already _have_ a patch which disables the IOMMU for the graphics device on the affected chipsets.
Whatever you're seeing, it seems to be something new -- and you've applied the big hammer without even bothering to Cc me or report it upstream.
Thanks.
kernel@lists.fedoraproject.org