Sorry, forgot to add something.
On 10/1/26 5:35 PM, Quentin Schulz wrote:
Hi Milivoje,
On 10/1/26 12:28 AM, Milivoje Legenovic wrote:
[You don't often get email from [email protected]. Learn why this
is important at https://aka.ms/LearnAboutSenderIdentification ]
Hello everyone,
Here are the details of my analysis:
The commit that introduced the change in behavior in version 2026.01
is this one:
commit 209bbc4e0032228c6ea17e2172a8a6b89756c4f5
Author: Adriana Nicolae <[email protected]>
Date: Thu Nov 27 08:28:34 2025 -0800
boot/bootfdt: Add smbios3-entrypoint to FDT for non-EFI boots
The Linux kernel can discover SMBIOS tables through two primary
methods:
1. Via EFI tables, when using EFI boot;
2. Via the 'smbios3-entrypoint' property in the /chosen node of the
device tree.
...
I found this out by comparing the device tree from a working version,
decompiled using
sudo dtc -I fs -O dts /sys/firmware/devicetree/base -o live_tree.dts
and difference was in /chosen node:
chosen {
u-boot,version =
"2026.01_armbian-2026.01-S127a-P7283-Hee1c-V2928-B3a7f-R448a";
linux,initrd-end = <0x00 0xecbffca5>;
bootargs = ...
smbios3-entrypoint = <0x00 0xedf47000>;
kaslr-seed = <0x00 0x00>;
linux,initrd-start = <0x00 0xeb519000>;
stdout-path = "serial2:1500000n8";
};
In 2026.01 version smbios3-entrypoint was there, in 2025.10 not. I
searched for this term in git history and found the commit mentioned
above.
With git show I saw what activates this, and made a patch in armbian
build system to disable it and confirm it fixes the problem. And it
fixed it.
Can you run a bisect between 2025.10 and 2026.01 without a change to the
defconfig? I'm pretty sure this commit is not the issue (you can revert
it and keep CONFIG_GENERATE_SMBIOS_TABLE enabled and you'll likely see
behavior hasn't changed, meaning the breaking change is coming from
another commit). After a glance at the log between 2025.10 and 2026.01,
I don't see anything obviously related to smbios that changed (aside
from the commit you mentioned and 2d226a735e0e ("smbios: Fix warning
when building with clang") but that isn't a clear candidate for a
breakage of this kind).
As far as my understanding goes, there's actually nothing consuming this
DT property right now. There is a patch on the Linux kernel mailing
list, c.f. https://lore.kernel.org/lkml/20251031115917.713105-2-
[email protected]/ but it's not merged. I doubt Armbian would backport
this but maybe they did?
So I don't think the *presence* of this property changes anything, but
there could be side-effects (e.g. actually having the SMBIOS3 table
somewhere it isn't expected, potentially corrupting e.g. the kernel).
I'm a bit skeptical though as the commit you point to only adds a
property, it doesn't seem to be doing anything else.
Here is also where kernel hangs for 60 seconds (always at the same
place):
[ 14.482048] calling gpio_led_driver_init+0x0/0x38 @ 1
[ 78.137967] Freeing initrd memory: 23448K
[ 78.165027] probe of leds returned 0 after 63677665 usecs
[ 78.166792] initcall gpio_led_driver_init+0x0/0x38 returned 0 after
63684076 usecs
So the probe of the drivers/leds/leds-gpio.c driver took 60+seconds,
that seems quite improbable (well, it technically could be anything on
the path for this driver to probe, c.f. really_probe() in drivers/base/
dd.c.
Can you disable that driver (CONFIG_LEDS_GPIO) and see if it goes
further? Being curious :) (I see Armbian did some - clearly downstream -
changes to this driver, so being curious :) ).
Can you provide us with a link (with commit hash) to the exact sources
of U-Boot and Linux kernel that Armbian builds for your board?
Can you provide us with the full bootlog (including U-Boot up until the
Linux kernel's hung)?
As you can see, I was only able to find the cause, but that’s the
extent of my expertise.
At first, I wanted to sort out the problem with a patch in the Armbian
build project, but then I thought: "Why not sort it out at source?"
I'm not convinced we're there yet but that's the kind of spirit I like,
let's not fix symptoms or consequences :)
Cheers,
Quentin
