linux-kernel - Re: Intel graphics drm issue?

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20121014224057.2033a769@neptune.home>
Date:	Sun, 14 Oct 2012 22:40:57 +0200
From:	Bruno Prémont <bonbons@...ux-vserver.org>
To:	dmarkh@....rr.com
Cc:	markh@...pro.net, linux-kernel@...r.kernel.org,
	Intel Graphics Development <intel-gfx@...ts.freedesktop.org>
Subject: Re: Intel graphics drm issue?

On Sun, 14 October 2012 Mark Hounschell <dmarkh@....rr.com> wrote:
> I gave it a try. I don't think it liked my kernel cmdline. dmesg attached. 
> There is a lot more in there now that nomodeset is gone and the debug is 
> turned on.
> 
> # ls -al /lib/firmware/edid/lg42lb9df.edid
> -rw-r--r-- 1 root root 1024 Oct 14  2012 /lib/firmware/edid/lg42lb9df.edid
> 
> ## cat /proc/cmdline
> root=/dev/disk/by-id/ata-INTEL_SSDSC2CW060A3_CVCV205106EB060AGN-part4 
> noresume splash=silent quiet apm=off vga=normal drm.debug=0xe irqpoll 
> drm_kms_helper.edid_firmware=edid/lg42lb9df.edid
> 
> 
> from attached dmesg:
> 1.833032] drm_kms_helper: Unknown parameter `edid'

As your drm drivers seem to all be built-in (according to kernel timings)
you will have to build the EDID firmware into the kernel as well (see
CONFIG_EXTRA_FIRMWARE), otherwise it probably can't be loaded (unless Linus'
firmware loading patch is already in 3.6.2 and root filesystem/initrd is
ready at that time).

Did you set CONFIG_DRM_LOAD_EDID_FIRMWARE?
If not, that may be the reason for unknown parameter `edid' error.

But I saw I mis-remembered side of EDID blobs, they are just 128 bytes
per block, not 512 (seems I was thinking disk sector sizes),
thus you should just get 256 bytes output.

Just truncating the file to 256 bytes will do. You may also
change your .c file to have
  uint8_t firmware[] = {
     ...
  };
  ...
  fwrite(firmware, sizeof(firmware), 1, fd);
  ...

that way compiler gets numbers right :)

Kernel code rejects edid with unexpected size! Thus it would have
complained if it had tried to load it with a size of 1k.

Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/