linux-kernel - Kernel command line seems broken when compiling vanilla source under Fedora 18

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <50FEB852.70304@palosanto.com>
Date:	Tue, 22 Jan 2013 11:03:30 -0500
From:	Alex Villacís Lasso 
	<a_villacis@...osanto.com>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Kernel command line seems broken when compiling vanilla source under
 Fedora 18

If this is not the correct list for this discussion, please indicate which list should be used.

I am having this strange issue. My computer has a LCD display that does not send any EDID, and therefore I need the command parameter "drm_kms_helper.edid_firmware=edid/1280x1024.bin" In Fedora 16, the stock kernel does not have 
CONFIG_DRM_LOAD_EDID_FIRMWARE set. Therefore I compiled my own kernel from vanilla sources, and the parameter worked. I have just now upgraded to Fedora 18. The new stock kernel is supposed to have CONFIG_DRM_LOAD_EDID_FIRMWARE set, but when I boot with 
the drm_kms_helper parameter, I get a message "drm_kms_helper: Unknown parameter `bin'". I thought this was a kernel bug caused by some patch in the stock kernel, so I filed https://bugzilla.redhat.com/show_bug.cgi?id=901899 , and then proceeded to compile 
3.8-rc4 from vanilla sources. However, I am surprised to find that the vanilla sources, when compiled under Fedora 18, exhibit the same bug. Has anyone seen a situation like this? Is this a possible compiler bug in Fedora 18? A grub2 bug? Apparently the 
kernel is misparsing the commandline parameter and thinks "bin" is the module parameter, not "edid_firmware".

I checked that I have CONFIG_DYNAMIC_DEBUG=y in my kernel config, and I tried adding dyndbg="file params.c +p" to the kernel command line, but I see no additional debug output that might point out what is happening.

View attachment "dmesg.txt" of type "text/plain" (56347 bytes)