Bug 21020

Summary: [BISECTED] xf86-video-ati fails spectacularly on X startup (on DEC Alpha)
Product: DRI Reporter: Matt Turner <mattst88>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED NOTOURBUG QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Alpha   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg output of the carnage
none
Xorg.0.log during crash none

Description Matt Turner 2009-04-02 17:12:25 UTC
Created attachment 24480 [details]
dmesg output of the carnage

commit 5b5441f8cc119db0d1e03dd35bd06015a26270dd "Increase default GART size to 32MB on >=R300" causes X to fail spectacularly, bringing down all sorts of running processes, such as sshd and hald.

All commits prior to this work. Tested with xserver-1.5.3.
Comment 1 Matt Turner 2009-04-02 19:58:27 UTC
Created attachment 24486 [details]
Xorg.0.log during crash

Looks like it doesn't show much of anything interesting.
Comment 2 Michel Dänzer 2009-04-03 00:04:21 UTC
So does it still work with Option "GARTSize" "8"? What about "16"?

When the kernel agpgart modules are loaded, what do they say about the aperture size? Assuming it's >= 32 MB: If I'm reading the dmesg correctly, the machine seems to have at least 4 GB of RAM? Does the problem occur if you boot with something like mem=1g or mem=2g?
Comment 3 Matt Turner 2009-04-03 18:10:38 UTC
(In reply to comment #2)
> So does it still work with Option "GARTSize" "8"? What about "16"?'

Yes, setting GARTSize to 8 allows X to start properly. With 16, it fails in the same fashion.
 
> When the kernel agpgart modules are loaded, what do they say about the aperture
> size? Assuming it's >= 32 MB: If I'm reading the dmesg correctly, the machine
> seems to have at least 4 GB of RAM? Does the problem occur if you boot with
> something like mem=1g or mem=2g?

I tried booting with mem=1g and GARTSize 16. It failed in the same way.

This motherboard is a UP1500, made by Samsung, and never had all the firmware bugs worked out. For instance, the PALcode initializes the AGP GART in such a way that it is unusable on Alpha. Hence, the card must be forced into PCI mode in xorg.conf to even start.

See http://bugzilla.kernel.org/show_bug.cgi?id=12127#c6 for a more detailed analysis. I'll contact the poster of that message to see if he can offer insight into this problem.
Comment 4 Michel Dänzer 2009-04-06 00:54:03 UTC
So this looks like a DRM or possibly even other kernel issue.
Comment 5 Matt Turner 2009-04-25 12:16:12 UTC
This problem appears to be specific to this motherboard, so I'm closing as NOTOURBUG.

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.