Bug#649448: udev loading radeon drivers garbles screen output

Ben Hutchings ben at decadent.org.uk
Sun Nov 20 19:12:54 PST 2011


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.

Ben.

-- 
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111121/afd7a565/attachment.pgp>


More information about the dri-devel mailing list