<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [v4.13 ARCH] GPU HANG: DMAR: DRHD: handling fault status reg 3 (arch reverted the use of intel_iommu=igfx_off)" href="https://bugs.freedesktop.org/show_bug.cgi?id=103076#c19">Comment # 19</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [v4.13 ARCH] GPU HANG: DMAR: DRHD: handling fault status reg 3 (arch reverted the use of intel_iommu=igfx_off)" href="https://bugs.freedesktop.org/show_bug.cgi?id=103076">bug 103076</a> from <a class="email" href="mailto:carstenmattner@gmail.com" title="Carsten Mattner <carstenmattner@gmail.com>"> Carsten Mattner</a> <pre>(In reply to Ansgar Hegerfeld from <a href="show_bug.cgi?id=103076#c16">comment #16</a>) > Maybe we should close this bug as a duplicate of > <a class="bz_bug_link bz_status_NEW " title="NEW - [bdw-u iommu] DMAR error -> GPU hang" href="show_bug.cgi?id=89360">https://bugs.freedesktop.org/show_bug.cgi?id=89360</a> or did I miss something? > The workaround "intel_iommu=igfx_off" works for me using Arch Linux, too. I don't think the problem is fixed. I'm on Sandybridge and have tested various kernels and configs. 4.9-LTS OK 4.4-LTS KINDA-OK because it has atomic modesetting errors that got introduced in 4.2 and haven't been fixed until 4.9-LTS (or earlier, don't have kernel in-between which is maintained). This would be a nice kernel because it will be supported until 2020 IIUC, but the new atomic modesetting code is buggier than in 4.9. 4.12 OK but EOL already 4.13 BAD. most problematic drm version: On my Sandybridge machine I've disabled IOMMU in the BIOS and also added intel_iommu=igfx_off, on top off the 4.13.5+ kernel having CONFIG_INTEL_IOMMU_DEFAULT_ON not set anymore. Even though it's harder to trigger now in 4.13, I can still provoke GPU errors not present in either 4.12 or 4.9. I've been successfully using 4.9 for more than a day with heavy GPU and CPU utilization and haven't hit the same errors as in 4.13. drm-tip from a week ago No improvement over 4.13.4 I'm able to hit errors in 4.13 by running ffmpeg to encode a video, utilizing vaapi for decoding the input stream, using the cpu cores for encoding, and then starting a second VAAPI client or a browser with a compositor process like Firefox or Chrome. If I just run ffmpeg as the sole VAAPI client and no browser or mpv with vaapi decoding, there are no hangs. The minute I fire up a video to watch via vaapi and rendering with OpenGL or use Firefox/Chrome, there's a GPU hang with reset. Firefox: [drm] GPU HANG: ecode 6:0:0x80202f7b, in Compositor [2620], reason: Hang on rcs0, action: reset drm/i915: Resetting chip after gpu hang Chrome: drm/i915: Resetting chip after gpu hang asynchronous wait on fence i915:[global]:a4255 timed out drm/i915: Resetting chip after gpu hang Summary: 4.9 stable for days, 4.4 not good, 4.12 good, 4.13 very bad.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are on the CC list for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>