Getting Open Source 3D graphics on R6XX/R7XX cards (NO FGLRX)

[rjwaldren]

quoted - "Is there anybody running Debian testing/unstable who can no longer get this to work?"

I'm having the same or similar problem with Lucid on my hd4850 - Since around the time the interrupt patches made it into the kernel tree. The current 2.6.32-9.13 kernel from Ubuntu works fine with KMS enabled, it looks to have drm upto the .32 release plus a few backported patches. The latest Ubuntu kernels from the mainline along with a custom compiled DRM-Radeon-Testing applied to Linus' git and Ubuntus 32-9.13 git source have all failed the same way. The remainder of the stack is the lastest (tried both Edgers-PPA and git compiles) and does not appear to be the problem.

I've been busy with other things so I haven't been trying to chase it down lately. When radeon modprobes on the newer kernels the screen immediately blanks (as though the HMDI output is disabled). This occurs with both UMS or KMS. SSHing in, dmesg shows the driver probed and loaded the firmwares with out error and reports that it's switching to a massive console mode (? 267x67). And Xorg.0.log looks like everything is going fine (detected modes look good,etc) and it selects the usual 1920x1080 mode. But the log just stops after that, haven't seen any errors reported aside from the failure to actually produce output.

Like I said the current 32-9.13 kernel along with the latest libdrm, mesa, DDX works great. So I've just been using that and checking every couple of days to see if the kernel (X server) issue is resolved. If rc2 is out now, I should be able to try it and collect some logs this w/e.

[h3xis]

What updates? If you compile mesa/drm, etc, then any update from debian repositories will rewrite your compilations. That will be until Debian unstable/testing update to the latest mesa and drm releases. If that is the case, you have to again install mesa and drm from git.

If that is not the case, try with the latest 2.6.33-rc2. Don't forget to put the interrupts firmware under /lib/firmware/radeon.

I recently did this. You have to set these 3 lines in kernel config to:
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="radeon/R600_rlc.bin radeon/R700_rlc.bin"
CONFIG_EXTRA_FIRMWARE_DIR="firmware"

Build, run and report.

This worked. Thank you so much. The only thing now that concerns me is I'm getting a warning that displays before radeon loads that says (II) [KMS] No DRICreatePCIBusID symbol, no kernel modesetting. I feel that I should have mentioned earlier that I'm building all of this for r300 - not r600/700. What is KMS and do I need it for r300? I did enable it in my kernel as the first post says to do. Does this error mean that it's not enabled, when it should be? When I run ./autogen.sh --prefix=/usr for xf86-video-ati, I see somewhere that it says checking for XEXT... no. Is this bad/important? It does say "yes" next to kernel modesetting as well. And last, what is OSMesa and do I need it? I have it installed under Debian, but when I run the autogen.sh script it says "no" next to it.

[aljaz]

This worked. Thank you so much. The only thing now that concerns me is I'm getting a warning that displays before radeon loads that says (II) [KMS] No DRICreatePCIBusID symbol, no kernel modesetting. I feel that I should have mentioned earlier that I'm building all of this for r300 - not r600/700. What is KMS and do I need it for r300? I did enable it in my kernel as the first post says to do. Does this error mean that it's not enabled, when it should be? When I run ./autogen.sh --prefix=/usr for xf86-video-ati, I see somewhere that it says checking for XEXT... no. Is this bad/important? It does say "yes" next to kernel modesetting as well. And last, what is OSMesa and do I need it? I have it installed under Debian, but when I run the autogen.sh script it says "no" next to it.

KMS=kernel modesetting. And no, you don't really need it unless you have multiple concurrent users on the same computer. Under KMS every user has DRI enabled as opposed to without KMS option (this is why it's useful to me).

Apart from that, you're in the wrong thread. This one talks about R6XX/R7XX. But anyway, it should be the same for R300 and below, because I use the same guide for a laptop with a R1XX. I only leave out the --with-dri-drivers=r600, which under the latest mesa git you shouldn't even need anymore.

So why don't you have KMS? Have you checked all your kernel options from the guide - they have to be exactly like written in the guide? Did you disable KMS via grub (radeon.modesett=0)?

For mesa and dri and stuff you should find a wiki.

[sovok_kpss]

Does hibernation(TuxOnIce) still don't work with KMS?

[h3xis]

KMS=kernel modesetting. And no, you don't really need it unless you have multiple concurrent users on the same computer. Under KMS every user has DRI enabled as opposed to without KMS option (this is why it's useful to me).

Apart from that, you're in the wrong thread. This one talks about R6XX/R7XX. But anyway, it should be the same for R300 and below, because I use the same guide for a laptop with a R1XX. I only leave out the --with-dri-drivers=r600, which under the latest mesa git you shouldn't even need anymore.

So why don't you have KMS? Have you checked all your kernel options from the guide - they have to be exactly like written in the guide? Did you disable KMS via grub (radeon.modesett=0)?

For mesa and dri and stuff you should find a wiki.

I couldn't find a thread for the R300 and this one worked, only I just replaced r600 with r300. I've narrowed down the KMS issue to the kernel. I get the same error as I did before (the "no usable configuration" one) if I use a kernel below 2.6.33, but KMS says it's enabled. If I use 2.6.33, everything works (including DRI), except for KMS. I don't really need that then since I have only 1 user on here. When configuring the kernel, instead of using radeon/R700_rlc.bin, I have been putting radeon/R300_cp.bin. Would this be correct?

[aljaz]

I couldn't find a thread for the R300 and this one worked, only I just replaced r600 with r300. I've narrowed down the KMS issue to the kernel. I get the same error as I did before (the "no usable configuration" one) if I use a kernel below 2.6.33, but KMS says it's enabled. If I use 2.6.33, everything works (including DRI), except for KMS. I don't really need that then since I have only 1 user on here. When configuring the kernel, instead of using radeon/R700_rlc.bin, I have been putting radeon/R300_cp.bin. Would this be correct?

Khm... For R300 you shouldn't add anything. It should work out of the box. Though I must say I haven't tried 2.6.33 yet on the mentioned laptop so it could be you've done nothing wrong. Maybe tomorrow I'll compile this kernel on the laptop and see what I get.

[tball]

quoted - "Is there anybody running Debian testing/unstable who can no longer get this to work?"

I'm having the same or similar problem with Lucid on my hd4850 - Since around the time the interrupt patches made it into the kernel tree. The current 2.6.32-9.13 kernel from Ubuntu works fine with KMS enabled, it looks to have drm upto the .32 release plus a few backported patches. The latest Ubuntu kernels from the mainline along with a custom compiled DRM-Radeon-Testing applied to Linus' git and Ubuntus 32-9.13 git source have all failed the same way. The remainder of the stack is the lastest (tried both Edgers-PPA and git compiles) and does not appear to be the problem.

I've been busy with other things so I haven't been trying to chase it down lately. When radeon modprobes on the newer kernels the screen immediately blanks (as though the HMDI output is disabled). This occurs with both UMS or KMS. SSHing in, dmesg shows the driver probed and loaded the firmwares with out error and reports that it's switching to a massive console mode (? 267x67). And Xorg.0.log looks like everything is going fine (detected modes look good,etc) and it selects the usual 1920x1080 mode. But the log just stops after that, haven't seen any errors reported aside from the failure to actually produce output.

Like I said the current 32-9.13 kernel along with the latest libdrm, mesa, DDX works great. So I've just been using that and checking every couple of days to see if the kernel (X server) issue is resolved. If rc2 is out now, I should be able to try it and collect some logs this w/e.

I have the exact same problem on a laptop with 4650.
With the mainline kernel 2.6.32-9 everything seems fine. But when I try to boot into a mainline ubuntu 2.6.33-rc2 kernel, I get the problem you describes. I don't see any errors in the kern.log, but it just stays black when gdm used to load.

I get this in the 2.6.33-rc2's kernel log also:
kernel: [ 20.811585] Console: switching to colour frame buffer device 240x67

I don't know if thats a problem at all.
Plz tell me if you find anything about the problem.

[h3xis]

I have the exact same problem on a laptop with 4650.
With the mainline kernel 2.6.32-9 everything seems fine. But when I try to boot into a mainline ubuntu 2.6.33-rc2 kernel, I get the problem you describes. I don't see any errors in the kern.log, but it just stays black when gdm used to load.

I get this in the 2.6.33-rc2's kernel log also:
kernel: [ 20.811585] Console: switching to colour frame buffer device 240x67

I don't know if thats a problem at all.
Plz tell me if you find anything about the problem.

I can't get it to work on anything less than 2.6.33. It seems we have the opposite problem.

As an update, I got KMS working. I just rebuilt everything and it worked. Dunno what I did wrong last time.

[tball]

I can't get it to work on anything less than 2.6.33. It seems we have the opposite problem.

As an update, I got KMS working. I just rebuilt everything and it worked. Dunno what I did wrong last time.

Well thats odd. I wonder if it has anything to do with fbcon. It is loaded with 2.6.32-9, but I don't know if its loaded with 2.6.33-rc2.
As I have been told, this modules should be loaded before the radeon module or else you won't see anything in the console.

EDIT:
BTW I am using Ubuntu Karmic with latest tormod ddx,drm, mesa etc. for Lucid.

[ankerman]

openSUSE 11.2 working

Just wanted to share that Neo's guide works like a charm on vanilla openSUSE 11.2 as well. I had to install xorg-x11-server-sdk as well as expat, to resolve some dependencies.
I started at step 5 - no need to patch and compile your own kernel, just build the Xorg stuff.

My system:

ATI Radeon Mobility X600 (M24) 3150 (PCIE) on a Dell D810.

Thanks for the guide!