[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
Sun Jun 6 00:52:44 PDT 2021

Issue #3280 has been updated by peeter.

File 6.1-messages-truncated added

I attach the drm.debug=0x777 messages for my laptop where it works. Mine is ironlake

- [drm:pid1034:intel_device_info_dump] i915 device info: platform=IRONLAKE gen=5 pciid=0x0046 rev=0x18

yours is 

- [drm:pid938:intel_device_info_dump] i915 device info: platform=SANDYBRIDGE gen=6 pciid=0x0126 rev=0x09

There is some interesting structure to the successful initialization on my laptop. It seems divided into two chunks. The first one is with pid1034 (ie pid=1034), but that fails to initialize in the end, see line 287. Then the pid changes to -1 in line 295. The next chunk of initialization messages shows success. Also, the errors you see, like

"WARNING state->crtc && !state->fb failed at /usr/src/sys/dev/drm/drm/../drm_atomic.c:862"

are in the first, failed part. The later, successful part does not have these messages.

The debug messages on your x220 has the first part with pid938, but when the pid changes to -1, then that part fails too. Or actually, it is abruptly cut off. I'm not sure what is happening. 

An idle thought: can you check out master branch, buildworld/kernel and see what happens? 

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)
6.1-messages-truncated (50.9 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