Bug 43138
| Summary: | Radeon HD5450 fails to load cedar firmware ? | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | bugtraq |
| Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | alexdeucher, glisse |
| Priority: | P1 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 3.3.2. | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
bugtraq
2012-04-20 13:06:31 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? -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 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 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. 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? (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(). "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? 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) (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. 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. (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. |