Bug#649448: udev loading radeon drivers garbles screen output

[Alex Deucher]

On Tue, Nov 22, 2011 at 7:08 AM, Touko Korpela <touko.korpela at iki.fi> 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 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
>

Should work and well tested are different things.

Alex