Bug 8790 - radeon driver apparently gets clocks wrong
Summary: radeon driver apparently gets clocks wrong
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.1 (2006.05)
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-27 04:50 UTC by Tom Horsley
Modified: 2008-01-08 16:09 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Here's the minimal xorg.conf file with everything automatically deduced (824 bytes, text/plain)
2006-10-27 14:05 UTC, Tom Horsley
no flags Details
Here's the Xorg.0.log file that xorg.conf file generates. (50.70 KB, text/plain)
2006-10-27 14:10 UTC, Tom Horsley
no flags Details
log from working version of X (49.59 KB, text/plain)
2006-10-28 23:05 UTC, Tom Horsley
no flags Details
log from i686 version of Fedora Core 6 (50.90 KB, text/plain)
2006-10-30 17:07 UTC, Tom Horsley
no flags Details
My working xorg.conf file (1.64 KB, text/plain)
2006-11-14 19:00 UTC, Tom Horsley
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Horsley 2006-10-27 04:50:09 UTC
I've been fighting with the radeon driver in the new Fedora Core 6 release
and the same hardware I had back in bug 7243. The symptoms this time:
In the X log file where the radeon driver is printing all the info about
video modes, it claims the 1920x1080 mode info results in 66.6 Khz vertical
and 59.9 Hz horizontal. Those numbers would be swell if they matched the
signal actually fed to the monitor, unfortunately the monitor tells me
(when it is able to work) that the signal it is getting is 68K vertical
and 61 horizontal.

The symtoms I see are the monitor blanking then unblanking then blanking,
etc. This goes on for a while and it either decides to cutoff completely,
or if I'm lucky, decides to stay on (but if I power off the monitor and come
back later, it will probably start the cutting on and off again).

I notice a Windows box connected to the same monitor, running off the same
DDC info provided to a radeon card produces a signal that the monitor
claims is 66k vertical and 59 horizontal and is rock solid - no flickering
on and off.

All the details of which versions of drivers and X log files and wot-not no
doubt need to be attached to this bug, but I can't do that till I get home
later today.

Just thought I'd go ahead and get this in the system and maybe someone might
recognize the problem.

Also if anyone can tell me how the heck to defeat all the wonderful new
fully self configuring stuff and make it go back to just using the mode line
I provide, that could be helpful as well since I might be able to manually
configure it to work (I don't think any mode I could manually generate could
do any more harm than constant turning on and off that I get now anyway :-).

The mode line reported in the log file is identical to the mode line I
provided manually with the older versions of X in previous fedora releases
(just copied from the info that showed up in the log, but wasn't applied
automagically like it is now), and I may have seen the signal cutout once
every few months, but not constantly like now, so something different is
happening to the numbers in this new driver by the time they generate
an actual signal on the DVI port.
Comment 1 Tom Horsley 2006-10-27 07:13:16 UTC
Perhaps this is all part of the saga recorded in bug 2859. I guess I need
to figure out how to build the source rpms from fedora 6 to try out some
of the patches...

It sure would be nice to have

        Option "UseTheModeLineLuke"

to let me manually plug in different values.
Comment 2 Tom Horsley 2006-10-27 14:05:49 UTC
Created attachment 7557 [details]
Here's the minimal xorg.conf file with everything automatically deduced

Other than the mouse definition I have to add to get draglock
working on my trackball, this xorg.conf is the same as the minimal
one that FC6 generated on install.
Comment 3 Tom Horsley 2006-10-27 14:10:00 UTC
Created attachment 7558 [details]
Here's the Xorg.0.log file that xorg.conf file generates.

The most interesting line in this file is the one that says:

(**) RADEON(0): *Driver mode "1920x1080": 138.5 MHz (scaled from 0.0 MHz), 66.6
kHz, 59.9 Hz

If the signal was actually that frequency, the monitor would have no problems,
but the onscreen display info menu for the monitor says it is getting
a 1920x1080 signal with H. Frequency 68KHz and V. Frequency 61Hz (I may
have gotten those backwards in my previous test :-).
Comment 4 Tom Horsley 2006-10-27 14:13:15 UTC
For what it is worth, here are all the xorg rpms installed on the system (looks
like it is version 7.1):

xorg-x11-fonts-base-7.1-2
xorg-x11-drv-trident-1.2.1-3.fc6
xorg-x11-drv-nv-1.2.0-4.fc6
xorg-x11-server-sdk-1.1.1-47.fc6
xorg-x11-xbitmaps-1.0.1-4.1
xorg-x11-xinit-1.0.2-12.fc6
xorg-x11-drv-mouse-1.1.1-1.1
xorg-x11-drv-microtouch-1.1.0-1.1
xorg-x11-drv-joystick-1.1.0-1.1
xorg-x11-drv-ati-6.6.2-4.fc6
xorg-x11-utils-7.1-2.fc6
xorg-x11-drv-palmax-1.1.0-1.1
xorg-x11-drv-aiptek-1.0.1-2
xorg-x11-drv-vmmouse-12.4.0-2.1
xorg-x11-drv-s3virge-1.9.1-2.1
xorg-x11-xtrans-devel-1.0.1-1.1.fc6
xorg-x11-proto-devel-7.1-9.fc6
xorg-x11-fonts-ISO8859-1-100dpi-7.1-2
xorg-x11-drv-acecad-1.1.0-2.1
xorg-x11-drv-s3-0.4.1-2.1
xorg-x11-xkb-utils-1.0.2-2.1
xorg-x11-drv-evdev-1.1.2-2.1
xorg-x11-drv-ur98-1.1.0-1.1
xorg-x11-fonts-ISO8859-1-75dpi-7.1-2
xorg-x11-drv-siliconmotion-1.4.1-2.1
xorg-x11-drv-summa-1.1.0-1.1
xorg-x11-drv-magellan-1.1.0-1.1
xorg-x11-drv-dummy-0.2.0-2.1
xorg-x11-drv-fbdev-0.3.0-2
xorg-x11-drv-vmware-10.13.0-2.1
xorg-x11-xfs-1.0.2-3.1
xorg-x11-drv-vesa-1.2.1-4
xorg-x11-twm-1.0.1-3.1
xorg-x11-apps-7.1-3.fc6
xorg-x11-fonts-truetype-7.1-2
xorg-x11-drv-penmount-1.1.0-2.1
xorg-x11-drv-digitaledge-1.1.0-1.1
xorg-x11-drv-vga-4.1.0-2.1
xorg-x11-drv-i810-1.6.5-9.fc6
xorg-x11-xtrans-devel-1.0.1-1.1.fc6
xorg-x11-server-utils-7.1-4.fc6
xorg-x11-server-Xorg-1.1.1-47.fc6
xorg-x11-fonts-75dpi-7.1-2
xorg-x11-drv-spaceorb-1.1.0-1.1
xorg-x11-drv-elographics-1.1.0-1.1
xorg-x11-drv-mutouch-1.1.0-2
xorg-x11-drv-voodoo-1.1.0-3.1
xorg-x11-drv-citron-2.2.0-1.1
xorg-x11-server-Xvfb-1.1.1-47.fc6
xorg-x11-xauth-1.0.1-2.1
xorg-x11-font-utils-7.1-2
xorg-x11-drv-void-1.1.0-3.1
xorg-x11-drv-dynapro-1.1.0-2
xorg-x11-xdm-1.0.5-5.fc6
xorg-x11-fonts-misc-7.1-2
xorg-x11-drv-sis-0.9.1-7
xorg-x11-drv-ast-0.81.0-3
xorg-x11-drv-tdfx-1.2.1-3.1
xorg-x11-drv-calcomp-1.1.0-1.1
xorg-x11-drv-elo2300-1.1.0-1.1
xorg-x11-util-macros-1.0.2-4.fc6
xorg-x11-xsm-1.0.2-4.fc6
xorg-x11-drv-dmc-1.1.0-2
xorg-x11-fonts-Type1-7.1-2
xorg-x11-drv-via-0.2.1-7
xorg-x11-drv-jamstudio-1.1.0-1.1
xorg-x11-drivers-7.1-3
xorg-x11-drv-mga-1.4.2-1.fc6
xorg-x11-fonts-100dpi-7.1-2
xorg-x11-drv-cirrus-1.1.0-2.fc6
xorg-x11-drv-hyperpen-1.1.0-2
xorg-x11-resutils-7.1-2.fc6
xorg-x11-xfs-utils-1.0.2-3.1
xorg-x11-drv-sisusb-0.8.1-4.1
xorg-x11-drv-magictouch-1.0.0.5-2.1
xorg-x11-docs-1.2-4.fc6
xorg-x11-filesystem-7.1-2.fc6
xorg-x11-drv-keyboard-1.1.0-2.1
xorg-x11-drv-fpit-1.1.0-1.1
xorg-x11-drv-savage-2.1.1-5.fc6
xorg-x11-server-Xnest-1.1.1-47.fc6
Comment 5 Tom Horsley 2006-10-28 23:05:31 UTC
Created attachment 7566 [details]
log from working version of X

This gets weirder and weirder. I have now installed SUSE 10.1 to compare the X
behavior with Fedora Core 6 (suse has X11 version 6.9.0). The monitor reports
the same 68K and 61Hz frequencies under SUSE as it does under Fedora, yet
for some reason (this is with all the same hardware), the display seems
rock solid under SUSE, so I'm including the SUSE log file in the hope that
someone will see something different that explains the behavior under FC6.
I do have to specify the modeline manually with SUSE, but I'm giving it
the same info from what the monitor claims it wants.
Comment 6 Tom Horsley 2006-10-30 05:10:40 UTC
I've now tried Windows XP and reinstalled FC5 on this box and noticed that
Windows does have an occasional flicker on and off problem even though the
monitor reports it running at the 66KHz, 59Hz that X claims to be trying
for (but actually exceeds). The problem is not excessive on Windows, and
often doesn't appear at all.

On FC5 I haven't yet seen a flicker (though I did occasionally encounter
one when I previously had FC5 installed). The monitor reports the same
68KHz, 61Hz numbers for FC5 that both suse and FC6 report. I really have
no idea why FC6 is so unusably unstable and everyone else either has no
problem at all, or only an occasional flicker, but since these are all on
the exact same hardware, there is clearly something the FC6 software is
doing that makes it lots worse.

I'm now contemplating an intense code review comparing the 7.0 and 7.1
radeon drivers :-).
Comment 7 Tom Horsley 2006-10-30 17:07:41 UTC
Created attachment 7604 [details]
log from i686 version of Fedora Core 6

Yikes! This is starting to seem like it might be a x86_64 compiler problem
or a 64 bit code problem in the 7.1 radeon driver. I have now installed
the i686 version of Fedora Core 6, and I haven't yet noticed a single
flickering on/off of the display when running i686. (Or perhaps I've just
been lucky so far tonight :-).
Comment 8 Tom Horsley 2006-10-30 17:24:02 UTC
Since this is potentially something like a x86_64 compiler or build problem,
I have also added a fedora bug:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213170
Comment 9 Tom Horsley 2006-10-31 06:15:34 UTC
Since adding the i686 version, I have observed one incident of flickering,
but it stabalized with the picture on fairly quickly, so the problem isn't
entirely gone on i686, but so far, still seems better than x86_64 with
same source base.

I don't supposed there is some kernel tracing code I can activate somehow
to record the actual transactions with the radeon card registers to compare
FC5 to FC6?
Comment 10 Tom Horsley 2006-11-05 13:43:34 UTC
I've now had a chance to use the FC6 i686 installation for a more extended
period of time, and I begin to suspect that the i686 has as big a problem
with flickering on and off as the x86_64, so the initial apparent improvement
may just have been random chance.
Comment 11 Tom Horsley 2006-11-08 17:01:31 UTC
I have noticed that the flickering could be triggered almost all the time
by running an opengl app (previewing 3d screensavers, running neverputt, etc),
so I thought maybe 3d had something to do with the problem. I finally contrived
a Modules section in xorg.conf that left out glx and dri, but when I let
dpms turn off the monitor, the flickering was back when I tried to turn it
back on.

Just continuting to gather data.

I'd like to run with my own modeline, but that seems to be impossible.
Even when I tried the PanelSize option of the radeon driver, the fedora
server manufactured its own modeline instead of using mine (and the one
it manufactured didn't have reduced blanking, so it was wayyy out of range
for the monitor).
Comment 12 Tom Horsley 2006-11-11 18:58:34 UTC
More news: I installed the (livna) fglrx driver on FC6 i686 and after
fighting with it for a while (had to manually run ldconfig to get the
ati version of mesa at the front of the search list), I get three things
for the first time: 1. Good 3d performance, 2. No screen flickering,
3. It is willing to take my hand crafted modeline (to run at a slightly
lower than 60HZ refresh rate).

All the things that trigger flickering with the radeon driver (letting
dpms power saver kick in, running 3d apps) have (so far - knock on wood)
not triggered any screen flickering.

I also noted that even before I installed my modeline, the refresh rate
my monitor was reporting was lower than the rate the radeon driver
runs the monitor at (presumably using the same EDID info, but apparently
not coming to the same conclusions). The fglrx driver was reporting
59HZ instead of 61HZ.
Comment 13 Tom Horsley 2006-11-14 19:00:03 UTC
Created attachment 7792 [details]
My working xorg.conf file

Pant, pant, wheeze....

At long last, I uncovered the key to forcing the smartass radeon driver
to use my modeline to run with reduced blanking at 58 HZ. I am using it
now, and so far, I have been able to induce some minor flickering by doing
things like running a fullscreen preview of the "Lattice" screensaver. but
mostly the display remain fairly stable (and the flickering stops when I
turn off the preview). Neverputt or glxgears don't seem to trigger the
flickering, and turning off the screen via dpms doesn't wind up with flickering

either.

The only way to force it to use my mode line?

Adding a module section with all the modules mentioned in the X log file
is the first step. That allows me to turn the "ddc" Load entry into a
subsection where I can specify the options to make it stop inventing
its own mode info.

Then I have to make sure I provide HorizSync and VertRefresh info in the
monitor section so as to convince X my modeline isn't out of range.

Then I have to add the ReducedBlanking monitor option to make X stop
protecting me from myself.

Then it finally uses my mode line.

Where did I get my modeline? The "cvt.c" program in the X server source rpm
has an option to generate a reduced blanking mode, but it is also a know-it-all

butt-head smartass and refuses to do reduced blanking for anything other than
60HZ, so I had to smack it around some and rebuild it so all it does is
print a warning, but is still willing to spit out the modeline.

The source code is the only way to deduce this stuff.

My monitor now claims to be running at Horiz 64KHz, Vert 58Hz.

Possibly, I can finally use Fedora Core 6 without switching to
an nvidia card (and running into as many problems with it as I
have had with ati :-).
Comment 14 Tom Horsley 2006-11-16 15:29:13 UTC
For the full story of my adventures in getting X to do my bidding,
see: http://home.att.net/~Tom.Horsley/easy-linux.html
where I document the whole sequence of events (and rant a bit :-).

One of the rants is probably a useful suggestion (perhaps even
planned already for next release?): Now that X contains the
source for the "cvt" program, why not provide a new way to specify
ModeLine data (the way everyone always wanted it to work :-),
a section where you can tell it width and height, refresh rate,
and the reduced blanking flag, and it just computes the mode line
data for you.
Comment 15 Daniel Stone 2007-02-27 01:34:13 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 16 Tom Horsley 2007-04-28 16:32:49 UTC
Here's an interesting data point: I just installed fedora core 7 test 4 on
the machine I've had all these screen blanking problems with, and so far,
while running fc7, the screen blanking has not appeared (of course, it may
just be waiting to get my hopes up before it crushes them :-).

fc7 comes with xorg 7.1 (I think) and the ati driver rpm is labeled
xorg-x11-drv-ati-6.6.3-2.fc7.
Comment 17 Tom Horsley 2007-05-05 10:29:55 UTC
Nope, fc7t4 does not work better after all. Used it extensively for most of
the day and the screen flickering did manifest again, so it was just trying
to jack up my hopes to watch them fall from a higher place :-).
Comment 18 Alex Deucher 2007-08-31 07:54:46 UTC
Can you try with the latest driver from ati git or release 6.7.192 or newer?  I think this should be resolved.
Comment 19 Alex Deucher 2008-01-08 16:09:56 UTC
closing


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.