| Summary: | Flickering or blanking on DVI output of Radeon 9200/9250 | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Tomas Lindén <tlinden> |
| Component: | Driver/Radeon | Assignee: | Xorg Project Team <xorg-team> |
| Status: | RESOLVED INVALID | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | high | CC: | aherrman, alexdeucher, alexm, aschultz, bengtv, benh, brian, carpdjih, dawajpoczte, dmiceman, fax, freedesktop2eran, freedesktop.org, gemkow, horsley1953, hyu, pawsa-gpa, sig, TurinCJ, xorg-driver-ati |
| Version: | git | ||
| Hardware: | x86 (IA32) | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | 4656 | ||
| Bug Blocks: | |||
| Attachments: | |||
|
Description
Tomas Lindén
2005-03-30 01:48:57 UTC
Created attachment 2256 [details]
My xorg.conf file
Created attachment 2257 [details]
The Xserver log file.
Created attachment 2258 [details]
The output from lspci -vv.
try changing the "displaypriority" option. See the radeon man page for more. Another thing to try is setting up a custom modeline with a vrefresh less than 60; like 50 or 55. I tried using Option "DisplayPriority" "BIOS" and Option "DisplayPriority" "HIGH" instead of the default value "AUTO", but this did not solve the blanking problem, the xv problem nor the problem with showing the DVI modes 1400x1050, 1280x102 and 800x600 properly. According the manual for My Eizo FlexScan L885 display the Vertical Scanning frequency in DVI mode is limited to the range 59-61 Hz. The manual also says concerning Digital Input that "Only the following resolutions with frequency can be displayed on this model" Resolution Frequency Dot Clock Remarks ... 1600x1200 60 Hz 162 MHz (max) VESA For this reason I don't think that it makes sense to try a lower frequency like 50 or 55 Hz. Bug 1129 seems similar to the one that I'm seening and it concerns also the same ASUS card that I have: https://bugs.freedesktop.org/show_bug.cgi?id=1129 Created attachment 2306 [details]
The striped desktop in 1400x1050 DVI mode, when setting Option Panelsize
Created attachment 2307 [details]
The rightshifted DVI 1280x1024 desktop when setting Option Panelsize
Created attachment 2308 [details]
The right shifted DVI 800x600 desktop when setting Option PanelSize
The following bugs might be related to the problems described here DVI screem flickering problem https://bugs.freedesktop.org/show_bug.cgi?id=1724 https://bugs.freedesktop.org/show_bug.cgi?id=2674 https://bugs.freedesktop.org/show_bug.cgi?id=2887 Xv driver problem https://bugs.freedesktop.org/show_bug.cgi?id=2759 The DVI screen flickering problem occurs for me even when there is no mouse activity or significant screen changes. However it does get _MUCH MORE_ frequent if there is lots of screen updates like when watching a video sequence in full screen with xine and the Xv driver, so the problem is also somehow related to the load on the graphics card. the 9200SE definitely has limited bandwidth due to their lower memory bandwidth. Have you tried running your vrefresh at 50 Hz? You may need a custom modeline. I think the windows drivers default to a lower refresh on the DVI port on the SE cards. Does the card work properly in windows? The failure rate on cheap 9200SE's seems somewhat higher than other radeons. (In reply to comment #11) > the 9200SE definitely has limited bandwidth due to their lower memory bandwidth. I don't think this is bandwidth related problem because the analog output over the VGA cable works fine in 1600x1200 mode. This card is supposed to support a maximum display size of 2048x1536, so DVI 1600x1200 should not be a problem. > Have you tried running your vrefresh at 50 Hz? You may need a custom > modeline. The URL to my monitor http://www.eizo.com/support/discontinued/lcd/l885.asp says that the vertical refresh rate for DVI-signals is 59-61 Hz (For VGA text modes the range is 69-71 Hz). The same information is given in the display manual and I have confirmed by the local Eizo support that 1600x1200 DVI only runs with a vertical refresh rate of 60 Hz. The distorted DVI-modes that I have shown screen shots of suggest to me that there is some kind of timing problem in the Radeon driver for this card. > I think the windows drivers default to a lower refresh on the DVI > port on the SE cards. Does the card work properly in windows? I don't have windows on this machine and no space on the harddrive to install Windows just for testing. ASUSTEK supplies a Windows driver for this card, but I don't know if this is a relabeled ATI driver. > The failure rate > on cheap 9200SE's seems somewhat higher than other radeons. I would have bougth a 9200 card, but I could not find any left in the local retail shops. The 9200 and 9200SE has all the features that I want supported in principle by the Radeon driver which is why I bought the card in the first place. Since I don't do gaming I did not go for a more expensive card with more 3D-performance. What do you mean by the failure rate in this context? (In reply to comment #12) > (In reply to comment #11) > > the 9200SE definitely has limited bandwidth due to their lower memory > bandwidth. > > I don't think this is bandwidth related problem because the analog output over > the VGA cable works fine in 1600x1200 mode. This card is supposed to support a > maximum display size of 2048x1536, so DVI 1600x1200 should not be a problem. > > > Have you tried running your vrefresh at 50 Hz? You may need a custom > > modeline. > > The URL to my monitor > http://www.eizo.com/support/discontinued/lcd/l885.asp > says that the vertical refresh rate for DVI-signals is 59-61 Hz (For VGA text > modes the range is 69-71 Hz). The same information is given in the display > manual and I have confirmed by the local Eizo support that 1600x1200 DVI only > runs with a vertical refresh rate of 60 Hz. > > The distorted DVI-modes that I have shown screen shots of suggest to me that > there is some kind of timing problem in the Radeon driver for this card. Unless their is some weirdness for the SE cards, I've never had a problem with DVI on my non-SE card. Problems with SE cards and DVI seem pretty common. One of the things that other users have reported as helping is running the DVI on SE cards at a lower refresh rate like 50 or 55 Hz. > > > I think the windows drivers default to a lower refresh on the DVI > > port on the SE cards. Does the card work properly in windows? > > I don't have windows on this machine and no space on the harddrive to install > Windows just for testing. > > ASUSTEK supplies a Windows driver for this card, but I don't know if this is a > relabeled ATI driver. Shouldn't really matter, ati's drivers will handle the card too. > > > The failure rate > > on cheap 9200SE's seems somewhat higher than other radeons. > > I would have bougth a 9200 card, but I could not find any left in the local > retail shops. The 9200 and 9200SE has all the features that I want supported in > principle by the Radeon driver which is why I bought the card in the first > place. Since I don't do gaming I did not go for a more expensive card with more > 3D-performance. > > What do you mean by the failure rate in this context? Quite a few people have not been able to get the DVI port to work properly on SE cards in both windows and Xorg. I tried using the vesa driver on my Fedore Core 3 machine to see if
that driver also exhibits the random blanking of the DVI signal. Unfortunately I
could not get any large resolution DVI modes, but only
1024x768x16
and
1024x768x24
worked. I could not see any blanking on the screen with this driver in
these modes. Watching a short film sequence with xine required the use of
-V Xshm
to get a signal DVI- and VGA-signal, but also this did not induce any
flickering.
I repeated the same exercise using Knopppix 3.8.1 (kernel 2.6.11,
XFree86 4.3.0.1) with the following drivers and modes
frambuffer 1024x768x16
vesa 800x600x16
vesa 800x600x24
Also in none of these cases did I see random blanking of the screen.
Even when not using
Option "PanelSize" "1600x1200"
at least the DVI mode 1400x1050x24 exhibits the blanking problem with
the radeon driver on my Fedora Core 3 machine.
It seems that
Option "PanelSize" "1600x1200"
makes the blanking problem significantly worse, because with this option
the blanking occurs for also for the DVI modes 1280x1024, 1024x768, 800x600
and 640x480.
To debug my DVI problems I have my FlexScan L885 monitor connected to
both the DVI- and the VGA-cable of my Radeon 9200SE card. This has the
side effect that the radeon driver activates a MergedFB mode with the
default value of Clone. The statement on the radeon man page that
connecting two monitors will by default enable the MergedFB mode would
deserve to be written with bold text in my opinion. I tried using
Option "MergedFB" "off"
to see if this could solve at least some problems for me.
but this did not solve the blanking problem in DVI mode 1600x1200.
Also if I don't use
Option "PanelSize" "1600x1200"
then the DVI mode 1400x1050 still blanks randomly.
However now it seems that with
Option "MergedFB" "off"
that the Xv driver gives output both on the DVI and the VGA cables, so
at least this problem is now solved.
I also tried the combination
Option "MergedFB" "off"
Option "MonitorLayout" "TMDS, NONE"
Option "PanelSize" "1600x1200"
but I still get the flickering problem.
TO SUMMARIZE MY REMAINING PROBLEMS:
To get any DVI output with the radeon driver I need to use
Option "MonitorLayout" "TMDS, CRT"
but already this option makes for random blanking at least in the
1400x1050 DVI mode. To enable the DVI mode 1600x1200 I need to use
Option "PanelSize" "1600x1200"
but this makes the random blanking occur even more often.
What does the usage of these options do that the radeon driver does not
do by default?
(In reply to comment #14) > > TO SUMMARIZE MY REMAINING PROBLEMS: > > To get any DVI output with the radeon driver I need to use > Option "MonitorLayout" "TMDS, CRT" > but already this option makes for random blanking at least in the > 1400x1050 DVI mode. To enable the DVI mode 1600x1200 I need to use > Option "PanelSize" "1600x1200" > but this makes the random blanking occur even more often. > > What does the usage of these options do that the radeon driver does not > do by default? > The radeon driver attempts to detect the way your card is wired up and what monitors are connected by default, sometimes however certain oems do weird things with the bios or the the card layout which makes the auto-detection stuff problematic. these options allow you to override what's detected. all radeons except the original r100 have 2 display controllers (crtcs). The "monitorlayout" option forces the monitor type connected to each crtc. so setting "TMDS, CRT" forces both outputs on and sets crtc1's monitor type to TMDS (which is the signaling used for DVI) and sets crtc2's monitor type to CRT (regular old 15-pin vga style connection). "Panelsize" is really for forcing the laptop LCD panel to a spcific size if the driver cannot detect it by default. I don't recall off hand how it interacts with the TMDS path. Mergedfb enables or disables the use of both crtcs on a shared framebuffer. by default this is enabled in Clone mode (both crtcs point at the same part of the framebuffer). Clone mode is enabled by default so that each output can have separate timings and you don't accidently cook one monitor if you try and run a mode supported by one head and not the other. However, the radeon only has one video overlay, and it can only be sourced to one crtc or the other at one time, so you can only use Xv on one head at a time. there is an xv attribute you can set to switch the overlay head in clone mode. dualhead modes will automatically switch. with mergedfb off, crtc1 drives both displays so the the overlay shows on both. I installed the demo version of Accelerated-X on my Fedora Core 3 machine to see if the blanking problem would show up with this server also. It turned out that with Accelerated-X the DVI modes blanks even more ofthen than if I only use the the X.org server with the radeon driver. The flickering occurs at least for 24 bit 1600x1200, 1280x1024 and 1024x768 modes. I tried also using options MTRR off, AGP1X and RenderExtensions NO, but none of these options had any effect on the random blanking. I installed xsvc-3. 0-54c.i386.rpm and Summit_DX-Platinum-2.2-20.i386.rpm and used the driver for the Radeon 9200 chipset. Created attachment 2591 [details]
My configuration file for Accelerated-X
(In reply to comment #16) > I installed the demo version of Accelerated-X on my Fedora Core 3 machine to see > if the blanking problem would show up with this server also. > It turned out that with Accelerated-X the DVI modes blanks even more ofthen than > if I only use the the X.org server with the radeon driver. > The flickering occurs at least for 24 bit 1600x1200, 1280x1024 and 1024x768 > modes. I tried also using options MTRR off, AGP1X and RenderExtensions NO, but > none of these options had any effect on the random blanking. I installed xsvc-3. > 0-54c.i386.rpm and Summit_DX-Platinum-2.2-20.i386.rpm and used the driver for > the Radeon 9200 chipset. > Sounds like it may be bad hardware. Adding my $0.02. The following is a bug report I had posted on redhats bugzilla. So references bug numbers are redhat bugzilla bug numbers. Note that I found a work-around that works for me. So I thought others might have an interest in this report. ========================================================================== I just upgraded to xorg-x11-6.8.2-1.FC3.13.x86_64 this morning and am now experiencing exactly the same behavior. I have a very similar setup. Shuttle SN85G4-V2 motherboard Ati radeon 9200se Samsung SyncMaster 213T LCD Monitor connected to DVI output What's a little odd is that previously I was running xorg-x11-6.8.1-12.FC3.21.x86_64 and this problem was NOT occuring. Yet this is the version that this bug was originally posted for. I see the screen blink out then back, even when there is no appearent activity (no mouse movement etc.). Note that I have also been experiencing the problem noted in bug 123511 (screen blinks while doing GL). So after reading the note on this bug above, I disabled DRI (commented out loading dri module in xorg.conf). After disabling DRI, both problems have improved. I have not yet had an instance of the screen blanking out. Oops, forgot to mention that the original redhat bugzilla number for this report is 142932. Link: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142932 I disabled DRI in my xorg.conf. It seemed to improve the flickering problem, but unfortunately it is not a complete workaround for me. I still have the flickering problem, but it took half an hour for the first blanking to occur. With DRI enabled it usually occurs within a few minutes or so. It seems that after an hour or so the blanking occurs more and more frequently and returns to the rate seen with DRI enabled. This is of the order of 3-4 blankings / minute so it still makes the DVI-connection unusable in practice after one hour or so. Using xine to watch a movie sequence does not seem to increase the rate of blanking events with DRI turned off as it does with DRI enabled. I would like to add that I have seen this random screen blanking problem as well, and I think the details in my situation may be informative. First, it has been a long-standing infrequent problem on a PCI Radeon 7000/VE with a DVI 1280x1024 DFP, but I don't have any further information about that. More interestingly, I recently started having this problem on my AGP Radeon 7000/VE with DVI 1600x1200 DFP when I simultaneously upgraded from Fedora Core 3 to Fedora Core 4 and from an Athlon XP to an Athlon 64. The symptoms were that the DFP would only be autodetected as 1280x1024, and that with PanelSize 1600x1200 the image would be frequently blanked, unusably so. What I wanted to report is that I was able to fix the panel size detection problem with my DFP, and that this also fixed the blanking problem. To get my panel size correctly detected, I had to modify RADEONUpdatePanelSize() in xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c. That function loops over the various DDC modes of the monitor, but when considering the detailed timings table, it seems to only look at the first mode bigger than the current mode, due to the line "if (info->DotClock) continue;" Since the native resolution of my monitor is listed second in its DDC detailed timings, this line was preventing it from ever being detected. Removing the line allowed radeon_driver to correctly detect the size of my panel, and as a side effect fixed my blanking problem. If this information is useful, I'm happy to provide more details, just let me know what you would like to know. Your modification sounds interesting. Could you please post a diff between the original code and your modifications? Created attachment 2929 [details] [review] Implement cairo_ps_surface_set_dpi() Without this patch, radeon_driver.c stops scanning the detailed DDC modes as soon as it finds one mode "better" than the current mode. As my 1600x1200 DFP lists a 1280x1024 mode before its native resolution, without this patch its panel size is incorrectly determined to be 1280x1024. With this patch, the panel is correctly determined to be 1600x1200. As a side effect, using this patch for 1600x1200, rather than forcing 1600x1200 via the PanelSize option, resolves for me the random blanking problem at 1600x1200 resolution. Presumably this is because the Modeline from the DDC differ from that X automatically generates?? >
> Sounds like it may be bad hardware.
>
Please let me add some more observations:
In short: In the past weeks we tried to switch to DVI (after buying some
LC-Displays :-) and found the same problem with different cards (older ones and
new ones) in different peculiarity. Using some of the cards with windows did
not show the problem.
We bought (in serveral steps) about 35 radeon cards in different configurations
with different chips: 7000, 9200SE, 9550, 9250, 9550SE from different producers
(ACER, HIS, Sapphire, ...). The different cards result simply from what could
be delivered by the suppliers. All cards are without fan (the reason we want to
use them).
We use different displays (EIZO, NEC) with different resolution (mostly
1600x1200 but also 1280x1024). We currently use Xorg 6.8.2 bute the problem
is the same with XFree86
Our oberservations are:
- Many (but not all) cards show the "screen-off" problem more or less often,
some cards never show the problem, some ones per day and some are not usable
because they flicker with an interval of some seconds,
- The problem is not dependant on the used radeon-chip, all chips show the
problem. There is no coherence between how often the problem happens and
the chip used,
- We tested some (but not all) cards with the windows drivers. In the time we
tested (which is shorter than the time we used the cards with Xorg) the
problem did not (never) occur.
- The problem often gets worse with the time the card is used. But some (also
rather old) cards never show the problem,
- We found some changes in how often the flicker occurs when changing the
AGP access time in the BIOS-Mainboard (where this is possible)
- The cards have no problem with analog output (besides the bad quality which
most of the cards show), only DVI is affected.
So my preliminary conclusions from these observations are:
- The problem seems to be caused by a hardware design flaw which is immanent in
all 2D-radeon-chips. Something in the chips seems to work at its limit
which shifts with usage time.
- BUT the driver seems to have a chance to handle the problem - or the cards
would not work with windows.
Our hardware guru says that there is a good possibility that the problem is
also present when using analog output but is not user-visible then because the
analog monitor simply would ignore i.e. sync flickers while a digital monitor
would go out-of-sync and show the flicker.
When trying to conclude:
- It seems we have "tested" a significant number of "simple" radeon-chips to
conclude that these have a problem with DVI which could not simply explained
by hardware defects - it is a flaw in hardware and/or a inadequate handling
in software.
- With incrasing number of users using DVI with these silent cards the
problem will become more visible and more annoying for the community.
Is there any chance to find a solution? Can we help to debug/test this? We had
to switch back to VGA for most of our seats which is not really a good
solution.
Thanks for your efforts and listening
(In reply to comment #23) > Is there any chance to find a solution? Can we help to debug/test this? We had > to switch back to VGA for most of our seats which is not really a good > solution. > Does adjusting the refresh rate down (try 50 or 55 Hz) help? You might also try the displaypriority option. If none of that helps, I'm not sure what else to do until someone can track down exactly what the problem is or ati can provide information about it. Unforunately none of my radeon cards exhibit the problem. Do they work properly with ati's fglrx binary driver? If so, you might try dumping and comparing the registers between xorg and fglrx to see if you can dig out the differences. > - We found some changes in how often the flicker occurs when changing the
> AGP access time in the BIOS-Mainboard (where this is possible)
Some of the Radeon chips are also used on PCI-cards for either very old computer
s without an AGP bus or for dual graphics cards setups. On one of my home
computers I use a Sappphire Radeon 9200SE PCI card with a Dell UltraSharp 1703FP
in DVI mode 1280x1024 without any problems at all.
Has there been any reports about this flickering problem with PCI-cards?
Would it be useful if I made a registerdump (how?) from my Sapphire Radeon
9200SE PCI card and compared it with my problematic ASUSTEK Radeon 9200SE AGP
card?
(In reply to comment #15) > all radeons > except the original r100 have 2 display controllers (crtcs). I am confused. I have a ThinkPad T30 which reportedly has a Radeon 7500 which reportedly has an R100 chipset. I am able to use mergedfb (laptop LCD panel, external VGA monitor). Does this mean that the T30 actually has two crtcs? (In reply to comment #26) > (In reply to comment #15) > > all radeons > > except the original r100 have 2 display controllers (crtcs). > > I am confused. I have a ThinkPad T30 which reportedly has a Radeon 7500 which > reportedly has an R100 chipset. I am able to use mergedfb (laptop LCD panel, > external VGA monitor). Does this mean that the T30 actually has two crtcs? the 7500 is actually an rv200 which is a variant of the r100 core. the original radeon 7200 (plain r100) is the only one with 1 crtc. If your chip didn't have two crtcs you wouldn't be able to use dualhead. *** Bug 2887 has been marked as a duplicate of this bug. *** *** Bug 2674 has been marked as a duplicate of this bug. *** *** Bug 3275 has been marked as a duplicate of this bug. *** I wouldn't be surprised if this were related to #1129. (In reply to comment #31) > I wouldn't be surprised if this were related to #1129. For those of you having problems with DVI, try the modelines with reduced blanking intervals as per this web page (from bug 1129): http://suif.stanford.edu/~csapuntz/rv280-linux-dvi.html *** Bug 2657 has been marked as a duplicate of this bug. *** *** Bug 1620 has been marked as a duplicate of this bug. *** (In reply to comment #32) > For those of you having problems with DVI, try the modelines with reduced > blanking intervals as per this web page (from bug 1129): > > http://suif.stanford.edu/~csapuntz/rv280-linux-dvi.html Tried it, didn't work. I fact i even switched to ATI's fglrx driver and compared the timing reported by a) its Modeline in the log and b) the information from the monitor. The AIT drivers uses the default VESA timing as reported by DDC and DOES NOT show the flickering problem. Andreas One small "datapoint", no idea whether this helps: Beginning in line 6090 of radeon_driver.c (current CVS) there is a section which looks like a workaround for a similiar problem. The workaround reduces interaction with the PLL because the author worried about lock problems for PLL-registers. Unfortunately removing the "if" around this section (so the section is executed also on non-mobility-usage) doesnt solve the problem. I run Fedora Core 3 with automatic updates using yum on the computer which exhibits the DVI-flickering problem. On September 17th yum updated X.org to version xorg-x11.i386 6.8.2-1.FC3.45 I was curious to see if this particular update would change anything for me, so I rebooted my machine on Monday September 19th. To my delight the DVI flickering problem was significantly reduced by this update, but unfortunately it is not completly eliminated. There was another X.org update on September 21st, to version xorg-x11.i386 6.8.2-1.FC3.45.1 so I rebooted my machine again. From Monday 19th to Friday 23rd of September I noticed one flickering event during normal usage and two when I was locking my screen and xscreensaver faded out the display. On Monday the 26th I noticed two more flickering events. Previously the DVI signal flickered so much that it was totally unusable, but now it is doing it less than once / day, so the improvement is great and the DVI-output is finally usable. The update xorg-x11.i386 6.8.2-1.FC3.45 which was the first update to significantly improve my DVI problem contains among another things a fix to a very old bug in X where the X-server accesses directly the PCI config registers instead of going trough the Linux kernel in a safe way. Unfortunately this update created some new problems on many machines, one them being my other computer with a Radeon 9200SE PCI card where this X update just hangs with a completely black screen. Reading this bug description suggests to me that the DVI flickering problem could be due to the problem of the X-server accessing the PCI config registers directly https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168750 Could it be that the remining infrequent flickering events that I see are due to some part of the X server code that still accesses the PCI config registers in an unsafe way? (In reply to comment #37) <snip> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168750 > Could it be that the remining infrequent flickering events that I see > are due to some part of the X server code that still accesses the PCI > config registers in an unsafe way? > I strongly suspect it's a problem with the mode being sent to the monitor; between what the port and the monitor support. The PCI regs shouldn't have anything to do with this. In reply to comment 38 > I strongly suspect it's a problem with the mode being sent to the monitor; > between what the port and the monitor support. The PCI regs shouldn't have > anything to do with this. Was there any bugfixes related to this then in the update xorg-x11.i386 6.8.2-1.FC3.45 ? (In reply to comment #37) > I run Fedora Core 3 with automatic updates using yum on the computer > which exhibits the DVI-flickering problem. On September 17th yum updated > X.org to version > xorg-x11.i386 6.8.2-1.FC3.45 > I was curious to see if this particular update would change anything for > me, so I rebooted my machine on Monday September 19th. To my delight the > DVI flickering problem was significantly reduced by this update, but > unfortunately it is not completly eliminated. > > There was another X.org update on September 21st, to version > xorg-x11.i386 6.8.2-1.FC3.45.1 > so I rebooted my machine again. From Monday 19th to Friday 23rd of > September I noticed one flickering event during normal usage and two > when I was locking my screen and xscreensaver faded out the display. On > Monday the 26th I noticed two more flickering events. > > Previously the DVI signal flickered so much that it was totally unusable, > but now it is doing it less than once / day, so the improvement is great > and the DVI-output is finally usable. > > The update > xorg-x11.i386 6.8.2-1.FC3.45 > which was the first update to significantly improve my DVI problem > contains among another things a fix to a very old bug in X where the > X-server accesses directly the PCI config registers instead of going > trough the Linux kernel in a safe way. Unfortunately this update created > some new problems on many machines, one them being my other computer > with a Radeon 9200SE PCI card where this X update just hangs with a > completely black screen. Reading this bug description suggests to me > that the DVI flickering problem could be due to the problem of the > X-server accessing the PCI config registers directly > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168750 The bug you reference is concerning the PCI config access patch, but is not a bug about problems on Radeon 9200SE PCI. It is important IMHO to consider the problem you are having as a separate unrelated problem, and diagnose it to the real problem rather than make premature conclusions. The problem may or may not turn out to be triggered by the pci-config changes. One thing to try, is to try the latest rpm rebuilt with the pci-config patch disabled, and if the problem goes away, file a new bug report in Red Hat bugzilla completely detailing the problem, the testing you've done, and attaching your X server log and config file. > Could it be that the remining infrequent flickering events that I see > are due to some part of the X server code that still accesses the PCI > config registers in an unsafe way? The pci-config registers are accessed via the kernel now, which is the _only_ safe way. The regressions this has caused in the X server are not due to the new pci-config changes being wrong or unsafe. The regressions are actually bugs that have always been in the X server, but the codepaths were never hit before. What we have discovered, is that video BIOSes access registers outside of PCI config space, but end up using the X server's pciReadByte which was doing a long read and masking off the wanted byte. That had side effect of reading multiple bytes on the hardware, and if those registers have side effects that trigger the hardware in some way when read, bad random things can happen. Our newer patch fixes the X server PCI code so that in these cases byte reads are used instead of masked long reads. It is entirely possible that there are other bugs in the X server code that the pci-config changes have unearthed which were never hit before, as the code paths were never exercized, or were never used the way they are now. So, just to clarify things, the pci-config patches are not "unsafe", but their presence definitely has uncovered dormant bugs elsewhere in the X server that were never hit before, and there may yet be other dormant bugs to find. May or may not be causing this issue. More diagnosis is needed to conclude anything. xorg-x11-6.8.2-37.FC4.49.2 is the current FC4 release xorg-x11-6.8.2-1.FC3.45.2 is the current FC3 release Try adding to the ServerFlags section of your xorg.conf Option "PCIOsConfig" Reboot the machine to force a full hardware reset. Test X, and see if there is any change, and make note of it. Then replace the above option with each of the following one at a time and do the same: Option "PciProbe1" Then: Option "PciProbe2" Be sure to reboot each time. After doing these 3 tests, update the bug report to indicate if anything at all changed in each test. Also, attach the X server log file to the report as a file attachment (not cut and paste), for each of the 3 above tests. This will help determine if the pci-config patch has unearthed other dormant bugs in the X server code. Thanks in advance. (In reply to comment #38) > I strongly suspect it's a problem with the mode being sent to the monitor; > between what the port and the monitor support. The PCI regs shouldn't have > anything to do with this. > I can confirm that using the clock reduction method described in http://suif.stanford.edu/~csapuntz/rv280-linux-dvi.html from Bug 1129 solves the problem for all cards we tested - even for a card which was completely unusable before. It remains the problem that the current radeon server does not accept Modelines when using digital displays so reducing the clock requires patching the driver source. I will file a separate bug report on this. Thanks for all hints. I had the same problem with a Sapphire 9250 and a Dell 2000FP with 1600x1200 mode not displaying anything (with the 2000FP going into power save mode). The "fix" described at http://suif.stanford.edu/~csapuntz/rv280-linux-dvi.html mostly fixed the problem. Most of the time the display was fine, but sometimes I would get the weird couple of second blanking. I ended up creating a new modeline with even an further reduced blanking interval, bringing the clock down to 125.97MHz. This seems to be working even better, but I have to admit, I don't know if it's a good idea to drop it even further. I'm not familiar enough with DVI and LCD monitor technology to know what a safe minimum is. I don't know what this means for a better general solution, but hopefully it'll help someone. (In reply to comment #42) > I ended up creating a new modeline with even an further reduced blanking > interval, bringing the clock down to 125.97MHz. This seems to be working even > better, but I have to admit, I don't know if it's a good idea to drop it even > further. I'm not familiar enough with DVI and LCD monitor technology to know > what a safe minimum is. Besides further reducing the blanking time, on some of our displays (mostly NEC, IBM) we also reduced the refresh rate to 50Hz without problems. Other displays (EIZO) have trouble with such a low rate (some accepted 57Hz). This further reduced the clock rate. After testing this for two weeks now, we found that reducing the clock rate reduced the problem but did not completely solve it - the effect still shows up with a very low rate (on some displays only one flicker per day). So the "correct" solution is in my opinion still missing or there is a serious design flaw in _all_ radeon chip (we currently use about 40 cards, a dozen different models from different vendors with 6 different radeon-chip-typs). What I still cannot understand is that about one third of our cards _never_ had any problems, they did not flicker even one time (as far as we observed it) - we can even increase the clock to any (reasonable) value and they do not flicker. These "good" cards use different chips- models and come from different vendors. Is there any chance that ATI comments on this or gives some help? Ok, there seem to be different problems here... let's see if we can sort it out.
- First of all, can you build the current CVS HEAD or at least RC1 and test from
that ? That will make things easier and make sure you have all the recent fixes.
- Your server log file that you attached. Was it taken with only that flat panel
connected (DVI input) or the analog input connected to a monitor as well ? The
DDC information seem to show an analog connector, so either you have a monitor
that lies (it happens quite often) or something is wrong in the driver. Also,
please also send the log without the PanelSize option.
- What connectors does your card physically have ? A DVI and a VGA ? Two DVIs ?
- At the beginning of radeon_driver.c, there is a table called
default_tmds_plls. It contains that line:
{{13000, 0x400f4}, {15000, 0x400f7}, {0xffffffff, 0x400f7/*0x40111*/}, {0,
0}}, /*CHIP_FAMILY_RV280*/
Can you try changing it to:
{{13000, 0x400f4}, {15000, 0x400f7}, {0xffffffff, 0x40111}, {0, 0}},
/*CHIP_FAMILY_RV280*/
And if it doesn't make a difference, to:
{{13000, 0xb00f4}, {15000, 0xb00f7}, {0xffffffff, 0xb0111}, {0, 0}},
/*CHIP_FAMILY_RV280*/
Tell me if it fixes your panel randomly "blanking" and that sort of things.
- Regardless of the above setup (or rather, going back to the initial values),
edit radeon_bios.c, and look near the end of the file, in function
RADEONGetTMDSInfoFromBIOS(), there is this blob:
/* revision 4 has some problem as it appears in RV280,
comment it off for now, use default instead */
/*
This is then followed by a bunch of code that is commented out. Can you remove
the commenting-out (that is actually -enable- this code) and tell me if it makes
any difference ? In fact, it would be nice if you could add a printf to this
function (Use X's ErrorF() which works just like printf) that tells what value
you get for RADEON_BIOS8(tmp) (3, 4, something else ?)
Thanks,
Ben.
Hello Ben, (In reply to comment #44) > Ok, there seem to be different problems here... let's see if we can sort it out. > I am not sure, to which of the different reporters your comments and suggestions were directed - I did not upload a server log, our displays are connected through DVI for sure. So I thoughtyour questions were directed to another poster. If this is wrong - I would be happy to test any suggestion which may help to isolate this problem. At least for us reducing the blanking time by patching the driver solves this problem (random blanking) mostly. I added bug 4656 to open a way for other users to easily follow the same way without patching the driver. But please correct me if I understand something wrong. My comment applies to everybody here. I think those digital output instabilities (flicker) are related to incorrect TMDS_PLL_* values, thus please try the various things I suggested and let us know. Stumbled over this bugzilla when searching for a fix for "random screen blanking" using a RV280 [Radeon 9200 PRO] with an Eizo FlexScan L885 with DVI. I am running xorg-x11-6.8.2-r6 on Gentoo with the radeon driver. Regarding comment 44: I have just tried out 5 new compiled radeon drivers. I changed the values in default_tmds_pll for CHIP_FAMILY_RV280 and combined this with the proposed activation of commented out code in drivers_bios.c (Thus ending up with 5 new versions) All tests failed, i.e. blanking of the screen was equal to the unchanged xorg-x11-6.8.2-r6 radeon driver. BTW, the blanking occurs randomly "from time to time" - although I am still able to work with the system but "it nerves". And it might sound odd, but screen blanking occurs also with high probability using firefox and walking through the bookmarks menu. Next I'll try the patch/fix addressed in comments 41 and 42. Patched radeon_driver.c and changed mode line as described on Constantine Sapuntzakis' web side. Could not provoke any screen blanking by walking my firefox bookmarks menu -- which was a quite reliable test so far. Furthermore up to now no random screen blanking occurred with the patched radeon version. Hence I assume that the blanking problem is solved for me. AFAIK, Constantine Sapuntzakis' patch allows that radeon_drv.o will accept modlines for DVI output. But it comments out significant code in the radeon driver. The question is: Is there already a similar fix (enabling modelines for DVI) officially available for xorg-x11? If yes, in which version will this fix be integrated? I ask because I don't feel like patching the radeon driver everytime I update the x11-xorg version on my Gentoo system. BTW, let me know if you need assistence (testing) in solving this problem without the "modeline-patch". I'll see what I can do. I have very bad DVI (1280x1024@75) flickering problems with a Radeon7000/VE PCI, too. Using xorg 6.8, those could be almost completely removed by disabling the dri module. Since 6.9, nothing (disabling dri, Display Priority, Refresh rate, ...) helped. I almost have to use 75 Hz refresh rate because otherwise, my second monitor (CRT) gets a distorted signal, fonts are "wobbly". Seems to be some kind of interference problem. But at 60Hz, the DVI problems persist... Flickering is worst using Firefox (pages with SVG make my monitor blank out completely for several seconds), OpenOffice and Nautilus. Just using xfce / terminals / mplayer / xscreensaver does very, very rarely lead to blanking. Opening http://code.google.com/webstats/2005-12/pages.html in Firefox 1.5 causes the image to shift left and right, most likely resulting in a blank display. The same applies to clicking on items in the tree view of nautilus, but it's not as bad as the page using SVG... - X Window System Version 6.9.0 (Debian 6.9.0.dfsg.1-3 20060110012652 David Nusinow <dnusinow@debian.org>) - DualHead configuration with xinerama disabled I am having blanking on my Radeon 9250 cards. I have tested four Radeon cards against this bug, and I have only been able to cause the blanking when playing a opengl game. I am using the CVS Head for the xserver, and CVS for the radeon driver, as well as for the DRI module also. These are the cards that I tested as well as the result: Radeon 7000VE : PASS, No screen blanking. Radeon 9000 : PASS, No screen blanking. Radeon 9250 128bit RAM, 256 MEG : FAIL, Screen was blanking when playing trigger, and other games. The eventual outcome if I kept playing while the screen was blanking was system lockup. If I quit the game the screen for the root window was clean. Radeon 9250 64bit RAM, 128 MEG : FAIL, Screen was blanking when playing trigger, and other games. The eventual outcome was system lockup. If I quit the game before lockup had occured the root X window had artifacts that were randomly showing up on the root window. After reading through this bug report there seems to be a little confusion as to what this bug is. To me this bug is having the screen displaying something to having nothing displayed for a second or forever. Now having read the bug report it seems that all users that have the 9200 are experiencing the same bug. Those that are using a video card other than the 9200/9250 are experiencing another bug/bugs. To me there seems to be some sort of errata with the RV280 because of the numerous reports in this report. I have used the two 9250 Cards for months using the VGA output. I experienced no screen blanking with the VGA out. All of the cads pass using the VGA output. Created attachment 5305 [details]
Xorg.0.log.screenblank
This is the Xorg log while using the Radeon 9250 128 bit RAM and 256 Meg. This
log is after the the screen had been blanking in the game trigger.
I uncommented the code that retrieves the TMDS information from the video bios in radeon_bios.c, and that fixed the screen blanking for me. I will be adding the comments in a couple of days to retrieve the RADEON_BIOS8 values. I have only tested on one of the Radeon 9250's, but I will be testing the other one with the same modification and sprinkling ErrorF()'s to read values. Thanks Benjamin for the suggestion. I was looking at the code, and I don't know why I would want to get the value of RADEON_BIOS8(tmp), and write it to X log file with ErrorF's. The section of code that was commented out required that that variable be 4, and so since that does fix the flickering/blanking problem I don't know why I want to put in printf's. I would like some more insight to this. uncommenting the else if (RADEON_BIOS8(tmp) == 4) { } in radeon_bios.c fixed the
screen flickering/blanking for both of my Radeon 9250 cards. Do you need more
information?
I changed the default_tmds_plls for the RV280 to this:
{{13000, 0x400f4}, {15000, 0x400f7}, {0xffffffff, 0x40111}, {0, 0}},
/*CHIP_FAMILY_RV280*/
This fixed the random flickering for me also. I am running the driver from CVS
head. It would be nice to see something submitted into CVS to fix this bug.
I think we need to uncomment the BIOS thing, I'll look into this. Regarding the default value in the table, it's unclear ... it may break currently working setups. *** Bug 2935 has been marked as a duplicate of this bug. *** This isn't critical enough to block the 7.1 release, moving out to 7.2. benh, I'd appreciate a status update when you get a moment. (In reply to comment #58) > This isn't critical enough to block the 7.1 release, moving out to 7.2. > > benh, I'd appreciate a status update when you get a moment. the RV280 TMDS PLL fixes are already be in cvs. Hello, I'm also having the radeon 1600x1200 DVI flickering problem, but the details are a bit different from most of the other respondents. I'm using an old "Radeon RV100 QY [Radeon 7000/VE] rev 0" PCI card in an x86_64 machine. FC5 development's xorg-x11-drv-ati-6.6.1-4.x86_64 reports that the DFP table revision is 3, so the issue with table revision 4 does not apply to this card. The problem I'm seeing is a regression: it was absent under FC4 (x.org 6.8.2) but started when I updated to FC5. Option DisplayPriority has no effect, while using a reduced blanking interval modeline (possible without patching the radeon driver using Option IgnoreEDID) significantly reduces the problem without eliminating it completely. Any suggestions on how to proceed with troubleshooting this regression? Thanks, Wayne *** Bug 7478 has been marked as a duplicate of this bug. *** I had once more a look on my DVI problem. Presently I'm running Fedora Core 5 with X.org 7.0 and the latest Fedora updates. To debug my DVI-problems I have both the DVI- and the VGA-input connected to the my Eizo FlexScan L885 panel. To get DVI-output from my Asus Radeon 9200SE card I have to use the following option in my xorg.conf file Option "MonitorLayout" "TMDS" This will only give DVI-output on resolutions lower that 1600x1200. The 1600x1200 resolution shows only on the VGA-connector with a modeline of Modeline "1600x1200@60Hz@75kHz" 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync This seems to be the modeline reported by my Eizo L885 panel and should be within the specifications of the panel. To have the DVI mode 1600x1200 visible on my Eizo L885 panel I have to use the following option in my xorg.conf file Option "PanelSize" "1600x1200" This gives me the same modeline 1600x1200@60@75kHz" 162.00 1600 1664 1856 2160 1200 1201 1204 1250 but now the image will randomly blank over the DVI-connector. The radeon man page says about the PanelSize "If you have a panel with timings different from that of a standard VESA mode, you have to provide this information through the Modeline." Inspired by the comments #31 and #32 and the experience in comments #41, #48 and #60 I also tried a Modeline with reduced blanking timing, but without patching radeon_driver.c. My first try with the line "1600x1200@60.01@75.67" 154.98 1600 1632 2016 2048 1200 1224 1236 1261 was an improvement, but the flickering was still there, so I went to Modeline "1600x1200@60" 132.0 1600 1648 1712 1820 1200 1202 1205 1207 seems to have solved the random blanking problem for me, because it has not flickered even once during three hours of testing. I will run like this for some days to really see if the blanking problem has been solved by this. I still would like to know why my ASUS Radeon 9200SE card cannot output a 1600x1200 DVI-signal without these two options? Option "MonitorLayout" "TMDS" Option "PanelSize" "1600x1200" Using Option "PanelSize" "1600x1200" has two side effects. If one wants to temporarily switch to a lower screen resolution using xrandr, then some of the lower resolutions are shifted towards one edge of the display, as in the screenshots I have posted in the beginning of this bug report and some resoultions are garbled with stripes at the edges in addition to that. The other side effect of "PanelSize" "1600x1200" is that the graphics card constantly outputs a 1600x1200 mode to the panel and the lower resolutions asked for with xrandr are scaled internally up to the output resolution of 1600x1200 by the graphics card. I guess this is the typical behaviour that one has on a laptop screen. Without the option "PanelSize" "1600x1200", the lower resolutions asked for with xrandr really switch output mode of the graphics card, so that the scaling to the panels native 1600x1200 resolution is done by the panel itself. Summary: A modeline with reduced blanking can help some flickering problems, but the problem can remain in some cases, comments #42 and #43. It seems that my blanking problem can also be solved by this. In comment #35 it is reported that reduced blanking did not help, so this could be another problem? In comment #23 it has been noted that the AGP access time can affect the blanking problem if it can be changed on the MB. Disabling DRI in comment #19 and #49 has improved things with older X.org releases, but not anymore with recent X.org releases. Changes in radeon_driver.c and radeon_bios.c suggested in comment #44 did not solve my problem, nor the problem in comment #47, but in comments #54 and #55 it is reported that this solved the problem. Is it true also for other users of Radeon cards that the options Option "MonitorLayout" "TMDS" Option "PanelSize" "1600x1200" are needed to enable DVI-output of 1600x1200? To add fuel to the fire: I've seen this problem on both NetBSD and Ubuntu with x.org, whereas this does not occur with XFree 4.x. What seems to happen is that if a large amount of data - particularly towards the top of the screen - gets redrawn, the frequency of the signal (as shown by my LCDs' status HUD) goes down by a few KHz and then goes back up. For whatever reason, the frequency seems to be a bit low - e.g. tell it to use 75khz, and when DDC is enabled it only uses 72. (Without DDC it's around 73.) As with others, disabling DRI and some accel options improves things. Created attachment 8023 [details] [review] may not fix everyone's problems but works for me not sure if this actually helps with this bug, I've some feeling it might only fix a more recent regression. However, without it I can't get tmds resolutions with pixel clocks between roughly 90Mhz and exactly 155Mhz (where another set of tmds parameter values gets used) at all. The reason being that some tmds values (in particular TMDS_TRANSMITTER_CNTL) which the driver only is supposed to change some bits end up unitialized (0), which seems to work only with some luck... I did not see any random blanking though, it either worked or the monitor didn't sync at all. Note there might be a more elegant solution to this, for exactly this problem a simple INREG certainly would do, but I didn't check if other functions called in ModeInit could suffer from similar issues. I should probably add my own "fix" to this problem. For me, I was able to get my display to be absolutely rock solid if I forced it to run with a reduced blanking modeline that was slightly less than 60HZ. This was not easy, but comparing the X server source code to the errors I got along the way eventually let me pick a path through the code that did what I wanted. Full story here: http://home.att.net/~Tom.Horsley/easy-linux.html Now that the VESA spreadsheet algorithm is included in the server source code, it would sure be nice if there was a new way to specify modeline info added where all I had to tell it was width, height, refresh rate, and optional flags (like reduced blanking). Using a Samsung 213T with a Radeon 9200SE connected via DVI at 1600x1200x60 here. System is a P4 Northwood on i875, HT disabled, Debian unstable, stock kernel 2.6.18.2. I had occasional blanking and interference/noise especially when moving the mouse pointer over an image in GIMP, but also during any operations in OpenOffice that caused large redraws. Tonight I tested with a Radeon 7000 PCI, same problem except the interference was even more pronounced. Changing modelines, reduced blanking etc. didn't help at all. What fixed it right while X was running was loading the Radeon DRM kernel module. It seems to do some kind of initialization that's otherwise missing. It can be unloaded again immediately, the effect will stay. Display is rock stable now. We had the blanking problem with about 40 cards when using Fedora Core 3 (which is xorg 6.8.2 based). We solved the issue with the reduced blanking (rb) method described above. We used rb modelines after patching the driver to accept them. Now we switched to Fedora Core 6, which uses xf86-video-ati rel 6.6.3. The blanking reappeared and even with the rb method (after patching the driver) the problem remained. For a few of our workstation we were able to reduce the problem by lowering the refresh rate below 60 Hz, but not all displays accept this. We also tried the latest git of xf86-video-ati with no success. So the current driver behaves worse in this respect than older releases. This is a regression against the 6.8.3 release. Is there any help or can anyone describe what could possibly lead to this worse behaviour? (In reply to comment #67) > Is there any help or can anyone describe what could possibly lead to > this worse behaviour? Did you try to use the DRM module? What I forgot to write; I had no problems at all with older X versions, this appeared only a few months ago after upgrading to the latest Xorg from Debian Unstable. I had never needed reduced blanking, on the contrary I used a modeline with 170 MHz pixel clock at 1600x1200 for years with this screen and card. I'm using OpenOffice.org all day right currently and I haven't had a single issue since "modprobe radeon". (In reply to comment #68) > (In reply to comment #67) > Did you try to use the DRM module? Thanks for you reply. No, I did not tried yet - I have found another solution (see next comment). I will check the DRM module next. Thanks again... Sorry to reply to myself in response to comment #67 (my last post): In git-commit 2b0cdd9448a24ea067b0d78f319b99c1041df2e0 of module xf86-video-ati a change was committed which enabled the retrieving the tmds-pll-config-values from the BIOS. The same commit also changed the default tmds-pll-init-values. When disabling the BIOS-sequence, our blanking problem disappeared (mostly) and we got the former (better) behaviour back. So it seems, getting the info from the BIOS is not fully reliable (at least for our cards). I left the changed default tmds-pll-init-values as defined in the commit mentioned above. I am more than willing to help in debugging this problem (we have a rather big "testbed") but need some hints what the tmds-init-values mean and how the BIOS sequence is expected to work. Thanks to the author of comment #44 which gave the important hint. It isn't as simple as it sounds. What is needed is the bios, and r250 chip revision for the graphics card. There may have been a bug in some of the early revisions. (In reply to comment #71) > It isn't as simple as it sounds. What is needed is the bios, and r250 chip > revision for the graphics card. There may have been a bug in some of the early > revisions. Please be sure, that I do not believe that its simple (there are 72 comments for this bug :-). I can only add our observation and share our experience. Most of our cards are RV 280 (not 250) and some of them were bought a few weeks ago (we buy them because they need no fan), so probably are not an early revision. I checked they have the table version 4, so the BIOS sequence is used for them (when enabled). We have about 45 cards and about 2/3 of them (bought from different vendors at different times) have problems when the BIOS sequence is enabled. Whatever that means for other owners of such cards... Created attachment 8437 [details] [review] print out the tmds table (In reply to comment #70) > Sorry to reply to myself in response to comment #67 (my last post): > > In git-commit 2b0cdd9448a24ea067b0d78f319b99c1041df2e0 of module > xf86-video-ati a change was committed which enabled the retrieving > the tmds-pll-config-values from the BIOS. The same commit also changed > the default tmds-pll-init-values. > > When disabling the BIOS-sequence, our blanking problem disappeared > (mostly) and we got the former (better) behaviour back. So it seems, > getting the info from the BIOS is not fully reliable (at least for our > cards). I left the changed default tmds-pll-init-values as defined in > the commit mentioned above. > > I am more than willing to help in debugging this problem (we have > a rather big "testbed") but need some hints what the tmds-init-values > mean and how the BIOS sequence is expected to work. Could you print out the table (the values as retrieved from the bios) using the attached patch? Basically, the tmds init values are "magic numbers" used to program the tmds pll, it seems different values are optimal for different pixel clocks. Actually, I had a problem with those values too, though the bios-supplied ones and the default ones were identical for me, but the monitor would switch off in a very short time if some 3d activity was on. Turns out it works just well if I used the values intended for a very slightly higher pixel clock (155Mhz and higher, whereas the actual pixel clock was 154Mhz). In any case, fglrx had the same problem. I suspect the values need to differ depending on the external components of a card, if someone wouldn't use reference layout, but that's just a guess. (In reply to comment #71) > There may have been a bug in some of the early > revisions. I have the same problem with an RV280 and a VE (Radeon 7000 PCI), completely different cards. (In reply to comment #73) > Basically, the tmds init values are "magic numbers" used to program the tmds > pll, it seems different values are optimal for different pixel clocks. If this is by any means relevant, how come that I had no problem ever with any pixel clock values in XFree86 and older Xorg versions? And that I also have no problems at all now after building and loading the DRM module (which is a ~1 minute task so I wonder why you didn't just do it). (In reply to comment #74) > > Basically, the tmds init values are "magic numbers" used to program the tmds > > pll, it seems different values are optimal for different pixel clocks. > > If this is by any means relevant, how come that I had no problem ever with any > pixel clock values in XFree86 and older Xorg versions? And that I also have no > problems at all now after building and loading the DRM module (which is a ~1 > minute task so I wonder why you didn't just do it). Not all people here might suffer from the same issue actually, just the same symptoms. One issue seems to be display buffer underflow, which I suspect is what you got since enabling the dri/drm (and thus using cp accel instead of mmio) changes timing/latency considerably. It would actually be possible to detect such underflows so we'd know if that actually was the problem in a specific case. Obviously, some people do not suffer from that (otherwise changing the tmds_pll values wouldn't make any difference), and enabling dri will not make any difference there (unless the driver has some really bad bug and programs the tmds registers differently depending on that). I can't talk for the others but I certainly had the drm module loaded (well I mentioned running 3d apps...), though not everyone can do that (not supported with all OS). (In reply to comment #75) > One issue seems to be display buffer underflow, which I suspect is > what you got since enabling the dri/drm (and thus using cp accel instead of > mmio) Point taken, should have read up more on this. Comment #40 about the different code paths explains it. What's odd though is a problem with buffer underruns showing itself in "analog looking" interference and the screen position moving by 1 or 2 pixels, instead of just plain blanking. That would mean buffer underruns can cause TMDS signalling problems? I can add some anecdotes for what they are worth: I have a Sapphire X700 PCI express (identified by X as RV410 chipset). I had once in a blue moon flickering problems in Fedora Core 5 with xorg 7.0, which changed to a couple of times a second with Fedora Core 6 and xorg 7.1. I got the flickering to stop by (painfully) forcing X to use a refresh rate lower than 60HZ. Comment #65 points to the details on my solution. However, the problem is not isolated to linux. I have Windows XP on this same machine, and in every version of Catalyst I've installed, I see occasional flickering just like X had (only not as frequent on XP). Weirdly, the flickering seems to be related to the actual contents of the screen. The mostly light purplish-blue screen that XP uses at login has never flickered. I changed my screen background from the default green fields and hills to a solid purplish-blue about like the login, and the flickering doesn't happen anymore till I run some app that paints something it doesn't like. The worst I've seen is adobe photoshop. When it came up initially in full screen with the sorta tan colored background it uses, it took forever to see enough of the cursor between blinking on and off to drag a corner down so it didn't fill the whole screen and get the flickering to stop. Even after the flickering mostly stopped, pulling down a menu in photoshop would almost always trigger an instant flicker attack which would go away just as instantly when I hit ESC to close the menu. I'm pretty sure I remember it being somewhat screen content sensitive in X as well till I found my refresh rate solution, but I don't remember anything under X that was as dramatic or reproducable as photoshop under windows. (In reply to comment #73) > Created an attachment (id=8437) [edit] > print out the tmds table > Could you print out the table (the values as retrieved from the bios) using the > attached patch? I used the following patch the print the table values (so I skipped the modification of the actual values, only printing the BIOS values) @@ -576,8 +576,11 @@ n = RADEON_BIOS8(tmp + 5) + 1; if (n > 4) n = 4; for (i=0; i<n; i++) { - info->tmds_pll[i].value = RADEON_BIOS32(tmp+stride+0x08); - info->tmds_pll[i].freq = RADEON_BIOS16(tmp+stride+0x10); + /* info->tmds_pll[i].value = RADEON_BIOS32(tmp+stride+0x08); */ + /* info->tmds_pll[i].freq = RADEON_BIOS16(tmp+stride+0x10); */ + xf86DrvMsg(pScrn->scrnIndex, X_INFO, + "tmds entry %d value 0x%x freq %d\n", + i, RADEON_BIOS32(tmp+stride+0x08), RADEON_BIOS16 (tmp+stride+0x10)); if (i == 0) stride += 10; else stride += 6; } and got for about 25 cards the same result: (II) RADEON(0): PLL parameters: rf=2700 rd=12 min=20000 max=40000; xclk=20000 (II) RADEON(0): DFP table revision: 4 (II) RADEON(0): tmds entry 0 value 0x1fa0191 freq 15500 (II) RADEON(0): tmds entry 1 value 0x1fa0191 freq 20000 (II) RADEON(0): tmds entry 2 value 0x4e20000c freq 0 Hope this helps. Please let me know when I can give more info (In reply to comment #78) > I used the following patch the print the table values > (so I skipped the modification of the actual values, only printing > the BIOS values) Ah sorry for that. I missed that the patch actually was for table rev. 3 only and not for 4. > and got for about 25 cards the same result: > > (II) RADEON(0): PLL parameters: rf=2700 rd=12 min=20000 max=40000; xclk=20000 > (II) RADEON(0): DFP table revision: 4 > (II) RADEON(0): tmds entry 0 value 0x1fa0191 freq 15500 > (II) RADEON(0): tmds entry 1 value 0x1fa0191 freq 20000 > (II) RADEON(0): tmds entry 2 value 0x4e20000c freq 0 > > Hope this helps. Please let me know when I can give more info These values strongly suggest that indeed the decoding of dfp table rev. 4 is incorrect. entry 2 is clearly garbage, though shouldn't matter, as entry 1 is good for up to 200Mhz (which is already higher than the 165Mhz official limit of tmds). But even the first two entries seem very fishy to me, as they are very different to the default rv280 values (see the default_tmds_pll table). It _could_ be different due to a different chip revision or different card reference design, but even then it wouldn't really make sense to include two identical entries in the bios. Looks like a broken BIOS indeed. The initial code drop from ATI just ignored tables version 4, though when I ask Hui why, he said he had problem with pre-production cards, but would expect production ones to work. I suppose OEMs screwed up as usual... Not sure what best to do here... not using the tables version 4 will break other people with perfectly good tables. Maybe we can find a way to sanity check them... Created attachment 8821 [details]
Radeon driver without bios tables rev. 4, x86-32
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future. I'm presently running with reduced blanking on my ASUS Radeon 9200 SE/TD card as described in comment #62 since September last year. xvidtune -show "1600x1200" 132.00 1600 1648 1712 1820 1200 1202 1205 1207 With this setting the blanking occurs of the order of once every week or once every second week in ordinary desktop usage. If I run GoogleEarth then the flickering frequency increases to a few times per minute. So the problem is not solved completly by using reduced blanking and it can be worsened by increased activity on the graphics card. Now I run Fedora Core 6 with kernel 2.6.18-1.2869.fc6 and X Window System Version 7.1.1. I tested also a Connect3D Radeon 9200 C3D-6028 in my machine, but I had even more problems with it than with my Asus card. There was more flickering and I could not reduce it to the present level as with the Asus card using reduced blanking. The largest stable display size that I could achieve was 640x480 over the DVI cable. Using reduced modelines sometimes resulted in videomodes reported to be in error by my monitor. I had the warnings pixel clock 79 Mhz flashed in red pixel clock 170,6 Mhz flashed in red by my Eizo L885 monitor. I also tested a Sapphire Radeon 9200SE PCI card. I could see the flickering problem on it too, but less frequently. Getting the resolution 1600x1200 over DVI did not require the options MonitorLayout and PanelSize in the xorg.conf file, so this card is much better in this respect, but the performance is not so good because it is a PCI card. Move to 7.3 tracker. I'd be happy to snail-mail one of the affected cards to whomever, if that'd help things along. Maybe it's late and I don't read the code correctly, but it seems like the "revision 4" code appears twice at the end of the current radeon_bios.c, once uncommented and once commented. Why is that? Some bioses may have bogus tmds pll data. We may want to add some verification or fall back to the default values in certain cases. An option to ignore the bios values may be worthwhile too. Short update wrt flickering problem of my radeon card. (VGA compatible controller [0300]: ATI Technologies Inc RV280 [Radeon 9200 PRO] [1002:5960] (rev 01)) I reported the problem begining of last year. I tried almost all fixes/workarounds found here and elsewhere but finally had to stick to the analog output to avoid flickering on an Eizo FlexScan L885. Meanwhile I have another screen. It is an Eizo FlexScan S2000. (1) On the new screen I can use the Radeon 9200 with DVI w/o any flickering! (2) Furthermore I have another Gfx card (VGA compatible controller [0300]: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] [1002:5b60]) It works perfectly with DVI on the older L885. (even w/o reduced blanking modeline or such) In fact I run each card with dual screen using both monitors w/o problems. The only thing that is not working is the combination of Radeon9200+DVI+FlexScan\ L885. This makes me think that just certain hardware combinations suck. It's not the radeon card not just the monitor that caused that flickering. This is dissatisfying but I don't care anymore ... And I think that certain monitors (e.g. Samsung 204B and Eizo L885) are less tolerant to the signal quality on the DVI input. I believe this should be fixed in ati git master or the ati 6.7.x releases. The driver uses the edid modes directly, and there is even the option to toggle the which tmds pll table to use via an output attribute. Beyond that, I don't think there's much more we can do. My flakey boards are all working fine now with ati git master. Clearing blocker status. Other release managers have deemed it non-blocker for their releases, and I agree that it doesn't appear common and severe enough for this status. Well, I have Fedora 8 now with xorg-x11-drv-ati-6.7.195-3.fc8 and 6.7 don't fix my flickering problem :-). Works fine when I boot up, but if I let the dpms stuff turn off the monitor, when it turns back on it starts to flicker on and off and eventually either completely loses the signal or gets a signal out of range. I had previously worked around this by providing my own mode line to operate as slightly less than 60HZ, but with the new an improved version of X it is looking quite difficult to get it to acknowledge that I even specified a ModeLine at all. DOH! Despite the other folks who chimed in here with apparently identical problems, I have finally discovered that the problem for me resides, not in the radeon card or driver, but in the DVI2 input of my monitor. If I use DVI1, the problems disappears. The flickering problem became tolearable (about a flickering event once a week or so) after I configured a modeline with reduced blanking as described in Comment #64. I changed the the stock DVI cable that came with my Eizo FlexScan L885 to a Dual link DVI cable. This fixed the remaining flickering problem for me. Changing cables is probably worth doing for everyone with DVI flickering problems. I have now a new PC with a Nvidia graphics card and the old PC with the Radeon card is taken out of usage, so from my point of view this bug could be closed, but apparently there are many others with remaining flickering problems. (In reply to comment #95) > The flickering problem became tolearable (about a flickering event once a week > or so) after I configured a modeline with reduced blanking as described in > Comment #64. I changed the the stock DVI cable that came with my Eizo FlexScan > L885 to a Dual link DVI cable. This fixed the remaining flickering problem for > me. FWIW, I've been using a dual-link DVI-D cable all along; my monitor wouldn't work without it. I still had the flickering/blanking issues. Three year old bug. I'm not alone :)
My setup is:
Fedora 8, xorg-x11-drv-ati-6.8.0-4.fc8
[01:00.0 0300: 1002:5961 (rev 01)] 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01)
[01:00.1 0380: 1002:5941 (rev 01)] 01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200] (Secondary) (rev 01)
monitor:
Manufacturer: IBM Model: 686e (IBM L170p)
How to reproduce:
1. in kde console (konsole) make 2 tabs
2. fill one tab with lots of text
3. second tab is empty
4. do a fast switching between these tabs
now screen starts to jump horizontally :(
sometimes lcd goes blank for 1-2 second
without user input screen in rock steady
Looks like on screen update somehow refresh rates changes (?).
Most people see this as lcd switch-off.
My xorg.conf is default (almost empty):
<=====================
# Xorg configuration created by system-config-display
Section "ServerLayout"
Identifier "single head configuration"
Screen 0 "Screen0" 0 0
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "pl"
EndSection
Section "Device"
Identifier "Videocard0"
Driver "radeon"
# Option "DisplayPriority" "HIGH"
# Option "DefaultTMDSPLL" "true"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Videocard0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
EndSection
=====================>
There are no modeline lines.
These options won't help at all:
Option "DisplayPriority" "HIGH"
Option "DefaultTMDSPLL" "true"
What could I do to help fixing this issue?
(In reply to comment #97) > > These options won't help at all: > Option "DisplayPriority" "HIGH" > Option "DefaultTMDSPLL" "true" > > > What could I do to help fixing this issue? > Does the following option help? Option "DisplayPriority" "BIOS" reboot after changing this option to ensure you are using the bios initialized values. Can you try the ati 6.9.0 release or git master? > does the following option help? > Option "DisplayPriority" "BIOS" > reboot after changing this option to ensure you are using the > bios initialized values. changed, power off - no effect > Can you try the ati 6.9.0 release or git master? tested this one: http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-6.9.0.tar.bz2 With or without 'Option "DisplayPriority" "BIOS"'... no change :( Can you attach your xorg log? Created attachment 17563 [details]
Xorg.0.log, Fedora8, xf86-video-ati-6.9.0
(In reply to comment #101) > Created an attachment (id=17563) [details] > Xorg.0.log, Fedora8, xf86-video-ati-6.9.0 > Can you try any of the other 1280x1024 modes and see if they work any better, you should have at least 4: (II) RADEON(0): Modeline "1280x1024"x60.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) RADEON(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1280x1024"x71.9 133.00 1280 1368 1504 1728 1024 1027 1034 1070 -hsync +vsync (77.0 kHz) (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) Another option would be to try a cvt mode or a reduced refresh rate. Do either of the following modes help? Modeline "1280x1024R" 90.75 1280 1328 1360 1440 1024 1027 1034 1054 +hsync -vsync Modeline "1280x1024_55.00_rb" 83.00 1280 1328 1360 1440 1024 1027 1034 1051 +HSync -Vsync Modeline "1280x1024_60.00_rb" 91.00 1280 1328 1360 1440 1024 1027 1034 1054 +HSync -Vsync Modeline "1280x1024_58.00_rb" 87.75 1280 1328 1360 1440 1024 1027 1034 1053 +HSync -Vsync Created attachment 17616 [details]
Modeline ignored
Created attachment 17617 [details]
Modeline ignored
Grabbing ModeLines from Xorg.log and setting them in xorg.conf won't work at all. They are ignored. Modified config and logfile attached. There is mode override in 'configure kdesktop / display'. But 'Apply settings on KDE startup' is off. If I set 1024x768 in xorg.conf and press ctrl+alt+backspace monitor switches to that res. Did I miss something? Lucky I can change modes (and vsync) by xrandr tool. 1280x1024@60Hz - default, screen jumps only on user input, 1280x1024@72Hz - screen jumps without user input, sometimes stops, 1280x1024@75Hz - screen jumps all the time. Underclocking video output might "solve" problem. Is it a proper soltion? (In reply to comment #105) > Grabbing ModeLines from Xorg.log and setting them in xorg.conf won't work at > all. > They are ignored. Modified config and logfile attached. I think that was a bug in xserver 1.3.0. xserver 1.3.0 also had a bug where it would reverse the sync polarity on modes from the edid. you might want to check if your xserver has been patched. > > There is mode override in 'configure kdesktop / display'. But 'Apply settings > on KDE startup' is off. > If I set 1024x768 in xorg.conf and press ctrl+alt+backspace monitor switches to > that res. > > Did I miss something? > you can also add modelines on the fly with xrandr. for example: xrandr --newmode "1280x1024R" 90.75 1280 1328 1360 1440 1024 1027 1034 1054 +hsync -vsync xrandr --addmode VGA-0 "1280x1024R" xrandr --output VGA-0 --mode "1280x1024R" > > Lucky I can change modes (and vsync) by xrandr tool. > 1280x1024@60Hz - default, screen jumps only on user input, > 1280x1024@72Hz - screen jumps without user input, sometimes stops, > 1280x1024@75Hz - screen jumps all the time. you might also try the 1280x1024@59.9Hz > > Underclocking video output might "solve" problem. > Is it a proper soltion? > It depends. lots of LCD monitors are very picky about the signal they like. the wrong combination of dividers, even though it produces the proper dotclock can make some monitors unhappy. As such some video cards need to produce a slightly different signal to make them happy in some circumstances. > Can you try any of the other 1280x1024 modes and see if they work > any better, you should have at least 4: > > (II) RADEON(0): Modeline "1280x1024"x60.0 108.00 1280 1328 1440 1688 1024 > 1025 1028 1066 +hsync +vsync (64.0 kHz) same as xrandr: 1280x1024@60Hz - default, screen jumps only on user input, > (II) RADEON(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 > 1025 1028 1066 +hsync +vsync (80.0 kHz) same as xrandr: 1280x1024@75Hz - screen jumps all the time. > (II) RADEON(0): Modeline "1280x1024"x71.9 133.00 1280 1368 1504 1728 1024 > 1027 1034 1070 -hsync +vsync (77.0 kHz) same as xrandr: 1280x1024@72Hz - screen jumps without user input, sometimes stops, > (II) RADEON(0): Modeline "1280x1024"x59.9 109.00 1280 1368 1496 1712 1024 > 1027 1034 1063 -hsync +vsync (63.7 kHz) same as xrandr: 1280x1024@60Hz - default, screen jumps only on user input, > Another option would be to try a cvt mode or a reduced refresh rate. > Do either of the following modes help? > > Modeline "1280x1024R" 90.75 1280 1328 1360 1440 1024 1027 1034 1054 +hsync > -vsync > Modeline "1280x1024_55.00_rb" 83.00 1280 1328 1360 1440 1024 1027 1034 1051 > +HSync -Vsync > Modeline "1280x1024_60.00_rb" 91.00 1280 1328 1360 1440 1024 1027 1034 1054 > +HSync -Vsync > Modeline "1280x1024_58.00_rb" 87.75 1280 1328 1360 1440 1024 1027 1034 1053 > +HSync -Vsync All of them works fine! >> Grabbing ModeLines from Xorg.log and setting them in xorg.conf won't work >> at all. >> They are ignored. Modified config and logfile attached. > I think that was a bug in xserver 1.3.0. > xserver 1.3.0 also had a bug where it would reverse the sync polarity > on modes from the edid. > you might want to check if your xserver has been patched. Could You please point to these commits in xserver tree? That would be very helpfull. > > Modeline "1280x1024R" 90.75 1280 1328 1360 1440 1024 1027 1034 1054 > > +hsync -vsync > > All of them works fine! Update. I'm using above Modeline. Blanks aren't gone. They are just less frequent. I think I'll choose cheap solution: https://bugzilla.redhat.com/show_bug.cgi?id=389041#c2 Are there still issues with ati from git master? Hello! I have the same problem on my desktop. Ubuntu version is Interpid - 8.10 I don't know what to do to slove this problem. regards Pawel My DVI problems with radeon driver were solved by adding Option "MacModel" "mini" in xorg.conf; please see: http://bugs.freedesktop.org/show_bug.cgi?id=12525#c13 However, let me know if I can help with this bug. (In reply to comment #109) > Are there still issues with ati from git master? I'm not yet sure what this is the same problem, but i see flickering and (infrequent) blanking with git version from 01/13/2009 on my 02:00.0 VGA compatible controller: ATI Technologies Inc RV515 PRO [Radeon X1300/X1550 Series] Seems what "xrandr --rate 60" help. Not sure yet what this removes problem completely for me. The original bug was fixed bug since then this bug has turned into a mess. 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.