On Sun, Nov 20, 2011 at 10:12 PM, Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote: > On Sun, 2011-11-20 at 19:02 -0600, Jonathan Nieder wrote: >> reassign 649448 src:linux-2.6 linux-2.6/3.0.0-3 >> severity 649448 important >> retitle 649448 radeon (evergreen): random-looking pattern of pixels when firmware not installed >> tags 649448 + upstream >> quit >> >> Hi Martin, >> >> Martin von Gagern wrote: >> >> > Version: 3.0.0-3 >> [...] >> > Just installed a wheezy setup using debootstrap, adding grub-pc and >> > linux-image-amd64 after the chroot was created. The kernel boots, the >> > initrd seems all right. When the main system boots up, udev gets launced >> > pretty early. Soon after it is started, the screen turns into a pretty >> > random-looking pattern of pixels, making the console pretty unusable. >> > This also happens in "recovery" i.e. single-user mode. >> [...] >> > Possible workarounds seem to include: >> [...] >> > - Adding a line "blacklist radeon" to /etc/modprobe.d/blacklist.conf, >> > followed by running "depmod -a". >> [...] >> >> [ 150.125768] r600_cp: Failed to load firmware "radeon/SUMO2_pfp.bin" >> >> [ 150.125818] [drm:evergreen_startup] *ERROR* Failed to load firmware! >> >> [ 150.125859] radeon 0000:00:01.0: disabling GPU acceleration >> >> Yes, the radeon driver currently copes poorly when firmware is missing. >> Compare [1], [2], [3]. >> >> [...] >> > Not having GPU accelleration due to lack of free firmware is acceptable. >> > Not having a usable text console can be a real problem. >> >> Agreed. The radeon driver should be bailing out when firmware is >> missing for cards that need it, but that is not working for some >> reason. > [...] > > At the time I converted the radeon driver to load external firmware, it > was apparently only required for 3D acceleration and both KMS and 2D > acceleration of X worked without it, at least on those systems I tested > (which were quite old, R100-R300 families). Therefore failure to load > firmware would only result in DRM (3D acceleration support) being > disabled. > > However, it looks like driver support for the R600 family onward now > absolutely requires the 'RLC' firmware blobs: > > commit d8f60cfc93452d0554f6a701aa8e3236cbee4636 > Author: Alex Deucher <alexdeucher@xxxxxxxxx> > Date: Tue Dec 1 13:43:46 2009 -0500 > > drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3) > > And the 'Northern Islands' GPUs and 'Fusion' APUs appear to require the > 'MC' firmware blobs: > > commit 0af62b0168043896a042b005ff88caa77dd94d04 > Author: Alex Deucher <alexdeucher@xxxxxxxxx> > Date: Thu Jan 6 21:19:31 2011 -0500 > > drm/radeon/kms: add ucode loader for NI > > Therefore I think that at least r600_init(), rv770_init(), > evergreen_init() and cayman_init() should be treating failure to load > firmware as a fatal error. > R6xx, r7xx should work ok without the RLC ucode, you just won't get acceleration. With chips that require the MC ucode, the driver will bail if the MC ucode is not available. Alex > Ben. > > -- > Ben Hutchings > Teamwork is essential - it allows you to blame someone else. > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
