Bug 224825
| Summary: | Screen corruption booting 20171227 snapshot | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Mason Loring Bliss <mason> | ||||||||||||||
| Component: | misc | Assignee: | Kyle Evans <kevans> | ||||||||||||||
| Status: | Closed FIXED | ||||||||||||||||
| Severity: | Affects Many People | CC: | debdrup, freebsdbugs, kevans, tsoome | ||||||||||||||
| Priority: | --- | Keywords: | regression | ||||||||||||||
| Version: | CURRENT | ||||||||||||||||
| Hardware: | Any | ||||||||||||||||
| OS: | Any | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
Created attachment 189322 [details]
Another screenshot
Created attachment 189323 [details]
Video showing corruption
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. 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. Created attachment 189327 [details]
available modes via gop list and mode
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... Created attachment 189347 [details]
OpenIndiana test
Created attachment 189349 [details]
mode images
I wonder if we might revert r327058 until mode selection is better understood...? I wonder if we might revert r327058 until mode selection is better understood...? 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 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. ran into this today on an X220: https://twitter.com/FiLiS/status/962653003604996096 Bumping to "affects many people" as clearly it does. I wonder if we might revert r327058 until mode selection is better understood...? (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. =) 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. 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 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. |
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.