[gentoo-amd64] Re: accelerated X 7.1 & ATI card

[Duncan]

Reinhard Kotucha <reinhard.kotucha@×××.de> posted
17639.58433.905934.461579@××××××××××××××.local, excerpted below, on  Sun,
20 Aug 2006 06:25:37 +0200:

> Hi, please apologize that I hijack the thread but it seems that I have
> the same problem as Piotr.
>
> The output of lspci is the same as described by Piotr.  So I think
> that we have the same cards.
>
>>>>>> "Duncan" == Duncan  <1i5t5.duncan@×××.net> writes:
>
>   > Support for the RV300 series is /very/ new and still somewhat
>   > experimental.  You may get 2D but not 3D support.  You are also
>   > likely to have better luck with the latest xorg 7.2, which may
>   > still be masked, I'm not sure (I loaded it when it was).
>
> I don't think that the RV300 cards are too new.  I bought it end of
> last year and it worked very well with the xorg-6.8 radeon server.

The cards aren't new, and they've had 2D support for awhile (AFAIK), but
the 3D support is what's new and experimental...  Checking, 3D for
your card isn't yet in what I'm running, either (xf86-video-ati-6.6.1,
xorg-server-1.1.1).  It must be only in CVS/SVN.

> It doesn't work after the latest system update (which switched to
> xorg-7.0.0.).
>
> I suppose that I did not install X11 completely.  I renamed /etc/X11
> to /etc/X11-backup and re-emerged xorg-x11 in the hope I get a new
> /etc/X11 directory.  But this did not happen.  /etc/X11 contains a lot
> of files and I assume that many things had been changed there.

There's a lot of stuff that has been switching to more standardized
system locations, instead of the old xf86 specific locations.  However,
most of that is in /usr.  Checking here, xorg-server doesn't have anything
in /etc/X11 at all.

FWIW, here's an equery showing all packages I have merged with files in
/etc/X11.  In particular, you'll want to check xinit and if you use it,
xfs (but your fonts section doesn't have a listing for it so you
apparently don't).

$equery b -f /etc/X11/.*
[ Searching for file(s) /etc/X11/.,/etc/X11/.. in *... ]
media-gfx/xloadimage-4.1-r4 (/etc/X11/xloadimagerc)
x11-base/xorg-x11-7.1 (/etc/X11/xorg.conf)
media-sound/xmms-1.2.10-r16 (/etc/X11/wmconfig)
media-sound/xmms-1.2.10-r16 (/etc/X11/wmconfig/xmms)
x11-apps/xfs-1.0.2 (/etc/X11/fs)
x11-apps/xfs-1.0.2 (/etc/X11/fs/config)
x11-apps/xinit-1.0.2-r6 (/etc/X11/Sessions/Xsession)
x11-apps/xinit-1.0.2-r6 (/etc/X11/chooser.sh)
x11-apps/xinit-1.0.2-r6 (/etc/X11/xinit/xinitrc)
x11-apps/xinit-1.0.2-r6 (/etc/X11/Sessions)
x11-apps/xinit-1.0.2-r6 (/etc/X11/xinit)
x11-apps/xinit-1.0.2-r6 (/etc/X11/startDM.sh)
sys-apps/groff-1.19.2-r1 (/etc/X11/app-defaults/GXditview)
sys-apps/groff-1.19.2-r1 (/etc/X11/app-defaults)
x11-libs/motif-config-0.10 (/etc/X11/mwm)
x11-libs/motif-config-0.10 (/etc/X11/mwm/system.mwmrc)
x11-libs/motif-config-0.10 (/etc/X11/app-defaults)
x11-libs/motif-config-0.10 (/etc/X11/app-defaults/Mwm.defaults)
kde-base/kdebase-startkde-3.5.4 (/etc/X11/Sessions)
kde-base/kdebase-startkde-3.5.4 (/etc/X11/Sessions/kde-3.5)

> I followed the instructions given in
>
>   http://gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml
>
> but I'm not sure that everything I did was correct.

Good following the instructions, not good of course that you aren't sure
you followed them correctly.

> Here is my xorg.conf with all comments removed.

[much snippage in file]
 
> Section "Monitor"
> 	Identifier   "Monitor0"
> 	HorizSync    30.0 - 121.0 # Warning: This may fry old Monitors
> 	VertRefresh  50.0 - 150.0 # Very conservative. May flicker.
>
> 	DisplaySize 400 300

Hmm... nice size monitor size! =8^)  I'm running two that size, @
1600x1200 stacked for 1600x2400.  (I used to run them at 2048x1536 for
2048x3072, but decided that was a bit much.)


> Section "Device"
> 	Identifier  "ATI Graphics Adapter 0"
> 	Driver      "radeon"
> 	Option      "NoAccel" "no"
> 	Option      "MergedFB" "off"
> 	Option      "UseFBDev" "off"
> 	Option      "BusType" "PCIE"
> 	Option      "MonitorLayout" "CRT"
> EndSection
>
> Section "Screen"
> 	Identifier "Screen 0"
> 	Device     "ATI Graphics Adapter 0"
> 	Monitor    "Monitor 0"

Note that the monitor section above may not be used -- here the ID
specified has a space.  Above, no space.  Does xorg ignore the space and
treat them the same?

> Here is the server log:

> (WW) RADEON: No matching Device section for instance (BusID PCI:1:0:1)
> found

This is the only indication of problems there, but as you probably already
know, this is often normal on chips that can have two outputs (whether
your card does or not), with the second instance only auxiliary and not
needed/used under normal circumstances, even when both outputs are used.

The only other thing of note here is how short the log file is.  Mine has
far more stuff about setting up the memory and DMA space and the like, and
about detecting the monitor.  However, I believe 7.1/7.2 are more verbose
in their log, part of that is 3D stuff only and you only have 2D drivers
for that chip, and it may be also be less verbose when you don't have a
direct monitor entry (as I said, it doesn't appear the monitor entry will
be used, due to the space in one place, no-space in the other).

> __________________________________________________________________
>
> The output of
>
>     strace -f -eopen startx
>
> is at:
>
>    http://ms25.ath.cx/strace_x.log
>    http://ms25.ath.cx/strace_x.log.bz2
>
> The log file is 800kB while the bz2 version is only 9kB.
>
> Any ideas what is going wrong?

I checked the strace output.  I'm /not/ an expert in such things and don't
claim to be, but the following caught my eye:

(**) RADEON(0): RADEONScreenInit finished
[pid  9421] open("/proc/bus/pci/devices", O_RDONLY) = 6
[pid  9421] open("/proc/bus/pci/devices", O_RDONLY) = 6
[pid  9421] open("/proc/bus/pci/devices", O_RDONLY) = 6
[pid  9421] open("/proc/bus/pci/devices", O_RDONLY) = 6
[pid  9421] open("/proc/bus/pci/devices", O_RDONLY) = 6
[pid  9421] open("/proc/bus/pci/devices", O_RDONLY) = 6
[pid  9421] open("/proc/bus/pci/devices", O_RDONLY) = 6
[pid  9421] open("/proc/bus/pci/devices", O_RDONLY) = 6
[pid  9421] open("/proc/bus/pci/devices", O_RDONLY) = 6
[pid  9421] open("/proc/bus/pci/devices", O_RDONLY) = 6
[pid  9421] open("/usr/lib64/xserver/SecurityPolicy", O_RDONLY) = 6
[pid  9421] open("/dev/input/mouse0", O_RDWR|O_NONBLOCK) = 6
[pid  9421] --- SIGFPE (Floating point exception) @ 0 (0) ---

   *** If unresolved symbols were reported above, they might not
   *** be the reason for the server aborting.

It looks like it finishes ScreenInit (it /says/ it does <g>), then crashes
just a bit later.  To my inexpert eye anyway, it /appears/ this crash is
right after, thus likely related to, either the SecurityPolicy read, or
the mouse initialization.

Now, that security file is part of xorg-server (according to equery
belongs), which you tried rebuilding, so that /shouldn't/ be the problem. 
Still, double-check it manually.  Open it in an editor and verify that
it's all normal text and looks "clean".  Sometimes a file system
corruption can stick a big block of binary trash in the config file, and
unsurprisingly, coming upon a bunch of binary garbage unexpectedly when
the app expects a nice text configuration can cause a crash! (Yes, I know
I'm stating the obvious. <g>)

The more likely issue from my viewpoint is the mouse config. 
/dev/input/mouse0 exists, right?  I notice in your xorg.conf, in the
ServerFlags section, you don't have an Option "AllowMouseOpenFail" entry.
Try adding that and see what happens.  I don't expect it to work however
because it will still try the mouse and that might be causing the crash. 
Next, try commenting out the mouse device section entirely.  Maybe it will
work then?

Here's what earch (a script I picked up off of the dev list) has to say
about the available mouse drivers:

earch xf86-input-mouse
xf86-input-mouse-1.0.4[0]: amd64 hppa x86 ~x86-fbsd
xf86-input-mouse-1.1.1[0]: alpha ~amd64 arm ~hppa ia64 mips ppc ppc64 sh sparc ~x86 ~x86-fbsd

So 1.0.4 is marked stable amd64, 1.1.1 is ~amd64.  You appear to be on
stable, so should have 1.0.4.  Try remerging it, but just in case, try
remerging x11-proto/inputproto first, /then/ the mouse driver.

Next suggestion if that doesn't work...

Here, in my xorg log, immediately after the RADEONScreenInit finished
entry, I have this:


(**) RADEON(0): RADEONScreenInit finished
(==) RandR enabled
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension XC-APPGROUP
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFIXES
(II) Initializing built-in extension XFree86-Bigfont
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE
(II) Initializing built-in extension DAMAGE
(II) Initializing built-in extension XEVIE
drmOpenDevice: node name is /dev/dri/card0

Thus, it's possible one of your extensions is causing the crash.  I'd try
remerging all your x11-proto/* packages, then anything owning
/usr/lib64/xorg/proto/.  For reference, here's what an equery belongs
turns up here:

$equery b /usr/lib64/xorg/modules
[ Searching for file(s) /usr/lib64/xorg/modules in *... ]
x11-drivers/xf86-input-keyboard-1.1.0 (/usr/lib64/xorg/modules)
x11-drivers/xf86-video-ati-6.6.1 (/usr/lib64/xorg/modules)
x11-drivers/xf86-input-mouse-1.1.1 (/usr/lib64/xorg/modules)
x11-base/xorg-server-1.1.1 (/usr/lib64/xorg/modules)

You will have remerged most of these above, but if the protos were screwed
up, that may not have fixed it, so after remerging them, hopefully
remerging these fixes the problem.

If you are still having issues after that... it's time to consider filing
a bug and seeing if the Gentoo xorg team can help.  I'm sure they have
more experience looking at those files for problems than most of us do. 
(I have a great respect for them.  It must be a big job dealing with all
the various xorg issues for all of Gentoo, even more so than most
distribs, given Gentoo's every user compiles from sources strategy, with
the immense variety in local
environments/compilers/kernels/binutils/glibcs/etc people have.  It's not
a job I'd want, but they actually volunteer for it!  As I said, a very
great respect!)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list