Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=901899
--- Comment #12 from Kay Sievers <kay(a)redhat.com> ---
This is the log from the initramfs, and I would suspect both timeouts
are caused by a firmware request which cannot be fulfilled. As you said above,
caused by missing firmware files inside the initramfs.
Udev gives up waiting for its event handler after 30 seconds, that might be
the 2 timeouts we see here, likely a blocking module_init().
The drm driver unconditionally calls request_firmware(), if that happens
inside the initramfs, udev will not cancel the request but leave it stay
around until we reach the udev in the real rootfs.
We no longer cancel firmware requests in the initramfs, to be able to handle
them after the rootfs is mounted. It was supposed to work around a set of
other problems with missing firmware files in the initramfs.
From a general view, this seems all too fragile, and whatever
behaviour we
change with the userspace firmware loading, it seems to cause some sort
of
misbehaviour somewhere else. The whole userspace firmware loading was a pretty
bad idea from day one, and caused nothing but problems so far.
In recent kernels, the loading is handled in a very simple and non-blocking
way inside the kernel, without the need for any of the fragile userspace
transaction kludge, which might block module loading for 60 seconds.
We should really just get rid of the entire userspace firmware loading
hackery and rely on the recent in-kernel loading only. That means adding
a kernel config option for the userspace callout and disable that option
in our kernel config.
It is planned anyway in the long run, to remove all the firmware loading
code from userspace tools, and rely solely on the in-kernel loading. The
whole userspace loop was a nice theory, but after all the years, we just need
to admit that theory and reality did not match; it created far more
problems than it has ever solved.
I see the following options to fix that:
1. make drm check for built-in firmware first, and not unconditionally call
out to userspace
2. cancel all non-fulfillable firmware requests inside the initramfs, to
prevent the in-kernel firmware timeouts to block module_init()
3. rely on the (robust, non-blocking) in-kernel firmware loading only,
and entirely disable the (fragile, blocking) userspace firmware loading
callout in the kernel
I would vote for trying 3., because that is what we want in the log rune
anyway.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=vgwQcFmNyd&a=cc_unsubscribe