[Bug 901899] kernel command line parameter parsing is broken at drm_kms_helper.edid_firmware
by Red Hat Bugzilla
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
11 years, 3 months
[Bug 901899] kernel command line parameter parsing is broken at drm_kms_helper.edid_firmware
by Red Hat Bugzilla
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=901899
--- Comment #9 from Alex Villacís Lasso <a_villacis(a)palosanto.com> ---
The file edid/1280x1024.bin happens to be one of the built-in EDID files. I
chose that one because it fits my monitor and I did not want to deal with
building my own EDID file. There are no custom EDID files under /lib/firmware,
under any name. Why should the kernel wait for the filesystem to be mounted
before loading a built-in EDID? This same command line parameter caused no
delays whatsoever under Fedora 16. Additionally, why should the kernel
parameter for drm cause a delay on filesystem mount? There are no delays at all
when I remove the drm_kms_helper parameter. If the kernel wants to hit the
filesystem before checking that the EDID is a built-in one, it should hurry up
and mount sdb2 as soon as possible.
--
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=ggf76yenkp&a=cc_unsubscribe
11 years, 3 months
[Bug 901899] kernel command line parameter parsing is broken at drm_kms_helper.edid_firmware
by Red Hat Bugzilla
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=901899
Josh Boyer <jwboyer(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kay(a)redhat.com
--- Comment #8 from Josh Boyer <jwboyer(a)redhat.com> ---
You have two delays here. The first seems to be mounting the ext4 filesystem
on sdb2 of ~30 seconds. That seems unrelated.
The second delay is ~60 seconds from the last DRM printk to the EDID loading
line. That happens to be the amount of time the in-kernel firmware loader will
wait before the firmware is loaded.
My guess here is that your rootfs is on sdb2. The drm layer makes it's
request_firmware call before your rootfs is loaded, and the .bin file for your
EDID information is not included in your initramfs. Since the rootfs isn't
mounted yet, it can't access the file directly and has to do the timeout route.
I don't think that is actually an issue in kmod at all. It's being done in the
kernel, and the kernel is acting as it should.
Kay, you've had quite a bit of experience with this. Does the above
explanation sound plausible?
--
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=PjhyXfjVQi&a=cc_unsubscribe
11 years, 3 months
[Bug 901899] kernel command line parameter parsing is broken at drm_kms_helper.edid_firmware
by Red Hat Bugzilla
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=901899
--- Comment #6 from Alex Villacís Lasso <a_villacis(a)palosanto.com> ---
I tried updating kmod and kmod-libs from updates-testing before doing a yum
update. This latest ordinary update happened to offer a kernel update to
kernel-3.7.4-204.fc18.x86_64 , so I used that for testing. When I added the
line drm_kms_helper.edid_firmware=edid/1280x1024.bin , the kernel boot process
hanged for half a minute (?!?!?), but then continued normally and obeyed the
parameter. The good news is that the kernel parameter was parsed correctly. The
bad news is that the delay in the kernel boot is unacceptable. If I remove the
drm_kms_helper line, then the kernel boots without delays, just as before.
The kernel delay is apparent in the dmesg output:
[ 0.879583] systemd[1]: Starting Local File Systems.
[ 0.879601] systemd[1]: Reached target Local File Systems.
[ 1.003678] systemd-udevd[123]: starting version 197
[ 1.161523] [drm] Initialized drm 1.1.0 20060810
[ 1.183925] checking generic (d0000000 130000) vs hw (d0000000 10000000)
[ 1.183928] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing
generic driver
[ 0.714564] ACPI: Invalid Power Resource to register!
[ 1.183942] Console: switching
[ 1.183943] to colour dummy device 80x25
[ 1.184032] i915 0000:00:02.0: setting latency timer to 64
[ 1.206537] i915 0000:00:02.0: irq 42 for MSI/MSI-X
[ 1.206546] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 1.206547] [drm] Driver supports precise vblank timestamp query.
[ 1.206577] vgaarb: device changed decodes:
PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 1.207743] [drm] initialized overlay support
[ 1.291200] input: ImPS/2 Generic Wheel Mouse as
/devices/platform/i8042/serio1/input/input3
[ 1.440027] tsc: Refined TSC clocksource calibration: 2755.321 MHz
[ 1.440035] Switching to clocksource tsc
[ 31.613019] EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts:
(null)
[ 31.758218] EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts:
(null)
[ 61.408164] [drm] Got built-in EDID base block and 0 extensions from
"edid/1280x1024.bin" for connector "VGA-1"
[ 61.413664] fbcon: inteldrmfb (fb0) is primary device
[ 61.481068] Console: switching to colour frame buffer device 160x64
[ 61.486625] fb0: inteldrmfb frame buffer device
[ 61.486627] drm: registered panic notifier
[ 61.486677] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor
0
[ 61.574967] systemd-journald[64]: Received SIGTERM
[ 62.094118] type=1404 audit(1359241072.059:2): enforcing=1 old_enforcing=0
auid=4294967295 ses=4294967295
Notice the jump from 1.440035 to 31.613019.
--
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=nlYmTXue1Y&a=cc_unsubscribe
11 years, 3 months