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

[bugtracker-admin at leaf.dragonflybsd.org]

Issue #3280 has been updated by mneumann.


On Tue, Jun 01, 2021 at 11:25:58AM -0700, bugtracker-admin at leaf.dragonflybsd.org wrote:
> Issue #3280 has been updated by cmusser.
> 
> 
> That commit removes the EFI console hack, so I think what you meant was testing with the hack back in place. I put the hack back in and set machdep.hack_efifb_probe_early=1. It didn't change the results after a reboot though: console output stops after i915 is loaded.

Yes, testing with the hack back in place is what I meant.

Ok, I just wanted to be sure that this is not related.

----------------------------------------
Bug #3280: KMS console and i915(4) not working in 6.0
http://bugs.dragonflybsd.org/issues/3280#change-14096

* 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().

---Files--------------------------------
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