loader.efi hang on Quanta D52B

I have a Quanta D52B-1U server which hangs during FreeBSD UEFI boot when the COM ports on the motherboard are enabled. I've tested booting from NVMe SSDs and several FreeBSD ISO images (14.1 and 15.0-snap (bootonly and disc1)). Here is a screen capture where it hangs:

D52B-1U hang when SOL.png


I think this point is where loader.efi is initializing the console. I think it hangs here because loader.efi expects the console on COM 1. On this server, the serial console is on COM 2, so it fails initialization.

One of the workarounds (boot in CSM / Legacy mode) is mostly a non-starter since my boot disks are NVMe drives (no legacy BIOS). I've worked around issues like this in the past by booting off a USB or SATADOM and then handing off the boot process to the ZFS, but that bit of added complexity has a way of coming back and biting one during future maintenance (OS upgrades).

Another workaround is disabling the COM ports. I can then boot off the FreeBSD ISOs, my local disks, and I have the BMC KVM for console access. The down side is that I can't get a Serial Over Lan, which is a really nice feature. Having a SOL has enabled me to rescue several servers days sooner, when I was away from high speed internet and large screens.

The last workaround I've found is setting
Code:
console="comconsole"
in loader.conf. This specifically excludes "efi" from the console menu and makes serial the primary output. Since I can't modify loader.conf on a FreeBSD ISO, this means booting off install media still hangs. On my local disks where I've configured loader.conf, it lets me enable SOL. Because loader.efi defaults to COM 1 for serial, I also have to set comconsole_port="0x2F8" and comconsole_speed="115200".

The motherboard chipset is Intel C621 & C624 with Skylake CPUs. Dmesg output is here. The results are the same whether SOL is enabled or disabled.

The contents of the EFI variable ConOut with COM ports disabled:

# efivar -p -d 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut
: PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010100)

With console ports enabled and console="comconsole":

# efivar -p -d 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut
: PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010100),/PciRoot(0x0)/Pci(0x1f,0x0)/Serial(0x0)/Uart(115200,8,N,1)/UartFlowCtrl(Hardware)/VenUtf8(),/PciRoot(0x0)/Pci(0x1f,0x0)/Serial(0x1)/Uart(115200,8,N,1)/UartFlowCtrl(Hardware)/VenUtf8()

All of this very much like the description over at https://wiki.freebsd.org/SerialConsole, except that I'm booting EFI and there's a poor interaction between loader.efi and my hardware which causes the boot process to screech to a halt. Is there anything left for me to try?
 
Probably /boot/device.hints need an entry.
Check the addresses of the COM ports. Are they standard addresses? 2F8 ect.....
 
Make sure you set "console=efi" for your serial port setting in /boot/loader.conf

You can try commenting out the serial console uart settings if it uses a non-standard serial address..

Code:
hint.sc.0.at="isa"
hint.sc.0.flags="0x100"
hint.uart.0.at="isa"
hint.uart.0.port="0x3F8"
hint.uart.0.flags="0x10"
hint.uart.0.irq="4"
hint.uart.1.at="isa"
hint.uart.1.port="0x2F8"
hint.uart.1.irq="3"
 
I find it strange your dmesg output shows no uarts. That could be the problem.
Are you sure the port is enabled in this cloud servers BIOS?

You should see something like this;
Code:
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
uart1: console (115200,n,8,1)
 
How about you tell it where console is in /boot/loader.conf
Setting the port is indeed necessary and I have done so, as I mentioned in paragraph 5.

Make sure you set "console=efi" for your serial port setting in /boot/loader.conf
Nope. Setting console="efi" with the COM ports enabled in BIOS freezes loader.efi. Every time. The only way this system can EFI boot FreeBSD is if console is defined and excludes "efi."

The device hints apply to the kernel, but we don't get to loading the kernel because loader.efi hangs first. FreeBSD hangs before the boot loader prompt / menu.
 
I find it strange your dmesg output shows no uarts.

That's likely because I hadn't yet discovered that I could get FreeBSD booted with the COM ports enabled, by excluding "efi" from console in loader.conf.

Code:
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 on acpi0
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0
uart1: console (115200,n,8,1)

Also of interest, the server has a single external COM port. There's not even a header for a 2nd physical COM port on the motherboard, so COM 2 is virtual and it's almost married to the BMCs Serial Over LAN feature.
 
I think it hangs here because loader.efi expects the console on COM 1. On this server, the serial console is on COM 2, so it fails initialization.
the server has a single external COM port. There's not even a header for a 2nd physical COM port on the motherboard, so COM 2 is virtual

I don't know if this is related to the issue, there is a reference in the source code of stand/efi/loader/main.c in the comments about dual-console situation failing. See also the other comments about "console":
Rich (BB code):
727  * Parse ConOut (the list of consoles active) and see if we can find a
728  * serial port and/or a video port. It would be nice to also walk the
729  * ACPI name space to map the UID for the serial port to a port. The
730  * latter is especially hard. Also check for ConIn as well. This will
731  * be enough to determine if we have serial, and if we don't, we default
732  * to video. If there's a dual-console situation with ConIn, this will
733  * currently fail.

The last workaround I've found is setting
Code:
console="comconsole"
in loader.conf. This specifically excludes "efi" from the console menu and makes serial the primary output. Since I can't modify loader.conf on a FreeBSD ISO, this means booting off install media still hangs.
Modifying a ISO isn't a problem. You can add the workaround to the FreeBSD ISO file by extracting the ISO, edit /boot/loader.conf, rebuild ISO. See "BUILDING AUTOMATIC INSTALL MEDIA" at end of manual bsdinstall(8).

Is there anything left for me to try?
I see you have posted the problem on freebsd-current@ mailing list, but there was no reply. Perhaps a PR on bugzilla can attract the attention of a developer.
 
Back
Top