Bug#649448: udev loading radeon drivers garbles screen output
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 :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- > SERR- Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 11 > Region 0: Memory at fc00 (32-bit, prefetchable) [size=32M] > Region 1: I/O ports at f000 [size=256] > Region 2: Memory at feb0 (32-bit, non-prefetchable) [size=256K] > Expansion ROM at [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: Data: > Capabilities: [100 v1] Vendor Specific Infor
Bug#649448: udev loading radeon drivers garbles screen output
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 :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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2021010240.ga11...@elie.hsd1.il.comcast.net
Bug#649448: udev loading radeon drivers garbles screen output
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 :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 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 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. signature.asc Description: This is a digitally signed message part
Bug#649448: udev loading radeon drivers garbles screen output
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 :00:01.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 > [ 380.274696] radeon :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: 0xFEB0 > [ 380.275173] [drm] register mmio size: 262144 > [ 380.275320] ATOM BIOS: General > [ 380.275348] radeon :00:01.0: VRAM: 32M 0x - > 0x01FF (32M used) > [ 380.275351] radeon :00:01.0: GTT: 512M 0x0200 - > 0x21FF > [ 380.275357] mtrr: type mismatch for fc00,200 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 :00:01.0: irq 55 for MSI/MSI-X > [ 380.275623] radeon :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 :00:01.0: disabling GPU acceleration > [ 380.297203] radeon :00:01.0: 880114d75400 unpin not necessary > [ 380.297205] radeon :00:01.0: 880114d75400 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 0xFC04 > [ 380.985120] [drm] vram apper at 0xFC00 > [ 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 :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 signature.asc Description: OpenPGP digital signature
Bug#649448: udev loading radeon drivers garbles screen output
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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2021074252.gb16...@elie.hsd1.il.comcast.net
Bug#649448: udev loading radeon drivers garbles screen output
On Sun, Nov 20, 2011 at 10:12 PM, Ben Hutchings 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 :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 > 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 > 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADnq5_OG9A6_duGBhUgkK67EuO=eT6QiN7w5ETxp6=pG=ts...@mail.gmail.com
Bug#649448: udev loading radeon drivers garbles screen output
On Mon, Nov 21, 2011 at 09:33:28AM -0500, Alex Deucher wrote: > On Sun, Nov 20, 2011 at 10:12 PM, Ben Hutchings 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 :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 > > 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 > > 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2022120853.GA17965@tiikeri.vuoristo.local
Bug#649448: udev loading radeon drivers garbles screen output
On Tue, Nov 22, 2011 at 7:08 AM, Touko Korpela 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 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 :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 >> > 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 >> > 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadnq5_mcwnzfbuykudwa7meqxkdgnankcmb8gpums8mmt3p...@mail.gmail.com
