[R480] screen display shows "shivering", wrong refresh rate

[Raynor]

Binary package hint: xorg

I the 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 have this problem since i upgraded to lucid. I have this problem only in KMS so i set
"options radeon modeset=0" /etc/modprobe.d/radeon-kms.conf to disable it.

Here are other URLs to the same bug (i think) :
https://bugs.freedesktop.org/show_bug.cgi?id=23508
https://bugs.freedesktop.org/show_bug.cgi?id=27278

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: xorg 1:7.5+3ubuntu1
ProcVersionSignature: Ubuntu 2.6.32-19.28-generic 2.6.32.10+drm33.1
Uname: Linux 2.6.32-19-generic i686
Architecture: i386
CheckboxSubmission: 1a456c9fa0d0b19a4a079c28070486e6
CheckboxSystem: edda5d4f616ca792bf437989cb597002
CurrentDmesg:
 [ 51.196034] end_request: I/O error, dev fd0, sector 0
 [ 54.736047] end_request: I/O error, dev fd0, sector 0
 [ 99.580021] Clocksource tsc unstable (delta = -169534079 ns)
 [ 117.812053] __ratelimit: 12 callbacks suppressed
 [ 117.812058] gvfsd-metadata[2112]: segfault at 8 ip 0804d35a sp bfc3f9c0 error 4 in gvfsd-metadata[8048000+c000]
Date: Sat Apr 3 16:26:19 2010
DkmsStatus: Error: [Errno 2] Aucun fichier ou dossier de ce type
Lsusb:
 Bus 002 Device 002: ID 046d:c042 Logitech, Inc.
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 001 Device 002: ID 0ccd:0038 TerraTec Electronic GmbH Cinergy T^2 DVB-T Receiver
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: System manufacturer System Product Name
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-19-generic root=UUID=22e38d43-2b96-411c-88b7-d95f0d2bb122 ro quiet splash
ProcEnviron:
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
SourcePackage: xorg
dmi.bios.date: 08/22/2005
dmi.bios.vendor: Phoenix Technologies, LTD
dmi.bios.version: ASUS A8N-E ACPI BIOS Revision 1008
dmi.board.name: A8N-E
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: 2.XX
dmi.chassis.asset.tag: 123456789000
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnPhoenixTechnologies,LTD:bvrASUSA8N-EACPIBIOSRevision1008:bd08/22/2005:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnA8N-E:rvr2.XX:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer
system:
 distro: Ubuntu
 codename: lucid
 architecture: i686
 kernel: 2.6.32-19-generic

[lspci]
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc R480 [Radeon X800 GTO (PCIE)] [1002:5d4f]
     Subsystem: PC Partner Limited Device [174b:1600]

[Markcooke666 (markcooke666)]

Created an attachment (id=28898)
Xorg log file

[agd5f (agd5f)]

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

[Markcooke666 (markcooke666)]

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.

[Markcooke666 (markcooke666)]

Created an attachment (id=29106)
XRandR output

[Markcooke666 (markcooke666)]

Created an attachment (id=29107)
Verbose XRandR output

[Markcooke666 (markcooke666)]

Created an attachment (id=29108)
Optical proof of Monitors OSD not matching server/xrandr/driver

[Markcooke666 (markcooke666)]

(From update of attachment 29108)
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.

[agd5f (agd5f)]

(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

[Markcooke666 (markcooke666)]

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.

[agd5f (agd5f)]

(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.

[Markcooke666 (markcooke666)]

(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?

[agd5f (agd5f)]

(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;

[Raynor (memphis007fr)]

(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.

[Raynor (memphis007fr)]

Binary package hint: xorg

I the 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 have this problem since i upgraded to lucid. I have this problem only in KMS so i set
"options radeon modeset=0" /etc/modprobe.d/radeon-kms.conf to disable it.

Here are other URLs to the same bug (i think) :
https://bugs.freedesktop.org/show_bug.cgi?id=23508
https://bugs.freedesktop.org/show_bug.cgi?id=27278

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: xorg 1:7.5+3ubuntu1
ProcVersionSignature: Ubuntu 2.6.32-19.28-generic 2.6.32.10+drm33.1
Uname: Linux 2.6.32-19-generic i686
Architecture: i386
CheckboxSubmission: 1a456c9fa0d0b19a4a079c28070486e6
CheckboxSystem: edda5d4f616ca792bf437989cb597002
CurrentDmesg:
 [ 51.196034] end_request: I/O error, dev fd0, sector 0
 [ 54.736047] end_request: I/O error, dev fd0, sector 0
 [ 99.580021] Clocksource tsc unstable (delta = -169534079 ns)
 [ 117.812053] __ratelimit: 12 callbacks suppressed
 [ 117.812058] gvfsd-metadata[2112]: segfault at 8 ip 0804d35a sp bfc3f9c0 error 4 in gvfsd-metadata[8048000+c000]
Date: Sat Apr 3 16:26:19 2010
DkmsStatus: Error: [Errno 2] Aucun fichier ou dossier de ce type
Lsusb:
 Bus 002 Device 002: ID 046d:c042 Logitech, Inc.
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 001 Device 002: ID 0ccd:0038 TerraTec Electronic GmbH Cinergy T^2 DVB-T Receiver
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: System manufacturer System Product Name
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-19-generic root=UUID=22e38d43-2b96-411c-88b7-d95f0d2bb122 ro quiet splash
ProcEnviron:
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
SourcePackage: xorg
dmi.bios.date: 08/22/2005
dmi.bios.vendor: Phoenix Technologies, LTD
dmi.bios.version: ASUS A8N-E ACPI BIOS Revision 1008
dmi.board.name: A8N-E
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: 2.XX
dmi.chassis.asset.tag: 123456789000
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnPhoenixTechnologies,LTD:bvrASUSA8N-EACPIBIOSRevision1008:bd08/22/2005:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnA8N-E:rvr2.XX:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer
system:
 distro: Ubuntu
 codename: lucid
 architecture: i686
 kernel: 2.6.32-19-generic

[Raynor (memphis007fr)]

I have seen this update for lucid:

Version 1:6.13.0-1ubuntu3 :

  * Drop /etc/modprobe.d/radeon-kms.conf; in the best case it's redundant
    because KMS is on by default in the Ubuntu kernel, in the worst case it
    breaks our ability to forcibly disable KMS when there's a problem.

If i understand correctly, with this update, i will not be able to deactivate kms anymore. So for now i will not update my ubuntu.

[penalvch (penalvch)]

Raynor, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p xserver-xorg-video-ati REPLACE-WITH-BUG-NUMBER

Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Ajax-a (ajax-a)]

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.

[Stef Fidder (steffidder)]

Nice thing broo https://crackswhale.com/