linux-kernel - Re: Kernel almost hangs when CONFIG_DRM

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]

Date:	Mon, 29 Aug 2011 09:48:22 -0400
From:	Alex Deucher <alexdeucher@...il.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Pavel Ivanov <paivanof@...il.com>,
	Michel Dänzer <michel@...nzer.net>,
	dri-devel@...ts.freedesktop.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Kernel almost hangs when CONFIG_DRM_RADEON=y

2011/8/29 Borislav Petkov <bp@...en8.de>:
> On Mon, Aug 29, 2011 at 03:20:21PM +0200, Peter Zijlstra wrote:
>> On Sun, 2011-08-28 at 07:36 +0200, Borislav Petkov wrote:
>> > > > With CONFIG_DRM_RADEON=y, the microcode is needed before it can be
>> > > > loaded from userspace, so it needs to be built into the kernel as well.
>> > >
>> > > How should I do that? I've tried to set all "m"s to "y" in .config and
>> > > still saw this issue. Should I set some special parameter?
>> >
>> > You need to add "radeon/CEDAR_pfp.bin" to CONFIG_EXTRA_FIRMWARE when you
>> > configure your kernel and enable CONFIG_FIRMWARE_IN_KERNEL.
>> >
>> > The radeon/CEDAR_pfp.bin file (+ leading directory, mind you) should
>> > most probably be located in /lib/firmware or to whatever you have set
>> > CONFIG_EXTRA_FIRMWARE_DIR so that Kbuild can find it (if not, you'll get
>> > a warning at the end of the kernel build). This way, it works for both
>> > radeon being =m and =y.
>>
>> Should we make Kconfig pop up a dialog and ask for the whereabouts of
>> these firmware thingies when you mark the driver =y?
>>
>> This all sounds like magic to me, having to know you need to add to
>> EXTRA_FIRMWARE, having to know what file it needs etc.. For all intents
>> and purposes =y just doesn't work and that's broken.
>
> Yep, you make a lot of sense. I had to fumble the build/reboot cycle a
> couple of times and do some code staring even to figure this out. In
> the end, I copied the whole radeon/ folder from David's firmware git
> repo into /lib/firmware and made radeon.ko =m again so that I don't have
> to add *.bin entries to CONFIG_EXTRA_FIRMWARE each time I'm building a
> kernel on a different machine.
>
> Besides, there was this other issue on lkml today where
> CONFIG_EXTRA_FIRMWARE can cause nconf to segfault when you overflow
> its length of 256 by trying to include a bunch of firmware *bin files:
> http://lkml.org/lkml/2011/8/29/86

If you are going to build the ucode into your kernel you'll need to
pick the ones you want to include or increase the limit regardless of
whether it's radeon ucode or ucode for some other chip.  For a
particular card you only need the ones for that card (e.g.,
CEDAR_*.bin or REDWOOD_*.bin, etc.)

Alex
--
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/