6.0 and console on ThinkPad x220

[Chuck Musser]

I worked on troubleshooting this, but didn't get very far.

For both 5.8 and 6.0, I set drm.debug to 0x777, booted the system, and
then kldloaded i915. I captured dmesg to a file in both cases for later
perusal. They are somewhat different: 6.0 does print more stuff and it
has couple warning messages that 5.8 doesn't show. Not sure what's the
best way to transmit those. Should I just attach files to the mail I
send to the list? 

The warning messages are about the framebuffer (or lack of it). These
two are of interest:
WARNING !set->fb failed at
/usr/src/sys/dev/drm/drm/../drm_atomic_helper.c:2750 

and a bit later: 

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

I tried to understand the control flow a bit better by putting some
additional trace messages in the drm modules and rebuilding with 'make
quickkernel' and 'make installkernel'. My traces did not appear in dmesg
after a reboot which is either because the traces are in the wrong place
or I am not actually running the kernel I expect. The 'uname' command
and the messages at the start of dmesg contain a date is in the past,
but I expected that date to be the date I built the kernel, i.e. right
now.

Chuck 

On 2021-05-24 00:34, karu.pruun wrote:

> Yes you can try all the gop modes and see if any of them work fine.
> Choosing a different mode means allocating a different framebuffer,
> with a different size, at boot.
> 
> So the main idea how this works is as follows. The syscons driver that
> you see working when in console is based on two other drivers, a
> keyboard and a video driver. The video driver is either vga or a drm
> driver, i915 or radeon. When the machine boots, syscons first uses the
> vga driver. The latter also takes the framebuffer (fb) that UEFI has
> set up while booting.
> 
> Enter drm/i915. At loading i915, the i915 sets up a new fb and
> registers it with the syscons. But something apparently goes wrong
> with this; and as your test showed, it did work in dragonfly 5.8.
> 
> There are two routines that carry out the bulk of the work in setting up the fb:
> 
> (1) drm_fb_helper.c: drm_fb_helper_single_fb_probe()
> (2) intel_fbdev.c: intelfb_create()
> 
> Actually, (1) calls (2). At the end of (1), register_framebuffer() is
> called, this tells syscons to use the newly allocated fb.
> 
> Both (1) and (2) have changed from 5.8 to 6.0. We just need to figure
> out what fails in those two functions.
> 
> Later in the week, I can try pulling out an older intel machine and
> see if I can replicate the problem. If yes, then we can hopefully
> figure out a patch. If not, then I can send you a couple of patches to
> test what fails.
> 
> Alternatively, if you feel like you can try chase down the problem in
> the two routines, and possibly in others called by them. It would be
> easiest if you could compare the output of debugging of 5.8 and 6.0
> --- then you could see where the calculations deviate. If you see
> garbage output on the screen, then it might mean that the address of
> fb is at least partially right, but possibly other parameters (e.g.
> pitch, ie the number of bytes that are in each row on screen) are
> wrong.
> 
> Peeter
> 
> --
> 
> On Sun, May 23, 2021 at 7:58 PM Chuck Musser <cmusser at sonic.net> wrote: 
> I couldn't complete all the tests you mention, but here's what I found:
> 
> (1) whether 5.8 with UEFI still works fine. You can boot the 5.8 img
> in the UEFI mode and load i915 manually. 
> Using USB sticks with 5.8 and 6.0 images, I booted the system via UEFI,
> logged in as root, and then attempted to 'kldload i915'. 5.8
> successfully
> switched into a framebuffer console (is that the term people use?). 6.0
> garbled the top half of the screen, as described earlier.
> 
> (2) Also, can you try if 6.0 boots in the legacy BIOS mode, and then
> load i915 manually. 
> I couldn't get it to  boot. What I did was put the system back into
> "legacy" (BIOS) boot mode and tried booting from the stick. I ran
> into "couldn't mount rootvp". There was some discussion about this
> at some point, having do do with disabling the ehci driver. I did
> try that, but no luck.
> 
> The fact that console output stops at that point seems to indicate
> that i915 has not succeeded in correctly setting up the framebuffer
> for the console driver (syscons). 
> Out of curiosity, how does the "gop set" command issued in the loader
> affect this? Maybe I did not try enough of the valid values to hit
> one that would make it work. 
> Just an idle thought: did you update the DragonFly UEFI loader image
> when you upgraded to 6.0? It should not matter, but better be safe.
> You can do this by mounting the EFI partition and copying over the
> /boot/boot1.efi to the correct location. 
> Yes I did do that after I did the upgrade because I figured that this
> was something that the upgrade might not be able to touch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20210527/6b6bec64/attachment-0002.htm>