Bug 209821 - UEFI - installation media hangs when booting on ASUS P6P67 DELUXE
Summary: UEFI - installation media hangs when booting on ASUS P6P67 DELUXE
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Keywords: uefi
Depends on:
Reported: 2016-05-29 00:12 UTC by zactoid
Modified: 2021-06-14 17:02 UTC (History)
33 users (show)

See Also:

Fix a boot hang on some systems (5.79 KB, patch)
2021-05-28 15:50 UTC, David Sebek
no flags Details | Diff
[PATCH] efi: loader: Fix a boot freeze on some amd64 systems (11.36 KB, patch)
2021-06-01 20:56 UTC, David Sebek
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description zactoid 2016-05-29 00:12:52 UTC
When trying to install FreeBSD with UEFI the installation media doesn't boot, hanging after the "Booting..." and EFI framebuffer information output.

From what I've read this seems specific to my mobo and its efi firmware, here's the relevant system information:

EFI version 2.31
EFI firmware American Megatrends (rev 4.651)

I'm unsure on where/how to get more detailed information that would help, so any hints or pointers I'm happy to try.

Also I was following this bug #193646 which I thought was similar to my issue, but apparently it was fixed so my issue may be different, although it was never confirmed so I thought I'd mention it.
Comment 1 Tomas 2016-07-09 11:03:54 UTC
I observe the same symptoms (UEFI installer gets stuck immediately after printing framebuffer info; system is frozen, keyboard doesn't react) with hardware:

MB: Asus P8Z68-V PRO GEN3, BIOS 3802 01/15/2015 (latest BIOS)
EFI v2.31 by American Megatrends

Tested with UEFI USB stick installation FreeBSD 10.3 (FreeBSD-10.3-RELEASE-amd64-uefi-memstick.img) and PCBSD 11-Current-May (PCBSD11.0-CURRENTMAY2016-05-14-2016-x64-netinstall-USB.img), both freeze.

Non-UEFI image boots.
Comment 2 Ivan 2016-07-23 14:44:53 UTC
I confirm this situation with FreeBSD11-BETA2
Comment 3 Andrew 2017-01-23 12:36:24 UTC
Same issue on UX21E
Comment 4 nsugeorge 2017-04-13 21:17:30 UTC
same issue on ASUS P6P67 LE
Comment 5 Travis 2017-05-01 04:04:21 UTC
Confirmed on Asus P8P67 PRO with Bios version 3602 x64, EC version MBECE-0018 and ME version The problem persisted after setting SATA mode to IDE as well as enabling legacy compatibility. 

It gets as far as printing some frame buffer info on the screen then hangs ignoring all input. BIOS boot works fine.
Comment 6 nsugeorge 2017-05-27 03:51:22 UTC
There is an error in comment 4
The motherboard is ASUS P8P67 LE not ASUS P6P67 LE
Comment 7 georg-bsd 2018-05-13 18:17:00 UTC
I have the same issue on an AMD Sabertooth 990FX Motherboard. 

The system hangs after the loading of the kernel with the EFI console information. It didn't change anything as i tried to change the GOP mode to 640x480/800x600/1024x768. 

I use currently FreeBSD 11.1 amd64. HDD is SSD and a Hardware Raid 5 3ware 9650SE-4LP DISK.
SSD contains the EFI partition. On the same SSD is space for the BSD ROOT ZFS. 

Booting from the installer in UEFI mode hangs the system after

EFI framebuffer information:
addr, size          0xc0000000, 0x10000000
dimensions          800 x 600
stride              832
masks               0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000

after i booted the installer in legacy mode, the kernel started. I installed the BSD manually on the SSD ZFS partiton and added the boot1.efi in the UEFI partition and added an entry in my EFI boot menu. The same procedure worked flawless in multiple VMs installed in UEFI mode. 

All other OS can run my system in UEFI mode. Windows 10, Windows 7 and Linux.

Some more information can be found on
Comment 8 georg-bsd 2018-05-13 18:21:06 UTC
I forgot, the manual installation hangs at the same step.
Comment 9 georg-bsd 2018-05-21 17:41:52 UTC
I unstalled FreeBSD on an SSD partiton with UFS2. As i started the freebsd kernel with grub2 instead of the boot1.efi loader, the graphic output was totally garbled. So maybe it's an issue with the EFI framebuffer handling.
Comment 10 georg-bsd 2018-05-22 16:59:52 UTC
With boot1.efi from 11.2-BETA2 on the EFI partiton i could boot 11.2-BETA2 and 11.1-RELEASE installation.

So i suspect the bug was fixed in the history of stand/efi/boot1/boot1.c between 11.1-RELEASE and 11.2-BETA2.
Comment 11 georg-bsd 2018-05-22 17:03:22 UTC
Good boot1.efi (from 11.2-BETA2 in use)
SHA256 (/tmp/efi/EFI/FreeBSD/boot1.efi) = eb2c3d4c2a5881973e22ecf7bebf9f07d4d9d12c232185d71f9caababb613650

Bad boot1.efi (from 11.1-RELEASE just on the root partiton but not used)
SHA256 (/boot/loader.efi) = f77a59198529a9b220fcc8fc9dd91c0bfbf76519240692527ebc1ca60f1817ee
Comment 12 georg-bsd 2018-06-07 17:30:26 UTC
I can reproduce this bug with bhyve and the FreeBSD 11.1-bootonly iso.

bhyve -AHP \
    -s 0:0,hostbridge \
    -s 1:0,lpc \
    -s 2:0,virtio-net,tap0 \
    -s 3:0,virtio-blk,/dev/zvol/data/VM/byhve/test-vm \
    -s 4:0,ahci-cd,/usr/home/georg/Downloads/FreeBSD-11.1-RELEASE-amd64-bootonly.iso \
    -m 2048M \
    -s 29,fbuf,tcp=,w=800,h=600,wait \
    -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
Comment 13 Jorge Fabregat López 2018-10-12 15:28:42 UTC
Same issue on Asus Sabertooth P67 UEFI Version 3602 (Latest available)

Happens with 11.2-RELEASE but also with 12.0-ALPHA8 isos. Both images boot fine on legacy mode.

Gets stuck at:

Loading kernel...
/boot/kernel/kernel text=0x169d318 data=0x1ceac8+0x80d270 syms=[0x8+0x180c00+0x8+0x19d837]
Loading configured modules...
Could not load one or more modules!
Start @ 0xffffffff80343000 ...
EFI framebuffer information:
addr, size       0xd0000000, 0x30000000
dimensions       800 x 600
stride           832
masks            0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000

Loader variables:

loader_conf_files=/boot/device.hints /boot/loader.conf /boot/loader.conf.local
smbios.bios.vendor=American Megatrends Inc.
smbios.chassis.maker=Chassis Manufacture
smbios.chassis.serial=Chassis Serial Number
smbios.chassis.version=Chassis Version
smbios.planar.location=To be filled by O.E.M.
smbios.planar.maker=ASUSTek Computer INC.
smbios.planar.product=SABERTOOTH P67
smbios.planar.serial= *omitted*
smbios.planar.tag=To be filled by O.E.M.
smbios.planar.version=Rev 1.xx
smbios.system.family=To be filled by O.E.M.
smbios.system.maker=System manufacturer
smbios.system.product=System Product Name
smbios.system.serial=System Serial Number
smbios.system.version=System Version

I'm new to BSD so I still don't know my way around here but I'll be glad to provide any more information given instructions on how to.
Comment 14 grash54 2018-11-18 13:29:15 UTC
This happens to me as well. P8P67 Pro motherboard with 3602 BIOS.
Comment 15 rob 2018-11-25 00:55:30 UTC
I also have this issue. Asus P8P67 rev 1.02
Comment 16 oz42 2019-04-30 16:30:14 UTC
Same here. ASUS P6P67 Rev. 3.1, BIOS 3602, 12-RELEASE a,d64
Comment 17 oz42 2019-05-08 12:44:20 UTC
(In reply to oz42 from comment #16)
Funny is: I dis a secure erase on my SSD and installed FreeBSD as the first system. No problems.
Comment 18 O. Hartmann 2019-12-11 16:17:14 UTC
I see the same hung with FreeBSD 12.1 (XigmaNAS ^ on an older Supermicro X9SCV-Q with firmware AMI Bios 2.10.1208 from 2012.

The problem is occurs eratic: most cases the box hang at 

EFI framebuffer information:
addr, size          0xe0000000, 0x3ff0000
dimensions          800 x 600
stride              800
masks               0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000

in some rare cases the box boots.
Comment 19 Stefan Eßer freebsd_committer 2020-02-05 20:25:52 UTC
Just a me-too, but on the latest -CURRENT:

I tried to switch from legacy boot to UEFI boot, and the EFI loader is started and lets me change options or select a kernel to boot from.

When the kernel is loaded and started, the system locks up with identical information about the EFI frame buffer as shown in comment 18 by O. Hartmann.

System hardware:

ASUS P8H67-M EVO with American Megatrends BIOS 3703 and with i7-2600K CPU (Sandy Bridge)
Comment 20 Stefan Eßer freebsd_committer 2020-02-05 20:29:28 UTC
I have updated the affected version to -CURRENT (which as of now is 13-CURRENT), in the hope that this PR gets more visibility that way.
Comment 21 Jerry Jacobs 2020-02-05 21:03:27 UTC
It seems I have the same with a HP Compaq 8200 Elite SFF PC. When disabling in the AMI Bios the EFI mode and using legacy it works fine. Also it hung on a similar message as posted earlier in this ticket:

EFI framebuffer information:
addr, size          0xc0000000, 0x10000000
dimensions          800 x 600
stride              832
masks               0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000

If more info is necessary i'm willing to provide.
Comment 22 Andreas Gustafsson 2020-03-16 12:04:39 UTC
I'm having a similar problem, with the slight difference that after printing the EFI framebuffer information, the system does not hang but rather reboots, causing an endless reboot loop.  This is booting FreeBSD-12.1-RELEASE-amd64-memstick.img from a USB flash drive on a HP Compaq 6300 Pro SFF PC.

Disabling the EFI boot devices in the BIOS works around the issue.
Comment 23 Kalten 2020-04-09 23:08:48 UTC

I do have the halting-problem.

Hardware 1:
* ASUS P8Z68-V PRO   (not a PRO/GEN3)
* AMIBIOS 080010 ALASKA Ver.36.03
* CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz (3110.22-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x206a7  Family=0x6  Model=0x2a  Stepping=7
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  XSAVE Features=0x1<XSAVEOPT>
  TSC: P-state invariant, performance statistics
* Onboard Graphics (I assume intel i915)
* tested with and without: nVidia GeForce GTX 770 in PCIe

Hardware 2:
* ASUS P8H67-M Rev.3.0
* SMBIOS v.2.6 Ver.39.01
* CPU: an i5 as well

I was not successful, but you might want to know what I have tried.

To sum it up: Booting successfully on another PC in UEFI mode I have
arrived at the speculation that it might be that it has nothing to do
with a problem related to the graphic chips etc—although switching to
VT(efifb) or similar might be the problem.

Obviously we are stuck at what ever comes after reporting the EFI
framebuffer information including the masks AND clearing the screen
followed by the to be reported lines:
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb

Using USB-Stick with following images:

One test was as follows: I did install—booting in UEFI mode—a
12.1-RELEASE onto an empty GPT disk in another PC.
That disk I did attach to my two problematic PCs and booted.
Strangely both do not think the hard disk to be bootable.

In the 12.1-RELEASE version I have tried several modifications:

* ...8<--- /boot/loader.conf on the USB-Stick
  Did not change the problem :-(

* ...8<--- /boot/loader.conf on the USB-Stick
  # as well as    kern.vty=sc
  Did not change the problem :-(

* ...8<--- /boot/loader.conf on the USB-Stick
  exec="set mode 0"
  # as well as 3, 12, ...
  # I could see the effect
  Did not change the problem :-(

* ...8<--- /boot/loader.conf on the USB-Stick
  exec="gop set 0"
  # as well as 3, 12, ...
  # I could see the effect
  Did not change the problem :-(

* ...8<--- /boot/loader.conf on the USB-Stick
  # as well as "720p", "1080p", "800x600" 
  # I could see the effect
  Did not change the problem :-(

* loading graphics/drm-kmod for the i915 (5th generation as CPU i5-*)
  mentions something about that topic (using port from 5th generation
  onward instead of /boot/kernel/i915kms.ko)
  I did install using BIOS boot. In that system I did build and install
  the mentioned port, than mounted the USB stick and copied
  /boot/modules/ to it. I did add a couple of lines on the USB stick:
  ...8<--- /boot/loader.conf on the USB-Stick
  I could observe that it did load the correct kernel module including
  the correct dependencies out of /boot/modules/.
  It did not help (I did this with my nVidia GeForce GTX 770 installed)
  Did not change the problem :-(

I too am at a loss.

Comment 24 Harald Schmalzbauer 2020-04-27 18:59:54 UTC
The symptoms are reproducable here if I boost efiloader's EFI_STAGING_SIZE to 512M or more.
Lowering to less than 512M (which was recently increased to 100M on amd64) allows normal boot.  Maybe someone with deeper UEFI knowledge can find a correlation between EFI_STAGING_SIZE in stand/efi/loader/copy.c and maybe vendor dependent implementation bugs?

Comment 25 Conrad Meyer freebsd_committer 2020-04-28 16:10:23 UTC
Re: EFI_STAGING_SIZE, IIRC loader assumes it can get 512 MB of contiguous memory, and/or doesn't consult the memory map to check for conflicts, or something like that.  With a slightly older 11.x version of efiloader, we had some hardware that couldn't boot with 128 MB memory (OOM) and some hardware that couldn't boot with 512 MB memory (crash).  The sweet spot we found was something like 380 MB for our hardware (which has custom BIOS/firmware anyway), but that's a very limited subset of the real hardware in existence.
Comment 26 Christos 2020-05-20 09:52:45 UTC
This problem exists !
Every new laptop/Ultrabook like my asus vivobook can't switch from efi to legacy there is no options for that, so I had to boot in efi 
The amd graphics card needs amdgpu and these two have problems combined.
I get the framebuffer info and stuck , I can't do anything else 
tried to disable syscons but that doesn't work it even made me unable to switch to any terminal or do anything at all after displaying the framebuffer messages,same as this bug reports.
I don't know if there is a solution for that.
The strange is that with FreeBSD 13 I succeed to start xorg but only two times and by pressing alt+f2 alt+f3 I don't know what is the problem
Comment 27 Steven Toth 2020-06-30 21:46:05 UTC
I'm having the same issue as well.

Version: F7 (5/11/2012)

I will try and update the bios but the exact same thing is happening.  I was having issues with my upgraded install and now am trying to reinstall.
Comment 28 Steven Toth 2020-06-30 22:11:26 UTC
At least for my issue, upgrading to the newest F16j version of the BIOS for my motherboard has gotten me to the next stage of the install.
Comment 29 Chris 2020-09-06 21:53:44 UTC
Okay, I'm feeling way out of my depths here and starting to get both frustrated and annoyed at myself for not being able to figure this out better. I picked up a cheap PC the other day, an HP Pavilion p7-1147c. The bios interface is extremely limited on this unit and no option for enabling/disable legacy boot but does have support for UEFI. With UEFI and a USB installer, I can get to the installer screen and choose which type of install but the only one that seems to do anything is option #1, then from there it gets to the masks line and halts completely. 

Here's where I'm lost after reading all the comments here. where and which version do I need to download, can I get a legacy boot version of the installer. I think that is my largest missing piece. I found a server link and may have found what I need but it's so much data, so many versions and no differentiators I feel lost there. 

Any direct links or assistance on finding what I'm needing would be stellar!
Comment 30 Christian Spiel 2020-09-16 06:58:19 UTC
I am having the same problem with my HP Z2 mini G4 (BIOS version is updated to the latest available version). 

The boot hangs after printing out the EFI framebuffer information. Booting in legacy mode and trying several boot parameters did not work either. 

It would be really great if somebody could look into this issue.
Comment 31 jonas.bulow 2020-10-26 06:58:59 UTC
Tested with 12.2-RC3 on a HP Z210 and a HP Z220, both using latest BIOS version.

The HP Z210 halts after EFI framebuffer information output and the HP Z220 works just fine. 

Is there anything I can do to help solving this issue by comparing the EFI environments of these two computers?
Comment 32 RichardG 2020-11-11 13:28:46 UTC
I tested with my ASUS K73SD + Freebsd 12.2 (DVD install): EFI boot failed.

However, if I escape to loader prompt and do a "boot -m" or "boot -q" the installation begins.
After installation, boot -q -m still works
Comment 33 Dhananjay Balan 2020-11-11 19:27:44 UTC
I am hitting the same bug:

Asus P8H67-V with Intel i5 (2nd Gen, Sandy Bridge)

- Reproduced with
  - FreeBSD 11.4, 12.0, 12.1, 12.2 and 13-CURRENT
Comment 34 RichardG 2020-11-15 17:00:53 UTC
(In reply to RichardG from comment #32)
My previous comment is wrong. Mute or quiet do not prevent hangs during boot.
I also experienced hangs during shutdowns. in that case, the messages "syncing disks vnodes remaining... etc" are'nt displayed.
Comment 35 Graham Perrin 2021-01-21 19:50:39 UTC
Reading this alongside more recent bug 251866
Comment 36 RichardG 2021-03-01 19:28:08 UTC
(In reply to Graham Perrin from comment #35)
I tested this, lowering EFI_STAGING_SIZE from 100 to 64 : I still got a freeze
Comment 37 David Sebek 2021-05-28 15:47:11 UTC
I fixed the problem on my machine! The boot process always got stuck after it printed the EFI framebuffer information. This is just before the kernel is started.
The EFI bootloader first loads the kernel to a staging area (which is 64MB large). Then, just before the kernel is started, the bootloader copies the contents of the staging area to the address 0x200000 and jumps to the kernel entry point that is now located at the expected location.
In my case, the LoaderCode and LoaderData memory pages of the EFI bootloader happened to be located at addresses 0x2d1e000 and 0x2e01000, which were overwritten by the contents of the staging area.
I made some changes to the code to avoid this issue, and now my system boots just fine.

These bug reports also seem to be similar to this one: Bug 255073, Bug 219957

I am attaching a patch against the main git branch, please test if it fixes the problem for you too.
Comment 38 David Sebek 2021-05-28 15:50:48 UTC
Created attachment 225333 [details]
Fix a boot hang on some systems
Comment 39 David Sebek 2021-05-28 19:31:42 UTC
There is also another scenario when the system can hang after displaying the EFI framebuffer information. This happens when EFI_STAGING_SIZE is too small (e.g., 32MB) and there is no available memory surrounding the staging area. In that case, efi_check_space correctly returns FALSE. The functions that called it (efi_copyin, efi_readin) also return an error. The return value of efi_readin seems to be checked by all of its callers. However, the return value of efi_copyin is never checked.

In a KVM virtual machine with OVMF, FreeBSD boots with no apparent issues even if EFI_STAGING_SIZE is set to 32 and efi_check_space does not expand the allocated memory and returns errors.

On my physical machine, with EFI_STAGING_SIZE set to 32, the bootloader prints a bunch of "efi_check_space: Unable to expand staging area" messages followed by the EFI framebuffer information, and then it hangs. Some graphical corruption was also displayed on the screen.
Comment 40 RichardG 2021-05-31 19:39:16 UTC
(In reply to David Sebek from comment #37)


On my ASUS K73SD, the patch works. 
Without the patch I never managed to do a cold boot (ie just after a power on) on UEFI. Every boot with the patch succeeded (power on, reboot).

patch applied on 13 current :
FreeBSD 13.0-RELEASE-p1 #0 releng/13.0-n244744-8023e729a52

Comment 41 David Sebek 2021-06-01 20:56:43 UTC
Created attachment 225480 [details]
[PATCH] efi: loader: Fix a boot freeze on some amd64 systems

Fix an issue when the boot process could freeze shortly after
displaying EFI framebuffer information on some amd64 systems.

Instead of calling the efi_copy_finish function from amd64_tramp,
include the copy instructions in the trampoline code itself.
This avoids boot hangs and restarts in the cases when
the EFI loader code and/or data segments happen to be located
at a memory location that is overwritten during the copy process.

Also, add missing return value checks. Add a new function that
prints a warning message if there is a danger that the bootloader
may attempt to overwrite memory pages of a type that should not
be overwritten.
Comment 42 ruben 2021-06-07 21:20:34 UTC
similar problem on an ASUS PRIME Z590M-PLUS visually, but it differs in that graphics (gop) is not seen while in UEFI mode, and loader.efi thinks everything must be serial console (boot info reports addr, size 0x0, 0x0) 

The system displays apparently no further activity past that point

I've tried the June 1st patch (though it needs some cleanup op 13.0-RELEASE-p2). It does continue the boot, but the screen is all garbled.

booting openbsd's install69.img in UEFI mode shows a working efifb though.

Booting in CSM mode, with an external video card, works
Comment 43 ruben 2021-06-08 09:10:29 UTC
A 12.2-RELEASE install image does boot with UEFI, and VT(efifb) is available, which means there is a regression between 12.2 and 13.0 handling of UEFI. After removing the PCI gfx card the IGP is detected and works
Comment 44 James Thomason 2021-06-09 08:55:15 UTC
(In reply to David Sebek from comment #41)

@David Sebek We're using a rather large mfsroot (mfsbsd) and have been seeing this issue on Vmware and bare metal OpenCompute Leopard. I built the loader.efi out of FreeBSD-current using your nice patch and this resolved the issue on VMware but not the OCP Leopard. 

The OCP Leopard previously would not even complete loading the mfs before it hung, but now we get past the mfsroot to: 

Loading kernel...
/boot/kernel/kernel text=0x16bdcc4 data=0x140 data=0x75fe80 syms=[0x8+0x17e098+0x8+0x19bdd3]
Loading configured modules...
/mfsroot size=0x57c0000
can't find '/etc/hostid'
can't find '/boot/entropy'
Start @ 0xffffffff80373000 ...
EFI framebuffer information:
addr, size     0x0, 0x0
dimensions     0 x 0
stride         0
masks          0x00000000, 0x00000000, 0x00000000, 0x00000000
Comment 45 David Sebek 2021-06-09 12:47:51 UTC
(In reply to James Thomason from comment #44)

Is your monitor connected to a graphics card, or are you using a serial console? I can reproduce a similar output in a virtual machine if I remove the GPU, use serial console instead, and then on the FreeBSD bootloader screen select "5. Cons: Video" instead of "5. Cons: Serial". In that case, the system boots but does not print any further information to the console. Other than that, I have not been able to reproduce your issue yet.
Comment 46 David Sebek 2021-06-09 13:22:47 UTC
(In reply to David Sebek from comment #45)

I am able to reproduce the problem when a GPU is used that doesn't support EFI GOP. I will take a look at it.
Comment 47 James Thomason 2021-06-09 17:36:50 UTC
(In reply to David Sebek from comment #46)

In this case the system does not have a framebuffer at all. They are OpenCompute servers which support serial console through ipmi redirect or otherwise through a debug header only. 

We are attempting to boot the host through ipxe sanboot of a UEFI compliant iso image containing a vanilla 12.2-RELEASE mfsbsd kernel+mfs and the loader.efi from FreeBSD-current with your patch. 

If you want I could set you up with ssh access into a tesbed with this type of host and the ipxe environment.
Comment 48 Sebastian 2021-06-14 16:40:58 UTC
(In reply to ruben from comment #43)

I can confirm that this seems to be a regression for 13.0-RELEASE.

I also suspect this is some kind of "special behaviour" with ASUS UEFI, as the affected system here is also an ASUS board (Pro M560M-C)

I just received a new workstation today with said ASUS Pro M560MC/CSM board and a FreeBSD 13.0-RELEASE memstick isn't able to boot, whereas the 12.2-RELEASE memstick boots and I'm able to install.
Comment 49 doa379 2021-06-14 17:02:36 UTC
(In reply to Sebastian from comment #48)

Did you apply the patch to see if your system booted? How do you know without the proper diagnostics on this problem.

I've tried Releases 11.4, 12.x, 13.0 and the test still fails. So it can't be a regression. NB. OEM/brand is almost an irrelevant quantity as any given vendor may use firmware from a variety of different sources.