Bug 31974

Summary: starting X with EXA, DRI enabled locks up the system (evergreen mobility card)
Product: xorg Reporter: Henning Fleddermann <Henning.Fleddermann>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: acelists
Version: 7.5 (2009.10)   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.log of locked up system.
none
Xorg.log of locked up system 2 none

Description Henning Fleddermann 2010-11-29 12:32:13 UTC
Whenever I start X on my machine with the radeon module loaded and the radeon-card enabled (I'm using vgaswitcheroo) I get a black screen with a white _ on it (it's not blinking though). I can't switch to a VT or anything then, the only thing the machine reacts to is magic-sysrq.
Starting X works fine radeon drivers before 6.13.2, but without any acceleration.
More info on my machine: It's a HP Pavilion dv6-3011sg. It has an integrated Intel and a dedicated ATi card (Radeon Mobility 5650). I use "echo DDIS >> /sys/kernel/debug/vgaswitcheroo/switch to switch to the ati-card.
I'm running Opensuse 11.3 with latest Xorg (7.5 currently) from this repo: http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.3/x86_64/ and latest kernel from this one (currently 2.6.37-rc2-git-snapshot): http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_11.3/
Unfortunately I don't have a second machine which I could use to ssh into mine and get a backtrace right now, but I'll attach an Xorg-log. Let me know if you need anything else.
Comment 1 Alex Deucher 2010-11-29 12:38:05 UTC
Does it work properly if you select the radeon card as the active one in the bios?
Comment 2 Henning Fleddermann 2010-11-29 12:39:46 UTC
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.
Comment 3 Henning Fleddermann 2010-11-29 12:42:24 UTC
(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.
Comment 4 aceman 2011-01-12 13:04:43 UTC
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.
Comment 6 aceman 2011-01-13 10:50:40 UTC
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.
Comment 7 Alex Deucher 2011-01-13 11:11:56 UTC
(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.
Comment 8 aceman 2011-01-13 11:23:33 UTC
Ok, can I test any other patch for r7xx?
Comment 9 Henning Fleddermann 2011-02-13 05:51:13 UTC
(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.
Comment 10 aceman 2011-02-18 12:49:30 UTC
Still hangs with 2.6.37.1, driver 6.14.0, card RV710.
Comment 11 Alex Deucher 2011-02-18 13:12:56 UTC
Does it still hang if you start X with:
Option "NoAccel" "True"
in the radeon device section of your xorg.conf?
Comment 12 aceman 2011-02-19 05:14:55 UTC
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.
Comment 13 aceman 2011-03-21 14:34:16 UTC
No change with kernel 2.6.38 and ati driver 6.14.1.
Comment 14 Henning Fleddermann 2011-04-20 13:43:38 UTC
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.
Comment 15 Alex Deucher 2011-04-20 14:00:50 UTC
(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.
Comment 16 Henning Fleddermann 2011-04-26 10:28:05 UTC
(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?
Comment 17 aceman 2011-04-26 11:16:04 UTC
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.
Comment 18 aceman 2011-04-30 05:16:10 UTC
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.
Comment 19 Michel Dänzer 2011-05-02 03:11:16 UTC
(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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.