kmod-maint January 2013

kmod-maint@lists.fedoraproject.org

2 participants
19 discussions

[Bug 901899] kernel command line parameter parsing is broken at drm_kms_helper.edid_firmware
by Red Hat Bugzilla 27 Jan '13

27 Jan '13

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=901899 --- Comment #13 from Josh Boyer <jwboyer(a)redhat.com> --- Or 1 and 3 combined. At any rate, this bug is to fix the cmdline parsing in kmod, which it does. It's also not kmod's fault things are getting delayed. This is probably something that needs to be resolved in the upstream kernel one way or another. There's nothing kmod itself can do about it. -- 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=z3ADCVKKu0&a=cc_unsubscribe

1 0

[Bug 901899] kernel command line parameter parsing is broken at drm_kms_helper.edid_firmware
by Red Hat Bugzilla 27 Jan '13

27 Jan '13

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

1 0

[Bug 901899] kernel command line parameter parsing is broken at drm_kms_helper.edid_firmware
by Red Hat Bugzilla 27 Jan '13

27 Jan '13

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=901899 --- Comment #11 from Alex Villacís Lasso <a_villacis(a)palosanto.com> --- I verified on 3.8-rc5 that the kernel uses request_firmware first. I patched and compiled 3.8-rc5 with the load order reversed (builtin, then request_firmware), and this makes the kernel proceed immediately (no filesystem mount delay). However, this still does not explain why the filesystem mount would get a delay if request_firmware is called before the filesystem is mounted. I used to boot 3.8-rc3 under Fedora 16, and there were no delays, without any need to patch the kernel. Why does the request_firmware call delay the filesystem mount in Fedora 18? -- 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=akng6Babvz&a=cc_unsubscribe

1 0

[Bug 901899] kernel command line parameter parsing is broken at drm_kms_helper.edid_firmware
by Red Hat Bugzilla 27 Jan '13

27 Jan '13

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=901899 --- Comment #10 from Josh Boyer <jwboyer(a)redhat.com> --- The drm_kms_helper calls request_firmware before it searches the built-in firmwares. Saying something works in F16 isn't particularly helpful as there are several differences. Namely, the 3.7 kernel changed how it loads firmware because udev changed how it handles firmware/module loading as well. I forget all the details but Kay should remember. -- 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=jz3cbLFvM3&a=cc_unsubscribe

1 0

[Bug 901899] kernel command line parameter parsing is broken at drm_kms_helper.edid_firmware
by Red Hat Bugzilla 27 Jan '13

27 Jan '13

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

1 0

[Bug 901899] kernel command line parameter parsing is broken at drm_kms_helper.edid_firmware
by Red Hat Bugzilla 27 Jan '13

27 Jan '13

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

1 0

[Bug 901899] kernel command line parameter parsing is broken at drm_kms_helper.edid_firmware
by Red Hat Bugzilla 26 Jan '13

26 Jan '13

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=901899 --- Comment #7 from Alex Villacís Lasso <a_villacis(a)palosanto.com> --- Created attachment 688186 --> https://bugzilla.redhat.com/attachment.cgi?id=688186&action=edit dmesg after kmod-12 update, shows 30-second delay in boot process -- 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=v7DNrVjR4u&a=cc_unsubscribe

1 0

[Bug 901899] kernel command line parameter parsing is broken at drm_kms_helper.edid_firmware
by Red Hat Bugzilla 26 Jan '13

26 Jan '13

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

1 0

[Bug 901899] kernel command line parameter parsing is broken at drm_kms_helper.edid_firmware
by Red Hat Bugzilla 25 Jan '13

25 Jan '13

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=901899 --- Comment #5 from Fedora Update System <updates(a)fedoraproject.org> --- Package kmod-12-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kmod-12-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-1482/kmod-12-1.fc18 then log in and leave karma (feedback). -- 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=23kveorINe&a=cc_unsubscribe

1 0

[Bug 901899] kernel command line parameter parsing is broken at drm_kms_helper.edid_firmware
by Red Hat Bugzilla 25 Jan '13

25 Jan '13

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=901899 Fedora Update System <updates(a)fedoraproject.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |ON_QA -- 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=rAVwbbTwBo&a=cc_unsubscribe

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

kmod-maint January 2013