Bug 31974

Does it work properly if you select the radeon card as the active one in the bios?

Created attachment 40648 [details] [review]
Xorg.log of locked up system.

I forgot to mention: I build radeon from git myself, so it's the newest version.

(In reply to comment #1)
> Does it work properly if you select the radeon card as the active one in the
> bios?

Unfortunately my bios has no such option.

Created attachment 41934 [details] [review]
Xorg.log of locked up system 2

I also get this hang only since kernel 2.6.37 (final). The next message in the log at a successful start (older kernel) should be:
(II) RADEON(0): Set up textured video
(II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled message.

Does this patch help?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=86f5c9edbb3bac37cc8cee6528a929005ba72aad

I suppose this is a patch for the kernel 2.6.37. Is it relevant for my RV710 card? The patch changes the drivers/gpu/drm/radeon/evergreen.c file.

(In reply to comment #6)
> I suppose this is a patch for the kernel 2.6.37. Is it relevant for my RV710
> card? The patch changes the drivers/gpu/drm/radeon/evergreen.c file.

Not relevant for r7xx.  Only evergreen.

Ok, can I test any other patch for r7xx?

(In reply to comment #5)
> Does this patch help?
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=86f5c9edbb3bac37cc8cee6528a929005ba72aad

Sorry I've only now gotten around to reporting back, as I moved recently and didn't have any internet yet at my new place.
I just now tested again with the latest radeon and linux-kernel 2.6.38-rc4 (as far as I can tell the patch you linked to should be included in that one, right?) and it still locks up at exactly the same point.
When I use an older radeon the XServer starts up but ofc without dri. I get indirect rendering though.

Still hangs with 2.6.37.1, driver 6.14.0, card RV710.

Does it still hang if you start X with:
Option "NoAccel" "True"
in the radeon device section of your xorg.conf?

Yes, this does help. X server starts normally and everything works (slower of course). for referrence, I see the same problem as the reporter (black screen with cursor and possibility to reboot system with alt-sysrq). But I do not have any dual GPUs. This is a normal desktop system with 1 GPU (RV710). X server is 1.9.4.

No change with kernel 2.6.38 and ati driver 6.14.1.

Recently my problem has disappeared. Unfortunately I've no idea what exactly fixed it for me, but at least with 2.6.39-rc2 and ati 6.14.1 it's now working for me... at least kinda. The XServer starts up and Xorg-log reports EXA and DRI2 are enabled, but everything is veeery slow... for example I only get ~16FPS (~24 with SwapBuffersWait off and ColorTiling on) on OpenArena and even kwin-compositing is sluggish.

(In reply to comment #14)
> Recently my problem has disappeared. Unfortunately I've no idea what exactly
> fixed it for me, but at least with 2.6.39-rc2 and ati 6.14.1 it's now working
> for me... at least kinda. The XServer starts up and Xorg-log reports EXA and
> DRI2 are enabled, but everything is veeery slow... for example I only get
> ~16FPS (~24 with SwapBuffersWait off and ColorTiling on) on OpenArena and even
> kwin-compositing is sluggish.

Sounds like you are getting sw rendering.  Make sure you have a a 3D driver that supports evergreen installed (r600g or r600c).  Check the output of glxinfo to see if you are using a hw or sw 3D driver.

(In reply to comment #15)
> Sounds like you are getting sw rendering.  Make sure you have a a 3D driver
> that supports evergreen installed (r600g or r600c).  Check the output of
> glxinfo to see if you are using a hw or sw 3D driver.
I'm pretty sure I'm getting hw-rendering. Here are the relevant lines from glxinfo:
direct rendering: Yes
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD REDWOOD
OpenGL version string: 2.1 Mesa 7.10
I think I'm hitting bug #34156 and/or #34493.

Anyway I think this bug can be closed... at least wrt evergreen?

I can confirm this. I am sure kernel 2.6.38 didn't work for me (on HD4350), but now kernel 2.6.38.3 works fine. I even tested that CONFIG_VGA_ARB has no effect on the problem (and I only have 1 discrete card).

I can not confirm the overall slowdown. I see slower xterm redraws and transparency effects (in kwin), but not slowness in 3D programs (e.g. celestia, googleearth). I am using R600c Mesa driver.

This happened to me again. I was on kernel 2.6.38.4. I noticed my kernel drivers for my v4l TV capture card were missing. The compile options propably changed since (2.6.36 or .37) and I didn't notice so the modules got compiled out. So I compiled them and loaded into the running kernel. They worked fine. However, when I logged off the KDE session, kdm should have appeared. This didn't happen and I got a black screen again. I think the X server restarts when the session is logged off. So I tried to reboot but when X was starting I got this bug again (black screen). Trying several reboots I determined that kernel 2.6.38.4 doesn't work since now, but 2.6.38.3 works (it does not have the v4l modules). So blaming the v4l kernel modules I removed loading the v4l module from the X server config. And guess what, X server started now fine with 2.6.38.4. The module version is 0.1.1 (according to Xorg.log), compiled for server 1.9.2. So, can this be caused by the removal of v4l API version 1 from the kernel. I read the v4l X module needs to be updated for this change. However, I find it strange that this module affect the main radeon module in any way. I would have thought the X server would hang at loading the v4l module if it doesn't find the proper kernel APIs. But the attached log (comment 4) shows hang much later.

(In reply to comment #16)
> Anyway I think this bug can be closed... at least wrt evergreen?

Sure, as your problem seems solved.


aceman, your problem is probably different and should be tracked separately. FWIW, check the X server's stderr output (should be captured in the kdm log file) for unresolved symbols or something like that.