Bug 224825 - Screen corruption booting 20171227 snapshot
Summary: Screen corruption booting 20171227 snapshot
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Many People
Assignee: Kyle Evans
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2018-01-01 18:00 UTC by Mason Loring Bliss
Modified: 2018-08-29 19:24 UTC (History)
4 users (show)

See Also:


Attachments
Screenshot (67.95 KB, image/jpeg)
2018-01-01 18:00 UTC, Mason Loring Bliss
no flags Details
Another screenshot (71.43 KB, image/jpeg)
2018-01-01 18:01 UTC, Mason Loring Bliss
no flags Details
Video showing corruption (617.43 KB, video/webm)
2018-01-01 18:01 UTC, Mason Loring Bliss
no flags Details
available modes via gop list and mode (163.46 KB, image/jpeg)
2018-01-01 21:04 UTC, Mason Loring Bliss
no flags Details
OpenIndiana test (94.28 KB, image/jpeg)
2018-01-02 20:45 UTC, Mason Loring Bliss
no flags Details
mode images (526.66 KB, application/x-gtar-compressed)
2018-01-02 22:30 UTC, Mason Loring Bliss
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mason Loring Bliss freebsd_triage 2018-01-01 18:00:01 UTC
Created attachment 189321 [details]
Screenshot

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 freebsd_triage 2018-01-01 18:01:13 UTC
Created attachment 189322 [details]
Another screenshot
Comment 2 Mason Loring Bliss freebsd_triage 2018-01-01 18:01:55 UTC
Created attachment 189323 [details]
Video showing corruption
Comment 3 Toomas Soome freebsd_committer freebsd_triage 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 freebsd_triage 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 freebsd_triage 2018-01-01 21:04:33 UTC
Created attachment 189327 [details]
available modes via gop list and mode
Comment 6 Toomas Soome freebsd_committer freebsd_triage 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 freebsd_triage 2018-01-02 20:45:20 UTC
Created attachment 189347 [details]
OpenIndiana test
Comment 8 Mason Loring Bliss freebsd_triage 2018-01-02 22:30:12 UTC
Created attachment 189349 [details]
mode images
Comment 9 Mason Loring Bliss freebsd_triage 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 freebsd_triage 2018-02-05 00:17:06 UTC
I wonder if we might revert r327058 until mode selection is better understood...?
Comment 11 Daniel Ebdrup Jensen freebsd_committer freebsd_triage 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 Daniel Ebdrup Jensen freebsd_committer freebsd_triage 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 FiLiS 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 freebsd_triage 2018-02-12 14:12:22 UTC
Bumping to "affects many people" as clearly it does.
Comment 15 Mason Loring Bliss freebsd_triage 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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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

Log:
  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

Changes:
  head/stand/defaults/loader.conf
  head/stand/efi/loader/framebuffer.c
Comment 19 Mason Loring Bliss freebsd_triage 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.