Created attachment 29152 [details] Xorg.0.log I've filed this under DDX/Radeon, but it could be anything. I'm just hoping someone has a good guess at the next step to debug it. Starting up X causes a black screen. Nothing interesting in Xorg.0.log. dmesg shows out of memory failures. Using xserver, mesa, drm, xf86-video-ati from git. Using drm-next branch, booted with radeon.modeset=0.
Created attachment 29153 [details] dmesg
> Starting up X causes a black screen. Nothing interesting in Xorg.0.log. You're aware that with current xserver, 'black screen' is the expected default behaviour until a client displays something, right? :) If so, does Option "DRI" "off" work around the problem? The log file shows a monitor being connected to VGA but none to DVI, is that correct? ... > dmesg shows out of memory failures. Do you mean the locking self-test failures? At the end of those it says 145 out of 218 testcases failed, as expected. | so I don't think there's any problem there. I can't seem to see anything else matching your description.
Created attachment 29188 [details] dmesg Sorry, I was debugging a couple things at once and gave some incorrect information, including attaching the wrong dmesg log. Also, the screen does not go black as previously said, the monitor loses signal, and keyboard is unresponsive (numlock light goes off). SSH access still works, but manually killing X doesn't bring the monitor/keyboard back.
I can reproduce this with a Radeon 9100 PCI as well. I tried GARTSize "8", but it changed nothing. This looks very similar (exactly the same, maybe) as what I was seeing in bug 21020. I think I might have closed that one quite prematurely.
I completely removed X, Mesa, libdrm, and reinstalled xserver-1.5.3, mesa-7.3, and libdrm-2.4.9 (the ones marked stable in Gentoo) and was able to reproduce this issue. The only common thing was the kernel: airlied's drm-next branch, 2.6.31-rc6-26678-g50f1530-dirty. radeon.modeset=0 for all cases. > The log file shows a > monitor being connected to VGA but none to DVI, is that correct? ... Yes, this is correct.
I booted with 2.6.29-gentoo-r5 with the xserver-1.5.3 stack, and it works. Commit 5b5441f8cc119db0d1e03dd35bd06015a26270dd to xf86-video-ati, as mentioned in bug 21020, doesn't affect anything with .29. I tried with and without it. Going to try xserver 1.6.3 or 1.7 and see what happens.
(In reply to comment #2) > If so, does Option "DRI" "off" work around the problem? Yes, disabling DRI works around the problem.
So this bug is entirely about UMS. With NoAccel=true, or DRI=false, X starts fine. No corruption. Starting X with DRI kills it in the same way it has been in the previous logs. xf86-video-ati - e76b90b399c3cc0f0998c0209300c46f97505498 mesa - b628950662a97452e539bcc704bd2acee70f8355 libdrm - 3130f94c6ee32668cb9f0b96b6c8e308a7bb3b11 xserver - 018b177591c9fade6d065e31858cc6e054d33eff linus's kernel - 9f3a6284880ceea452903e2043c88d7226736318
UMS bug. No one cares.
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.