Bug 23671

Summary: X on alpha causes out-of-memory failures
Product: xorg Reporter: Matt Turner <mattst88>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED WONTFIX QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: mcree
Version: git   
Hardware: Alpha   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.0.log
none
dmesg
none
dmesg none

Description Matt Turner 2009-09-02 20:32:53 UTC
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.
Comment 1 Matt Turner 2009-09-02 20:33:13 UTC
Created attachment 29153 [details]
dmesg
Comment 2 Michel Dänzer 2009-09-03 06:49:46 UTC
> 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.
Comment 3 Matt Turner 2009-09-03 12:03:21 UTC
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.
Comment 4 Matt Turner 2009-09-07 11:47:43 UTC
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.
Comment 5 Matt Turner 2009-09-08 11:18:26 UTC
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.
Comment 6 Matt Turner 2009-09-08 12:19:59 UTC
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.
Comment 7 Matt Turner 2009-09-22 11:49:55 UTC
(In reply to comment #2)
> If so, does Option "DRI" "off" work around the problem?

Yes, disabling DRI works around the problem.
Comment 8 Matt Turner 2010-02-26 13:52:08 UTC
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
Comment 9 Matt Turner 2017-03-13 23:08:38 UTC
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.