Hi,
I observe very strange behavior dependent on value of CONFIG_DRM_RADEON parameter. When it's set to m everything works very good, no problem. When I set it to y I see kernel hang during boot. Or I should better say it "almost hangs" because during last boot attempt I accidentally waited a little bit longer and saw that after more than a minute waiting system continued to boot. Dmesg after "hang" shows these messages:
[ 8.542639] [drm] Loading CEDAR Microcode [ 69.161605] r600_cp: Failed to load firmware "radeon/CEDAR_pfp.bin" [ 69.161670] [drm:evergreen_startup] *ERROR* Failed to load firmware!
While during normal boot
[ 9.898870] [drm] Loading CEDAR Microcode [ 9.908425] radeon 0000:05:00.0: WB enabled
Is this a bug?
I'm seeing this on 3.1-rc3. Full dmesgs for both boots are attached.
Pavel
On Sam, 2011-08-27 at 00:20 -0400, Pavel Ivanov wrote:
I observe very strange behavior dependent on value of CONFIG_DRM_RADEON parameter. When it's set to m everything works very good, no problem. When I set it to y I see kernel hang during boot. Or I should better say it "almost hangs" because during last boot attempt I accidentally waited a little bit longer and saw that after more than a minute waiting system continued to boot. Dmesg after "hang" shows these messages:
[ 8.542639] [drm] Loading CEDAR Microcode [ 69.161605] r600_cp: Failed to load firmware "radeon/CEDAR_pfp.bin" [ 69.161670] [drm:evergreen_startup] *ERROR* Failed to load firmware!
While during normal boot
[ 9.898870] [drm] Loading CEDAR Microcode [ 9.908425] radeon 0000:05:00.0: WB enabled
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.
2011/8/27 Michel Dänzer michel@daenzer.net:
I observe very strange behavior dependent on value of CONFIG_DRM_RADEON parameter. When it's set to m everything works very good, no problem. When I set it to y I see kernel hang during boot. Or I should better say it "almost hangs" because during last boot attempt I accidentally waited a little bit longer and saw that after more than a minute waiting system continued to boot. Dmesg after "hang" shows these messages:
[ 8.542639] [drm] Loading CEDAR Microcode [ 69.161605] r600_cp: Failed to load firmware "radeon/CEDAR_pfp.bin" [ 69.161670] [drm:evergreen_startup] *ERROR* Failed to load firmware!
While during normal boot
[ 9.898870] [drm] Loading CEDAR Microcode [ 9.908425] radeon 0000:05:00.0: WB enabled
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?
Pavel
On Sat, Aug 27, 2011 at 06:50:37PM -0400, Pavel Ivanov wrote:
2011/8/27 Michel Dänzer michel@daenzer.net:
I observe very strange behavior dependent on value of CONFIG_DRM_RADEON parameter. When it's set to m everything works very good, no problem. When I set it to y I see kernel hang during boot. Or I should better say it "almost hangs" because during last boot attempt I accidentally waited a little bit longer and saw that after more than a minute waiting system continued to boot. Dmesg after "hang" shows these messages:
[ 8.542639] [drm] Loading CEDAR Microcode [ 69.161605] r600_cp: Failed to load firmware "radeon/CEDAR_pfp.bin" [ 69.161670] [drm:evergreen_startup] *ERROR* Failed to load firmware!
While during normal boot
[ 9.898870] [drm] Loading CEDAR Microcode [ 9.908425] radeon 0000:05:00.0: WB enabled
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.
HTH.
On Sun, Aug 28, 2011 at 1:36 AM, Borislav Petkov bp@alien8.de 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.
Everything else in /lib/firmware/radeon is needed after user space become available?
Pavel
On Sun, Aug 28, 2011 at 05:47:59PM -0400, Pavel Ivanov wrote:
On Sun, Aug 28, 2011 at 1:36 AM, Borislav Petkov bp@alien8.de 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.
Everything else in /lib/firmware/radeon is needed after user space become available?
You mean the other *.bin files? If so, not for your case, AFAICT - your driver is requesting CEDAR_pfp.bin only, correct? But I mean, it won't hurt if you leave them all there, they're under 1M.
You should recheck and add any other .bin files to the CONFIG_EXTRA_FIRMWARE string so that radeon.ko is satisfied :).
HTH.
On Mon, 2011-08-29 at 07:49 +0200, Borislav Petkov wrote:
On Sun, Aug 28, 2011 at 05:47:59PM -0400, Pavel Ivanov wrote:
On Sun, Aug 28, 2011 at 1:36 AM, Borislav Petkov bp@alien8.de 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.
Everything else in /lib/firmware/radeon is needed after user space become available?
You mean the other *.bin files? If so, not for your case, AFAICT - your driver is requesting CEDAR_pfp.bin only, correct?
It'll need all the CEDAR_*.bin files.
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.
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
Alex?
2011/8/29 Borislav Petkov bp@alien8.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.
That asks the question is your distro isn't shipping those firmware for you.
The main thing is you build in the driver which firmware to include? granted all the radeon firmware is only about 580k so its probably not a problem to somehow magically add them all to CONFIG_EXTRA_FIRMWARE if RADEON=y, if someone thinks to make kbuild do it, but you really only 3 or 4 of them on any one card.
Dave.
2011/8/29 Borislav Petkov bp@alien8.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
On Mon, Aug 29, 2011 at 09:48:22AM -0400, Alex Deucher wrote:
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, Dave, yeah, that's all fine.
The question Peter asked is, how to make this much more understandable to the user so that she/he doesn't have to figure it out on their own. IOW, if one sets RADEON to =y in Kconfig, it should automatically generate a selection menu with all the firmware required so that the user can select from it either the CEDAR* or the REDWOOD* (or the DOUGHNUT* :-)) ones for her/his card and when the user selects one entry, the required strings are added to CONFIG_EXTRA_FIRMWARE _automatically_.
Maybe even Kbuild should try to find them on the system, and, if unable to, remind the user to install the needed firmware package.
Anyway, something to that effect, the above is just to illustrate the intention, I don't know whether it would work. In any case, we're lacking user help there and we don't want to put every user through the process of finding which firmware files she/he needs when setting RADEON=y.
Does that make more sense?
----- Original Message -----
From: "Borislav Petkov" bp@alien8.de To: "Alex Deucher" alexdeucher@gmail.com, "Dave Airlie" airlied@gmail.com Cc: "Peter Zijlstra" peterz@infradead.org, "Michel Dänzer" michel@daenzer.net, "linux-kernel" linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, "Pavel Ivanov" paivanof@gmail.com Sent: Monday, 29 August, 2011 3:16:12 PM Subject: Re: Kernel almost hangs when CONFIG_DRM_RADEON=y On Mon, Aug 29, 2011 at 09:48:22AM -0400, Alex Deucher wrote:
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, Dave, yeah, that's all fine.
The question Peter asked is, how to make this much more understandable to the user so that she/he doesn't have to figure it out on their own. IOW, if one sets RADEON to =y in Kconfig, it should automatically generate a selection menu with all the firmware required so that the user can select from it either the CEDAR* or the REDWOOD* (or the DOUGHNUT* :-)) ones for her/his card and when the user selects one entry, the required strings are added to CONFIG_EXTRA_FIRMWARE _automatically_.
Maybe even Kbuild should try to find them on the system, and, if unable to, remind the user to install the needed firmware package.
Anyway, something to that effect, the above is just to illustrate the intention, I don't know whether it would work. In any case, we're lacking user help there and we don't want to put every user through the process of finding which firmware files she/he needs when setting RADEON=y.
Does that make more sense?
Oh it makes sense, just neither of us are Kbuild hackers and I'm not sure that'll change at any point :)
It also sounds like something that could apply to any driver with external firmware.
Dave.
On Mon, Aug 29, 2011 at 11:47:24AM -0400, David Airlie wrote:
On Mon, Aug 29, 2011 at 09:48:22AM -0400, Alex Deucher wrote:
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, Dave, yeah, that's all fine.
The question Peter asked is, how to make this much more understandable to the user so that she/he doesn't have to figure it out on their own. IOW, if one sets RADEON to =y in Kconfig, it should automatically generate a selection menu with all the firmware required so that the user can select from it either the CEDAR* or the REDWOOD* (or the DOUGHNUT* :-)) ones for her/his card and when the user selects one entry, the required strings are added to CONFIG_EXTRA_FIRMWARE _automatically_.
Maybe even Kbuild should try to find them on the system, and, if unable to, remind the user to install the needed firmware package.
Anyway, something to that effect, the above is just to illustrate the intention, I don't know whether it would work. In any case, we're lacking user help there and we don't want to put every user through the process of finding which firmware files she/he needs when setting RADEON=y.
Does that make more sense?
Oh it makes sense, just neither of us are Kbuild hackers and I'm not sure that'll change at any point :)
It also sounds like something that could apply to any driver with external firmware.
So it seems like all the request_firmware() drivers could use a Kbuild functionality of some sort which presents the user with an option to select the firmware blobs for his hw when those drivers are =y. Hairy.
Adding kbuild ML.
Hi,
On Mon, Aug 29, 2011 at 11:55 AM, Borislav Petkov bp@alien8.de wrote:
On Mon, Aug 29, 2011 at 11:47:24AM -0400, David Airlie wrote:
On Mon, Aug 29, 2011 at 09:48:22AM -0400, Alex Deucher wrote:
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, Dave, yeah, that's all fine.
The question Peter asked is, how to make this much more understandable to the user so that she/he doesn't have to figure it out on their own. IOW, if one sets RADEON to =y in Kconfig, it should automatically generate a selection menu with all the firmware required so that the user can select from it either the CEDAR* or the REDWOOD* (or the DOUGHNUT* :-)) ones for her/his card and when the user selects one entry, the required strings are added to CONFIG_EXTRA_FIRMWARE _automatically_.
Maybe even Kbuild should try to find them on the system, and, if unable to, remind the user to install the needed firmware package.
Anyway, something to that effect, the above is just to illustrate the intention, I don't know whether it would work. In any case, we're lacking user help there and we don't want to put every user through the process of finding which firmware files she/he needs when setting RADEON=y.
Does that make more sense?
Oh it makes sense, just neither of us are Kbuild hackers and I'm not sure that'll change at any point :)
It also sounds like something that could apply to any driver with external firmware.
So it seems like all the request_firmware() drivers could use a Kbuild functionality of some sort which presents the user with an option to select the firmware blobs for his hw when those drivers are =y. Hairy.
Adding kbuild ML.
do you want something ala:
config EXTRA_FIRMWARE string default "" append "FOO" if BAR append "FOZ" if BAZ
or maybe a new type "list" which would behave as a comma/space separated value.
config EXTRA_FIRMWARE list "bla" append "FOO" if BAR append "FOZ" if BAZ
?
Thanks, - Arnaud
-- Regards/Gruss, Boris.
-- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 29, 2011 at 12:10:45PM -0400, Arnaud Lacombe wrote:
do you want something ala:
config EXTRA_FIRMWARE string default "" append "FOO" if BAR append "FOZ" if BAZ
or maybe a new type "list" which would behave as a comma/space separated value.
config EXTRA_FIRMWARE list "bla" append "FOO" if BAR append "FOZ" if BAZ
Yeah, actually Kyle's note (http://lkml.org/lkml/2011/8/29/289) makes much more sense for linux and the whole firmware in the kernel deal. So it looks like the drivers should be taught to wait for userspace to appear instead of Kconfig helping them build-in firmware. And then we should go ahead and remove CONFIG_EXTRA_FIRMWARE completely...
Thanks.
On Mon, 2011-08-29 at 19:17 +0200, Borislav Petkov wrote:
On Mon, Aug 29, 2011 at 12:10:45PM -0400, Arnaud Lacombe wrote:
do you want something ala:
config EXTRA_FIRMWARE string default "" append "FOO" if BAR append "FOZ" if BAZ
or maybe a new type "list" which would behave as a comma/space separated value.
config EXTRA_FIRMWARE list "bla" append "FOO" if BAR append "FOZ" if BAZ
Yeah, actually Kyle's note (http://lkml.org/lkml/2011/8/29/289) makes much more sense for linux and the whole firmware in the kernel deal. So it looks like the drivers should be taught to wait for userspace to appear [...]
What would be the point of building radeon into the kernel then? It's not gonna be active before the module could be loaded...
On Mon, 2011-08-29 at 19:17 +0200, Borislav Petkov wrote:
On Mon, Aug 29, 2011 at 12:10:45PM -0400, Arnaud Lacombe wrote:
do you want something ala:
config EXTRA_FIRMWARE string default "" append "FOO" if BAR append "FOZ" if BAZ
or maybe a new type "list" which would behave as a comma/space separated value.
config EXTRA_FIRMWARE list "bla" append "FOO" if BAR append "FOZ" if BAZ
Yeah, actually Kyle's note (http://lkml.org/lkml/2011/8/29/289) makes much more sense for linux and the whole firmware in the kernel deal. So it looks like the drivers should be taught to wait for userspace to appear instead of Kconfig helping them build-in firmware. And then we should go ahead and remove CONFIG_EXTRA_FIRMWARE completely...
That would suck, suppose this radeon thing is the only console you've got (ppc64/sparc64 don't have text mode iirc) and userspace doesn't come up?
On Mon, 2011-08-29 at 19:50 +0200, Peter Zijlstra wrote:
On Mon, 2011-08-29 at 19:17 +0200, Borislav Petkov wrote:
On Mon, Aug 29, 2011 at 12:10:45PM -0400, Arnaud Lacombe wrote:
do you want something ala:
config EXTRA_FIRMWARE string default "" append "FOO" if BAR append "FOZ" if BAZ
or maybe a new type "list" which would behave as a comma/space separated value.
config EXTRA_FIRMWARE list "bla" append "FOO" if BAR append "FOZ" if BAZ
Yeah, actually Kyle's note (http://lkml.org/lkml/2011/8/29/289) makes much more sense for linux and the whole firmware in the kernel deal. So it looks like the drivers should be taught to wait for userspace to appear instead of Kconfig helping them build-in firmware. And then we should go ahead and remove CONFIG_EXTRA_FIRMWARE completely...
That would suck, suppose this radeon thing is the only console you've got (ppc64/sparc64 don't have text mode iirc) and userspace doesn't come up?
Same is true for NICs and netconsole of course. Not being able to stick blobs into the kernel image would so suck.
Silently building a kernel without one and then getting stuck on boot, only to figure out after much pain that you need EXTRA_FIRMWARE and the more pain to figure out what blob to stick in is beyond crazy.
On Mon, 2011-08-29 at 20:09 +0200, Peter Zijlstra wrote:
That would suck, suppose this radeon thing is the only console you've got (ppc64/sparc64 don't have text mode iirc) and userspace doesn't come up?
Same is true for NICs and netconsole of course. Not being able to stick blobs into the kernel image would so suck.
NICs and nfsroot, I suppose can you use an initrd over tftp as well, but really, what's the point of an in-kernel nfsroot if you need initrd crap.
On Mon, Aug 29, 2011 at 08:16:53PM +0200, Peter Zijlstra wrote:
On Mon, 2011-08-29 at 20:09 +0200, Peter Zijlstra wrote:
That would suck, suppose this radeon thing is the only console you've got (ppc64/sparc64 don't have text mode iirc) and userspace doesn't come up?
Same is true for NICs and netconsole of course. Not being able to stick blobs into the kernel image would so suck.
NICs and nfsroot, I suppose can you use an initrd over tftp as well, but really, what's the point of an in-kernel nfsroot if you need initrd crap.
Damn,
just when I thought that the lofty goal of Linux distancing itself from firmware crap is within reach, you came up with all those real-life, nagging examples.
So here's the whole deal IMHO:
* driver =m and request_firmware() works fine - you only need the blobs in the right place.
* driver =y and request_firmware() should be fixed in all cases where driver can wait.
Your use cases could probably be addressed by supplying firmware blobs from the bootloader. We had this talk already concerning CPU microcode updates and how the current method is to load CPU ucode when the module gets loaded, which might be too late for some obscure (and not so obscure) cases.
So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing in the real-mode kernel header and parse_setup_data() can look at them and map them somewhere later for the driver to find. This should be doable because you're only gonna need a handful of blobs for CPU ucode, network and GPU if the last is compiled in.
I wanted to take a serious look at that for the ucode loading, maybe I should try to shuffle some time for it...
On Mon, 29 Aug 2011, Borislav Petkov wrote:
So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing in the real-mode kernel header and parse_setup_data() can look at them and map them somewhere later for the driver to find. This should be doable because you're only gonna need a handful of blobs for CPU ucode, network and GPU if the last is compiled in.
I wanted to take a serious look at that for the ucode loading, maybe I should try to shuffle some time for it...
It would be very useful, yes.
Alternatively, you could extend the initrd format to have a firmware directory appended after the filesystem image. ACPI is going to abuse the initrd in just that way to override ACPI tables very soon (patches have been already submitted to linux-acpi), so if a more structured and extensible way to piggy-back early-init data in the initrd is needed, it would be good to bring that to the table NOW.
On Mon, Aug 29, 2011 at 11:08:28PM -0300, Henrique de Moraes Holschuh wrote:
On Mon, 29 Aug 2011, Borislav Petkov wrote:
So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing in the real-mode kernel header and parse_setup_data() can look at them and map them somewhere later for the driver to find. This should be doable because you're only gonna need a handful of blobs for CPU ucode, network and GPU if the last is compiled in.
I wanted to take a serious look at that for the ucode loading, maybe I should try to shuffle some time for it...
It would be very useful, yes.
Alternatively, you could extend the initrd format to have a firmware directory appended after the filesystem image. ACPI is going to abuse the initrd in just that way to override ACPI tables very soon (patches have been already submitted to linux-acpi),
.. lemme guess: they didn't put the correct tables in the BIOS in the first place and now it is too late for a BIOS fix and want to shuffle in all those "fixes" through initrd ontop of ACPI. Oh boy, do I love all the ACPI crap stories :).
so if a more structured and extensible way to piggy-back early-init data in the initrd is needed, it would be good to bring that to the table NOW.
Yeah, that's not more than an idea right now, I haven't even started playing with it. If it turns out to be more superior, it could be reused for other things too but right now it's too early to tell.
On Tue, 30 Aug 2011, Borislav Petkov wrote:
On Mon, Aug 29, 2011 at 11:08:28PM -0300, Henrique de Moraes Holschuh wrote:
On Mon, 29 Aug 2011, Borislav Petkov wrote:
So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing in the real-mode kernel header and parse_setup_data() can look at them and map them somewhere later for the driver to find. This should be doable because you're only gonna need a handful of blobs for CPU ucode, network and GPU if the last is compiled in.
I wanted to take a serious look at that for the ucode loading, maybe I should try to shuffle some time for it...
It would be very useful, yes.
Alternatively, you could extend the initrd format to have a firmware directory appended after the filesystem image. ACPI is going to abuse the initrd in just that way to override ACPI tables very soon (patches have been already submitted to linux-acpi),
.. lemme guess: they didn't put the correct tables in the BIOS in the first place and now it is too late for a BIOS fix and want to shuffle in all those "fixes" through initrd ontop of ACPI. Oh boy, do I love all the ACPI crap stories :).
Heh.
Actually, the patches were created by a distro for debug purposes. No vendor pushed for them. But it is a safe bet that users will end up using them to work around ACPI vendor crap that will never get fixed properly through a BIOS update, etc.
On Mon, 2011-08-29 at 23:08 -0300, Henrique de Moraes Holschuh wrote:
On Mon, 29 Aug 2011, Borislav Petkov wrote:
So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing in the real-mode kernel header and parse_setup_data() can look at them and map them somewhere later for the driver to find. This should be doable because you're only gonna need a handful of blobs for CPU ucode, network and GPU if the last is compiled in.
I wanted to take a serious look at that for the ucode loading, maybe I should try to shuffle some time for it...
It would be very useful, yes.
Alternatively, you could extend the initrd format to have a firmware directory appended after the filesystem image. ACPI is going to abuse the initrd in just that way to override ACPI tables very soon (patches have been already submitted to linux-acpi), so if a more structured and extensible way to piggy-back early-init data in the initrd is needed, it would be good to bring that to the table NOW.
Uhm,.. does that mean that soon we can't boot kernels without initrd? That too is a massive regression in my eyes.
On Tue, 30 Aug 2011, Peter Zijlstra wrote:
On Mon, 2011-08-29 at 23:08 -0300, Henrique de Moraes Holschuh wrote:
On Mon, 29 Aug 2011, Borislav Petkov wrote:
So, hypothetically speaking, hpa suggested then that we could pass firmware blobs over the linked list setup_data thing in the real-mode kernel header and parse_setup_data() can look at them and map them somewhere later for the driver to find. This should be doable because you're only gonna need a handful of blobs for CPU ucode, network and GPU if the last is compiled in.
I wanted to take a serious look at that for the ucode loading, maybe I should try to shuffle some time for it...
It would be very useful, yes.
Alternatively, you could extend the initrd format to have a firmware directory appended after the filesystem image. ACPI is going to abuse the initrd in just that way to override ACPI tables very soon (patches have been already submitted to linux-acpi), so if a more structured and extensible way to piggy-back early-init data in the initrd is needed, it would be good to bring that to the table NOW.
Uhm,.. does that mean that soon we can't boot kernels without initrd? That too is a massive regression in my eyes.
Well, if work starts soon enough on a bootloader extension to avoid messing with the initrd, we could refuse to set that initrd-based ACPI table override as ABI on the grounds that it is a debug thing, and later move it to the properly designed firmware bootloader extension.
Maybe the grub multiboot protocol[1] is worth looking at, assuming that thing is salvagable and would actually work for both 32bit and 64bit BIOS and UEFI bootstrapping?
[1]http://www.gnu.org/software/grub/manual/multiboot/multiboot.html
On Mon, Aug 29, 2011 at 09:48, Alex Deucher alexdeucher@gmail.com wrote:
2011/8/29 Borislav Petkov bp@alien8.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.)
No, Linus pushed back really hard last time this issue came up with something; a network driver if I recall correctly.
The issue is that this happens *EVEN FOR MODULAR DRIVERS* during suspend/resume. The firmware simply may not be available yet.
If the driver fundamentally cannot work without the firmware then it should bind to the device and wait until the first userspace action before requesting firmware.
Furthermore, the trend is generally to push the firmware OUT of the kernel binary to avoid any chance of license issues. Even if the code is built-in it should not need built-in firmware.
The quickest fix is probably something like this:
config DRM_RADEON_FIRMWARE tristate default m if STANDALONE default y
config DRM_RADEON depends DRM_RADEON_FIRMWARE
That should prevent somebody from building the radeon driver into the kernel unless they manually indicate that they have the extra firmware.
Long-term, the driver should support modular firmware even when it's built-in to the kernel.
Cheers, Kyle Moffett
On Mon, Aug 29, 2011 at 12:28:31PM -0400, Kyle Moffett wrote:
No, Linus pushed back really hard last time this issue came up with something; a network driver if I recall correctly.
r8169 probably.
The issue is that this happens *EVEN FOR MODULAR DRIVERS* during suspend/resume. The firmware simply may not be available yet.
If the driver fundamentally cannot work without the firmware then it should bind to the device and wait until the first userspace action before requesting firmware.
Furthermore, the trend is generally to push the firmware OUT of the kernel binary to avoid any chance of license issues. Even if the code is built-in it should not need built-in firmware.
The quickest fix is probably something like this:
config DRM_RADEON_FIRMWARE tristate default m if STANDALONE default y
config DRM_RADEON depends DRM_RADEON_FIRMWARE
That should prevent somebody from building the radeon driver into the kernel unless they manually indicate that they have the extra firmware.
Long-term, the driver should support modular firmware even when it's built-in to the kernel.
Yep, and drivers should be able to select the firmware they need without users even needing to do anything about it except installing some firmware-nonfree package or whatever.
Yeah, sounds much better than Kconfig actually aiding and abetting firmware blobs in the kernel and users needing to do stuff.
Thanks.
On Mon, 2011-08-29 at 19:21 +0200, Borislav Petkov wrote:
Yeah, sounds much better than Kconfig actually aiding and abetting firmware blobs in the kernel and users needing to do stuff.
I would very much like to retain that option.. and having to manually figure out what blob goes with what driver just isn't fun.
2011/8/27 Michel Dänzer michel@daenzer.net:
On Sam, 2011-08-27 at 00:20 -0400, Pavel Ivanov wrote:
I observe very strange behavior dependent on value of CONFIG_DRM_RADEON parameter. When it's set to m everything works very good, no problem. When I set it to y I see kernel hang during boot. Or I should better say it "almost hangs" because during last boot attempt I accidentally waited a little bit longer and saw that after more than a minute waiting system continued to boot. Dmesg after "hang" shows these messages:
[ 8.542639] [drm] Loading CEDAR Microcode [ 69.161605] r600_cp: Failed to load firmware "radeon/CEDAR_pfp.bin" [ 69.161670] [drm:evergreen_startup] *ERROR* Failed to load firmware!
While during normal boot
[ 9.898870] [drm] Loading CEDAR Microcode [ 9.908425] radeon 0000:05:00.0: WB enabled
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.
Linus has gotten pissed previously about drivers that do this.
I actually recall a patch previously that made request_firmware() fail instantly before userspace is loaded, which would get rid of the hang, but presumably not actually make the driver work when built-in.
The solution is to allow the driver to "attach" to the device but if the firmware is not available at that time then retrying the request_firmware() later, ideally triggered from some userspace action.
Cheers, Kyle Moffett
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Arnaud Lacombe -
Borislav Petkov -
Dave Airlie -
David Airlie -
Henrique de Moraes Holschuh -
Kyle Moffett -
Michel Dänzer -
Pavel Ivanov -
Peter Zijlstra