Bug#649448: udev loading radeon drivers garbles screen output

11-20-2011, 10:25 PM

Package: linux-image-3.0.0-1-amd64
Version: 3.0.0-3

This is to inform you of a possible problem. I've solved it to my own
satisfaction, so if I'm the only one, feel free to ignore this report.

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.

Passing "init=/bin/bash" on the kernel command line, I could get a
working text console. Manually executing the udev init script from there
has the same effect.

Possible workarounds seem to include:
- removing the kernel/drivers/gpu/drm/radeon/radeon.ko kernel module
from the kernel module tree
- Adding a line "blacklist radeon" to /etc/modprobe.d/blacklist.conf,
followed by running "depmod -a". Seems I forgot that on my first
attempt, causing me hours of unnecessary work.
Adding "video=vga16fb" to the kernel command line didn't help.

It seems that the radeon.ko module itself is to blame, neither one of
its dependencies nor some other module depending on it. After moving the
file back in place, a "modprobe -v radeon" prints the following commands
(over ssh):
> insmod /lib/modules/3.0.0-1-amd64/kernel/drivers/power/power_supply.ko
> insmod /lib/modules/3.0.0-1-amd64/kernel/drivers/i2c/algos/i2c-algo-bit.ko
> insmod /lib/modules/3.0.0-1-amd64/kernel/drivers/gpu/drm/drm.ko
> insmod /lib/modules/3.0.0-1-amd64/kernel/drivers/gpu/drm/drm_kms_helper.ko
> insmod /lib/modules/3.0.0-1-amd64/kernel/drivers/gpu/drm/ttm/ttm.ko
> insmod /lib/modules/3.0.0-1-amd64/kernel/drivers/gpu/drm/radeon/radeon.ko

Running those commands manually gives me this (over netconsole):
> [ 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
The middle line doesn't seem to occur every time.

Not having GPU accelleration due to lack of free firmware is acceptable.
Not having a usable text console can be a real problem. Particularly as
that makes fixing the problem a real challenge.

The controller in question is located on my motherboard, an ASrock A75
Extreme6. "lspci -vvv" describes it like this:
> 00:01.0 VGA compatible controller: ATI Technologies Inc Device 9644 (prog-if 00 [VGA controller])
> Subsystem: ASRock Incorporation Device 9640
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 11
> Region 0: Memory at fc000000 (32-bit, prefetchable) [size=32M]
> Region 1: I/O ports at f000 [size=256]
> Region 2: Memory at feb00000 (32-bit, non-prefetchable) [size=256K]
> Expansion ROM at <unassigned> [disabled]
> Capabilities: [50] Power Management version 3
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [58] Express (v2) Root Complex Integrated Endpoint, MSI 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
> ExtTag+ RBE+ FLReset-
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> MaxPayload 128 bytes, MaxReadReq 128 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
> LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
> ClockPM- Surprise- LLActRep- BwNot-
> LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
> DevCap2: Completion Timeout: Not Supported, TimeoutDis-
> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
> LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
> Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
> Compliance De-emphasis: -6dB
> LnkSta2: Current De-emphasis Level: -6dB
> Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
> Address: 0000000000000000 Data: 0000
> Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>

If there is any additional information I can provide, please let me know.

Greetings,
Martin von Gagern

--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EC98C5E.3050006@gmx.net">http://lists.debian.org/4EC98C5E.3050006@gmx.net

11-21-2011, 12:02 AM

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.

Thanks for reporting it. If you can (for example by ssh-ing in),
please attach full output from "dmesg" and from
"/usr/share/bug/xserver-xorg-video-radeon/script 3>&1" after
reproducing the problem.

Sincerely,
Jonathan

[1] http://bugs.debian.org/607194
[2] http://bugs.debian.org/637943
[3] http://bugs.debian.org/627497

--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111121010240.GA11611@elie.hsd1.il.comcast.net">h ttp://lists.debian.org/20111121010240.GA11611@elie.hsd1.il.comcast.net

11-21-2011, 02:12 AM

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.

11-21-2011, 06:20 AM

On 21.11.2011 02:02, Jonathan Nieder wrote:
> Yes, the radeon driver currently copes poorly when firmware is missing.
> Compare [1], [2], [3].
> [1] http://bugs.debian.org/607194
> [2] http://bugs.debian.org/637943
> [3] http://bugs.debian.org/627497

[2] sounds a lot like what I see.

> Thanks for reporting it. If you can (for example by ssh-ing in),
> please attach full output from "dmesg"

Here you go, everything after the modprobe:
> [ 380.238466] [drm] Initialized drm 1.1.0 20060810
> [ 380.274651] [drm] radeon defaulting to kernel modesetting.
> [ 380.274654] [drm] radeon kernel modesetting enabled.
> [ 380.274692] radeon 0000:00:01.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> [ 380.274696] radeon 0000:00:01.0: setting latency timer to 64
> [ 380.274851] [drm] initializing kernel modesetting (SUMO2 0x1002:0x9644 0x1849:0x9640).
> [ 380.275171] [drm] register mmio base: 0xFEB00000
> [ 380.275173] [drm] register mmio size: 262144
> [ 380.275320] ATOM BIOS: General
> [ 380.275348] radeon 0000:00:01.0: VRAM: 32M 0x0000000000000000 - 0x0000000001FFFFFF (32M used)
> [ 380.275351] radeon 0000:00:01.0: GTT: 512M 0x0000000002000000 - 0x0000000021FFFFFF
> [ 380.275357] mtrr: type mismatch for fc000000,2000000 old: write-back new: write-combining
> [ 380.275360] [drm] Detected VRAM RAM=32M, BAR=32M
> [ 380.275361] [drm] RAM width 32bits DDR
> [ 380.275532] [TTM] Zone kernel: Available graphics memory: 2002580 kiB.
> [ 380.275535] [TTM] Initializing pool allocator.
> [ 380.275563] [drm] radeon: 32M of VRAM memory ready
> [ 380.275565] [drm] radeon: 512M of GTT memory ready.
> [ 380.275581] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [ 380.275582] [drm] Driver supports precise vblank timestamp query.
> [ 380.275618] radeon 0000:00:01.0: irq 55 for MSI/MSI-X
> [ 380.275623] radeon 0000:00:01.0: radeon: using MSI.
> [ 380.275656] [drm] radeon: irq initialized.
> [ 380.275661] [drm] GART: num cpu pages 131072, num gpu pages 131072
> [ 380.276516] [drm] Loading SUMO2 Microcode
> [ 380.296057] r600_cp: Failed to load firmware "radeon/SUMO2_pfp.bin"
> [ 380.296099] [drm:evergreen_startup] *ERROR* Failed to load firmware!
> [ 380.296134] radeon 0000:00:01.0: disabling GPU acceleration
> [ 380.297203] radeon 0000:00:01.0: ffff880114d75400 unpin not necessary
> [ 380.297205] radeon 0000:00:01.0: ffff880114d75400 unpin not necessary
> [ 380.297229] failed to evaluate ATIF got AE_BAD_PARAMETER
> [ 380.297411] [drm] Radeon Display Connectors
> [ 380.297413] [drm] Connector 0:
> [ 380.297414] [drm] DVI-D
> [ 380.297415] [drm] HPD2
> [ 380.297417] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c
> [ 380.297419] [drm] Encoders:
> [ 380.297420] [drm] DFP2: INTERNAL_UNIPHY2
> [ 380.297422] [drm] Connector 1:
> [ 380.297423] [drm] DVI-D
> [ 380.297424] [drm] HPD1
> [ 380.297426] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
> [ 380.297427] [drm] Encoders:
> [ 380.297428] [drm] DFP1: INTERNAL_UNIPHY2
> [ 380.776030] [drm] Radeon display connector DVI-D-1: No monitor connected or invalid EDID
> [ 380.830275] [drm] Radeon display connector DVI-D-2: Found valid EDID
> [ 380.830311] [drm] Internal thermal controller without fan control
> [ 380.830348] [drm] radeon: power management initialized
> [ 380.985119] [drm] fb mappable at 0xFC040000
> [ 380.985120] [drm] vram apper at 0xFC000000
> [ 380.985122] [drm] size 1892352
> [ 380.985123] [drm] fb depth is 8
> [ 380.985124] [drm] pitch is 1792
> [ 380.985182] fbcon: radeondrmfb (fb0) is primary device
> [ 381.003344] Console: switching to colour frame buffer device 210x65
> [ 381.004682] fb0: radeondrmfb frame buffer device
> [ 381.004683] drm: registered panic notifier
> [ 381.004690] [drm] Initialized radeon 2.10.0 20080528 for 0000:00:01.0 on minor 0

> and from
> "/usr/share/bug/xserver-xorg-video-radeon/script 3>&1" after
> reproducing the problem.

No xorg installed on that machine, and I'd like to keep it that way.

Greetings,
Martin

11-21-2011, 06:42 AM

severity 627497 important
tags 637943 + upstream
tags 627497 + upstream
merge 607194 627497 637943 649448
quit

Martin von Gagern wrote:

> Here you go, everything after the modprobe:

Thanks.

[...]
> On 21.11.2011 02:02, Jonathan Nieder wrote:

>> and from
>> "/usr/share/bug/xserver-xorg-video-radeon/script 3>&1" after
>> reproducing the problem.
>
> No xorg installed on that machine, and I'd like to keep it that way.

Makes sense. No problem.

--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111121074252.GB16521@elie.hsd1.il.comcast.net">h ttp://lists.debian.org/20111121074252.GB16521@elie.hsd1.il.comcast.net

11-21-2011, 01:33 PM

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

--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CADnq5_OG9A6_duGBhUgkK67EuO=eT6QiN7w5ETxp6=pG=Tshs w@mail.gmail.com">http://lists.debian.org/CADnq5_OG9A6_duGBhUgkK67EuO=eT6QiN7w5ETxp6=pG=Tshs w@mail.gmail.com

11-22-2011, 11:08 AM

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

--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111122120853.GA17965@tiikeri.vuoristo.local">htt p://lists.debian.org/20111122120853.GA17965@tiikeri.vuoristo.local

11-22-2011, 01:45 PM

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

--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CADnq5_McwnZfBuyKuDWa7MEQxKdGnankcmb8gpumS8MMT3Pw9 A@mail.gmail.com">http://lists.debian.org/CADnq5_McwnZfBuyKuDWa7MEQxKdGnankcmb8gpumS8MMT3Pw9 A@mail.gmail.com