Bug 6796 - "ati" wrapper detection failures: PCI-E X800 (and X300, X600, X700...) card work only using Driver "radeon"
Summary: "ati" wrapper detection failures: PCI-E X800 (and X300, X600, X700...) card w...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.0.0
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Xorg Project Team
QA Contact:
URL:
Whiteboard:
Keywords:
: 7959 8778 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-04-30 20:43 UTC by Timo Jyrinki
Modified: 2007-01-12 06:24 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
lspci (1.88 KB, text/plain)
2006-04-30 20:44 UTC, Timo Jyrinki
no flags Details
lspci -n (773 bytes, text/plain)
2006-04-30 20:45 UTC, Timo Jyrinki
no flags Details
xvinfo (4.85 KB, text/plain)
2006-04-30 20:45 UTC, Timo Jyrinki
no flags Details
Xorg.0.log-ati (21.94 KB, text/plain)
2006-04-30 20:46 UTC, Timo Jyrinki
no flags Details
Xorg.0.log radeon (154.90 KB, text/plain)
2006-04-30 20:46 UTC, Timo Jyrinki
no flags Details
xorg.conf (4.19 KB, text/plain)
2006-04-30 20:47 UTC, Timo Jyrinki
no flags Details
example patch (1.71 KB, patch)
2006-05-07 21:37 UTC, Timo Jyrinki
no flags Details | Splinter Review
Xorg.0.log-usingpatch (144.43 KB, text/plain)
2006-05-07 21:39 UTC, Timo Jyrinki
no flags Details
radeon-detect.patch (1.69 KB, patch)
2007-01-02 00:28 UTC, Timo Jyrinki
no flags Details | Splinter Review

Description Timo Jyrinki 2006-04-30 20:43:54 UTC
Running Ubuntu dapper, with the latest CVS version of
http://webcvs.freedesktop.org/xorg/driver/xf86-video-ati/ installed. The PCI ID
of my graphics card is (1002:)5d4f, which should be supported. The
manufacturer/model is Sapphire's X800 GTO Ultimate 256MB. The motherboard is a
RS482-based ATI board.

With "ati" driver (default after ubuntu's gfx detection), X doesn't start at
all. With "radeon" specified, X starts but only with 640x480 resolution whatever
I do.

This bug's aim would probably to have at least 2D working at higher resolutions,
and also have "ati" driver working correctly, ie. delegating the handling of gfx
to "radeon" driver. I can also get some debug output about eg. some variables at
some point in the driver code, if someone would like to know something more
specific. I've only casually looked at the driver code (and X is quite unknown
to me in other ways too), so I would need some specific points to study to
continue myself.

uname -a: Linux test-desktop 2.6.15-21-amd64-generic #1 SMP PREEMPT Fri Apr 21
16:42:20 UTC 2006 x86_64 GNU/Linux

lsmod:
Module                  Size  Used by
rfcomm                 45600  0
l2cap                  30464  5 rfcomm
bluetooth              59268  4 rfcomm,l2cap
radeon                116768  0
drm                    95656  1 radeon
powernow_k8            12992  1
cpufreq_powersave       3328  0
cpufreq_stats           8264  0
cpufreq_userspace       9184  1
cpufreq_ondemand        9768  0
cpufreq_conservative    10984  0
freq_table              6464  2 powernow_k8,cpufreq_stats
tc1100_wmi              9096  0
video                  18824  0
acpi_sbs               24600  0
battery                12296  1 acpi_sbs
i2c_acpi_ec             7040  1 acpi_sbs
container               6272  0
button                  8864  0
pcc_acpi               16128  0
sony_acpi               7060  0
ac                      7176  1 acpi_sbs
dev_acpi               15364  0
hotkey                 13768  0
ext3                  145936  1
jbd                    70952  1 ext3
ipv6                  300416  8
dm_mod                 63176  1
md_mod                 76792  0
af_packet              28172  2
tuner                  46244  0
tvaudio                28316  0
msp3400                36300  0
bttv                  201296  0
video_buf              27012  1 bttv
i2c_algo_bit           11144  1 bttv
v4l2_common             9088  1 bttv
btcx_risc               6792  1 bttv
tveeprom               19344  1 bttv
i2c_core               26624  7
i2c_acpi_ec,tuner,tvaudio,msp3400,bttv,i2c_algo_bit,tveeprom
tsdev                  10240  0
videodev               13696  1 bttv
snd_hda_intel          21664  0
8139too                31744  0
8139cp                 26880  0
snd_hda_codec         170952  1 snd_hda_intel
floppy                 74120  0
mii                     7680  2 8139too,8139cp
snd_pcm_oss            59424  0
snd_mixer_oss          20608  1 snd_pcm_oss
ohci1394               37452  0
ieee1394              369688  1 ohci1394
snd_pcm               104712  3 snd_hda_intel,snd_hda_codec,snd_pcm_oss
snd_timer              29064  1 snd_pcm
snd                    68576  6
snd_hda_intel,snd_hda_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore              13216  1 snd
snd_page_alloc         13968  2 snd_hda_intel,snd_pcm
rtc                    16760  0
pcspkr                  3592  0
psmouse                40452  0
serio_raw               9732  0
shpchp                 51360  0
pci_hotplug            33168  1 shpchp
sg                     43568  0
sr_mod                 19748  0
cdrom                  41144  1 sr_mod
evdev                  14464  1
reiserfs              257904  3
ide_generic             2816  0
ehci_hcd               34568  0
ohci_hcd               23684  0
usbcore               145980  3 ehci_hcd,ohci_hcd
atiixp                  8464  1
sd_mod                 21504  6
sata_sil               12292  10
libata                 82328  1 sata_sil
scsi_mod              160248  4 sg,sr_mod,sd_mod,libata
generic                 7300  0
thermal                16524  0
processor              29224  2 powernow_k8,thermal
fan                     6408  0
capability              7176  0
commoncap               9728  1 capability
vga16fb                14864  1
cfbcopyarea             5120  1 vga16fb
vgastate               10368  1 vga16fb
cfbimgblt               4224  1 vga16fb
cfbfillrect             5760  1 vga16fb
fbcon                  43136  72
tileblit                4096  1 fbcon
font                    9984  1 fbcon
bitblit                 7424  1 fbcon
softcursor              3712  1 bitblit
Comment 1 Timo Jyrinki 2006-04-30 20:44:38 UTC
Created attachment 5527 [details]
lspci
Comment 2 Timo Jyrinki 2006-04-30 20:45:01 UTC
Created attachment 5528 [details]
lspci -n
Comment 3 Timo Jyrinki 2006-04-30 20:45:19 UTC
Created attachment 5529 [details]
xvinfo
Comment 4 Timo Jyrinki 2006-04-30 20:46:01 UTC
Created attachment 5530 [details]
Xorg.0.log-ati

Xorg.0.log using the default "ati" driver (ie. X doesn't start).
Comment 5 Timo Jyrinki 2006-04-30 20:46:37 UTC
Created attachment 5531 [details]
Xorg.0.log radeon

Xorg.0.log using "radeon" (ie. X starts but only in 640x480 mode)
Comment 6 Timo Jyrinki 2006-04-30 20:47:20 UTC
Created attachment 5532 [details]
xorg.conf
Comment 7 Timo Jyrinki 2006-04-30 20:48:32 UTC
Forgot to mention that I also tried ati-1-0-branch, even though I didn't yet
find information what's different in that. Same results ("ati" does not work /
"radeon" gives 640x480).
Comment 8 Michel Dänzer 2006-04-30 21:05:49 UTC
Unless you really have two monitors connected, the 640x480 limit is probably due
to bug 5623.

As for the ati wrapper failing, that's probably the PCI ID missing in one of the
lists.
Comment 9 Timo Jyrinki 2006-04-30 21:40:59 UTC
I have an LCD monitor and TV connected. Disconnecting TV-out and rebooting
doesn't change a thing. However, Option "MonitorLayout" "TMDS,NONE" seems to fix
this problem as pointed out in bug 5623, but of course the detection should
succeed automatically. Now running successfully at 1280x1024.

About the ati-wrapper problem: I can't find a place in code where 5D4F wouldn't
be mentioned where other X800-series cards are, so it might be it's not just a
missing PCI ID. I checked atipciids.h, radeon_chipset.h, radeon_driver.c and
radeon_probe.c. It probably does not matter that this is not really a "X850 Pro"
card but one of these rebranded X800 GTO cards.
Comment 10 Roland Scheidegger 2006-05-07 08:27:20 UTC
(In reply to comment #9)
> About the ati-wrapper problem: I can't find a place in code where 5D4F wouldn't
> be mentioned where other X800-series cards are, so it might be it's not just a
> missing PCI ID. I checked atipciids.h, radeon_chipset.h, radeon_driver.c and
> radeon_probe.c. It probably does not matter that this is not really a "X850 Pro"
> card but one of these rebranded X800 GTO cards.
Yes, that shouldn't matter at all. I think something might go wrong in the
ATIProbe function. Can't see what though at first glance, you could add some
printfs to that function-from-hell to see what's going on - I think ultimately
it should just end up calling that RadeonProbe function in the end, however I
can't even tell if it's expected that you get a warning that the device could
(naturally) not be attached as a mach64. The ati wrapper is kinda deprecated
though and may be removed in the future, I don't think anyone is really
interested in it and working on it. I certainly get a headache from looking at it.
Comment 11 Timo Jyrinki 2006-05-07 21:37:11 UTC
Created attachment 5567 [details] [review]
example patch

A nice function, that is. Anyway, the attached example patch let's the radeon
driver do it job for me.

In the first part, if it's looking for Mach64's, is that kind of using of
ATIChipID a completely wrong thing to do? Without it, the code dwells into that
part of the code and yields "PCI Mach64 (...) could not be detected".

The second part is of course just a hack, but combined with the previous part:
is that pVideo->size[1] supposed to be some completely trustworthy thing to say
if a chip is a Mach64 (if FALSE) or something else (if TRUE)? Because in first
part it's false with my card, the code dwells into Mach64 code, and in the
second part the whole "look for block I/O devices"-code is skipped because of
!pVideo->size[1]?

I first used only the first part of the patch, and noticed that then it skipped
Mach64 code but also skipped block I/O devices code and found nothing.
Comment 12 Timo Jyrinki 2006-05-07 21:39:38 UTC
Created attachment 5568 [details]
Xorg.0.log-usingpatch

Xorg.0.log created with startx when using the patched version of the driver.
Comment 13 Brian Beardall 2006-05-16 08:11:40 UTC
This is a description of two bugs. This bug needs to be split into two bugs. 
1. The first bug that is covered is that the Sapphire Radeon X800 GTO is not
detected using the "ati" wrapper. 
2. The second bug is that the driver won't change the resolution to anything
higher than 640x480 using the dvi output. Modelines work correctly when using
the vga output, in other words I have 1600x1200 using the vga output.

Pertaining to the first bug, I checked the radeon atipciids.h, and the pci id is
listed. For some reason the "ati" wrapper wants to detect the card as a mach64.
I saw the message detecting an X300SE on the second pci bus address as a mach64
also.
Comment 14 Michel Dänzer 2006-05-16 15:25:41 UTC
(In reply to comment #13)
> 2. The second bug is that the driver won't change the resolution to anything
> higher than 640x480 using the dvi output. Modelines work correctly when using
> the vga output, in other words I have 1600x1200 using the vga output.

As pointed out before, this is probably bug 5623.

> For some reason the "ati" wrapper wants to detect the card as a mach64.

I think that's just the ati wrapper's way of saying 'I have no idea what this
is; I tried treating it as a Mach64 eventually, but it didn't work'.
Comment 15 Timo Jyrinki 2006-05-16 16:46:04 UTC
(In reply to comment #14)
> I think that's just the ati wrapper's way of saying 'I have no idea what this
> is; I tried treating it as a Mach64 eventually, but it didn't work'.

Well, I (think I) found that it's not like that. It looks like it is actually
detected as Mach64, and it's never even tried to be found out whether it's
Radeon or not (as Mach64 detection comes before Radeon). If you check the
portion of the patch in the code, it looks like the ati wrapper thinks a card is
a Mach64 if:
1. Chip is not MACH32 (but still made by ATI)
2. pVideo->size[1] == FALSE
(if the chip is MACH32 or the 2. is TRUE, it continues to Radeon model detection)

Please correct if I'm wrong, but that's how it currently looks to me (though I
might very easily miss something the function is doing). And similarly, if a
Mach64 is not found, a Radeon is "detected" by checking that the chip is still
not MACH32, and that pVideo->size[1] == TRUE.

Assuming ATIChipID can't be trusted wholely (as it only knows chips listed in
atipciids.h), would it be okay to use it if the chip id is actually found as
listed? Then the first part of the patch could be applied with additional
chip-id-was-found-in-the-pci-id-list check so that the Mach64 would be skipped
at least for the known/listed newer Radeons. And maybe in the latter part
similar check could also be made so that the Radeon code is enabled for the
known cards at least. 

This bug might be affecting all "PCI-E Xxxx series cards", or does someone how a
working X300/X600/X700/X800 PCI-E card?
Comment 16 Timo Jyrinki 2006-11-01 12:51:01 UTC
*** Bug 7959 has been marked as a duplicate of this bug. ***
Comment 17 Timo Jyrinki 2006-11-01 12:55:38 UTC
*** Bug 8778 has been marked as a duplicate of this bug. ***
Comment 18 Timo Jyrinki 2006-11-01 13:01:32 UTC
(removing the "only 640x480" from the summary because it's a different issue
that has its own bug)
Comment 19 Timo Jyrinki 2006-11-02 23:56:01 UTC
Considering Ubuntu has 16 duplicates for this problem
(https://launchpad.net/distros/ubuntu/+source/xserver-xorg-video-ati/+bug/28925),
I'd propose changing the severity to major, though I'm not sure how severity
levels are defined here. For out-of-the-box experience or for anyone new to free
OSs / X.org, this is a big problem.
Comment 20 Timo Jyrinki 2007-01-02 00:28:13 UTC
Created attachment 8275 [details] [review]
radeon-detect.patch

Added something "proper" to the second problematic place in the code, plus
comments. Applies to latest git. What do you think, any sense in that or does
it expose to some problems? 

The root problem still probably is why none of us, who have problematic (PCI-E,
apparently) X600/X700/X800 cards, have pVideo->size[1] set. Though I don't even
know if it has to be set, as everything works properly anyway using this patch
or the driver "radeon" in xorg.conf.
Comment 21 Dave Airlie 2007-01-12 04:09:11 UTC
Okay I've committed this please close the bug if it fixes the problem..
Comment 22 Timo Jyrinki 2007-01-12 06:24:50 UTC
Thanks a lot for applying the patch. It works for me now with the latest GIT and
Driver "ati", and hopefully it works for all the others as well.

(now if only I'd be able to fix bug 5991 and/or bug 5623 to give >640x480
resolution without specifying MonitorLayout... :)


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.