Messages in this thread | | | From | Kyle Moffett <> | Date | Sat, 27 Aug 2011 19:03:22 -0400 | Subject | Re: Kernel almost hangs when CONFIG_DRM_RADEON=y |
| |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |