svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64
Toomas Soome
tsoome at me.com
Thu Mar 19 12:55:30 UTC 2020
> On 19. Mar 2020, at 14:33, Tomoaki AOKI <junchoon at dec.sakura.ne.jp> wrote:
>
> On Thu, 19 Mar 2020 00:28:59 +0200
> Toomas Soome <tsoome at me.com <mailto:tsoome at me.com>> wrote:
>
>>
>>
>>> On 18. Mar 2020, at 20:41, Ruslan Garipov <brigadir15 at 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 <brigadir15 at 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 <tsoome at 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 <junchoon at 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 <junchoon at dec.sakura.ne.jp>
>>
>
>
> --
> Tomoaki AOKI <junchoon at dec.sakura.ne.jp <mailto:junchoon at dec.sakura.ne.jp>>
More information about the svn-src-head
mailing list