Date: Thu, 15 Feb 2018 19:10:51 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: svn-src-head@freebsd.org Cc: kevans@freebsd.org, mizhka@FreeBSD.org Subject: Re: svn commit: r327058 - head/stand/efi/boot1 Message-ID: <20180215191051.55cd6dd9b08d2715ca4e3e1f@dec.sakura.ne.jp>
next in thread | raw e-mail | index | archive | help
> On Thu, Dec 21, 2017 at 6:21 AM, Michael Zhilin <mizhka at freebsd.org> wrote: >> Author: mizhka >> Date: Thu Dec 21 12:21:35 2017 >> New Revision: 327058 >> URL: https://svnweb.freebsd.org/changeset/base/327058 >> >> Log: >> [boot/efi] scan all display modes rather than sequential try-fail way >> >> This patch allows to scan all display modes in boot1 as loader does. >> >> Before system tried to select optimal display mode by sequential scan of >> modes and if error then stop scanning. This way is not good, because >> if mode N is not present, mode N+1 may exist. >> >> In loader we use conout->Mode->MaxMode to identify maximum number of modes. >> This commit is to use same way in boot1 as in loader. >> >> Reported by: Andrey Pustovetov <andrey.pustovetov at gmail.com> >> Reviewed by: tsoome >> Differential Revision: https://reviews.freebsd.org/D13541 >> > > HI, > > Just FYI- we've had several reports of this doing the wrong thing for > many people, most recently by Allan yesterday (IIRC). I'm going to > avoid MFC'ing it, I think we should either back this out or figure out > where it's going wrong sooner rather than later. =( > > Thanks, > >Kyle Evans +1. I've been reporting back to mizhka@ what he wants off-list. (First report is on-list. [1]) Please wait MFC for this fixed, and, if possible, report below to mizhka@. *Output of "mode" command of loader console. *Video of broken boot process or photo of broken screen. *CPU model with integrated video. *Which mode worked and which isn't if specified by loader command. *Result of `got list` by loader command. *Result of `uga list` by loader command. As no one other than me posts negative comment to the commit mail here, I've not requested him to revert this. (Requested to do so if someone else reports problem.) FYI: For me, boot1 and loader screen are OK, but once kernel starts, broken screen. So vt (efifb) driver should be fixed to be aware of current (actual) screen mode. [1] https://lists.freebsd.org/pipermail/svn-src-head/2017-December/107598.html -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180215191051.55cd6dd9b08d2715ca4e3e1f>