Bug 40332
Summary: | Lenovo X201s: Kernel panic - not syncing: DMAR hardware is malfunctioning | ||
---|---|---|---|
Product: | Drivers | Reporter: | Yves-Alexis Perez (corsac) |
Component: | Video(DRI - Intel) | Assignee: | drivers_video-dri-intel (drivers_video-dri-intel) |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | chris |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.0 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
dmesg with no I/O MMU enabled
dmesg with intel_iommu=on dmesg with intel_iommu=igfx_off disable iommu for graphics on ironlake too |
Description
Yves-Alexis Perez
2011-07-29 13:52:38 UTC
And note that while: [ 415.884326] panic occurred, switching back to text console is displayed, there's no switch, it stays in X. The ironlake iommu does not work with the igfx due to a silicon bug, hence why the kernel disables it... Hmh, I might be confused but I thought that it was just a matter of excluding igfx (setting up an identity mapping) from DMAR. Do you mean there's *no* way to use the I/O MMU on this laptop? Created attachment 67082 [details]
dmesg with no I/O MMU enabled
Created attachment 67092 [details]
dmesg with intel_iommu=on
Created attachment 67102 [details]
dmesg with intel_iommu=igfx_off
It seems that, for now, intel_iommu=igfx_off works fine (no lockup, though I'm only booted for half an hour).
Hum, indeed, with igfx_off it seems that it doesn't really use DMAR: [ 0.939792] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Ok, I might be wrong but couldn't the same kind of fix than http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2d9e667e be applied? AIUI in the patch only GFX DMAR is disabled, for the relevant device ([8086:2a40] rev07). In my case my device is: 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) I'll try to extend the patch and see it leads somewhere. Created attachment 67152 [details]
disable iommu for graphics on ironlake too
Ok, using this patch seems to fix the problem but still enable DMAR.
Is it normal that when booting with intel_iommu=igfx_off the setup does:
dmar_map_gfx = 0;
but not
dmar_disabled = 0; ?
Debian doesn't have DMAR_DEFAULT_ON enabled (for good reasons) but I think (according to the documentation) that intel_iommu=igfx_off means “DMAR remapping enabled except for IGFX”:
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.
What do you think? Should I prepare a patch adding dmar_disable = 0; for intel_iommu=igfx_on?
Ok, I was confused. I still think the quirk is valid (in order to prevent users like me to shoot themselves in the foot) but I didn't realized one could do: intel_iommu=on,igfx_off to have the same behavior as with the quirk. As Dave Airled said on #intel-gfx though, it might make sense to extend the quirk to all Cantiga and Ironlake chipsets where apparently the GFX I/O MMU is buggy, while the main one does work. Note that Intel-IOMMU.txt in Documentation says: Graphics Problems? ------------------ If you encounter issues with graphics devices, you can try adding option intel_iommu=igfx_off to turn off the integrated graphics engine. If this fixes anything, please ensure you file a bug reporting the problem. so this is exactly what I did. My understanding is that intel_iommu=igfx_off is a temporary workaround until a fix is committed to the code (wether it's a real fix or disabling the IGFX I/O MMU). If I'm wrong, maybe rephrasing the documentation would be a good idea? |