Summary: | i915 drm error after update to FreeBSD 13.0-BETA3, BETA4 | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Igor Osminin <osm.gosha> | ||||
Component: | kern | Assignee: | Graham Perrin <grahamperrin> | ||||
Status: | Closed Feedback Timeout | ||||||
Severity: | Affects Some People | CC: | asensiolaizola, dch, grahamperrin, linimon, maurizio1018, osm.gosha, patovm04, x11 | ||||
Priority: | --- | Keywords: | i915 | ||||
Version: | 13.0-STABLE | ||||||
Hardware: | amd64 | ||||||
OS: | Any | ||||||
See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253801 | ||||||
Attachments: |
|
After that, the graphics is drawn very slowly. This is especially noticeable when dragging windows or viewing web pages through the browser. Today the error appeared again, on FreeBSD 13.0-BETA 4. In /var/log/messages, everything is the same. can you post any sysctls, loader.conf tunables that might be related? and for history, which pkg versions are installed? Hi, David. The pkg version I have is 1.16.3. Contents of /boot/loader.conf related to the i915 driver: i915kms_load="YES" drm.i915.enable_rc6=0 drm.i915.semaphores="1" drm.i915.enable_fbc="1" kern.vt.fb.default_mode="1600x900" $ 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_edid_firmware: 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 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? (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). (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. 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 :( (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: hw.acpi.lid_switch_state=S3 I will check the other laptop, which is on RC5, later. So, this is puzzling. (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. Hi everyone, I think I finally made some progress to workaround this issue. I explained it on the other bug report about this problem: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253801#c14 Cross-reference: [i915kms] broken suspend/resume on MacbookPro15/13.0-RC3 · Issue #67 · freebsd/drm-kmod <https://github.com/freebsd/drm-kmod/issues/67> (In reply to Patricio Villar from comment #11) I just tried on my thinkpad t450 running: 13.0-RELEASE-p4 gpu-firmware-kmod-g20210330 drm-fbsd13-kmod-5.4.144.g20210908 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. Please try FreeBSD 13.1-RELEASE with graphics/drm-510-kmod <https://www.freshports.org/graphics/drm-510-kmod/#add> (In reply to Graham Perrin from comment #12) NB the closing comment. Things seem to be fixed in parallel bug 253801, so, with no recent feedback here, I think it's time to close both reports. If a new bug report is required, probably better to make it 'Ports & Packages' (not base system). Thanks. graphics/drm-510-kmod <https://www.freshports.org/graphics/drm-510-kmod/> |
Created attachment 222759 [details] Log 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.