[ubuntu-x] [gutsy-current-state] Radeon 200M (RC410)
Bryce Harrington
bryce at bryceharrington.org
Fri Sep 21 20:29:13 BST 2007
On Fri, Sep 21, 2007 at 11:57:50AM +0200, Dimitri Van Landuyt wrote:
> On my 200M, the default behaviour is that the laptop boots, then you can
> see the screen blinking a few times, and then finally hanging hard, as
> described in the above bug. I found that expliitly adding
>
> Option "GARTSize" "128"
>
> to xorg.conf helps: the laptop boots. However, the X-server crashes (and
> restarts automatically) as soon as anything 3D related is started:
> glxinfo, glxgears, compiz, even f-spot manages to make it crash.
>
> I would like to help you fix this issue, as I think the currently
> default behaviour is really unacceptable for when gutsy is ready. I
> tried several additional options, using EXA instead of XAA, all to no
> avail. No open source acceleration for my card...
Hi Dimitri,
Glad to have your help on this bug. Since the bug's not been triaged,
it otherwise probably wouldn't get worked on. I can give you some
directions:
First, you should test against a more recent daily. We've switched out
the -ati driver and made several bug fixes to xserver since the 8th, so
to make sure you're not experiencing an already-fixed issue, test
something from at least the 19th.
The cycling behavior sounds like gdm trying to start X but failing.
Normally, this should put you into the Bulletproof-X failsafe mode, but
that depends on the -vesa driver working; for some ATI hardware there
have been some known issues with ATI's vesa. So that'd be my first
guess (however my first guesses on X bugs are usually wrong, so take
that with a grain of salt).
I would start investigation by booting to the console, and then attempt
to manually start X using startx. Try switching drivers in xorg.conf
between "vesa", "ati", and maybe even framebuffer or fglrx. You may
have to fiddle with driver options and monitor resolutions for some of
these (e.g. vesa has limited resolution ranges). Attempt to narrow down
which driver(s) fail, and collect any relevant error messages you can.
If by chance you're able to get things up and running fine through
startx and a manually configured xorg.conf, then this is likely a
ubuntu-specific issue. Let me know if this is the case and we can work
from here.
Otherwise, next look upstream in bugzilla.freedesktop.org and
bugs.debian.org to see if there are already bug reports that match the
error messages and behavior you're seeing. Don't forget to search
against closed as well as open bugs.
It can also be of use to install xserver or the relevant driver(s) from
upstream git, if you're comfortable compiling and installing these on
your own. If the git version works, then it suggests either there is a
fix we can backport, or that there is a ubuntu- or debian-specific patch
that should be dropped. In these cases it is just a matter of sorting
through the changes to narrow in on what patch does the trick.
If it does not work either, then this suggests a problem that should be
reported upstream. Create a new bug report at bugzilla.freedesktop.org,
and include as much info as you can, including at least Xorg.0.log,
xorg.conf, lspci -vvnn, a photo (if appropriate - probably not needed
here), and detailed steps to reproduce. Also, if you know specific
versions of xserver, drivers, etc. where the issue does occur, and other
versions where it doesn't, those are very important to report too.
I hope this all gives you enough to go on towards getting this fixed.
Thanks again for the help in getting this resolved.
Bryce
More information about the Ubuntu-x
mailing list