Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #94793

Bug#1151632: linux: config: consider setting DRIVER_DEFERRED_PROBE_TIMEOUT to -1 (arm64 luks laptops)

From Ben Hutchings <ben@decadent.org.uk>
Newsgroups linux.debian.bugs.dist, linux.debian.kernel
Subject Bug#1151632: linux: config: consider setting DRIVER_DEFERRED_PROBE_TIMEOUT to -1 (arm64 luks laptops)
Date 2026-11-05 15:00 +0100
Message-ID <NW6at-a013-1@gated-at.bofh.it> (permalink)
References <NR1uN-7bXB-3@gated-at.bofh.it> <NR1uN-7bXB-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Cross-posted to 2 groups.

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

On Thu, 22 Oct 2026 15:48:25 +0200 Agathe Porte <agathe.porte@oss.qualcomm.com> wrote:
> Source: linux
> Version: 7.2.11-1
> Severity: wishlist
> X-Debbugs-Cc: debian-arm@lists.debian.org, agathe.porte@oss.qualcomm.com
> User: debian-arm@lists.debian.org
> Usertags: arm64
> 
> Dear Maintainer,
> 
> (self-reporting, I intent to create the necessary PRs in salsa)
> 
> arm64 laptops that are using luks encryption need to set the
> deferred_probe_timeout=30 command-line option to avoid having a timeout
> while typing the LUKS password.

What specifically times-out here?
 
> Quoting the commit [1] that introduced DRIVER_DEFERRED_PROBE_TIMEOUT as
> a Kconfig option for the justification:
> 
> > Code using driver_deferred_probe_check_state() differs from most
> > EPROBE_DEFER handling in the kernel. Where other EPROBE_DEFER handling
> > (e.g. clks, gpios and regulators) waits indefinitely for suppliers to
> > show up, code using driver_deferred_probe_check_state() will fail
> > after the deferred_probe_timeout.
> > 
> > This is a problem for generic distro kernels which want to support many
> > boards using a single kernel build. These kernels want as much drivers to
> > be modular as possible. The initrd also should be as small as possible,
> > so the initrd will *not* have drivers not needing to get the rootfs.

I don't entirely follow the logic here.  If the dependencies aren't
needed in the initramfs, that means the drivers depending on them also
aren't needed, so then shouldn't those also be excluded from the
initramfs?  (I understand that the dependencies are discovered at boot
time from the device tree and the initramfs builder won't be able to see
them.  But this still seems strange to me.)

> > Combine this with waiting for a full-disk encryption password in
> > the initrd and it is pretty much guaranteed that the default 10s timeout
> > will be hit, causing probe() failures when drivers on the rootfs happen
> > to get modprobe-d before other rootfs modules providing their suppliers.
> > 
> > Make the default timeout configurable from Kconfig to allow distro kernel
> > configs where many of the supplier drivers are modules to set the default
> > through Kconfig.
> > 
> > Reviewed-by: Saravana Kannan <saravanak@kernel.org>
> > Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> > Link: https://patch.msgid.link/20260314084916.10868-1-johannes.goede@oss.qualcomm.com
> > [ Drop deferred_probe_timeout documentation change in
> >   kernel-parameters.txt. - Danilo ]
> > Signed-off-by: Danilo Krummrich <dakr@kernel.org>
> 
> Since this option now allows for distributions to change the default 10s
> value to something else, we can now tweak the Debian kernel to have a
> more generous timeout (eg. 30s) or even disable the timeout so that
> taking time to enter a LUKS decryption key does not lead to driver
> timeouts on arm64 laptops.

It sounds like there have been multiple fixes here that weren't entirely
thought out:

1. Sometimes devices don't get detected in the right order, and probes
fail because dependencies haven't yet been probed.
2. Introduce -EPROBE_DEFER and retry all probes that return that.  But
now we can keep retrying probes that will never succeeed.
3. Add a timeout to (some) retries.  But now a long wait in the
initramfs will mean we timeout probes that can succeed after it hands
over to the main system.
4. Allow the time limit to be turned off at build or boot time.  GOTO 2.

You are proposing step 4, and I do agree with the reasoning for it, yet
that can also be a regression.  Would it not be better to add a way to
reduce the timeout once the main system is running?

Ben.

> 
> Thanks,
> 
> Agathe.
> 
> [1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/base/Kconfig?id=56e3ee721b33bdc4ce0765d370983aa4384f8a59
> 
> 

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

Back to linux.debian.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

Bug#1151632: linux: config: consider setting DRIVER_DEFERRED_PROBE_TIMEOUT to -1 (arm64 luks laptops) Agathe Porte <agathe.porte@oss.qualcomm.com> - 2026-10-22 16:00 +0200
  Bug#1151632: linux: config: consider setting DRIVER_DEFERRED_PROBE_TIMEOUT to -1 (arm64 luks laptops) Ben Hutchings <ben@decadent.org.uk> - 2026-11-05 15:00 +0100

csiph-web