On 3/19/2020 5:55 PM, Toomas Soome via svn-src-head wrote: > > >> On 19. Mar 2020, at 14:33, Tomoaki AOKI <junch...@dec.sakura.ne.jp> wrote: >> >> On Thu, 19 Mar 2020 00:28:59 +0200 >> Toomas Soome <tso...@me.com <mailto:tso...@me.com>> wrote: >> >>> >>> >>>> On 18. Mar 2020, at 20:41, Ruslan Garipov <brigadi...@gmail.com> wrote: >>>> >>>> On 3/18/2020 10:29 PM, Toomas Soome via svn-src-head wrote: >>>>> >>>>> >>>>>> On 18. Mar 2020, at 18:40, Ruslan Garipov <brigadi...@gmail.com> wrote: >>>>>> >>>>>> On 3/17/2020 5:16 PM, Tomoaki AOKI wrote: >>>>>>> Hi! Thanks for your respond. >>>>>>> >>>>>>> Unfortunately, no. >>>>>>> I'm running on ThinkPad P52, which has no com connector installed. >>>>>>> No USB serial interface connected. >>>>>>> >>>>>>> `efi-show -g global -v ConOut` on loader prompt shows >>>>>>> >>>>>>> global NV,BS,RS ConOut = >>>>>>> PciRoot(0,0)/Pci((0x1,oxo)/Pci(0x0,0x0)/AcpiAdr(0x80010100) >>>>>>> >>>>>>> Moreover, my previous idea didn't help. >>>>>>> >>>>>>> Neither >>>>>>> console="vidconsole" >>>>>>> console="eficonsole" >>>>>>> console="efi_console" >>>>>>> nor >>>>>>> console="efi" >>>>>>> in /boot/loader.conf works. >>>>>>> >>>>>>> Defining / undefining TERM_EMU on build are untested. >>>>>>> >>>>>>> Is there any setting for /boot/loader.conf to control the behavior? >>>>>>> >>>>>>> >>>>>>> Regards. >>>>>>> >>>>>>> >>>>>>> On Mon, 16 Mar 2020 08:26:56 +0200 >>>>>>> Toomas Soome <tso...@me.com> wrote: >>>>>>> >>>>>>>> Hi! >>>>>>>> >>>>>>>> This means, your system has UART serial device 〓 you can check this >>>>>>>> from loader prompt: efi-show -g global -v ConOut or with efivar from >>>>>>>> running system. This would 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? >>>>>>>> >>>>>>>> rgds, >>>>>>>> toomas >>>>>>>> >>>>>>>>> On 15. Mar 2020, at 17:17, Tomoaki AOKI <junch...@dec.sakura.ne.jp> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi. >>>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> Reverting this fixes the issue. >>>>>> I got the same issue with loader menu when was upgrading from r358827 to >>>>>> r359028 (x86-64). >>>>>> >>>>>> 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.'' >>>>>> >>>>>> The virtual guests don't have any UART (even USB) serial devices in >>>>>> their settings. efi-show prints result similar to what Tomoaki got: >>>>>> >>>>>> OK efi-show -g global -v CounOut >>>>>> global NV,BS,RS ConOut = PciRoot(0x0)/Pci(0x2,0x0)/AcpiAdr(0x80014310) >>>>>> >>>>>> 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. >>>>>> >>>>>> Reverting this revision fix booting (and menu, of course). >>>>>> >>>>>> FreeBSD on physical hardware boots just fine with this revision, but has >>>>>> corrupted loader menu. >>>>>> >>>>>> 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. >>>>> >>>>> >>>>> Hi! >>>>> >>>>> 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’d like to get to the bottom of this. >>>> Hello! >>>> >>>> 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+= -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. Thanks, this fixed loader menu. At least on virtual machines. I couldn't check it on a physical one, because I failed to install graphics/drm-current-kmod kernel module from ports. But I think it will be ok there.
>> >> Many thanks! Worked fine for me, at least buildworld after `make clean` >> on /usr/src/stand. >> >> >> A bit details: >> Cleaning /usr/src/stand before building itself didn't help. >> Updating to r359099 and later was mandatory. >> No VMs are tested, as I'm currently not running any VMs. >> >> >> For your further investigation, kenv output is like this: > > > This output is not from patched loader, is it? Could you mail me from latest > — specifically, I’m expecting to see LINES and COLUMNS values. FreeBSD 13.0-CURRENT r359117 (VMware ESXi guest) shows: $ kenv | egrep "COLUMNS|LINES" COLUMNS="80" LINES="25" FreeBSD 13.0-CURRENT r359028 (physical machine) doesn't have that rows in kenv output at all. > > What seems to be the cause is, we allocate screen buffer for text, if that > allocation does fail, we did abort efi_cons_init() and the putchar did switch > to direct output without interpreting the esc sequences. Now the question > would be, why we failed to allocate the buffer - we do have 64MB heap as > default and console is initialized early… > > thanks, > toomas > >> >> === `kenv` output except hardware serial No. and UUID below === >> >> acpi.oem="LENOVO" >> acpi.revision="2" >> acpi.rsdp="0x000000004fd0e014" >> acpi.rsdt="0x000000004fd0c0c4" >> acpi.xsdt="0x000000004fd0c188" >> acpi.xsdt_length="36" >> bootenv_autolist="YES" >> bootenvs[0]="zfs:zsysS05/ROOT/head-r359007-boot1Rev6TA3" >> bootenvs[10]="zfs:zsysS05/ROOT/head-r358565-boot1Rev6TA3" >> bootenvs[11]="zfs:zsysS05/ROOT/" >> bootenvs[1]="zfs:zsysS05/ROOT/head-r359005-boot1Rev6TA3" >> bootenvs[2]="zfs:zsysS05/ROOT/head-r358989-boot1Rev6TA3" >> bootenvs[3]="zfs:zsysS05/ROOT/head-r358906-boot1Rev6TA3" >> bootenvs[4]="zfs:zsysS05/ROOT/head-r358872-boot1Rev6TA3" >> bootenvs[5]="zfs:zsysS05/ROOT/head-r358865-boot1Rev6TA3-2" >> bootenvs[6]="zfs:zsysS05/ROOT/head-r358827-boot1Rev6TA3" >> bootenvs[7]="zfs:zsysS05/ROOT/head-r358734-boot1Rev6TA3" >> bootenvs[8]="zfs:zsysS05/ROOT/head-r358729-boot1Rev6TA3" >> bootenvs[9]="zfs:zsysS05/ROOT/head-r358669-boot1Rev6TA3" >> bootenvs_count="12" >> bootfile="kernel" >> comconsole_pcidev="" >> comconsole_port="1016" >> comconsole_speed="9600" >> console="efi" >> currdev="zfs:zsysS05/ROOT/default:" >> efi-version="2.60" >> efi_max_resolution="2160p" >> hint.acpi.0.oem="LENOVO" >> hint.acpi.0.revision="2" >> hint.acpi.0.rsdp="0x000000004fd0e014" >> hint.acpi.0.rsdt="0x000000004fd0c0c4" >> hint.acpi.0.xsdt="0x000000004fd0c188" >> hint.acpi.0.xsdt_length="36" >> hint.acpi_throttle.0.disabled="1" >> hint.atkbd.0.at <http://hint.atkbd.0.at/>="atkbdc" >> hint.atkbd.0.irq="1" >> hint.atkbdc.0.at <http://hint.atkbdc.0.at/>="isa" >> hint.atkbdc.0.port="0x060" >> hint.atrtc.0.at <http://hint.atrtc.0.at/>="isa" >> hint.atrtc.0.irq="8" >> hint.atrtc.0.port="0x70" >> hint.attimer.0.at <http://hint.attimer.0.at/>="isa" >> hint.attimer.0.irq="0" >> hint.attimer.0.port="0x40" >> hint.fd.0.at <http://hint.fd.0.at/>="fdc0" >> hint.fd.0.drive="0" >> hint.fd.1.at <http://hint.fd.1.at/>="fdc0" >> hint.fd.1.drive="1" >> hint.fdc.0.at <http://hint.fdc.0.at/>="isa" >> hint.fdc.0.drq="2" >> hint.fdc.0.irq="6" >> hint.fdc.0.port="0x3F0" >> hint.p4tcc.0.disabled="1" >> hint.ppc.0.at <http://hint.ppc.0.at/>="isa" >> hint.ppc.0.irq="7" >> hint.psm.0.at <http://hint.psm.0.at/>="atkbdc" >> hint.psm.0.irq="12" >> hint.sc.0.at <http://hint.sc.0.at/>="isa" >> hint.sc.0.flags="0x100" >> hint.smbios.0.mem="0x4d580000" >> hint.uart.0.at <http://hint.uart.0.at/>="isa" >> hint.uart.0.flags="0x10" >> hint.uart.0.irq="4" >> hint.uart.0.port="0x3F8" >> hint.uart.1.at <http://hint.uart.1.at/>="isa" >> hint.uart.1.irq="3" >> hint.uart.1.port="0x2F8" >> hw.ata.atapi_dma="1" >> hw.ibrs_disable="0" >> hw.pci.allow_unsupported_io_range="1" >> hw.psm.elantech_support="1" >> hw.psm.trackpoint_support="1" >> kern.hz="8192" >> kern.ipc.semmni="40" >> kern.ipc.semmns="300" >> kern.ipc.shm_use_phys="1" >> kern.ipc.shmmni="1024" >> kern.ipc.shmseg="1024" >> kern.maxfiles="250000" >> kern.vty="vt" >> kernel="kernel" >> kernel_options="" >> kernel_path="/boot/kernel" >> kernelname="/boot/kernel/kernel" >> kernels="kernel kernel.old" >> kernels_autodetect="YES" >> loaddev="zfs:zsysS05/ROOT/default:" >> loader_conf_files="/boot/device.hints /boot/loader.conf >> /boot/loader.conf.local" >> machdep.mitigations.taa.enable="3" >> module_blacklist="drm drm2 radeonkms i915kms amdgpu" >> module_path="/boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays" >> net.graph.maxdata="65536" >> nextboot_conf="/boot/nextboot.conf" >> nextboot_enable="NO" >> script.lang="lua" >> smbios.bios.reldate="11/04/2019" >> smbios.bios.vendor="LENOVO" >> smbios.bios.version="N2CET48W (1.31 )" >> smbios.chassis.maker="LENOVO" >> smbios.chassis.serial="********" >> smbios.chassis.tag="No Asset Information" >> smbios.chassis.version="None" >> smbios.memory.enabled="33554432" >> smbios.planar.location="Not Available" >> smbios.planar.maker="LENOVO" >> smbios.planar.product="20M9CTO1WW" >> smbios.planar.serial="***********" >> smbios.planar.tag="Not Available" >> smbios.planar.version="SDK0J40697 WIN" >> smbios.socket.enabled="1" >> smbios.socket.populated="1" >> smbios.system.family="ThinkPad P52" >> smbios.system.maker="LENOVO" >> smbios.system.product="20M9CTO1WW" >> smbios.system.serial="********" >> smbios.system.sku="LENOVO_MT_20M9_BU_Think_FM_ThinkPad P52" >> smbios.system.uuid="********-****-****-****-************" >> smbios.system.version="ThinkPad P52" >> smbios.version="3.1" >> twiddle_divisor="1" >> verbose_loading="NO" >> vfs.root.mountfrom="zfs:zsysS05/ROOT/default" >> vfs.zfs.abd_chunk_size="1024" >> vfs.zfs.prefetch_disable="1" >> vm.pmap.pti="1" >> zfs_be_active="zfs:zsysS05/ROOT/default" >> zfs_be_currpage="1" >> zfs_be_root="zsysS05/ROOT" >> >> >> === `kenv` output except hardware serial No and UUID above === >> >> >>> >>> >>>> >>>>> >>>>> 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. >>>> 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 >>>> <http://bugs.freebsd.org/><http://bugs.freebsd.org/ >>>> <http://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. Francis Dupont created PR 244906 yesterday: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244906 I just added a comment there. >>> >>> >>>> >>>> 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 >>> >>>> >>>>> >>>>> rgds, >>>>> toomas >>>>> >>>>> >>>>>> >>>>>> [1] >>>>>> https://old.reddit.com/r/freebsd/comments/drxqlm/failed_to_do_efi_boot_on_a_vmware_virtual_machine/f6om6p2/ >>>>>> >>>>>> <https://old.reddit.com/r/freebsd/comments/drxqlm/failed_to_do_efi_boot_on_a_vmware_virtual_machine/f6om6p2/><https://old.reddit.com/r/freebsd/comments/drxqlm/failed_to_do_efi_boot_on_a_vmware_virtual_machine/f6om6p2/ >>>>>> >>>>>> <https://old.reddit.com/r/freebsd/comments/drxqlm/failed_to_do_efi_boot_on_a_vmware_virtual_machine/f6om6p2/>><https://old.reddit.com/r/freebsd/comments/drxqlm/failed_to_do_efi_boot_on_a_vmware_virtual_machine/f6om6p2/ >>>>>> >>>>>> <https://old.reddit.com/r/freebsd/comments/drxqlm/failed_to_do_efi_boot_on_a_vmware_virtual_machine/f6om6p2/><https://old.reddit.com/r/freebsd/comments/drxqlm/failed_to_do_efi_boot_on_a_vmware_virtual_machine/f6om6p2/ >>>>>> >>>>>> <https://old.reddit.com/r/freebsd/comments/drxqlm/failed_to_do_efi_boot_on_a_vmware_virtual_machine/f6om6p2/>>> >>>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Author: tsoome >>>>>>>>>> Date: Sat Mar 14 06:36:03 2020 >>>>>>>>>> New Revision: 358989 >>>>>>>>>> URL: https://svnweb.freebsd.org/changeset/base/358989 >>>>>>>>>> >>>>>>>>>> Log: >>>>>>>>>> loader: add comconsole implementation on top of SIO protocol >>>>>>>>>> >>>>>>>>>> Provide comconsole on top of SIO for arm platforms (x86 does use bios >>>>>>>>> version). >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> Modified: head/stand/efi/libefi/efi_console.c >>>>>>>>>> ============================================================================== >>>>>>>>>> --- 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 >>>>>>>>>> { >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> +/* >>>>>>>>>> + * Set up conin/conout/coninex to make sure we have input ready. >>>>>>>>>> + */ >>>>>>>>>> static void >>>>>>>>>> efi_cons_probe(struct console *cp) >>>>>>>>>> { >>>>>>>>>> + EFI_STATUS status; >>>>>>>>>> + >>>>>>>>>> + conout = ST->ConOut; >>>>>>>>>> + conin = ST->ConIn; >>>>>>>>>> + >>>>>>>>>> + status = BS->OpenProtocol(ST->ConsoleInHandle, >>>>>>>>> &simple_input_ex_guid, >>>>>>>>>> + (void **)&coninex, IH, NULL, >>>>>>>>> EFI_OPEN_PROTOCOL_GET_PROTOCOL); >>>>>>>>>> + if (status != EFI_SUCCESS) >>>>>>>>>> + coninex = NULL; >>>>>>>>>> + >>>>>>>>>> cp->c_flags |= C_PRESENTIN | C_PRESENTOUT; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> @@ -889,15 +902,7 @@ efi_cons_init(int arg) >>>>>>>>>> if (conin != NULL) >>>>>>>>>> return (0); >>>>>>>>>> >>>>>>>>>> - conout = ST->ConOut; >>>>>>>>>> - conin = ST->ConIn; >>>>>>>>>> - >>>>>>>>>> conout->EnableCursor(conout, TRUE); >>>>>>>>>> - status = BS->OpenProtocol(ST->ConsoleInHandle, >>>>>>>>> &simple_input_ex_guid, >>>>>>>>>> - (void **)&coninex, IH, NULL, >>>>>>>>> EFI_OPEN_PROTOCOL_GET_PROTOCOL); >>>>>>>>>> - if (status != EFI_SUCCESS) >>>>>>>>>> - coninex = NULL; >>>>>>>>>> - >>>>>>>>>> if (efi_cons_update_mode()) >>>>>>>>>> return (0); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Modified: head/stand/efi/loader/arch/arm/Makefile.inc >>>>>>>>>> ============================================================================== >>>>>>>>>> --- 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$ >>>>>>>>>> >>>>>>>>>> SRCS+= exec.c \ >>>>>>>>>> + efiserialio.c \ >>>>>>>>>> start.S >>>>>>>>>> >>>>>>>>>> HAVE_FDT=yes >>>>>>>>> >>>>>>>>> (Snip) >>>>>>>>> >>>>>>>>>> @@ -930,7 +936,6 @@ main(int argc, CHAR16 *argv[]) >>>>>>>>>> if (!has_kbd && (howto & RB_PROBE)) >>>>>>>>>> howto |= RB_SERIAL | RB_MULTIPLE; >>>>>>>>>> howto &= ~RB_PROBE; >>>>>>>>>> - uhowto = parse_uefi_con_out(); >>>>>>>>>> >>>>>>>>>> /* >>>>>>>>>> * Read additional environment variables from the boot device's >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Tomoaki AOKI <junch...@dec.sakura.ne.jp> >>> >> >> >> -- >> Tomoaki AOKI <junch...@dec.sakura.ne.jp >> <mailto:junch...@dec.sakura.ne.jp>> > > _______________________________________________ > svn-src-head@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" > _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"