|Summary:||Radeon HD5450 fails to load cedar firmware ?|
|Component:||Video(DRI - non Intel)||Assignee:||drivers_video-dri|
Description bugtraq 2012-04-20 13:06:31 UTC
lspci 03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cedar PRO [Radeon HD 5450] 03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cedar HDMI Audio [Radeon HD 5400/6300 Series] dmesg snippets [drm] Initialized drm 1.1.0 20060810 [drm] radeon kernel modesetting enabled. [drm] initializing kernel modesetting (CEDAR 0x1002:0x68F9 0x1043:0x0366). [drm] register mmio base: 0xFDCC0000 [drm] register mmio size: 131072 ATOM BIOS: 68F22.214.171.124.2.AS03 radeon 0000:03:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used) radeon 0000:03:00.0: GTT: 512M 0x0000000040000000 - 0x000000005FFFFFFF [drm] Detected VRAM RAM=1024M, BAR=256M [drm] RAM width 64bits DDR [drm] radeon: 1024M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. radeon 0000:03:00.0: irq 44 for MSI/MSI-X radeon 0000:03:00.0: radeon: using MSI. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] radeon: ib pool ready. [drm] Loading CEDAR Microcode r600_cp: Bogus length 4480 in firmware "radeon/CEDAR_me.bin" r600_rlc: Bogus length 5504 in firmware "radeon/CEDAR_rlc.bin" [drm:evergreen_startup] *ERROR* Failed to load firmware! radeon 0000:03:00.0: disabling GPU acceleration
Comment 1 Michel Dänzer 2012-04-20 13:28:55 UTC
(In reply to comment #0) > r600_cp: Bogus length 4480 in firmware "radeon/CEDAR_me.bin" > r600_rlc: Bogus length 5504 in firmware "radeon/CEDAR_rlc.bin" What does ls -l /lib/firmware/radeon/CEDAR_* say?
Comment 2 bugtraq 2012-04-20 19:41:40 UTC
-rw-r--r-- 1 root root 5504 Jan 19 04:25 CEDAR_me.bin -rw-r--r-- 1 root root 4480 Jan 19 04:25 CEDAR_pfp.bin -rw-r--r-- 1 root root 3072 Jan 19 04:25 CEDAR_rlc.bin
Comment 3 bugtraq 2012-04-20 19:46:24 UTC
already tried fetching from http://people.freedesktop.org/~agd5f/radeon_ucode/ directly as well as installing standard Debian distri kernel & firmware package, same error, not sure though if the numbers in the error were absolute identical - was some time ago, 3D accel isn't _that_ important as long as everything else works fine, now finally got around to writing a bugreport
Comment 4 Alex Deucher 2012-04-20 20:27:34 UTC
Sounds like there's a problem with your initrd or kernel if you built the ucode into the kernel. This is an issue on your end.
Comment 5 bugtraq 2012-04-21 06:51:09 UTC
considering the age of that code I share your suspicions, but why then does a stock debian kernel & initrd show same behavior as my self-compiled (newer) one?
Comment 6 Michel Dänzer 2012-04-23 09:16:31 UTC
(In reply to comment #2) > -rw-r--r-- 1 root root 5504 Jan 19 04:25 CEDAR_me.bin > -rw-r--r-- 1 root root 4480 Jan 19 04:25 CEDAR_pfp.bin > -rw-r--r-- 1 root root 3072 Jan 19 04:25 CEDAR_rlc.bin Looks like these all have the correct length. Are there files of the same names somewhere else on your system that might get picked up instead? If not, it looks like a bug in either the initrd generation or request_firmware().
Comment 7 bugtraq 2012-04-23 22:25:51 UTC
"locate CEDAR_" shows only these 3 files, so there should be no other duplicates with the same names on my filesystem... as a stock Debian kernel/initrd is showing same behavior and my own selfcompiled kernel does not use an initrd, the initrd related tools cannot be the cause. that leaves the pretty unlikely bug in the loader and/or some weird local hardware problem - no idea how much different the cards in the cedar family really are from each other?
Comment 8 Jérôme Glisse 2012-04-23 22:32:45 UTC
Boot with "radeon.modeset=0 3" as root: rmmod radeon modprobe radeon modeset=1 If it works it means debian initrd doesn't include the firmware. Your own compiled kernel can't load the firmware because the radeon kernel module load before your filesystem is accessible. ie you need to build the firmware inside your kernel image. There 99% chance that this issue is on your side. I tested cedar, lastest kernel on a fedora and it doesn't have issue to load the firmware (firmware are in the inirtd file)
Comment 9 Michel Dänzer 2012-04-24 08:24:23 UTC
(In reply to comment #7) > that leaves the pretty unlikely bug in the loader and/or some weird local > hardware problem - no idea how much different the cards in the cedar family > really are from each other? It's got nothing to do with the hardware. request_firmware() reports sizes of the files in question which do not match the sizes of the files on your system (which match the expected sizes). So something goes wrong between your filesystem and request_firmware(). The most likely explanation seeming a problem when copying the files into the initrd, or maybe /lib/udev/firmware.agent in the initrd doing something wrong or something like that. What does gunzip -c /boot/initrd.img-$(uname -r) | cpio -tv | grep CEDAR say? (In reply to comment #8) > Boot with "radeon.modeset=0 3" The '3' won't have any visible effect on a Debian system, you'd need 'single' for single user mode. > If it works it means debian initrd doesn't include the firmware. It does include something (otherwise the failure would be different), but possibly not the correct files.
Comment 10 bugtraq 2012-04-24 10:17:27 UTC
stupid me should've checked this beforehand, very sorry for having wasted your time & thanks for your patience... ...nope, as Debian considers that particular firmware to be "nonfree" it is not included in the initrd at all, so it boils down to a somewhat misleading "bogus length" instead of a more appropriate "file not found" error for all cases above. issue solved.
Comment 11 Michel Dänzer 2012-04-24 13:42:41 UTC
(In reply to comment #10) > ...nope, as Debian considers that particular firmware to be "nonfree" it is > not > included in the initrd at all, That the firmware is in the firmware-linux-nonfree package merely means it's not installed on the system by default, it doesn't directly prevent the firmware from getting included in the initrd. > so it boils down to a somewhat misleading "bogus length" instead of a more > appropriate "file not found" error for all cases above. The lengths in the original error messages are the amounts of firmware data written by the /lib/udev/firmware.agent helper. If the firmware was missing altogether, how could the helper guess their sizes? Anyway, glad it's working for you now.