On Tue, Nov 22, 2011 at 7:08 AM, Touko Korpela <touko.korpela@xxxxxx> wrote: > 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 > Should work and well tested are different things. Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
