* grab-boot-data.sh fails on mkroot (zombies abound)
From: Bird, Tim @ 2026-06-18 18:40 UTC (permalink / raw)
To: Rob Landley, linux-embedded@vger.kernel.org
In-Reply-To: <064b8c64-ebd7-4210-ac28-8be27773c8bf@landley.net>
Hey Rob,
I tried grab-boot-data.sh on mkroot, using 'toybox sh' as interpreter.
I got some weird behavior that I'd like to report. (I was planning on experimenting
more to see if I could determine the issue, but I'm going on vacation next week.)
Maybe you have an idea off the top of you head what might be the problem...
When I use init=/bin/sh, and then try to run grab-boot-data.sh, it always
goes zombie after execution.
$ grab-boot-data.sh -h
Usage: ...
...
$ ps -l
F S UID PID PPID C PRI NI BIT SZ WCHAN TTY TIME CMD
0 S 0 56 1 0 19 0 32 244 do_wait ttyS0 00:00:00 sh
1 Z 0 58 1 0 19 0 - 0 0 4:64 00:00:00 grab-boot-da.
5 R 0 65 56 1 19 0 32 246 0 ttyS0 00:00:00 sh
Also, the program does not execute fully, and produces no output
when run in operational mode:
$ grab-boot-data.sh -l timslab -m mkroot-qemu-x86-64
$
(and it leaves another zombie)
I added 'vi' to toybox, and tried to edit grab-boot-data.sh to add
some echos to see where it's exiting, but when I try to save
the file, the qemu session hangs. (I think this is a separate problem,
with toybox vi).
When running toybox sh as the 'init' process, does it need to
do a 'wait' on it's children at some point, in order to reap them?
Regards,
-- Tim
^ permalink raw reply
* Re: Reminder of Boot-Time SIG meeting (June 30, 2026)
From: Roberto A. Foglietta @ 2026-06-18 19:08 UTC (permalink / raw)
To: Bird, Tim; +Cc: Embedded Linux mailing list
In-Reply-To: <MW5PR13MB563294337A346C20F42DFC7DFDE32@MW5PR13MB5632.namprd13.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]
On Thu, 18 Jun 2026 at 20:18, Bird, Tim <Tim.Bird@sony.com> wrote:
>
> Hey Linux Boot-Time SIG interested parties (and other interested Linux kernel developers),
>
Just for the record, I read
items in flight:
- early_times - fix zero-valued printks in kernel "blind spot"
- original patch thread here:
- https://lore.kernel.org/all/39b09edb-8998-4ebd-a564-7d594434a981@bird.org/
- see V4 submission here:
- https://lore.kernel.org/linux-embedded/20260410203741.997410-1-tim.bird@sony.com/
- patch is saved here:
https://github.com/tbird20d/boot-time-wizard/blob/main/patches/early-times.patch
- next action: make v5 version of patch?
However, a V6 is already available since 2026-04-16, now also in more
LKML format alike
- https://raw.githubusercontent.com/robang74/uchaosys/b88e3c6c493108ca9dad8474ec41ec95c74db01c/cnfg/printk-early-boot-timestamps-hack-v6.patch
Also in attachment for reference but wget (or lynx) is your friend
since the link points to the raw patch.
Best regards,
--
Roberto A. Foglietta
+49.176.274.75.661
+39.349.33.30.697
[-- Attachment #2: 0001-printk-fix-zero-valued-printk-timestamps-in-early-bo.patch --]
[-- Type: text/x-patch, Size: 8382 bytes --]
From 68b9eef9f37f991ea33ec134ea67bd6b8c95e97e Mon Sep 17 00:00:00 2001
From: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
Date: Thu Apr 16 09:34:35 2026 +0200
Subject: [PATCH] printk: fix zero-valued printk timestamps in early boot V6
This is a heavily "refactored by hands" patch for Linux Kernel 5.15.202 LTS
trying to solve the source tree janitoring vs 1-single place hack for hackers
in need for a simple-bare profiling tool and based on the patch V4 submitted by
Pre-Kernel boot time (qemu, KVM, bios) is 0.251063 / 1.896 = 0.132 seconds
[ 0.250814] Linux version 5.15.202 (roberto@x280) (x86_64-linux-musl-gcc
(GCC) 14.3.0, GNU ld (GNU Binutils) 2.44) #1 Thu A6
[ 0.250820] Command line: HOST=x86_64 root=/dev/ram0 init=/init
console=ttyS0,115200n8 net.ifnames=0 nokaslr
[ 0.250823] KERNEL supported cpus:
[ 0.250824] Intel GenuineIntel
[ 0.250826] AMD AuthenticAMD
[ 0.250972] BIOS-provided physical RAM map:
[ 0.250973] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[ 0.250978] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[ 0.250981] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[ 0.250983] BIOS-e820: [mem 0x0000000000100000-0x0000000001fdefff] usable
[ 0.250986] BIOS-e820: [mem 0x0000000001fdf000-0x0000000001ffffff] reserved
[ 0.250989] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
[ 0.250991] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[ 0.250994] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
[ 0.250996] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
[ 0.251043] NX (Execute Disable) protection: active
[ 0.251050] Hypervisor detected: KVM
[ 0.251053] kvm-clock: Using msrs 4b564d01 and 4b564d00
[ 0.251063] kvm-clock: cpu 0, msr bac001, primary cpu clock
[ 0.000001] kvm-clock: using sched offset of 56130848 cycles
[ 0.000003] clocksource: kvm-clock: mask: 0xffffffffffffffff
max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[ 0.000005] tsc: Detected 1896.002 MHz processor
From: Tim Bird <tim.bird@sony.com>
Date: Fri, 10 Apr 2026 14:37:41 -0600
Message-ID: <20260410203741.997410-2-tim.bird@sony.com>
During early boot, printk timestamps are reported as zero before
kernel timekeeping starts (i.e. before time_init()). This hinders
boot-time optimization efforts. This period ranges from 17 to 1700
milliseconds on different embedded machines running Linux.
Add support for early timestamps based on processor cycle-generators
that need no kernel initialization.This feature isn't intended for a
generic distro kernels but for temporary use during kernel development
and boot-time research and optimization by kernel hackers only.
This yields non-zero timestamps for printks from the very start
of kernel execution. The timestamps are relative to the start of
an architecture-specific counter (e.g. tsc on x86_64 and cntvct_el0
on arm64). Affected timestamps reflect cycle counter related values
since init (usually machine power-on or virtual machine start) instead
of time from the kernel's timekeeping initialization. This results in
a discontinuity in the printk timestamp values, one time, when
kernel timekeeping starts.
Suggested-by: Tim Bird <tim.bird@sony.com>
Signed-off-by: Roberto A. Foglietta <roberto.foglietta@gmail.com>
V5 -> V6 // RAF
Feature moved in the proper menu place, immediately after:
Kernel hacking -> printk and dmesg options -> show timitng information printks
Comments and descriptions more clearly indicate the aim and the limits of this
patch and the related feature introduced by this patch.
V4 -> V5 // RAF
Rationale: single point of change hack for printk. Code rewritten, entirely.
It provides a feature for kernel hackers willing to profiling the early boot
with a basic printk approach (rather than using HW monitors which might not
be available or immediately available). Thus, it is a first-look or a last
resort hack profiling feature. Something that isn't good to spread around
the kernel sources tree and it is fine to have into a single header file.
V3 -> V4 // Tim
Replace config vars with single one: CONFIG_EARLY_CYCLES_KHZ
Replace runtime calibration with static config variable
Remove reference to get_cycles()
Add support for RISCV platforms
V2 -> V3 // Tim
Default CONFIG option to 'n'
Move more code into early_times.h (reduce ifdefs in init/main.c)
Use match64 helper routines
Use cycles_t instead of u64 type
Add #defines for EARLY_CYCLES_BIT and EARLY_CYCLES_MASK
Invert if logic in adjust_early_ts()
V1 -> V2 // Tim
Remove calibration CONFIG vars
Add 'depends on' to restrict arches (to handle ppc bug)
Add early_ts_offset to avoid discontinuity
Save cycles in ts_nsec, and convert on output
Move conditional code to include file early_times.h
Source:
- https://raw.githubusercontent.com/robang74/uchaosys/refs/heads/v074/
/cnfg/printk-early-boot-timestamps-hack-v6.patch
- commit: 2026-04-16, #2bd0bb1
---
kernel/printk/early_times.h | 26 ++++++++++++++++++++++++++
kernel/printk/printk.c | 12 ++++++++++++
lib/Kconfig.debug | 23 +++++++++++++++++++++++
3 files changed, 61 insertions(+)
create mode 100644 kernel/printk/early_times.h
diff --git a/kernel/printk/early_times.h b/kernel/printk/early_times.h
new file mode 100644
index 000000000000..af0ef42bd1f1
--- /dev/null
+++ b/kernel/printk/early_times.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _EARLY_TIMES_H
+#define _EARLY_TIMES_H
+
+#include <linux/timekeeping.h>
+
+/*
+ * Fencing isn't optional here, otherwise unreliable values displaying
+ */
+#if defined(CONFIG_ARM64)
+ #include <asm/sysreg.h>
+ #define __early_raw_cycles ({ u64 val; \
+ asm volatile("isb; mrs %0, cntvct_el0" : "=r"(val)); val; })
+#elif defined(CONFIG_X86_64)
+ #define __early_raw_cycles ({ u64 val; \
+ asm volatile("lfence; rdtsc; shl $32, %%rdx; or %%rdx, %%rax" \
+ : "=a"(val) : : "rdx"); val; })
+#elif defined(CONFIG_RISCV_TIMER)
+ #define __early_raw_cycles ({ u64 val; \
+ asm volatile("fence; rdtime %0" : "=r"(val)); val; })
+#else
+ #define __early_raw_cycles 0
+#endif
+
+#endif /* _EARLY_TIMES_H */
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 113990f38436..0405a988c96f 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2151,6 +2151,18 @@ int vprintk_store(int facility, int level,
*/
ts_nsec = local_clock();
+#if CONFIG_PRINTK_EARLY_BOOT_TIMINGS
+#include "early_times.h"
+ /*
+ * Very few developers are going to use this feature and it is
+ * expected they're able to deal with it as a single entry-point of
+ * changes. An hack to be further customised by them for porting the
+ * kernel on not-yet-supported silicon or bug fixing / optimisations.
+ */
+ if (unlikely(!ts_nsec))
+ ts_nsec = __early_raw_cycles;
+#endif
+
if (!printk_enter_irqsave(recursion_ptr, irqflags))
return 0;
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index db4f8ac489d4..714427089cb7 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -18,6 +18,29 @@ config PRINTK_TIME
The behavior is also controlled by the kernel command line
parameter printk.time=1. See Documentation/admin-guide/kernel-parameters.rst
+config PRINTK_EARLY_BOOT_TIMINGS
+ bool "Early boot printk shows times in raw cycle counter style"
+ default 0
+ depends on PRINTK
+ depends on ARM64 || X86_64 || RISCV_TIMER
+ select PRINTK_TIME
+ help
+ Boolean value, disabled by default.
+
+ Set this option to provide cycles information for printks at early
+ boot times (before the start of kernel timekeeping), that would
+ otherwise show as 0.
+
+ Useful for profiling by relative monotonic values, not time.
+
+ Note that this causes the kernel to show, for some early printks,
+ cycles that are relative to processor power on, instead of
+ relative to the start of kernel timekeeping. When kernel
+ timekeeping starts, the timestamps values reset, causing
+ a discontinuity in the timestamp values.
+
+ If unsure, say N.
+
config PRINTK_CALLER
bool "Show caller information on printks"
depends on PRINTK
--
2.34.1
^ permalink raw reply related
* RE: grab-boot-data.sh fails on mkroot (zombies abound)
From: Bird, Tim @ 2026-06-29 20:58 UTC (permalink / raw)
To: Rob Landley, linux-embedded@vger.kernel.org
In-Reply-To: <42eb69fb-928c-4e74-bc2f-aa04eaa97681@landley.net>
> -----Original Message-----
> From: Rob Landley <rob@landley.net>
>
> On 6/18/26 13:40, Bird, Tim wrote:
> > Hey Rob,
> >
> > I tried grab-boot-data.sh on mkroot, using 'toybox sh' as interpreter.
> > I got some weird behavior that I'd like to report. (I was planning on experimenting
> > more to see if I could determine the issue, but I'm going on vacation next week.)
> > Maybe you have an idea off the top of you head what might be the problem...
> >
> > When I use init=/bin/sh, and then try to run grab-boot-data.sh, it always
> > goes zombie after execution.
>
> Do you mean rdinit=? (Or does 7.0 make init= apply to initramfs now?)
Actually, I was doing:
KARGS="quiet initcall_debug log_buf_len=1M HANDOFF=/bin/sh" root/i686/run-qemu.sh
(which I presumed, mistakenly, turned into 'init=/bin/sh' on the kernel command line.)
But, upon closer inspection HANDOFF is handled by root/i686/fs/init, which is a shell script
with this line in it:
setsid -c <>/dev/$(sed '$s@.*[ /]@@' /sys/class/tty/console/active) >&0 2>&1 \
$HANDOFF
>
> Zombies mean the SIGCHLD signal isn't getting consumed by the parent
> process. When a process's parent died, the orphaned child gets
> reparented to init, and PID 1 is weird about signal delivery. In theory
> toysh is setting up a signal handler to do job control, in practice I
> haven't tried it much as PID 1 (and there's different codepaths for job
> control in interactive vs "sh script.sh" mode, and interactive could
> EASILY be screwed up by /dev/console not providing a TTY, which is why
> the init script has that <>/dev/ttyS0 nonsense and the $HANDOFF stuff is
> calling setsid to give the child shell a proper environment.)
>
> I want to run your script, but going back through the mailing list your
> meeting notices just link to jitsi (which has no further info), and
> drilling back trough your posts in my mbox, the first relevant thing I
> spotted was "new page for tracking boot-time activities" post just over
> one year ago, which links to https://elinux.org/Boot-Time_Activities
> which doesn't seem to link to the script? (Unless it was under
> https://birdcloud.org/boot-time/ which is down?)
It was under https://birdcloud.org/boot-time. I was on vacation last week,
and my personal server appears to have crashed (due to Murphy's law of IT problems
while vacationing, I suppose.)
>
> I googled for "tim bird grab-boot-data.sh" and the first hit was
> https://hosted-files.sched.co/ossna2025/6e/Boot-Time-BOF-Bird-ELC-2025-06.pdf
> which links to those two places again.
>
> The second hit was https://lkml.iu.edu/2411.0/07491.html from 2024. Is
> that current?
No.
> There's no git repo for this or anything...?
Yes. It's in this repo:
https://github.com/tbird20d/boot-time-wizard, with blob here:
https://github.com/tbird20d/boot-time-wizard/blob/main/grab-boot-data.sh
>
> Could you leave a trail of breadcrumbs for people who are a little less
> plugged in? I can't currently reproduce what you did from the
> information I have.
Hopefully the above info will help. Thanks for looking into this.
-- Tim
^ permalink raw reply
* Re: grab-boot-data.sh fails on mkroot (zombies abound)
From: Roberto A. Foglietta @ 2026-06-29 21:42 UTC (permalink / raw)
To: Bird, Tim; +Cc: Rob Landley, linux-embedded@vger.kernel.org
In-Reply-To: <MW5PR13MB563273DDAC28AAB1FDF887DAFDE82@MW5PR13MB5632.namprd13.prod.outlook.com>
On Mon, 29 Jun 2026 at 23:00, Bird, Tim <Tim.Bird@sony.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Rob Landley <rob@landley.net>
> >
> > On 6/18/26 13:40, Bird, Tim wrote:
> > > Hey Rob,
> > >
> > > I tried grab-boot-data.sh on mkroot, using 'toybox sh' as interpreter.
> > > I got some weird behavior that I'd like to report. (I was planning on experimenting
> > > more to see if I could determine the issue, but I'm going on vacation next week.)
> > > Maybe you have an idea off the top of you head what might be the problem...
> > >
> > > When I use init=/bin/sh, and then try to run grab-boot-data.sh, it always
> > > goes zombie after execution.
> >
> > Do you mean rdinit=? (Or does 7.0 make init= apply to initramfs now?)
>
> Actually, I was doing:
> KARGS="quiet initcall_debug log_buf_len=1M HANDOFF=/bin/sh" root/i686/run-qemu.sh
> (which I presumed, mistakenly, turned into 'init=/bin/sh' on the kernel command line.)
>
> But, upon closer inspection HANDOFF is handled by root/i686/fs/init, which is a shell script
> with this line in it:
> setsid -c <>/dev/$(sed '$s@.*[ /]@@' /sys/class/tty/console/active) >&0 2>&1 \
> $HANDOFF
>
The init ROB fs is referring to toybox's Rob Ladley, not Rob(erto)
https://github.com/robang74/bare-minimal-linux-system/blob/main/update/initrobfs/init
feel free to help yourself, R-
^ permalink raw reply
* [PATCH] driver core: add driver name to probe debug print
From: Francesco Valla @ 2026-06-29 21:51 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich
Cc: Tim Bird, driver-core, linux-kernel, linux-embedded,
Francesco Valla
The initcall_debug command line option is a useful tool while debugging
and optimizing the initialization of a new system, mainly because it
allows to see probe failures and deferrals without recompiling the
kernel (e.g., with CONFIG_DEBUG_DRIVER). However, matching a device
with the driver it is being probed with can become difficult, since
some devices use names that are not explicit, at least at a first sight
(e.g.: '1-0:1.0' or '1-0060').
Add an additional debug print to inform the user which driver is being
used for a device, allowing for a quick match. The print is inserted in
the same really_probe_debug() wrapper that is already used to report
the result of the probe, and is thus not affecting executions not using
the initcall_debug option.
Suggested-by: Tim Bird <tim.bird@sony.com>
Signed-off-by: Francesco Valla <francesco@valla.it>
---
Hello,
this very small patch comes from a discussion started at the end of
2024 after a Boot Time SIG meeting [1]; I decided to reduce the patch
proposed there by Tim to the bare minimum, as this should already be
enough information for a developer to work with.
I was unsure on whether to add information to the existing print or
introduce a new one; while IMO technically worse, I opted for this
second solution, since the existing print *might* be viewed as
userspace-facing ABI. I'll be happy to do otherwise if there is
consensus.
Thank you!
Regards,
Francesco
[1] https://lore.kernel.org/linux-embedded/MW5PR13MB563277AF5972FD2B56026CF9FD3C2@MW5PR13MB5632.namprd13.prod.outlook.com/
---
drivers/base/dd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 60c005223844..3c0930020050 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -782,6 +782,9 @@ static int really_probe_debug(struct device *dev, const struct device_driver *dr
ktime_t calltime, rettime;
int ret;
+ /* Don't change this to pr_debug() - see comment below. */
+ printk(KERN_DEBUG "probing %s with driver %s\n", dev_name(dev), drv->name);
+
calltime = ktime_get();
ret = really_probe(dev, drv);
rettime = ktime_get();
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260628-probe_driver-3f14e94573f6
Best regards,
--
Francesco Valla <francesco@valla.it>
^ permalink raw reply related
* Re: [PATCH] driver core: add driver name to probe debug print
From: Greg Kroah-Hartman @ 2026-06-30 10:21 UTC (permalink / raw)
To: Francesco Valla
Cc: Rafael J. Wysocki, Danilo Krummrich, Tim Bird, driver-core,
linux-kernel, linux-embedded
In-Reply-To: <20260629-probe_driver-v1-1-fc58117581b5@valla.it>
On Mon, Jun 29, 2026 at 11:51:18PM +0200, Francesco Valla wrote:
> The initcall_debug command line option is a useful tool while debugging
> and optimizing the initialization of a new system, mainly because it
> allows to see probe failures and deferrals without recompiling the
> kernel (e.g., with CONFIG_DEBUG_DRIVER). However, matching a device
> with the driver it is being probed with can become difficult, since
> some devices use names that are not explicit, at least at a first sight
> (e.g.: '1-0:1.0' or '1-0060').
>
> Add an additional debug print to inform the user which driver is being
> used for a device, allowing for a quick match. The print is inserted in
> the same really_probe_debug() wrapper that is already used to report
> the result of the probe, and is thus not affecting executions not using
> the initcall_debug option.
>
> Suggested-by: Tim Bird <tim.bird@sony.com>
> Signed-off-by: Francesco Valla <francesco@valla.it>
> ---
> Hello,
>
> this very small patch comes from a discussion started at the end of
> 2024 after a Boot Time SIG meeting [1]; I decided to reduce the patch
> proposed there by Tim to the bare minimum, as this should already be
> enough information for a developer to work with.
>
> I was unsure on whether to add information to the existing print or
> introduce a new one; while IMO technically worse, I opted for this
> second solution, since the existing print *might* be viewed as
> userspace-facing ABI. I'll be happy to do otherwise if there is
> consensus.
>
> Thank you!
>
> Regards,
> Francesco
>
> [1] https://lore.kernel.org/linux-embedded/MW5PR13MB563277AF5972FD2B56026CF9FD3C2@MW5PR13MB5632.namprd13.prod.outlook.com/
> ---
> drivers/base/dd.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 60c005223844..3c0930020050 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -782,6 +782,9 @@ static int really_probe_debug(struct device *dev, const struct device_driver *dr
> ktime_t calltime, rettime;
> int ret;
>
> + /* Don't change this to pr_debug() - see comment below. */
> + printk(KERN_DEBUG "probing %s with driver %s\n", dev_name(dev), drv->name);
So you now get 2 lines per driver probe attempt?
What exactly is this going to help out with? You aleady get the probe
result line, how is doing 2 going to change anything except explode your
kernel log? Why not just modify the one existing line instead?
And the comment "see below" should mean that you move the comment up
here so that it doesn't need to be repeated.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] driver core: add driver name to probe debug print
From: Francesco Valla @ 2026-06-30 16:00 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rafael J. Wysocki, Danilo Krummrich, Tim Bird, driver-core,
linux-kernel, linux-embedded
In-Reply-To: <2026063043-slouchy-outgoing-a958@gregkh>
Hello Greg,
thank you for the quick feedback.
On Tue, Jun 30, 2026 at 12:21:39PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jun 29, 2026 at 11:51:18PM +0200, Francesco Valla wrote:
> > The initcall_debug command line option is a useful tool while debugging
> > and optimizing the initialization of a new system, mainly because it
> > allows to see probe failures and deferrals without recompiling the
> > kernel (e.g., with CONFIG_DEBUG_DRIVER). However, matching a device
> > with the driver it is being probed with can become difficult, since
> > some devices use names that are not explicit, at least at a first sight
> > (e.g.: '1-0:1.0' or '1-0060').
> >
> > Add an additional debug print to inform the user which driver is being
> > used for a device, allowing for a quick match. The print is inserted in
> > the same really_probe_debug() wrapper that is already used to report
> > the result of the probe, and is thus not affecting executions not using
> > the initcall_debug option.
> >
> > Suggested-by: Tim Bird <tim.bird@sony.com>
> > Signed-off-by: Francesco Valla <francesco@valla.it>
> > ---
> > Hello,
> >
> > this very small patch comes from a discussion started at the end of
> > 2024 after a Boot Time SIG meeting [1]; I decided to reduce the patch
> > proposed there by Tim to the bare minimum, as this should already be
> > enough information for a developer to work with.
> >
> > I was unsure on whether to add information to the existing print or
> > introduce a new one; while IMO technically worse, I opted for this
> > second solution, since the existing print *might* be viewed as
> > userspace-facing ABI. I'll be happy to do otherwise if there is
> > consensus.
> >
> > Thank you!
> >
> > Regards,
> > Francesco
> >
> > [1] https://lore.kernel.org/linux-embedded/MW5PR13MB563277AF5972FD2B56026CF9FD3C2@MW5PR13MB5632.namprd13.prod.outlook.com/
> > ---
> > drivers/base/dd.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> > index 60c005223844..3c0930020050 100644
> > --- a/drivers/base/dd.c
> > +++ b/drivers/base/dd.c
> > @@ -782,6 +782,9 @@ static int really_probe_debug(struct device *dev, const struct device_driver *dr
> > ktime_t calltime, rettime;
> > int ret;
> >
> > + /* Don't change this to pr_debug() - see comment below. */
> > + printk(KERN_DEBUG "probing %s with driver %s\n", dev_name(dev), drv->name);
>
> So you now get 2 lines per driver probe attempt?
>
> What exactly is this going to help out with? You aleady get the probe
> result line, how is doing 2 going to change anything except explode your
> kernel log? Why not just modify the one existing line instead?
>
I was being overzealous with the "don't break the userspace ABI" rule
and included the existing print into this kind of ABI. Given your
response, though, this might not be the case. I'll wait a couple of days
to see if anyone has something to add and then send a V2 that adds the
driver name to the existent print (solution that I technically prefer).
> And the comment "see below" should mean that you move the comment up
> here so that it doesn't need to be repeated.
>
> thanks,
>
> greg k-h
Regards,
Francesco
^ permalink raw reply
* Re: [PATCH] driver core: add driver name to probe debug print
From: Greg Kroah-Hartman @ 2026-06-30 20:40 UTC (permalink / raw)
To: Francesco Valla
Cc: Rafael J. Wysocki, Danilo Krummrich, Tim Bird, driver-core,
linux-kernel, linux-embedded
In-Reply-To: <akPnMERmg-QO6kjC@bywater>
On Tue, Jun 30, 2026 at 06:00:17PM +0200, Francesco Valla wrote:
> Hello Greg,
>
> thank you for the quick feedback.
>
> On Tue, Jun 30, 2026 at 12:21:39PM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Jun 29, 2026 at 11:51:18PM +0200, Francesco Valla wrote:
> > > The initcall_debug command line option is a useful tool while debugging
> > > and optimizing the initialization of a new system, mainly because it
> > > allows to see probe failures and deferrals without recompiling the
> > > kernel (e.g., with CONFIG_DEBUG_DRIVER). However, matching a device
> > > with the driver it is being probed with can become difficult, since
> > > some devices use names that are not explicit, at least at a first sight
> > > (e.g.: '1-0:1.0' or '1-0060').
> > >
> > > Add an additional debug print to inform the user which driver is being
> > > used for a device, allowing for a quick match. The print is inserted in
> > > the same really_probe_debug() wrapper that is already used to report
> > > the result of the probe, and is thus not affecting executions not using
> > > the initcall_debug option.
> > >
> > > Suggested-by: Tim Bird <tim.bird@sony.com>
> > > Signed-off-by: Francesco Valla <francesco@valla.it>
> > > ---
> > > Hello,
> > >
> > > this very small patch comes from a discussion started at the end of
> > > 2024 after a Boot Time SIG meeting [1]; I decided to reduce the patch
> > > proposed there by Tim to the bare minimum, as this should already be
> > > enough information for a developer to work with.
> > >
> > > I was unsure on whether to add information to the existing print or
> > > introduce a new one; while IMO technically worse, I opted for this
> > > second solution, since the existing print *might* be viewed as
> > > userspace-facing ABI. I'll be happy to do otherwise if there is
> > > consensus.
> > >
> > > Thank you!
> > >
> > > Regards,
> > > Francesco
> > >
> > > [1] https://lore.kernel.org/linux-embedded/MW5PR13MB563277AF5972FD2B56026CF9FD3C2@MW5PR13MB5632.namprd13.prod.outlook.com/
> > > ---
> > > drivers/base/dd.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> > > index 60c005223844..3c0930020050 100644
> > > --- a/drivers/base/dd.c
> > > +++ b/drivers/base/dd.c
> > > @@ -782,6 +782,9 @@ static int really_probe_debug(struct device *dev, const struct device_driver *dr
> > > ktime_t calltime, rettime;
> > > int ret;
> > >
> > > + /* Don't change this to pr_debug() - see comment below. */
> > > + printk(KERN_DEBUG "probing %s with driver %s\n", dev_name(dev), drv->name);
> >
> > So you now get 2 lines per driver probe attempt?
> >
> > What exactly is this going to help out with? You aleady get the probe
> > result line, how is doing 2 going to change anything except explode your
> > kernel log? Why not just modify the one existing line instead?
> >
>
> I was being overzealous with the "don't break the userspace ABI" rule
> and included the existing print into this kind of ABI. Given your
> response, though, this might not be the case. I'll wait a couple of days
> to see if anyone has something to add and then send a V2 that adds the
> driver name to the existent print (solution that I technically prefer).
printk() messages are NOT a userspace ABI so all should be fine.
Especially for debugging messages :)
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH] driver core: add driver name to probe debug print
From: Bird, Tim @ 2026-07-02 15:53 UTC (permalink / raw)
To: Francesco Valla, Greg Kroah-Hartman
Cc: Rafael J. Wysocki, Danilo Krummrich, driver-core@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org
In-Reply-To: <akPnMERmg-QO6kjC@bywater>
> -----Original Message-----
> From: Francesco Valla <francesco@valla.it>
> Hello Greg,
>
> thank you for the quick feedback.
>
> On Tue, Jun 30, 2026 at 12:21:39PM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Jun 29, 2026 at 11:51:18PM +0200, Francesco Valla wrote:
> > > The initcall_debug command line option is a useful tool while debugging
> > > and optimizing the initialization of a new system, mainly because it
> > > allows to see probe failures and deferrals without recompiling the
> > > kernel (e.g., with CONFIG_DEBUG_DRIVER). However, matching a device
> > > with the driver it is being probed with can become difficult, since
> > > some devices use names that are not explicit, at least at a first sight
> > > (e.g.: '1-0:1.0' or '1-0060').
> > >
> > > Add an additional debug print to inform the user which driver is being
> > > used for a device, allowing for a quick match. The print is inserted in
> > > the same really_probe_debug() wrapper that is already used to report
> > > the result of the probe, and is thus not affecting executions not using
> > > the initcall_debug option.
> > >
> > > Suggested-by: Tim Bird <tim.bird@sony.com>
> > > Signed-off-by: Francesco Valla <francesco@valla.it>
> > > ---
> > > Hello,
> > >
> > > this very small patch comes from a discussion started at the end of
> > > 2024 after a Boot Time SIG meeting [1]; I decided to reduce the patch
> > > proposed there by Tim to the bare minimum, as this should already be
> > > enough information for a developer to work with.
> > >
> > > I was unsure on whether to add information to the existing print or
> > > introduce a new one; while IMO technically worse, I opted for this
> > > second solution, since the existing print *might* be viewed as
> > > userspace-facing ABI. I'll be happy to do otherwise if there is
> > > consensus.
> > >
> > > Thank you!
> > >
> > > Regards,
> > > Francesco
> > >
> > > [1] https://lore.kernel.org/linux-
> embedded/MW5PR13MB563277AF5972FD2B56026CF9FD3C2@MW5PR13MB5632.namprd13.prod.outlook.com/
> > > ---
> > > drivers/base/dd.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> > > index 60c005223844..3c0930020050 100644
> > > --- a/drivers/base/dd.c
> > > +++ b/drivers/base/dd.c
> > > @@ -782,6 +782,9 @@ static int really_probe_debug(struct device *dev, const struct device_driver *dr
> > > ktime_t calltime, rettime;
> > > int ret;
> > >
> > > + /* Don't change this to pr_debug() - see comment below. */
> > > + printk(KERN_DEBUG "probing %s with driver %s\n", dev_name(dev), drv->name);
> >
> > So you now get 2 lines per driver probe attempt?
> >
> > What exactly is this going to help out with? You aleady get the probe
> > result line, how is doing 2 going to change anything except explode your
> > kernel log? Why not just modify the one existing line instead?
> >
>
> I was being overzealous with the "don't break the userspace ABI" rule
> and included the existing print into this kind of ABI. Given your
> response, though, this might not be the case. I'll wait a couple of days
> to see if anyone has something to add and then send a V2 that adds the
> driver name to the existent print (solution that I technically prefer).
I examined scripts/bootgraph.pl, bootchart, tools/power/pm-graph/bootgraph.py
systemd-analyze and some others that parse dmesg lines produced by the initcall_debug
option (including my own tools).
The only tool I found that parses the probe debug lines is analyze-initcall-debug.py
- which is your program, and we discussed that you planned to modify that tool to
accept both old and new string formats for this line.
This is all to say that I'm not aware of anything that will break if you change the
format of the existing probe debug line. So my vote would be to add the driver
name to the existing printk line. Of course, it would be great if you can do so conservatively
(that is, keeping most of the string elements intact and in the same order, so that existing parsers
that we might not be aware of don't break).
I'll be glad to see this extra data available.
-- Tim
^ permalink raw reply
* [PATCH v2] driver core: add driver name to probe debug print
From: Francesco Valla @ 2026-07-03 15:10 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich
Cc: Tim Bird, driver-core, linux-kernel, linux-embedded,
Francesco Valla
The initcall_debug command line option is a useful tool while debugging
and optimizing the initialization of a new system, mainly because it
allows to see probe failures and deferrals without recompiling the
kernel (e.g., with CONFIG_DEBUG_DRIVER). However, matching a device
with the driver it is being probed with can become difficult, since
some devices use names that are not explicit, at least at a first sight
(e.g.: '1-0:1.0' or '1-0060').
Add the driver name alongside the device name, to allow for an immediate
match between the two.
Suggested-by: Tim Bird <tim.bird@sony.com>
Signed-off-by: Francesco Valla <francesco@valla.it>
---
Hello,
this very small patch comes from a discussion started at the end of
2024 after a Boot Time SIG meeting [1]; I decided to reduce the patch
proposed there by Tim to the bare minimum, as this should already be
enough information for a developer to work with.
Thank you!
Regards,
Francesco
[1] https://lore.kernel.org/linux-embedded/MW5PR13MB563277AF5972FD2B56026CF9FD3C2@MW5PR13MB5632.namprd13.prod.outlook.com/
---
Changes in v2:
- Moved driver name in the existent print instead of introducing a new
one.
- Link to v1: https://patch.msgid.link/20260629-probe_driver-v1-1-fc58117581b5@valla.it
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
To: Danilo Krummrich <dakr@kernel.org>
Cc: driver-core@lists.linux.dev
Cc: linux-kernel@vger.kernel.org
---
drivers/base/dd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 60c005223844..f6525a7ee8c5 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -790,8 +790,8 @@ static int really_probe_debug(struct device *dev, const struct device_driver *dr
* CONFIG_DYNAMIC_DEBUG and we want a simple 'initcall_debug' on the
* kernel commandline to print this all the time at the debug level.
*/
- printk(KERN_DEBUG "probe of %s returned %d after %lld usecs\n",
- dev_name(dev), ret, ktime_us_delta(rettime, calltime));
+ printk(KERN_DEBUG "probe of %s with driver %s returned %d after %lld usecs\n",
+ dev_name(dev), drv->name, ret, ktime_us_delta(rettime, calltime));
return ret;
}
---
base-commit: d2c9a99135da931377240942d44f3dea104cedb8
change-id: 20260628-probe_driver-3f14e94573f6
Best regards,
--
Francesco Valla <francesco@valla.it>
^ permalink raw reply related
* Re: [PATCH v2] driver core: add driver name to probe debug print
From: Danilo Krummrich @ 2026-07-03 16:59 UTC (permalink / raw)
To: Francesco Valla
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Tim Bird, driver-core,
linux-kernel, linux-embedded
In-Reply-To: <20260703-probe_driver-v2-1-b6060559f33b@valla.it>
On Fri Jul 3, 2026 at 5:10 PM CEST, Francesco Valla wrote:
> The initcall_debug command line option is a useful tool while debugging
> and optimizing the initialization of a new system, mainly because it
> allows to see probe failures and deferrals without recompiling the
> kernel (e.g., with CONFIG_DEBUG_DRIVER). However, matching a device
> with the driver it is being probed with can become difficult, since
> some devices use names that are not explicit, at least at a first sight
> (e.g.: '1-0:1.0' or '1-0060').
>
> Add the driver name alongside the device name, to allow for an immediate
> match between the two.
>
> Suggested-by: Tim Bird <tim.bird@sony.com>
> Signed-off-by: Francesco Valla <francesco@valla.it>
Acked-by: Danilo Krummrich <dakr@kernel.org>
^ permalink raw reply
* RE: [PATCH v2 2/5] software node: add fw_devlink support
From: Bird, Tim @ 2026-07-06 16:55 UTC (permalink / raw)
To: Bartosz Golaszewski; +Cc: Embedded Linux mailing list
In-Reply-To: <20260706-swnode-fw-devlink-v2-2-f39b09d50112@oss.qualcomm.com>
Hey Bartosz,
Can you also please CC: linux-embedded@vger.kernel.org on this patch set, in the future?
There are a few embedded Linux developers working on boot-time for the Linux kernel,
who are interested in this work.
Thanks,
-- Tim
> -----Original Message-----
> From: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Sent: Monday, July 6, 2026 6:54 AM
> To: Brendan Higgins <brendan.higgins@linux.dev>; David Gow <david@davidgow.net>; Rae Moar <raemoar63@gmail.com>; Andy
> Shevchenko <andriy.shevchenko@linux.intel.com>; Daniel Scally <djrscally@gmail.com>; Heikki Krogerus <heikki.krogerus@linux.intel.com>;
> Sakari Ailus <sakari.ailus@linux.intel.com>; Bartosz Golaszewski <brgl@kernel.org>; Greg Kroah-Hartman <gregkh@linuxfoundation.org>;
> Rafael J. Wysocki <rafael@kernel.org>; Danilo Krummrich <dakr@kernel.org>; Linus Walleij <linusw@kernel.org>; Dmitry Torokhov
> <dmitry.torokhov@gmail.com>
> Cc: linux-kernel@vger.kernel.org; linux-kselftest@vger.kernel.org; kunit-dev@googlegroups.com; linux-acpi@vger.kernel.org; driver-
> core@lists.linux.dev; linux-gpio@vger.kernel.org; Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Subject: [PATCH v2 2/5] software node: add fw_devlink support
>
> Software nodes can be used to describe supplier-consumer relationships between devices they represent using reference property entries.
> Unlike for OF-nodes, driver core cannot yet use these references to create a probe order that avoids needless
>
> Software nodes can be used to describe supplier-consumer relationships
> between devices they represent using reference property entries. Unlike
> for OF-nodes, driver core cannot yet use these references to create a
> probe order that avoids needless probe deferrals on missing providers.
>
> Implement software_node_add_links() modelled on of_fwnode_add_links().
> For every DEV_PROP_REF property we resolve each referenced supplier and
> create an fwnode link from the node to it. The driver core later promotes
> these to device links and defers the consumer until the suppliers are
> ready.
>
> There's no allowlist like the one DT needs - devicetree phandles appear
> in plenty of non-supplier contexts, but a software node only carries a
> reference property when its author explicitly points at another node, so
> we treat every reference as an intentional supplier dependency and link
> all of them. Graph "remote-endpoint" references are skipped for now: they
> go 2-ways between endpoint nodes and would create graph cycles without
> the port-parent lifting DT does via get_con_dev(). References to
> suppliers that aren't registered yet and self-references are ignored.
>
> fw_devlink resolves the supplier device through fwnode->dev but the core
> only records the owning device on the primary fwnode. When the software
> node is a device's secondary fwnode, mirror the device pointer onto it in
> software_node_notify() so the consumer can actually find the supplier
> instead of deferring forever.
>
> While at it: purge the fwnode links in software_node_release() now that
> software nodes can own them.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> drivers/base/swnode.c | 79 +++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 79 insertions(+)
>
> diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
> index 869228a65cb365567ddac7db6ad7b8743e0dbca9..e6e2d6926fef2db82eb1f2bf439e80aacf48668a 100644
> --- a/drivers/base/swnode.c
> +++ b/drivers/base/swnode.c
> @@ -699,6 +699,62 @@ software_node_graph_parse_endpoint(const struct fwnode_handle *fwnode,
> return 0;
> }
>
> +static int software_node_add_links(struct fwnode_handle *fwnode)
> +{
> + const struct software_node_ref_args *ref, *ref_array;
> + struct swnode *swnode = to_swnode(fwnode);
> + const struct property_entry *prop;
> + struct fwnode_handle *refnode;
> + unsigned int count;
> +
> + if (!swnode || !swnode->node->properties)
> + return 0;
> +
> + /*
> + * Unlike Device Tree, where phandles appear in many non-supplier
> + * contexts and a curated allowlist is required, a software node only
> + * carries a DEV_PROP_REF property when the author explicitly describes
> + * a reference to another node. Every such reference is therefore an
> + * intentional supplier dependency, so we create fwnode links for all
> + * of them.
> + */
> + for (prop = swnode->node->properties; prop->name; prop++) {
> + if (prop->type != DEV_PROP_REF || prop->is_inline)
> + continue;
> +
> + /*
> + * TODO: Graph "remote-endpoint" references go both ways
> + * between endpoint child nodes and would create endpoint
> + * cycles. Let's leave it out for now until we have potential
> + * users.
> + */
> + if (!strcmp(prop->name, "remote-endpoint"))
> + continue;
> +
> + ref_array = prop->pointer;
> + count = prop->length / sizeof(*ref_array);
> +
> + for (unsigned int i = 0; i < count; i++) {
> + ref = &ref_array[i];
> +
> + if (ref->swnode)
> + refnode = software_node_fwnode(ref->swnode);
> + else if (ref->fwnode)
> + refnode = ref->fwnode;
> + else
> + continue;
> +
> + /* Supplier not registered yet, or self-reference. */
> + if (!refnode || refnode == &swnode->fwnode)
> + continue;
> +
> + fwnode_link_add(&swnode->fwnode, refnode, 0);
> + }
> + }
> +
> + return 0;
> +}
> +
> static const struct fwnode_operations software_node_ops = {
> .get = software_node_get,
> .put = software_node_put,
> @@ -716,6 +772,7 @@ static const struct fwnode_operations software_node_ops = {
> .graph_get_remote_endpoint = software_node_graph_get_remote_endpoint,
> .graph_get_port_parent = software_node_graph_get_port_parent,
> .graph_parse_endpoint = software_node_graph_parse_endpoint,
> + .add_links = software_node_add_links,
> };
>
> /* -------------------------------------------------------------------------- */
> @@ -787,6 +844,8 @@ static void software_node_release(struct kobject *kobj)
> {
> struct swnode *swnode = kobj_to_swnode(kobj);
>
> + fwnode_links_purge(&swnode->fwnode);
> +
> if (swnode->parent) {
> ida_free(&swnode->parent->child_ids, swnode->id);
> list_del(&swnode->entry);
> @@ -1105,6 +1164,17 @@ void software_node_notify(struct device *dev)
> if (!swnode)
> return;
>
> + /*
> + * When the software node is the device's secondary firmware node,
> + * the core only records the owning device on the primary fwnode
> + * (see device_add()). fw_devlink resolves a supplier device through
> + * fwnode->dev, so without this a consumer referencing the software
> + * node could never find the supplier device and would defer forever.
> + * Make fwnode.dev point to its owner in that case.
> + */
> + if (dev_fwnode(dev) != &swnode->fwnode && !swnode->fwnode.dev)
> + swnode->fwnode.dev = dev;
> +
> swnode_get(swnode);
> ret = sysfs_create_link(&dev->kobj, &swnode->kobj, "software_node");
> if (ret)
> @@ -1127,6 +1197,15 @@ void software_node_notify_remove(struct device *dev)
>
> sysfs_remove_link(&swnode->kobj, dev_name(dev));
> sysfs_remove_link(&dev->kobj, "software_node");
> +
> + /*
> + * Drop the device pointer mirrored onto a secondary software node in
> + * software_node_notify(). For a primary software node the core owns
> + * fwnode->dev and clears it in device_del().
> + */
> + if (dev_fwnode(dev) != &swnode->fwnode && swnode->fwnode.dev == dev)
> + swnode->fwnode.dev = NULL;
> +
> swnode_put(swnode);
>
> if (swnode->managed) {
>
> --
> 2.47.3
>
^ permalink raw reply
page: | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox