2011/8/27 Michel Dänzer <michel@xxxxxxxxxxx>: > 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 mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel