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 http://bugs.dragonflybsd.org/issues/3280#change-14098 * 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