[DragonFlyBSD - Bug #3280] KMS console and i915(4) not working in 6.0

bugtracker-admin at leaf.dragonflybsd.org bugtracker-admin at leaf.dragonflybsd.org
Wed Jun 2 11:02:10 PDT 2021

Issue #3280 has been updated by cmusser.

peeter wrote:
> I'll try run the drm.debug messages for my old intel laptop where it works. What is confusing is that some of the warnings you mention do appear on the working system too. However, clearly, something fails at the end: 
So, on 6.0 with your laptop that works, do you get this warning:

WARNING !set->fb failed at /usr/src/sys/dev/drm/drm/../drm_atomic_helper.c:2750

If so, then yes, maybe that isn't really indicative of a problem. One thing I do notice is that in 5.8, there are quite a few lines where no framebuffer is set for the various planes, but eventually one line appears that indicating that the framebuffer is set for one of them:

[drm:pid703:drm_atomic_set_fb_for_plane] Set [FB:57] for plane state 0xfffff800c7915700

In the 6.0 case, all the "set framebuffer" log traces look like:

[drm:pid900:drm_atomic_set_fb_for_plane] Set [NOFB] for plane state 0xfffff800cf13e700

Bug #3280: KMS console and i915(4) not working in 6.0

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Driver
* Target version: 6.0
I have a ThinkPad x220 laptop with i915 integrated graphics that had a working KMS console in 5.8, but in 6.0, it doesn't work anymore. Loading the i915 module causes the screen to stop updating after a couple of initialization messages. The system still runs: I can log into it via SSH, retrieve the logs, recompile kernels and such.

I attached the dmesg logs from both 5.8 and 6.0. In 5.8, you can see it assigning a framebuffer to a CRTC and proceeding normally through startup, whereas in 6.0, all the framebuffers are marked NOFB and eventually you see this error:

WARNING !set->fb failed at /usr/src/sys/dev/drm/drm/../drm_atomic_helper.c:2750

Later, the driver attempts a verification and prints this:

WARNING state->crtc && !state->fb failed at /usr/src/sys/dev/drm/drm/../drm_atomic.c:862
[drm:pid938:drm_atomic_plane_check] CRTC set but no FB

In very general terms, it looks like a framebuffer gets allocated, but never set into a field where it gets read later in the setup process. I read through the drm code and put some tracing statements in various functions to try to understand the execution path.

- At some point in the startup, drm_fb_helper_single_fb_probe() is entered and it uses intelfb_create() to allocate a framebuffer.

- Later, fb_probe() winds up calling  restore_fbdev_mode_atomic(), which  loops through all the fb_helper struct's crtc_info fields, extracting a drm_mode_set struct.

- The drm_mode_set is passed to __drm_atomic_helper_set_config, which checks to see if the fb field in the drm_mode_set structure is non-NULL, which fails (it is NULL) This results in the warning message  mentioned earlier.

- I could only find one place that this fb field was populated, drm_setup_crtcs_fb(), and this function doesn't get called.

- drm_setup_crtcs_fb() is called from two places that I could find: __drm_fb_helper_initial_config_and_unlock() and drm_fb_helper_hotplug_event. That first one doesn't get called, and the second one gets called later, but does not end up calling drm_setup_crtcs_fb().

5.8-dmesg-after (63.7 KB)
6.0-dmesg-after (108 KB)

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account

More information about the Bugs mailing list