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.
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.
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
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
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Ben Hutchings -
Touko Korpela