Bug 36812 - Radeon fails to load firmware
Summary: Radeon fails to load firmware
Status: RESOLVED INVALID
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-06 23:54 UTC by James Cloos
Modified: 2011-06-07 04:01 UTC (History)
2 users (show)

See Also:
Kernel Version: 3.0-rc2
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description James Cloos 2011-06-06 23:54:53 UTC
This used to work, but I had been booting with radeon.modset=0 for a few weeks, so I do not know when it broke.

With 3.0-rc2 (compiled from git master) I get (note this first two lines):

[   61.920296] r600_cp: Failed to load firmware "radeon/R600_rlc.bin"
[   61.920370] [drm:r600_startup] *ERROR* Failed to load firmware!
[   61.920442] radeon 0000:01:05.0: disabling GPU acceleration
[   61.921543] radeon 0000:01:05.0: ffff8802fc74c400 unpin not necessary
[   61.921615] radeon 0000:01:05.0: ffff8802fc74c400 unpin not necessary
[   61.921697] [drm] Enabling audio support
[   61.921949] [drm] Radeon Display Connectors
[   61.922030] [drm] Connector 0:
[   61.922100] [drm]   VGA
[   61.922170] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[   61.922287] [drm]   Encoders:
[   61.922357] [drm]     CRT1: INTERNAL_KLDSCP_DAC1
[   61.922427] [drm] Connector 1:
[   61.922496] [drm]   HDMI-A
[   61.922565] [drm]   HPD1
[   61.922634] [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[   61.922751] [drm]   Encoders:
[   61.922820] [drm]     DFP1: INTERNAL_KLDSCP_LVTMA
[   61.942202] [drm] radeon: power management initialized
[   61.958278] No connectors reported connected with modes
[   61.958351] [drm] Cannot find any crtc or sizes - going 1024x768
[   61.965068] [drm] fb mappable at 0xD0040000
[   61.965137] [drm] vram apper at 0xD0000000
[   61.965206] [drm] size 3145728
[   61.965274] [drm] fb depth is 24
[   61.965342] [drm]    pitch is 4096
[   61.965460] fbcon: radeondrmfb (fb0) is primary device
[   61.979478] Console: switching to colour frame buffer device 128x48
[   61.985634] fb0: radeondrmfb frame buffer device
[   61.985696] drm: registered panic notifier
[   61.985755] [drm] Initialized radeon 2.10.0 20080528 for 0000:01:05.0 on minor 0

and yet:

:; ls -sl /lib/firmware/radeon/R600_rlc.bin
4 -rw-r--r-- 1 root root 3072 Jun  6 12:15 /lib/firmware/radeon/R600_rlc.bin

(from a fresh update from 
http://people.freedesktop.org/~agd5f/radeon_ucode/ .)
Comment 1 Andrew Morton 2011-06-06 23:59:54 UTC
If it was Ok a couple of weeks ago then I assume that this is a psot-2.6.39 regression?
Comment 2 James Cloos 2011-06-07 00:47:29 UTC
Longer than that.

The box is usually headless; when I first got it the missing firmware prevented booting, so I added radeon.modeset=0 to the grub config and manually changed that for those occasions when I moved the box to the TV.  Today I changed the grub config in honour of the upcoming 3.0. ☺

(That it boots now even though it fails to load that firmware is a nice progression.)

My best guess, based on the timestamps of my .config archive, is that I last connected it to the TV during the 38-rc1 timeframe.
Comment 3 James Cloos 2011-06-07 00:53:41 UTC
I forgot to add:

I don’t see from git-grep(1)ing the tree where or how the kernel knows to find firmware in /lib/firmware.

All I can see is /lib/firmware as the target to make firmware_install and several comments specifying /lib/firmware as the typical location.

What am I missing?
Comment 4 Alex Deucher 2011-06-07 02:17:36 UTC
Most likely you did not include the firmware in your initrd.
Comment 5 James Cloos 2011-06-07 04:01:31 UTC
Ah.  OK.  The driver tries to load the firmware before / is mounted, then?

As I do not use initrd there the answer seems to be:

-CONFIG_EXTRA_FIRMWARE=""
+CONFIG_EXTRA_FIRMWARE="radeon/R600_rlc.bin"
+CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"

to the .config.

Closing as invalid.  Will reopen if the above .config change doesn’t fix it.

(Last time I must have manually done what EXTRA_FIRMWARE does.  I lost that clone in the meantime, though, so that is only a guess.  (It was a clone of
my local, pristine clone.  And the .configs were backed up in their own git
repo.  So that loss didn’t seem like much of a nuisance.  But I obviously forgot about this issue in the meantime. ☹)

Note You need to log in before you can comment on or make changes to this bug.