Bug 3242

Created attachment 2633 [details]
output of 'lspci -v' for the radeon xpress 200 device

Created attachment 2634 [details]
Xorg logfile with Radeon Xpress 200

turn off colortiling.  it's probably not set up correctly for the xpress chips
yet.  It should probably be disabled by default for the xpress chips.  Add this
line:
Option "ColorTiling" "false"
to your device config.

(In reply to comment #3)
> turn off colortiling.  it's probably not set up correctly for the xpress chips
> yet.  It should probably be disabled by default for the xpress chips.  Add this
> line:
> Option "ColorTiling" "false"
> to your device config.

Yes, this works - sort of. It gives me a normal display, but it freezes the
machine completely (ie no activity, no response from ssh shell, does not answer
ping) as soon as there is activity on the X display.
How to repeat: run 'startx' (default w/ 3 shells), try 'xvinfo' or another
command in a shell window. Result: it gives me a screenfull of info, then the
machine is dead. If I do nothing in X, the machine does not die.

Created attachment 2642 [details]
Xorg logfile with radeon driver and 'Option "ColorTiling" "false"'

comment out the load dri line in your modules section.

(In reply to comment #6)
> comment out the load dri line in your modules section.

Done, it doesn't make a difference. But I have noticed that if I just use a
command like 'echo "some text"' my machine doesn't die, it dies only when I use
the 'xvinfo' or 'xdpyinfo' commands (I haven't tested other X commands yet).

Also, the vesa driver detects the capabilities of my monitor through ddc without
fail, but the radeon driver does not (see attachments after this comment).

Created attachment 2647 [details]
Xorg log file with vesa driver

This is the Xorg log file when using the vesa driver, and a xorg.conf file
which autodetects all the rest. Notice that ddc detection of the monitor is
working (and correct).

Created attachment 2648 [details]
Xorg log file with the radeon driver, and specified HorizSync and VertRefresh

This is a xorg log file when using the radeon driver, and this Monitor section
in xorg.conf:
Section "Monitor"
	Identifier   "Monitor0"
	VendorName   "Monitor Vendor"
	ModelName    "Monitor Model"
	HorizSync	32-91
	VertRefresh	58-85
EndSection

The vesa driver uses vbe to determine the DDC information.  The radeon driver
queries it directly.  There is no formal support for the xpress200 chips; right
now they are treated like RS300 chips.  They may require some special handling.
 Perhaps Michel or Hui has some insight.

I have the same system using Fedora3 with recent Xorg from CVS and I see the
same behaviour.

Vesa driver is running fine in 1280x1024.

Thanks a lot.

(In reply to comment #11)
> Vesa driver is running fine in 1280x1024.

Interesting. I just found out that if I run the vesa driver in 1280x1024, I have
broken text (blurred / garbled for lack of a better word - it is like it has
horizontal white stripes through each line of text), but if I run vesa in
1024x768, the text is ok.

I have exactly the same motherboard running X 6.8.99.15 on gentoo 2005.0/AMD64.
 I installed the ati drivers as well as the open source ones.  Here are the
results of my testing

a) "ati" - X comes up but any attempt to move a window makes it freeze and the
window itself breaks up. Didn't try any further to see if the system would
freeze too.
b) "radeon" - Same as "ati"
c) "vesa" - Appears to work but completely freezes the computer intermittently
when switching from X to text terminal for example (e.g ctrl-alt-F1. All that is
left is a message from the monitor saying "mode not supported" (Syncmaster 171s).

Any help much appreciated.

Attachments to follow.

Raphael

Created attachment 3237 [details]
xorg.conf

Created attachment 3238 [details]
xorg log

Created attachment 3239 [details]
dmesg

Created attachment 3240 [details]
lspci

Created attachment 3241 [details]
faulty document

Has anyone tried the patch at 
http://www.c.csce.kyushu-u.ac.jp/~kenta/index.php?plugin=attach&refer=Linux%20on%20RS480&openfile=XOrg-6.8.2-XPRESS200.patch

at the Japanese web site 

http://www.c.csce.kyushu-u.ac.jp/~kenta/index.php?Linux%20on%20RS480

?


It appears not to be in 6.8.99.15 yet but I may be mistaken.
Raphael

(In reply to comment #19)
> Has anyone tried the patch at 
>
http://www.c.csce.kyushu-u.ac.jp/~kenta/index.php?plugin=attach&refer=Linux%20on%20RS480&openfile=XOrg-6.8.2-XPRESS200.patch
> 
> at the Japanese web site 
> 
> http://www.c.csce.kyushu-u.ac.jp/~kenta/index.php?Linux%20on%20RS480
> 
> ?
> 
> 
> It appears not to be in 6.8.99.15 yet but I may be mistaken.
> Raphael


The above patch just adds the PCI id.  That id has been in xorg cvs for 4 months
now:
http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_chipset.h?rev=1.4&view=markup

Created attachment 3254 [details] [review]
HEAD patch 2/2: Add missing locking to _cairo_scaled_glyph_lookup

I forgot to give the result of using fglrx.  X won't even start finishing with
the error

(EE) No devices detected.

Fatal server error:
no screens found

The fglrx problem is solved. Two things are needed

One is that you can't use the latest ati-drivers for xpress 200. You have to use
8.13.4 NOT 8.14.13-r2 (at least under gentoo).

Secondly it won't work unless you use X 6.8.2. 6.8.99.15 is NOT supported.

fglrx works great now. Just vesa and radeon that are flaky/broken.

Raphael

You might try adding 
chipid  0x5B60
to your device section using the radeon driver.  It could be that the xpress200s
are more like rv370s than rs300s.  I just guessed when I added the pci ids.  ati
hasn't released any documentation on the xpress chipsets.

(In reply to comment #23)
> You might try adding 
> chipid  0x5B60
> to your device section using the radeon driver.


Did this work?

I have a motherboard with ATI Radeon XPress200 chipset RC410 (chip id 5a61). 
Is there a way now for making xorg running with radeon driver ?
It work's with VESA generic driver but i'm not able to play correctly videos 
with Mplayer.

Can you try the ati-1-0-branch driver ?

I'm on Freebsd, How can i do that ?

You check out that current branch from the cvs. 

jmd, are you still experiencing this issue using a current version of xorg and
the ati driver?

(In reply to comment #29)
> jmd, are you still experiencing this issue using a current version of xorg and
> the ati driver?

FWIW, I still need the 'ChipID 0x5b60' in the Device Section on my xorg.conf.
If that line is removed, no devices are detected.
This is with
FreeBSD 6.1-stable from May 10th, 2006
Xorg 6.9.0

(In reply to comment #30)
> FWIW, I still need the 'ChipID 0x5b60' in the Device Section on my xorg.conf.
> If that line is removed, no devices are detected.
> This is with
> FreeBSD 6.1-stable from May 10th, 2006
> Xorg 6.9.0
If your (5954) id is not detected with xorg 6.9/7.0 that would probably be
because you're using the ati wrapper, as that id has been added to the radeon
driver (but forgotten to be added to the wrapper) before xorg 6.9/7.0 release.
Try using radeon as driver directly instead of that deprecated mess. In any
case, it ought to be fixed with xorg 7.1.
Some feedback on tiling would be nice, while it's disabled by default and
doesn't make much sense if dri is not enabled (because it doesn't work) anyway
I'm actually not sure anyone has tested it on rs400 igps.

(In reply to comment #31)
> If your (5954) id is not detected with xorg 6.9/7.0 that would probably be
> because you're using the ati wrapper, as that id has been added to the radeon
> driver (but forgotten to be added to the wrapper) before xorg 6.9/7.0 release.
> Try using radeon as driver directly instead of that deprecated mess.

I am using the radeon driver.

> In any case, it ought to be fixed with xorg 7.1.

xorg 7.1 isn't in the FreeBSD ports tree yet. :-/

Marking broken (status null/blank) bugs in xorg with no activity in a long time as fixed. Please reopen if you think it's necessary, but first do a search if a similar bug report is already filed and in a NEW/ASSIGNED state. These bugs do not currently show in most search results as they do not have any status.

Sorry for this janitorial spam, you know where to send hate mails to when your inbox gets full of bugs you're subscribed to.