Created attachment 28898 [details]
Xorg log file

You monitor does not provide an edid, so the xserver selects an mode based on the sync ranges and modelines you provided.  If it does not select a mode you like, you can change it at run time using xrandr:
xrandr --output VGA-0 --mode <mode name>
Run xrandr by itself to see what modes are available.
Alternatively, you can force the preferred mode by adding a PreferredMode option to the monitor section of your config:
Option "PreferredMode" "1400x1050_85"
See this page for more info:
http://wiki.debian.org/XStrikeForce/HowToRandR12

Hi,
I've done as you suggested and put the Preferred Mode option into my config file - hasn't made any difference - The server/driver/xrandr *thinks* the screen is being driven at 85Hz - but it's still 82Hz.

There *has* to be something broken somewhere - I've been using this PC with Linux for about nine months and have only been getting headaches in the last two.  And I haven't been changing the config file at all until I got the headaches.

The Modeline is exactly the same as on a Mandriva 2007 partition which drives exactly the same monitor at 85Hz.

xrandr output (plain and verbose) to follow.
Also screen photographic proof to follow.

Regards,
Mark.

Created attachment 29106 [details]
XRandR output

Created attachment 29107 [details]
Verbose XRandR output

Created attachment 29108 [details]
Optical proof of Monitors OSD not matching server/xrandr/driver

Comment on attachment 29108 [details]
Optical proof of Monitors OSD not matching server/xrandr/driver

Sorry for the bad quality, but you should be able to see xrandr in the background being run in a terminal showing 1400x1050_85 as the current and preferred mode.

(In reply to comment #3)
> Hi,
> I've done as you suggested and put the Preferred Mode option into my config
> file - hasn't made any difference - The server/driver/xrandr *thinks* the
> screen is being driven at 85Hz - but it's still 82Hz.
> 
> There *has* to be something broken somewhere - I've been using this PC with
> Linux for about nine months and have only been getting headaches in the last
> two.  And I haven't been changing the config file at all until I got the
> headaches.
> 
> The Modeline is exactly the same as on a Mandriva 2007 partition which drives
> exactly the same monitor at 85Hz.

Are you sure the Mandriva partition is using the exact same modeline?  Slight differences in timings may affect perceived clock.  You might try adjusting the modeline.  here are some example using cvt:
# 1400x1050 84.96 Hz (CVT 1.47M3) hsync: 93.88 kHz; pclk: 179.50 MHz
Modeline "1400x1050_85.00"  179.50  1400 1512 1656 1912  1050 1053 1057 1105 -hsync +vsync
# 1400x1050 85.08 Hz (CVT) hsync: 94.01 kHz; pclk: 179.75 MHz
Modeline "1400x1050_85.20"  179.75  1400 1512 1656 1912  1050 1053 1057 1105 -hsync +vsync

Hi,
Quick response!...and thanks for the help.
Both distro's Modelines are exactly the same.

Please excuse me for being dense, but what do you mean by perceived clock?

I've tried the modeline that cvt (and your comment) suggests for 1400x1050 @85 and that doesn't appear to have made any difference either.

Shouldn't the timings from gtf be used anyway though?  CVT didn't exist until 2003 (or so googling tells me) and my monitor was made in 1999 so wouldn't the two be incompatible?

I'll try upping the timings (maybe using gtf in the first instance?) gradually to see if I can get 85Hz out - but how far can I safely go before I'm at risk of frying my monitor's circuitry? ;-)

Regards,
Mark.

(In reply to comment #9)
> Hi,
> Quick response!...and thanks for the help.
> Both distro's Modelines are exactly the same.
> 
> Please excuse me for being dense, but what do you mean by perceived clock?

my monitors often report a slightly different refresh than the mode would indicate.  So for example the modeline would indicate a 75 Hz mode, but my monitor would claim it's actually 74 Hz or 76 Hz, etc.

> 
> I've tried the modeline that cvt (and your comment) suggests for 1400x1050 @85
> and that doesn't appear to have made any difference either.
> 
> Shouldn't the timings from gtf be used anyway though?  CVT didn't exist until
> 2003 (or so googling tells me) and my monitor was made in 1999 so wouldn't the
> two be incompatible?

Either should work.  The only thing that may be a problem is reduced blanking modes.

> 
> I'll try upping the timings (maybe using gtf in the first instance?) gradually
> to see if I can get 85Hz out - but how far can I safely go before I'm at risk
> of frying my monitor's circuitry? ;-)

You can use gtf and adjust the timings as well.

It could likely be the pixel clock.  Some monitors are very picky about the set of dividers used, even though the end result is the same exact clock.  Using the pll dividers you can come up with multiple combinations that all get you the exact same clock, but some monitors prefer some divider combinations to others.

(In reply to comment #10)
> my monitors often report a slightly different refresh than the mode would
> indicate.  So for example the modeline would indicate a 75 Hz mode, but my
> monitor would claim it's actually 74 Hz or 76 Hz, etc.

Because of rounding in the OSD?...but a difference of 3 can't be due to rounding alone.

> Either should work.  The only thing that may be a problem is reduced blanking
> modes.
> You can use gtf and adjust the timings as well.

OK, I'll try with gtf tomorrow.

> 
> It could likely be the pixel clock.  Some monitors are very picky about the set
...

How does any of that (some of which I'll have to google to understand fully) account for different behaviour with exactly the same modeline with exactly the same hardware?  Surely the same line should produce the same timing?

(In reply to comment #11)
> 
> How does any of that (some of which I'll have to google to understand fully)
> account for different behaviour with exactly the same modeline with exactly the
> same hardware?  Surely the same line should produce the same timing?
> 

Changes to the pll divider selection algorithm could account for the change.  Basically you have a reference clock on the board (say 27 Mhz) and the driver uses a set of dividers to derive the requested pixel clock.  Sometimes there are multiple sets of dividers that match the requested frequency.  Other times there is not an exact match and the driver has to get as close as possible.  These variances can affect the timing sent to your monitor.  For example, in the case of your modeline, the driver isn't able to find an exact match:

ref_freq: 2700
freq: 179260000
best_freq: 175000000
best_feedback_div: 350
best_ref_div: 27
best_post_div: 2

dot clock = (ref_freq * (feedback_div / ref_div)) / post_div;

(In reply to comment #0)
> Created an attachment (id=28897) [details]
> Config File
> 
> I have a Radeon 8500LE connected to a Mitsubishi Diamond Pro 900U CRT monitor
> through the VGA/D-SUB port.  For a refresh rate setting of 1400x1050@85Hz, I'm
> actually seeing 82 or 83Hz (as reported by my monitor's OSD) - which is low
> enough to give me headaches.
> 
> My OS is Mandriva 2009.1 with all the latest updates (version 6.12.2 of the
> radeon driver).
> Windows XP and Mandriva 2007 on other partitions are fine, this must have been
> introduced fairly recently.
> 
> Contact me if any more info is required.
> 
> Thanks,
> Mark.
> Also, My apologies if I've chosen the wrong project to report this to...
> 

I have the same problem with a Radeon X800GTO on a Mitsubishi Diamond Plus 230SB. xrandr says 1600*1200@85Hz but the OSD says 78.4Hz and the image is shaking.
There is no problem in 75Hz.

I think i know why it worked for you with Mandriva 2007: It's kernel mode setting. New versions of the distributions activate it by default. I have this problem only when kernel mode setting is activated.

Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.