Bug#649448: udev loading radeon drivers garbles screen output

Bug#649448: udev loading radeon drivers garbles screen output

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 2848 bytes --]

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@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@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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Bug#649448: udev loading radeon drivers garbles screen output

[Alex Deucher]

On Sun, Nov 20, 2011 at 10:12 PM, Ben Hutchings <ben@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@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@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.

Alex

> Ben.
>
> --
> Ben Hutchings
> Teamwork is essential - it allows you to blame someone else.
>

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@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@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@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

Re: Bug#649448: udev loading radeon drivers garbles screen output

[Alex Deucher]

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