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
Can you attach the dmesg output from the non-working case?
and the xorg log from the non-working case?
Does X load ok if you disable acceleration: Option "NoAccel" "TRUE" in the device section of your xorg.conf?
(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.
(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
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?
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.