> 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. > > 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. 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. >> >> >>> >>> 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"