Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #94793
| 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.
[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
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