On Mon, Nov 21, 2011 at 09:33:28AM -0500, Alex Deucher wrote: > 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. In what kernel versions should that be true? These bugs are reported that question it (some are reported against older kernels). http://bugs.debian.org/607194 http://bugs.debian.org/637943 http://bugs.debian.org/627497 and also my report: http://bugs.debian.org/646306 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
