Skip to content

UBUNTU: SAUCE: iommu/intel: disable DMAR for SKL integrated gfx #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

RawDiamondMC
Copy link

BugLink: https://bugs.launchpad.net/bugs/2062951

This patch addresses a screen flickering issues on systems with Skylake integrated graphics, identified under Ubuntu kernel version 6.8.0-x. Initially thought to be a regression from kernel 6.6, it has been determined that the flickering was caused by changes to the Ubuntu kernel configuration, specifically the enabling of CONFIG_INTEL_IOMMU_DEFAULT_ON and CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON.
77e530c ("UBUNTU: [Config] enable Intel DMA remapping by default")

The problem persists in the latest drm tip, and there is an upstream bug addressing the issue.
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11504

Before there is a real fix for the issue, we may have to add the affected GPU IDs to the quirk to disable its DMAR.

Acked-by: Kuan-Ying Lee [email protected]
Acked-by: Aaron Jauregui [email protected]

Link: https://bugs.launchpad.net/bugs/2062951
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11504

BugLink: https://bugs.launchpad.net/bugs/2062951

This patch addresses a screen flickering issues on systems with Skylake
integrated graphics, identified under Ubuntu kernel version 6.8.0-x.
Initially thought to be a regression from kernel 6.6, it has been
determined that the flickering was caused by changes to the Ubuntu kernel
configuration, specifically the enabling of CONFIG_INTEL_IOMMU_DEFAULT_ON
and CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON.
77e530c ("UBUNTU: [Config] enable Intel DMA remapping by default")

The problem persists in the latest drm tip, and there is an upstream bug
addressing the issue.
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11504

Before there is a real fix for the issue, we may have to add the affected
GPU IDs to the quirk to disable its DMAR.

Signed-off-by: Chia-Lin Kao (AceLan) <[email protected]>
Acked-by: Kuan-Ying Lee <[email protected]>
Acked-by: Aaron Jauregui <[email protected]>
Signed-off-by: Timo Aaltonen <[email protected]>

Link: https://bugs.launchpad.net/bugs/2062951
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11504
Signed-off-by: RawDiamondMC <[email protected]>
@MingcongBai MingcongBai merged commit 9b38ff5 into AOSC-Tracking:aosc/v6.14.10 Jun 9, 2025
KexyBiscuit pushed a commit that referenced this pull request Jun 12, 2025
pert script tests fails with segmentation fault as below:

  92: perf script tests:
  --- start ---
  test child forked, pid 103769
  DB test
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.012 MB /tmp/perf-test-script.7rbftEpOzX/perf.data (9 samples) ]
  /usr/libexec/perf-core/tests/shell/script.sh: line 35:
  103780 Segmentation fault      (core dumped)
  perf script -i "${perfdatafile}" -s "${db_test}"
  --- Cleaning up ---
  ---- end(-1) ----
  92: perf script tests                                               : FAILED!

Backtrace pointed to :
	#0  0x0000000010247dd0 in maps.machine ()
	#1  0x00000000101d178c in db_export.sample ()
	#2  0x00000000103412c8 in python_process_event ()
	#3  0x000000001004eb28 in process_sample_event ()
	#4  0x000000001024fcd0 in machines.deliver_event ()
	#5  0x000000001025005c in perf_session.deliver_event ()
	torvalds#6  0x00000000102568b0 in __ordered_events__flush.part.0 ()
	torvalds#7  0x0000000010251618 in perf_session.process_events ()
	torvalds#8  0x0000000010053620 in cmd_script ()
	torvalds#9  0x00000000100b5a28 in run_builtin ()
	torvalds#10 0x00000000100b5f94 in handle_internal_command ()
	torvalds#11 0x0000000010011114 in main ()

Further investigation reveals that this occurs in the `perf script tests`,
because it uses `db_test.py` script. This script sets `perf_db_export_mode = True`.

With `perf_db_export_mode` enabled, if a sample originates from a hypervisor,
perf doesn't set maps for "[H]" sample in the code. Consequently, `al->maps` remains NULL
when `maps__machine(al->maps)` is called from `db_export__sample`.

As al->maps can be NULL in case of Hypervisor samples , use thread->maps
because even for Hypervisor sample, machine should exist.
If we don't have machine for some reason, return -1 to avoid segmentation fault.

Reported-by: Disha Goel <[email protected]>
Signed-off-by: Aditya Bodkhe <[email protected]>
Reviewed-by: Adrian Hunter <[email protected]>
Tested-by: Disha Goel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Suggested-by: Adrian Hunter <[email protected]>
Signed-off-by: Namhyung Kim <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants