From owner-svn-src-head@freebsd.org Wed Mar 18 22:29:12 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 11A8F26F40F for ; Wed, 18 Mar 2020 22:29:12 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv50p00im-ztdg10021201.me.com (pv50p00im-ztdg10021201.me.com [17.58.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48jPpY2vGvz4BYP for ; Wed, 18 Mar 2020 22:29:09 +0000 (UTC) (envelope-from tsoome@me.com) Received: from nazgul.lan (148-52-235-80.sta.estpak.ee [80.235.52.148]) by pv50p00im-ztdg10021201.me.com (Postfix) with ESMTPSA id B0E28A40649; Wed, 18 Mar 2020 22:29:05 +0000 (UTC) From: Toomas Soome Message-Id: <4ABF87AE-948F-43A8-940A-744FC2F4DE4D@me.com> Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64 Date: Thu, 19 Mar 2020 00:28:59 +0200 In-Reply-To: <944c641f-b570-1420-6b63-96374217d795@gmail.com> Cc: svn-src-head@freebsd.org, junchoon@dec.sakura.ne.jp To: Ruslan Garipov References: <20200316001745.07df62f72d647b924b657d86@dec.sakura.ne.jp> <746EE981-536F-49AD-9B76-F9F103ECB1F9@me.com> <20200317211614.bbe1b18a32d7863941fffbe8@dec.sakura.ne.jp> <55b1f91b-6157-bfee-cd74-124ed50bc663@gmail.com> <944c641f-b570-1420-6b63-96374217d795@gmail.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-03-18_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2003180097 X-Rspamd-Queue-Id: 48jPpY2vGvz4BYP X-Spamd-Bar: - X-Spamd-Result: default: False [-1.93 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; MV_CASE(0.50)[]; URI_COUNT_ODD(1.00)[13]; DKIM_TRACE(0.00)[me.com:+]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; FREEMAIL_TO(0.00)[gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[148.52.235.80.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; RCVD_IN_DNSWL_LOW(-0.10)[45.6.58.17.list.dnswl.org : 127.0.5.1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[me.com]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; NEURAL_HAM_MEDIUM(-0.34)[-0.337,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-0.995,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE(0.00)[ip: (-3.91), ipnet: 17.58.0.0/20(-2.00), asn: 714(-2.38), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; DWL_DNSWL_LOW(-1.00)[me.com.dwl.dnswl.org : 127.0.5.1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 22:29:12 -0000 > On 18. Mar 2020, at 20:41, Ruslan Garipov = wrote: >=20 > On 3/18/2020 10:29 PM, Toomas Soome via svn-src-head wrote: >>=20 >>=20 >>> On 18. Mar 2020, at 18:40, Ruslan Garipov = wrote: >>>=20 >>> On 3/17/2020 5:16 PM, Tomoaki AOKI wrote: >>>> Hi! Thanks for your respond. >>>>=20 >>>> Unfortunately, no. >>>> I'm running on ThinkPad P52, which has no com connector installed. >>>> No USB serial interface connected. >>>>=20 >>>> `efi-show -g global -v ConOut` on loader prompt shows >>>>=20 >>>> global NV,BS,RS ConOut =3D >>>> PciRoot(0,0)/Pci((0x1,oxo)/Pci(0x0,0x0)/AcpiAdr(0x80010100) >>>>=20 >>>> Moreover, my previous idea didn't help. >>>>=20 >>>> Neither >>>> console=3D"vidconsole" >>>> console=3D"eficonsole" >>>> console=3D"efi_console" >>>> nor >>>> console=3D"efi" >>>> in /boot/loader.conf works. >>>>=20 >>>> Defining / undefining TERM_EMU on build are untested. >>>>=20 >>>> Is there any setting for /boot/loader.conf to control the behavior? >>>>=20 >>>>=20 >>>> Regards. >>>>=20 >>>>=20 >>>> On Mon, 16 Mar 2020 08:26:56 +0200 >>>> Toomas Soome wrote: >>>>=20 >>>>> Hi! >>>>>=20 >>>>> This means, your system has UART serial device =E3=80=93 you can = check this from loader prompt: efi-show -g global -v ConOut or with = efivar from running system. This w ould trigger efi = console driver to use TERM_EMU, which can be turned off by user and = doing that would cause ESC sequences to be passed directly to console. = Might that be true in your case? >>>>>=20 >>>>> rgds, >>>>> toomas >>>>>=20 >>>>>> On 15. Mar 2020, at 17:17, Tomoaki AOKI = wrote: >>>>>>=20 >>>>>> Hi. >>>>>>=20 >>>>>> This broke loader menu display on efifb. At least on amd64. >>>>>> ESC sequences without ESC character are shown. >>>>>> Key input (at least 1, 2 and enter) works OK. >>>>>> I suspect outputs for SIO is sent to efifb and ESC codes are = ignored. >>>>>>=20 >>>>>> Reverting this fixes the issue. >>> I got the same issue with loader menu when was upgrading from = r358827 to >>> r359028 (x86-64). >>>=20 >>> But unfortunately the broken menu is just a part of my problem. The >>> real pain is that a FreeBSD 13.0-CURRENT system hosted by VMware = ESXi or >>> Workstation doesn't boot anymore after r358989. An ugly = workaround[1] >>> (exiting from the loader menu into the loader prompt, running ls or >>> show, scrolling the result down and then executing boot) I found = some >>> time ago doesn't work anymore. After running boot/boot -s/selecting >>> menu item, a hypervisor just shuts session down with the following >>> message: ``The firmware encountered an unexpected exception. The = virtual >>> machine cannot boot.'' >>>=20 >>> The virtual guests don't have any UART (even USB) serial devices in >>> their settings. efi-show prints result similar to what Tomoaki got: >>>=20 >>> OK efi-show -g global -v CounOut >>> global NV,BS,RS ConOut =3D = PciRoot(0x0)/Pci(0x2,0x0)/AcpiAdr(0x80014310) >>>=20 >>> Undefining TERM_EMU doesn't help. I had completely removed CFLAGS >>> assignment with TERM_EMU from stand/efi/libefi/Makefile and rebuilt >>> kernel/world -- nothing changed. I don't define TERM_EMU in my >>> make.conf or/and src.conf. >>>=20 >>> Reverting this revision fix booting (and menu, of course). >>>=20 >>> FreeBSD on physical hardware boots just fine with this revision, but = has >>> corrupted loader menu. >>>=20 >>> Toomas, please help us to fix this. I can live with the broken = menu, >>> but I don't want to revert this revision every time I will upgrade = my >>> virtual machines after r359028 now. >>=20 >>=20 >> Hi! >>=20 >> The build, are you doing build with -DNO_CLEAN? or can you run make = clean in stand and then build it again? Otherwise, if you can poke me on = irc, I=E2=80=99d like to get to the bottom of this. > Hello! >=20 > I'm sorry, currently I have no access to either IRC, nor my build > machine. Therefore, I can't show you the build log. NO_CLEAN -- no, = I > don't use it. What I've actually done regarding to testing TERM_EMU: = I > removed `CFLAGS+=3D -DTERM_EMU` (and the .if condition wrapping this = line) > from the Makefile, removed /usr/obj directory, and buildworld and > buildkernel then. And then install rebuilt kernel/userland on a = target > machine. Nothing changed, but it should? Please try r359099. >=20 >>=20 >> Regarding the issue with vm, I am afraid the roots are going much = deeper there. I have not got to the exact cause (and therefore a fix), = but the problem is not about this specific patch. The problem is about = memory map, specifically one just before and after we switch off Boot = Services.=20 > That's a very bad news for me. Looking at HEAD's commit list I hope > that's a known problem? Or should I open a PR on bugs.FreeBSD.org = ? PR is always good idea. Finding the exact cause and getting sure fix is = question of time. I have done quite amount of investigation, but I can = not yet point the finger even as there is one known issue identified. = *IF* I am correct about the issue, the fix will take some time as it is = not too trivial. >=20 > Moreover, I believe the next snapshot of the CURRENT (which will be = made > after r358989) made by the release team will be unbootable on VMware > hypervisors. BIOS version is ok. rgds, toomas >=20 >>=20 >> rgds, >> toomas >>=20 >>=20 >>>=20 >>> [1] >>> = https://old.reddit.com/r/freebsd/comments/drxqlm/failed_to_do_efi_boot_on_= a_vmware_virtual_machine/f6om6p2/ = > >>>>>>=20 >>>>>> Not tried (not enough time for now as I'm mainly using = stable/12), >>>>>> but possibly calling efi_cons_probe() from efi_cons_init() would = be >>>>>> needed, as ome codes are moved from the latter to the former. >>>>>>=20 >>>>>>=20 >>>>>>> Author: tsoome >>>>>>> Date: Sat Mar 14 06:36:03 2020 >>>>>>> New Revision: 358989 >>>>>>> URL: https://svnweb.freebsd.org/changeset/base/358989 >>>>>>>=20 >>>>>>> Log: >>>>>>> loader: add comconsole implementation on top of SIO protocol >>>>>>>=20 >>>>>>> Provide comconsole on top of SIO for arm platforms (x86 does use = bios >>>>>> version). >>>>>>>=20 >>>>>>> Added: >>>>>>> head/stand/efi/loader/efiserialio.c (contents, props changed) >>>>>>> Modified: >>>>>>> head/stand/efi/libefi/efi_console.c >>>>>>> head/stand/efi/loader/arch/arm/Makefile.inc >>>>>>> head/stand/efi/loader/arch/arm64/Makefile.inc >>>>>>> head/stand/efi/loader/conf.c >>>>>>> head/stand/efi/loader/main.c >>>>>>>=20 >>>>>>> Modified: head/stand/efi/libefi/efi_console.c >>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>>>> --- head/stand/efi/libefi/efi_console.c Sat Mar 14 05:57:22 >>>>>> 2020 (r358988) >>>>>>> +++ head/stand/efi/libefi/efi_console.c >>>>>> Sat Mar 14 06:36:03 2020 (r358989) >>>>>>> @@ -377,9 +377,22 @@ efi_cons_respond(void *s __unused, const = void *buf __u >>>>>>> { >>>>>>> } >>>>>>>=20 >>>>>>> +/* >>>>>>> + * Set up conin/conout/coninex to make sure we have input = ready. >>>>>>> + */ >>>>>>> static void >>>>>>> efi_cons_probe(struct console *cp) >>>>>>> { >>>>>>> + EFI_STATUS status; >>>>>>> + >>>>>>> + conout =3D ST->ConOut; >>>>>>> + conin =3D ST->ConIn; >>>>>>> + >>>>>>> + status =3D BS->OpenProtocol(ST->ConsoleInHandle, >>>>>> &simple_input_ex_guid, >>>>>>> + (void **)&coninex, IH, NULL, >>>>>> EFI_OPEN_PROTOCOL_GET_PROTOCOL); >>>>>>> + if (status !=3D EFI_SUCCESS) >>>>>>> + coninex =3D NULL; >>>>>>> + >>>>>>> cp->c_flags |=3D C_PRESENTIN | C_PRESENTOUT; >>>>>>> } >>>>>>>=20 >>>>>>> @@ -889,15 +902,7 @@ efi_cons_init(int arg) >>>>>>> if (conin !=3D NULL) >>>>>>> return (0); >>>>>>>=20 >>>>>>> - conout =3D ST->ConOut; >>>>>>> - conin =3D ST->ConIn; >>>>>>> - >>>>>>> conout->EnableCursor(conout, TRUE); >>>>>>> - status =3D BS->OpenProtocol(ST->ConsoleInHandle, >>>>>> &simple_input_ex_guid, >>>>>>> - (void **)&coninex, IH, NULL, >>>>>> EFI_OPEN_PROTOCOL_GET_PROTOCOL); >>>>>>> - if (status !=3D EFI_SUCCESS) >>>>>>> - coninex =3D NULL; >>>>>>> - >>>>>>> if (efi_cons_update_mode()) >>>>>>> return (0); >>>>>>>=20 >>>>>>>=20 >>>>>>> Modified: head/stand/efi/loader/arch/arm/Makefile.inc >>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>>>> --- head/stand/efi/loader/arch/arm/Makefile.inc Sat Mar 14 >>>>>> 05:57:22 2020 (r358988) >>>>>>> +++ head/stand/efi/loader/arch/arm/Makefile.inc Sat Mar 14 = 06:36:03 >>>>>> 2020 (r358989) >>>>>>> @@ -1,6 +1,7 @@ >>>>>>> # $FreeBSD$ >>>>>>>=20 >>>>>>> SRCS+=3D exec.c \ >>>>>>> + efiserialio.c \ >>>>>>> start.S >>>>>>>=20 >>>>>>> HAVE_FDT=3Dyes >>>>>>=20 >>>>>> (Snip) >>>>>>=20 >>>>>>> @@ -930,7 +936,6 @@ main(int argc, CHAR16 *argv[]) >>>>>>> if (!has_kbd && (howto & RB_PROBE)) >>>>>>> howto |=3D RB_SERIAL | RB_MULTIPLE; >>>>>>> howto &=3D ~RB_PROBE; >>>>>>> - uhowto =3D parse_uefi_con_out(); >>>>>>>=20 >>>>>>> /* >>>>>>> * Read additional environment variables from the boot = device's >>>>>>=20 >>>>>> --=20 >>>>>> Tomoaki AOKI