Skip to content
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

radeonkms conflicts with efifb #170

juikim opened this Issue Aug 30, 2017 · 3 comments


None yet
4 participants
Copy link

commented Aug 30, 2017

I have Pitcairn and Turks and both use UEFI. Unfortunately, these GPUs conflict with efifb. For example, with Turks, GPU acceleration gets disabled:

[drm:r600_ring_test] radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
drmn0: disabling GPU acceleration

@mattmacy let me know that it can be worked around by disabling efifb, i.e., set hw.syscons.disable=1 in loader(8). After disabling the efifb and blindly loading radeonkms.ko, it worked fine on both systems. Booting with legacy BIOS (using vga fb) does not show the problem.

@mattmacy mattmacy self-assigned this Aug 30, 2017

@mattmacy mattmacy added this to the amdgpu-4.14 milestone Aug 30, 2017


This comment has been minimized.

Copy link

commented Aug 30, 2017

Please note an additional patch was used to detect monitors, i.e.,

--- radeon/radeon_drv.c.orig	2017-08-30 01:42:41 UTC
+++ radeon/radeon_drv.c
@@ -186,7 +186,7 @@ int radeon_connector_table = 0;
 int radeon_tv = 1;
 int radeon_audio = -1;
 int radeon_disp_priority = 0;
-int radeon_hw_i2c = 0;
+int radeon_hw_i2c = 1;
 int radeon_pcie_gen2 = -1;
 int radeon_msi = -1;
 int radeon_lockup_timeout = 10000;

Please see issue #171.


This comment has been minimized.

Copy link

commented Sep 10, 2017

I had to use hw.syscons.disable=1 on Polaris as well. (Found that in #158)

myfreeweb referenced this issue in freebsd/freebsd-ports Sep 14, 2017

jmd jmd
graphics/drm-next-kmod: update to later github snapshot which include…
…s improvements made in response to bug reports and removes the collision of the port's drm.ko with base drm.ko. Also increase the FreeBSD version check in response to PR 221937. Additionally, improve pkg-message and note that radeonkms is also available in this port.

PR:		221937
Reviewed by:	swills (mentor)
Approved by:	swills (mentor)
Differential Revision:

johalun added a commit that referenced this issue Sep 19, 2017

drm/i915: Remove overzealous fence warn on runtime suspend
The goal of the WARN was to catch when we are still actively using the
fence as we go into the runtime suspend. However, the reg->pin_count is
too coarse as it does not distinguish between exclusive ownership of the
fence register from activity.

I've not improved on the WARN, nor have we captured this WARN in an
exact igt, but it is showing up regularly in the wild:

[ 1915.935332] WARNING: CPU: 1 PID: 10861 at drivers/gpu/drm/i915/i915_gem.c:2022 i915_gem_runtime_suspend+0x116/0x130 [i915]
[ 1915.935383] WARN_ON(reg->pin_count)[ 1915.935399] Modules linked in:
 snd_hda_intel i915 drm_kms_helper vgem netconsole scsi_transport_iscsi fuse vfat fat x86_pkg_temp_thermal coretemp intel_cstate intel_uncore snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd mei_me mei serio_raw intel_rapl_perf intel_pch_thermal soundcore wmi acpi_pad i2c_algo_bit syscopyarea sysfillrect sysimgblt fb_sys_fops drm r8169 mii video [last unloaded: drm_kms_helper]
[ 1915.935785] CPU: 1 PID: 10861 Comm: kworker/1:0 Tainted: G     U  W       4.9.0-rc5+ #170
[ 1915.935799] Hardware name: LENOVO 80MX/Lenovo E31-80, BIOS DCCN34WW(V2.03) 12/01/2015
[ 1915.935822] Workqueue: pm pm_runtime_work
[ 1915.935845]  ffffc900044fbbf0 ffffffffac3220bc ffffc900044fbc40 0000000000000000
[ 1915.935890]  ffffc900044fbc30 ffffffffac059bcb 000007e6044fbc60 ffff8801626e3198
[ 1915.935937]  ffff8801626e0000 0000000000000002 ffffffffc05e5d4e 0000000000000000
[ 1915.935985] Call Trace:
[ 1915.936013]  [<ffffffffac3220bc>] dump_stack+0x4f/0x73
[ 1915.936038]  [<ffffffffac059bcb>] __warn+0xcb/0xf0
[ 1915.936060]  [<ffffffffac059c4f>] warn_slowpath_fmt+0x5f/0x80
[ 1915.936158]  [<ffffffffc052d916>] i915_gem_runtime_suspend+0x116/0x130 [i915]
[ 1915.936251]  [<ffffffffc04f1c74>] intel_runtime_suspend+0x64/0x280 [i915]
[ 1915.936277]  [<ffffffffac0926f1>] ? dequeue_entity+0x241/0xbc0
[ 1915.936298]  [<ffffffffac36bb85>] pci_pm_runtime_suspend+0x55/0x180
[ 1915.936317]  [<ffffffffac36bb30>] ? pci_pm_runtime_resume+0xa0/0xa0
[ 1915.936339]  [<ffffffffac4514e2>] __rpm_callback+0x32/0x70
[ 1915.936356]  [<ffffffffac451544>] rpm_callback+0x24/0x80
[ 1915.936375]  [<ffffffffac36bb30>] ? pci_pm_runtime_resume+0xa0/0xa0
[ 1915.936392]  [<ffffffffac45222d>] rpm_suspend+0x12d/0x680
[ 1915.936415]  [<ffffffffac69f6d7>] ? _raw_spin_unlock_irq+0x17/0x30
[ 1915.936435]  [<ffffffffac0810b8>] ? finish_task_switch+0x88/0x220
[ 1915.936455]  [<ffffffffac4534bf>] pm_runtime_work+0x6f/0xb0
[ 1915.936477]  [<ffffffffac074353>] process_one_work+0x1f3/0x4d0
[ 1915.936501]  [<ffffffffac074678>] worker_thread+0x48/0x4e0
[ 1915.936523]  [<ffffffffac074630>] ? process_one_work+0x4d0/0x4d0
[ 1915.936542]  [<ffffffffac074630>] ? process_one_work+0x4d0/0x4d0
[ 1915.936559]  [<ffffffffac07a2c9>] kthread+0xd9/0xf0
[ 1915.936580]  [<ffffffffac07a1f0>] ? kthread_park+0x60/0x60
[ 1915.936600]  [<ffffffffac69fe62>] ret_from_fork+0x22/0x30

In the case the register is pinned, it should be present and we will
need to invalidate them to be restored upon resume as we cannot expect
the owner of the pin to call get_fence prior to use after resume.

Fixes: 7c108fd8feac ("drm/i915: Move fence cancellation to runtime suspend")
Reported-by: Lionel Landwerlin <>
Signed-off-by: Chris Wilson <>
Cc: Daniel Vetter <>
Cc: Imre Deak <>
Cc: Jani Nikula <>
Cc: <> # v4.10-rc1+
Reviewed-by: Joonas Lahtinen <>
(cherry picked from commit e0ec3ec698851a6c97a12d696407b3ff77700c23)
Signed-off-by: Jani Nikula <>
Signed-off-by: Johannes Lundberg <>

This comment has been minimized.

Copy link

commented Dec 31, 2018

If I may, I would like to add some "artifacts" for this problem, since I am hitting it as well.
My tests shows that if I boot using EFI (using grub2 chainload to efi) an intermittent pattern occurs, when:

  1. sometimes Xorg will work but sometimes it does not (having a black screen, "lights off");
  2. many "interrupt storm" messages for the vga will be shown;

If I don't boot using EFI everything works as expected;
More details, such as sysctl, driver versions, Xorg.0.log, dmesg (from when it works and it does not) in the gist above;
I can help with tests and more investigation. If there is something else that I can do please let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.