Bug#649448: udev loading radeon drivers garbles screen output

[Touko Korpela]

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 at decadent.org.uk> 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 at gmail.com>
> > 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 at gmail.com>
> > 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