Bug 253797 - i915 drm error after update to FreeBSD 13.0-BETA3, BETA4
Summary: i915 drm error after update to FreeBSD 13.0-BETA3, BETA4
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 13.0-STABLE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Keywords: i915
Depends on:
Reported: 2021-02-23 15:19 UTC by Igor Osminin
Modified: 2022-06-19 16:40 UTC (History)
7 users (show)

See Also:

Log (25.51 KB, text/plain)
2021-02-23 15:19 UTC, Igor Osminin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Igor Osminin 2021-02-23 15:19:46 UTC
Created attachment 222759 [details]

Hi. On a laptop with Intel HD Graphics 5500, after waking up from sleep mode, I got some error messages (the system continues to work after that):

Feb 23 16:43:29 freebsd kernel: [drm ERROR :fw_domain_wait_ack_clear] render: timed out waiting for forcewake ack to clear.
Feb 23 16:43:29 freebsd kernel: drmn1: Failed to idle engines, declaring wedged!

Also, I attach all /var/log/messages for today's date.
Comment 1 Igor Osminin 2021-02-23 19:12:37 UTC
After that, the graphics is drawn very slowly. This is especially noticeable when dragging windows or viewing web pages through the browser.
Comment 2 Igor Osminin 2021-03-01 10:30:10 UTC
Today the error appeared again, on FreeBSD 13.0-BETA 4. In /var/log/messages, everything is the same.
Comment 3 Dave Cottlehuber freebsd_committer 2021-03-06 08:43:32 UTC
can you post any sysctls, loader.conf tunables that might be related? and for history, which pkg versions are installed?
Comment 4 Igor Osminin 2021-03-06 09:05:40 UTC
Hi, David. The pkg version I have is 1.16.3.
Contents of /boot/loader.conf related to the i915 driver:


$ sysctl compat.linuxkpi
compat.linuxkpi.i915_enable_dpcd_backlight: 0
compat.linuxkpi.i915_enable_dp_mst: 1
compat.linuxkpi.i915_guc_log_level: -1
compat.linuxkpi.i915_enable_guc: 0
compat.linuxkpi.i915_edp_vswing: 0
compat.linuxkpi.i915_nuclear_pageflip: 0
compat.linuxkpi.i915_verbose_state_checks: 1
compat.linuxkpi.i915_mmio_debug: 0
compat.linuxkpi.i915_disable_display: 0
compat.linuxkpi.i915_invert_brightness: 0
compat.linuxkpi.i915_force_reset_modeset_test: 0
compat.linuxkpi.i915_load_detect_test: 0
compat.linuxkpi.i915_prefault_disable: 0
compat.linuxkpi.i915_fastboot: -1
compat.linuxkpi.i915_enable_ips: 1
compat.linuxkpi.i915_disable_power_well: 0
compat.linuxkpi.i915_alpha_support: 1
compat.linuxkpi.i915_enable_psr: 0
compat.linuxkpi.i915_enable_hangcheck: 1
compat.linuxkpi.i915_error_capture: 1
compat.linuxkpi.i915_reset: 2
compat.linuxkpi.i915_vbt_sdvo_panel_type: -1
compat.linuxkpi.i915_panel_use_ssc: -1
compat.linuxkpi.i915_lvds_channel_mode: 0
compat.linuxkpi.i915_enable_fbc: 0
compat.linuxkpi.i915_enable_dc: -1
compat.linuxkpi.i915_modeset: -1
compat.linuxkpi.drm_drm_fbdev_overalloc: 100
compat.linuxkpi.drm_fbdev_emulation: 1
compat.linuxkpi.drm_timestamp_precision_usec: 20
compat.linuxkpi.drm_vblankoffdelay: 5000
compat.linuxkpi.drm_poll: 1
compat.linuxkpi.drm_edid_fixup: 6
compat.linuxkpi.drm_debug: 0
compat.linuxkpi.drm_dp_aux_i2c_transfer_size: 16
compat.linuxkpi.drm_dp_aux_i2c_speed_khz: 10
compat.linuxkpi.debug: 0
Comment 5 Patricio Villar 2021-03-14 17:48:08 UTC
Hi, a while ago I reported (I believe) the same problem as yours here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253801

In my case, since 13.0-RC1 and now RC2, the issue has become harder to reproduce. What about you? Is it too less likely to happen now?
Comment 6 Igor Osminin 2021-03-15 07:45:30 UTC
(In reply to Patricio Villar from comment #5)
Hi, Patricio. Yes, it's the same problem. In 13.0-RC1, this occurred twice, before that, it happened more often. Now, in 13.0-RC2, I have not encountered this yet (updated yesterday).
Comment 7 Patricio Villar 2021-03-15 13:13:12 UTC
(In reply to Igor Osminin from comment #6)
Cool! That means it wasn't just my impression or a coincidence. So far it haven't happened here on 13.0-RC2 either.
Comment 8 Patricio Villar 2021-04-05 19:46:07 UTC
How's it going for you lately?
Sadly, in my case it's gone completely backwards. Resuming from suspend is really broken right now on both 13.0-RC4 and 13.0-RC5. It's a real shame, and I'm afraid it's gonna make it to 13.0-RELEASE :(
Comment 9 Mark Linimon freebsd_committer freebsd_triage 2021-04-06 05:36:16 UTC
(In reply to Patricio Villar from comment #8)
> Resuming from suspend is really broken right now on both 13.0-RC4 and 13.0-RC5.

Hmm.  I have been doing some updates around the house.  This laptop (a Dell Latitude E5430) is on RC4 and it suspends ok.  I have the following set, if it matters:


I will check the other laptop, which is on RC5, later.

So, this is puzzling.
Comment 10 Patricio Villar 2021-04-06 17:57:27 UTC
(In reply to Mark Linimon from comment #9)
Thanks for replying!
I think this problem is very hardware-specific after all, as I have Intel HD Graphics 5500 just like Igor Osminin (who first reported the issue).
And I have "hw.acpi.lid_switch_state=S3" too, but don't think it's related to this bug really.
Comment 11 Patricio Villar 2021-05-03 22:13:52 UTC
Hi everyone, I think I finally made some progress to workaround this issue. I explained it on the other bug report about this problem:

Comment 12 Graham Perrin freebsd_committer 2021-10-16 05:39:54 UTC

[i915kms] broken suspend/resume on MacbookPro15/13.0-RC3 · Issue #67 · freebsd/drm-kmod
Comment 13 eaosfu 2021-10-17 04:34:36 UTC
(In reply to Patricio Villar from comment #11)

I just tried on my thinkpad t450 running:


I manually ran through several cycles of suspend/resume with firefox playing a youtube video. I never locked the screen during these cycles and thus never wedged the gpu.

I then tried running through several cycles of suspend/resume again except this time the only program I'd run before triggering suspend is i3-lock. This time, I reliable wedge the gpu on the second resume.
Comment 14 Graham Perrin freebsd_committer 2022-06-19 16:40:30 UTC
Please try FreeBSD 13.1-RELEASE with graphics/drm-510-kmod


(In reply to Graham Perrin from comment #12)

NB the closing comment.