Bug 224825

Summary: Screen corruption booting 20171227 snapshot
Product: Base System Reporter: Mason Loring Bliss <mason>
Component: miscAssignee: Kyle Evans <kevans>
Status: Closed FIXED    
Severity: Affects Many People CC: debdrup, freebsdbugs, kevans, tsoome
Priority: --- Keywords: regression
Version: CURRENT   
Hardware: Any   
OS: Any   
Description Flags
Another screenshot
Video showing corruption
available modes via gop list and mode
OpenIndiana test
mode images none

Description Mason Loring Bliss 2018-01-01 18:00:01 UTC
Created attachment 189321 [details]

My hardware: Thinkpad T420, UEFI mode, Intel-only graphics.

Booting the 20171227 snapshot of -current, the screen's unusable. The boot menu comes up occupying a smaller fraction of the screen than normal, and then a mode switch happens and the screen becomes garbled and unusable.

By contrast, the 20171220 snapshot doesn't exhibit this behaviour.

mizhka thinks this might be his commit r327058. If it helps, I'm happy to test potential fixes on this machine, as it's largely a test platform anyway.

Attached are two screenshots and a short video showing the corruption.
Comment 1 Mason Loring Bliss 2018-01-01 18:01:13 UTC
Created attachment 189322 [details]
Another screenshot
Comment 2 Mason Loring Bliss 2018-01-01 18:01:55 UTC
Created attachment 189323 [details]
Video showing corruption
Comment 3 Toomas Soome freebsd_committer 2018-01-01 20:27:07 UTC
The problem is that you are getting GOP mode which is not working properly in framebuffer mode. You can try from loader OK prompt:

gop list  -- this will show supported modes, and 
gop set X -- to set the mode, then check if the console is still garbled.
Comment 4 Mason Loring Bliss 2018-01-01 21:02:48 UTC
Toomas, that works. Just saying "mode foo" also works.

Interesting is that "gop list" and "mode" give me different modes. I've not encountered either before last night and today, so I'm not sure what the difference is, or how selection is supposed to happen automatically. However, I can't say "mode 1" (shown by gop list).

"mode 0" lets me boot and doesn't corrupt the screen, incidentally. None of the other listed modes work.

Thank you for noting /boot/loader.rc.local on IRC. I'm more interested in just seeing the bug fixed than actually working around it at present. This box sees new software at a head-spinning pace so it won't be running FreeBSD for long.
Comment 5 Mason Loring Bliss 2018-01-01 21:04:33 UTC
Created attachment 189327 [details]
available modes via gop list and mode
Comment 6 Toomas Soome freebsd_committer 2018-01-01 21:48:02 UTC
mode command does manage the UEFI text terminal, which is built on top of GOP graphics mode. Now it is depending on UEFI implementation, if specific text mode change will also cause the GOP mode change or not.

Also note that this all may be fixed with firmware update, so it is good idea to check for firmware update...
Comment 7 Mason Loring Bliss 2018-01-02 20:45:20 UTC
Created attachment 189347 [details]
OpenIndiana test
Comment 8 Mason Loring Bliss 2018-01-02 22:30:12 UTC
Created attachment 189349 [details]
mode images
Comment 9 Mason Loring Bliss 2018-01-13 04:48:14 UTC
I wonder if we might revert r327058 until mode selection is better understood...?
Comment 10 Mason Loring Bliss 2018-02-05 00:17:06 UTC
I wonder if we might revert r327058 until mode selection is better understood...?
Comment 11 D. Ebdrup 2018-02-08 21:16:40 UTC
I don't think it'd be a problem if you bumped this from 'Affects Only Me' to 'Affects Other People', since I can confirm that I see this exact same behaviour on my T420, and it has been reported at least once (and I seem to recall more times, though I can't find them) on various social media like [1].

Once I get the Intel ME password removed, I'll try and see if I can add more information.

[1]: https://twitter.com/v_mfm_yss/status/961685497398558722
Comment 12 D. Ebdrup 2018-02-08 21:55:27 UTC
Turns out it was a lot less effort to reset the ME password, so in case any additional information needs to be had, I can provide it easily.
Comment 13 Philip Jocks 2018-02-11 12:13:09 UTC
ran into this today on an X220: https://twitter.com/FiLiS/status/962653003604996096
Comment 14 Mason Loring Bliss 2018-02-12 14:12:22 UTC
Bumping to "affects many people" as clearly it does.
Comment 15 Mason Loring Bliss 2018-03-19 16:18:57 UTC
I wonder if we might revert r327058 until mode selection is better understood...?
Comment 16 Kyle Evans freebsd_committer 2018-03-22 13:11:51 UTC
(In reply to Mason Loring Bliss from comment #15)

I've completely ripped out the mode selection stuff that was causing this and replaced it with a different method for choosing console resolution that should give us the same effect result without the regression. Please give anything after r331353 a test and let me know how it goes. =)
Comment 17 Mason Loring Bliss 2018-03-23 14:32:00 UTC
As noted on IRC, r331353 addresses the issue nicely. Thank you!

Also as noted on IRC, with this new method VMs end up with a vast screen size that makes VM consoles a bit difficult to use.

Thank you very much for correcting this.
Comment 18 commit-hook freebsd_committer 2018-03-23 21:03:08 UTC
A commit references this bug:

Author: kevans
Date: Fri Mar 23 21:02:46 UTC 2018
New revision: 331464
URL: https://svnweb.freebsd.org/changeset/base/331464

  efi loader: Respect efi_max_resolution in loader.conf(5)

  Default the max resolution to 1080p, we'll accept Width x Height
  specifications along with the following presets:

  - 480p
  - 720p
  - 1080p
  - 2160p or 4k
  - 5k

  PR:		224825
  Differential Revision:	https://reviews.freebsd.org/D14801

Comment 19 Mason Loring Bliss 2018-03-24 01:11:17 UTC
The latest changes make VM consoles usable, and my hardware is also happy. Thank you.

This can probably be closed, although it'd be nice to hear back from other folks who experienced it as well, on different hardware.