Bug 54662

Summary: [bisected] Kernel 3.6 breaks KMS on Radeon RV530 (black screen)
Product: DRI Reporter: Simon Kitching <skitching>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Dmesg output from a kernel that does not show black screen problem none

Description Simon Kitching 2012-09-08 06:42:16 UTC 
Created attachment 66826 [details]
Dmesg output from a kernel that does not show black screen problem

The following commit (merged in 3.6 rc series) makes the screen go black immediately after Plymouth completes (ie just before greeter screen):

876dc9f32907e57e0298bcd0f1607cb7a2582f63 is the first bad commit
commit 876dc9f32907e57e0298bcd0f1607cb7a2582f63
Author: Christian König <deathsimple@vodafone.de>
Date:   Tue May 8 14:24:01 2012 +0200

    drm/radeon: remove radeon_fence_create

Note that this is a different bug than https://bugs.freedesktop.org/show_bug.cgi?id=54129 (which I'm also getting) but might be related.

The same kernel boots without problems using "nomodeset".

System is an x86-32 laptop (about 5 years old) with Radeon mobility X1600, running Ubuntu 12.04.

lspci reports:
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI M56P [Radeon Mobility X1600]

Attached is full dmesg output from a *different* (ie earlier, working) kernel. Some relevant bits include:
[    2.978637] [drm] Initialized drm 1.1.0 20060810
[    3.052940] [drm] radeon defaulting to kernel modesetting.
[    3.052945] [drm] radeon kernel modesetting enabled.
[    3.053261] [drm] initializing kernel modesetting (RV530 0x1002:0x71C5 0x103C:0x30A3).
..
[    3.245417] [drm] Loading R500 Microcode
[    3.247401] [drm] radeon: ring at 0x0000000010001000
[    3.247441] [drm] ring test succeeded in 9 usecs
...
[    4.064745] [drm] Initialized radeon 2.17.0 20080528 for 0000:01:00.0 on minor 0
Comment 1 Alex Deucher 2012-09-08 15:36:53 UTC 
Can you attach the dmesg output from the non-working case?
Comment 2 Alex Deucher 2012-09-08 15:37:09 UTC 
and the xorg log from the non-working case?
Comment 3 Alex Deucher 2012-09-08 15:38:42 UTC 
Does X load ok if you disable acceleration:

Option "NoAccel" "TRUE"

in the device section of your xorg.conf?
Comment 4 Simon Kitching 2012-09-09 13:43:26 UTC 
(In reply to comment #1)
> Can you attach the dmesg output from the non-working case?

Hi Alex,

Thanks very much for your suggestions. 

I'm not sure how to obtain dmesg output, given that I can't get a console in the failing case. The normal login screen is black, ctrl-alt-f2 doesn't work. Unfortunately I don't have another machine available to try to SSH to this laptop. Booting with "nomodeset" works, but then dmesg isn't very useful.

Recent Ubuntu versions don't come with an xorg.conf file, and "sudo Xorg -configure" reports a fatal error, so I'm not sure how to generate a base file to tweak.

I could attach /var/log/Xorg.0.log.old after rebooting from the failed state to something saner, if this would be useful.

However patch "https://bugs.freedesktop.org/attachment.cgi?id=66876" attached to bug #54129 appears to fix this bug too, so the above are probably moot.
Comment 5 Tony Thomas 2012-09-11 15:52:36 UTC 
(In reply to comment #4)
> (In reply to comment #1)

> 
> Recent Ubuntu versions don't come with an xorg.conf file, and "sudo Xorg
> -configure" reports a fatal error, so I'm not sure how to generate a base file
> to tweak.
> 

Recent versions of Ubuntu (and others) allow for snippets of Xorg.conf in either /etc/X11/xorg.conf.d, or (as in Ubuntu) /usr/share/X11/xorg.conf.d. Just make a new file, and add a section such as this:

#vi 50-mydevice.conf

Section "Device"
    Identifier "my-radeon-card"
    Option "NoAccel" "TRUE"
EndSection
Comment 6 Simon Kitching 2012-09-16 07:20:29 UTC 
Most of the discussion on this issue has been going on at bug 54129 and bug 51344.

A patch has recently been merged into Linus' tree for 3.6-rc5+:

commit f492c171a38d77fc13a8998a0721f2da50835224
Author: Christian König <deathsimple@vodafone.de>
Date:   Thu Sep 13 10:33:47 2012 +0200

    drm/radeon: make 64bit fences more robust v3

This fixes the issue, so I'll close this bug as fixed.
Thanks to Christian,Alex,Tony,Jerome.

Just a minor note: perhaps a comment in the patch would have been useful, to explain why the extra ORs and comparisons are needed - so the next cleanup doesn't take them out again?
Comment 7 Christian König 2012-10-03 10:54:03 UTC 
An additional comment why those extra checks are needed indeed sounds like a good idea.

I will keep this in mind when I write the next set of patches touching this.

Till then we can probably safely close this bug.

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.