Date: Thu, 19 Mar 2020 14:55:19 +0200 From: Toomas Soome <tsoome@me.com> To: junchoon@dec.sakura.ne.jp Cc: Ruslan Garipov <brigadir15@gmail.com>, svn-src-head@freebsd.org Subject: Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64 Message-ID: <BCBD8E38-32D5-42D2-B097-1CB2B4278B21@me.com> In-Reply-To: <20200319213329.f354314a9a72e1419d76d2ba@dec.sakura.ne.jp> 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> <EFDD40A1-3583-489A-9F4A-50BD19B5049E@me.com> <944c641f-b570-1420-6b63-96374217d795@gmail.com> <4ABF87AE-948F-43A8-940A-744FC2F4DE4D@me.com> <20200319213329.f354314a9a72e1419d76d2ba@dec.sakura.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 19. Mar 2020, at 14:33, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> = wrote: >=20 > On Thu, 19 Mar 2020 00:28:59 +0200 > Toomas Soome <tsoome@me.com <mailto:tsoome@me.com>> wrote: >=20 >>=20 >>=20 >>> On 18. Mar 2020, at 20:41, Ruslan Garipov <brigadir15@gmail.com> = 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 <brigadir15@gmail.com> = 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 <tsoome@me.com> 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 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? >>>>>>>=20 >>>>>>> rgds, >>>>>>> toomas >>>>>>>=20 >>>>>>>> On 15. Mar 2020, at 17:17, Tomoaki AOKI = <junchoon@dec.sakura.ne.jp> 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? >>=20 >>=20 >> Please try r359099. >=20 > Many thanks! Worked fine for me, at least buildworld after `make = clean` > on /usr/src/stand. >=20 >=20 > 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. >=20 >=20 > For your further investigation, kenv output is like this: This output is not from patched loader, is it? Could you mail me from = latest =E2=80=94 specifically, I=E2=80=99m expecting to see LINES and = COLUMNS values.=20 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=E2=80=A6 thanks, toomas >=20 > =3D=3D=3D `kenv` output except hardware serial No. and UUID below =3D=3D= =3D >=20 > acpi.oem=3D"LENOVO" > acpi.revision=3D"2" > acpi.rsdp=3D"0x000000004fd0e014" > acpi.rsdt=3D"0x000000004fd0c0c4" > acpi.xsdt=3D"0x000000004fd0c188" > acpi.xsdt_length=3D"36" > bootenv_autolist=3D"YES" > bootenvs[0]=3D"zfs:zsysS05/ROOT/head-r359007-boot1Rev6TA3" > bootenvs[10]=3D"zfs:zsysS05/ROOT/head-r358565-boot1Rev6TA3" > bootenvs[11]=3D"zfs:zsysS05/ROOT/" > bootenvs[1]=3D"zfs:zsysS05/ROOT/head-r359005-boot1Rev6TA3" > bootenvs[2]=3D"zfs:zsysS05/ROOT/head-r358989-boot1Rev6TA3" > bootenvs[3]=3D"zfs:zsysS05/ROOT/head-r358906-boot1Rev6TA3" > bootenvs[4]=3D"zfs:zsysS05/ROOT/head-r358872-boot1Rev6TA3" > bootenvs[5]=3D"zfs:zsysS05/ROOT/head-r358865-boot1Rev6TA3-2" > bootenvs[6]=3D"zfs:zsysS05/ROOT/head-r358827-boot1Rev6TA3" > bootenvs[7]=3D"zfs:zsysS05/ROOT/head-r358734-boot1Rev6TA3" > bootenvs[8]=3D"zfs:zsysS05/ROOT/head-r358729-boot1Rev6TA3" > bootenvs[9]=3D"zfs:zsysS05/ROOT/head-r358669-boot1Rev6TA3" > bootenvs_count=3D"12" > bootfile=3D"kernel" > comconsole_pcidev=3D"" > comconsole_port=3D"1016" > comconsole_speed=3D"9600" > console=3D"efi" > currdev=3D"zfs:zsysS05/ROOT/default:" > efi-version=3D"2.60" > efi_max_resolution=3D"2160p" > hint.acpi.0.oem=3D"LENOVO" > hint.acpi.0.revision=3D"2" > hint.acpi.0.rsdp=3D"0x000000004fd0e014" > hint.acpi.0.rsdt=3D"0x000000004fd0c0c4" > hint.acpi.0.xsdt=3D"0x000000004fd0c188" > hint.acpi.0.xsdt_length=3D"36" > hint.acpi_throttle.0.disabled=3D"1" > hint.atkbd.0.at <http://hint.atkbd.0.at/>=3D"atkbdc" > hint.atkbd.0.irq=3D"1" > hint.atkbdc.0.at <http://hint.atkbdc.0.at/>=3D"isa" > hint.atkbdc.0.port=3D"0x060" > hint.atrtc.0.at <http://hint.atrtc.0.at/>=3D"isa" > hint.atrtc.0.irq=3D"8" > hint.atrtc.0.port=3D"0x70" > hint.attimer.0.at <http://hint.attimer.0.at/>=3D"isa" > hint.attimer.0.irq=3D"0" > hint.attimer.0.port=3D"0x40" > hint.fd.0.at <http://hint.fd.0.at/>=3D"fdc0" > hint.fd.0.drive=3D"0" > hint.fd.1.at <http://hint.fd.1.at/>=3D"fdc0" > hint.fd.1.drive=3D"1" > hint.fdc.0.at <http://hint.fdc.0.at/>=3D"isa" > hint.fdc.0.drq=3D"2" > hint.fdc.0.irq=3D"6" > hint.fdc.0.port=3D"0x3F0" > hint.p4tcc.0.disabled=3D"1" > hint.ppc.0.at <http://hint.ppc.0.at/>=3D"isa" > hint.ppc.0.irq=3D"7" > hint.psm.0.at <http://hint.psm.0.at/>=3D"atkbdc" > hint.psm.0.irq=3D"12" > hint.sc.0.at <http://hint.sc.0.at/>=3D"isa" > hint.sc.0.flags=3D"0x100" > hint.smbios.0.mem=3D"0x4d580000" > hint.uart.0.at <http://hint.uart.0.at/>=3D"isa" > hint.uart.0.flags=3D"0x10" > hint.uart.0.irq=3D"4" > hint.uart.0.port=3D"0x3F8" > hint.uart.1.at <http://hint.uart.1.at/>=3D"isa" > hint.uart.1.irq=3D"3" > hint.uart.1.port=3D"0x2F8" > hw.ata.atapi_dma=3D"1" > hw.ibrs_disable=3D"0" > hw.pci.allow_unsupported_io_range=3D"1" > hw.psm.elantech_support=3D"1" > hw.psm.trackpoint_support=3D"1" > kern.hz=3D"8192" > kern.ipc.semmni=3D"40" > kern.ipc.semmns=3D"300" > kern.ipc.shm_use_phys=3D"1" > kern.ipc.shmmni=3D"1024" > kern.ipc.shmseg=3D"1024" > kern.maxfiles=3D"250000" > kern.vty=3D"vt" > kernel=3D"kernel" > kernel_options=3D"" > kernel_path=3D"/boot/kernel" > kernelname=3D"/boot/kernel/kernel" > kernels=3D"kernel kernel.old" > kernels_autodetect=3D"YES" > loaddev=3D"zfs:zsysS05/ROOT/default:" > loader_conf_files=3D"/boot/device.hints /boot/loader.conf = /boot/loader.conf.local" > machdep.mitigations.taa.enable=3D"3" > module_blacklist=3D"drm drm2 radeonkms i915kms amdgpu" > module_path=3D"/boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays" > net.graph.maxdata=3D"65536" > nextboot_conf=3D"/boot/nextboot.conf" > nextboot_enable=3D"NO" > script.lang=3D"lua" > smbios.bios.reldate=3D"11/04/2019" > smbios.bios.vendor=3D"LENOVO" > smbios.bios.version=3D"N2CET48W (1.31 )" > smbios.chassis.maker=3D"LENOVO" > smbios.chassis.serial=3D"********" > smbios.chassis.tag=3D"No Asset Information" > smbios.chassis.version=3D"None" > smbios.memory.enabled=3D"33554432" > smbios.planar.location=3D"Not Available" > smbios.planar.maker=3D"LENOVO" > smbios.planar.product=3D"20M9CTO1WW" > smbios.planar.serial=3D"***********" > smbios.planar.tag=3D"Not Available" > smbios.planar.version=3D"SDK0J40697 WIN" > smbios.socket.enabled=3D"1" > smbios.socket.populated=3D"1" > smbios.system.family=3D"ThinkPad P52" > smbios.system.maker=3D"LENOVO" > smbios.system.product=3D"20M9CTO1WW" > smbios.system.serial=3D"********" > smbios.system.sku=3D"LENOVO_MT_20M9_BU_Think_FM_ThinkPad P52" > smbios.system.uuid=3D"********-****-****-****-************" > smbios.system.version=3D"ThinkPad P52" > smbios.version=3D"3.1" > twiddle_divisor=3D"1" > verbose_loading=3D"NO" > vfs.root.mountfrom=3D"zfs:zsysS05/ROOT/default" > vfs.zfs.abd_chunk_size=3D"1024" > vfs.zfs.prefetch_disable=3D"1" > vm.pmap.pti=3D"1" > zfs_be_active=3D"zfs:zsysS05/ROOT/default" > zfs_be_currpage=3D"1" > zfs_be_root=3D"zsysS05/ROOT" >=20 >=20 > =3D=3D=3D `kenv` output except hardware serial No and UUID above =3D=3D=3D= >=20 >=20 >>=20 >>=20 >>>=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 = <http://bugs.freebsd.org/><http://bugs.freebsd.org/ = <http://bugs.freebsd.org/>>? >>=20 >>=20 >> 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 >>=20 >>>=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. >>=20 >> BIOS version is ok. >>=20 >> rgds, >> toomas >>=20 >>>=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/ = <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/comme= nts/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/comm= ents/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/comme= nts/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/>>> >>>>>>>>=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 <junchoon@dec.sakura.ne.jp> >>=20 >=20 >=20 > --=20 > Tomoaki AOKI <junchoon@dec.sakura.ne.jp = <mailto:junchoon@dec.sakura.ne.jp>>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BCBD8E38-32D5-42D2-B097-1CB2B4278B21>