Project

General

Profile

Actions

Bug #3280

open

KMS console and i915(4) not working in 6.0

Added by cmusser almost 3 years ago. Updated over 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Driver
Target version:
Start date:
06/01/2021
Due date:
% Done:

0%

Estimated time:

Description

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) 5.8-dmesg-after 5.8 dmesg, including after kldload i915 cmusser, 06/01/2021 09:25 AM
6.0-dmesg-after (108 KB) 6.0-dmesg-after 6.0 dmesg, including after kldload i915 cmusser, 06/01/2021 09:25 AM
6.1-messages-truncated (50.9 KB) 6.1-messages-truncated i915-ironlake-successful-drm.debug peeter, 06/06/2021 12:50 AM
6.1-var_log_messages (51.6 KB) 6.1-var_log_messages cmusser, 06/06/2021 01:02 PM
Actions #1

Updated by mneumann almost 3 years ago

Can you check this commit:

https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/b1122e3cbd55be825debb5766a4242317c71d40d

I am just guessing, but this changed in 6.0.

Actions #2

Updated by cmusser almost 3 years ago

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.

Actions #3

Updated by cmusser almost 3 years ago

Reading the code a little farther: drm_fb_helper_hotplug_event() actually calls __drm_fb_helper_initial_config_and_unlock(), but only if the fb_helper's deferred_setup flag is true, which it is not. Something is preventing the proper sequence from happening, but I don't understand yet what it is.

Actions #4

Updated by mneumann almost 3 years ago

On Tue, Jun 01, 2021 at 11:25:58AM -0700, 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.

Actions #5

Updated by peeter almost 3 years ago

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:

---
drm:pid900:drm_atomic_plane_check] CRTC set but no FB
[drm:pid900:drm_atomic_check_only] [PLANE:28:primary A] atomic core check failed
[drm:pid900:drm_atomic_state_default_clear] Clearing atomic state 0xfffff800d478cbc0
---

Actions #6

Updated by cmusser almost 3 years ago

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

Actions #7

Updated by peeter almost 3 years ago

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?

Actions #8

Updated by cmusser almost 3 years ago

master didn't work either. I'm attaching the /var/log/messages starting from when I did the kldload i915. It's largely similar, but I did not study it too closely for differences.

Actions #9

Updated by tuxillo over 2 years ago

  • Target version changed from 6.0 to 6.2
Actions

Also available in: Atom PDF