On Thu, Oct 01, 2026 at 02:27:38AM +0100, Simon Glass wrote: > Hi Milivoje, > > On Wed, 30 Sept 2026 at 23:29, Milivoje Legenovic <[email protected]> > wrote: > > > > 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. > > > > 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 > > > > 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?" > > Good idea! > > Does 'dmesg | grep -i dmi' show a DMI line, and is > /sys/firmware/dmi/tables populated? That shows whether the kernel > reads the property. > > Does the hang go away if the property stays but the region is > reserved? A quick hack is fdt_add_mem_rsv(fdt, smbiosaddr, TABLE_SIZE) > next to the setprop in fdt_chosen() > > If so, you could add a fix for 209bbc4e003 - i.e. reserve the table.
Thanks for the additional details Milivoje, I'm hoping that someone else that worked on this can explain how the change in question here leads to a kernel hang. Can you please confirm what kernel(s) you've seen this with? It might be worth increasing the kernel loglevel too. -- Tom
signature.asc
Description: PGP signature
