Description of problem: ATI Radeon 7000 video cards will not reliably display high video modes such as 1600x1200 or 1920x1200 using DVI. The same modes though VGA work fine. There is a temperature dependence in the ASIC used on the video card (part number 215R6LAEA12G). Cards with other ASICs such as 215R6LAFA12E do not seem to be affected. Since DVI panels have become cheap and plentiful recently we can expect to see this problem more often as older systems are connected to new DVI monitors. Affected component: ATI Radeon 7000 video cards with AMD Part number: 102-85537-00 Or HP Part number: AH391A Steps to Reproduce: 1. Use the DVI output of the Radeon 7000 2. Use a monitor capable of displaying at least 1600x1200@60 Hz with a pixel clock of 162MHz. Determine the clock using "xrandr --verbose". Or if your version of xrandr doesn't provide this find the modeline in /var/log/Xorg.0.log and read the clock value there, OR use an oscilloscope to view DVI connector pins 23 and 24 (TMDS differential clock). 3. Apply heat to the video chip. Actual results: Failure (black screen) will often occur between 30C to 50C. Expected results: Normal video up to at least 50C. Additional info: The original design limit for the DVI output of the Radeon 7000 was 108MHz. Testing has shown 135MHz to be stable. To handle this problem, the video driver should restrict modes to at least 135MHz for these cards. Sixteen cards were tested at AMD after being returned from HP customers. All cards failed at DVI/162MHz. None of the cards failed at DVI/135MHz.
fix pushed to master: 7b01e1ee29f681bf1735ecded6445d12beeb52d8 and 6.12-branch: e8b9de06482ff792b8d7fa40ce3bc024caca62f6 I'll send out a patch for kms as well.
Argh. fixed properly in 6a363f68415d37c302151581f2a86855dba39b67.
(In reply to comment #2) > Argh. fixed properly in 6a363f68415d37c302151581f2a86855dba39b67. Because this patch eliminates the mode which has a high pixel clock, probably it can't meet Rod's requirement. Actually Rod wants to use reduced timing while mode is 1600x1200. Before, I clamped the pixel clock to 135Mhz in mode probe function, and this patch will decrease the refresh rate because pixel clock gets lower, for instance, 1600x1200@60Hz, pixel clock is 162M, when fresh rate is 50.9Hz, the pixel clock get 135Mhz, but this fresh rate (50.9Hz) may not be supported by all monitors, although a handy DELL monitor can support it.
(In reply to comment #3) > (In reply to comment #2) > > Argh. fixed properly in 6a363f68415d37c302151581f2a86855dba39b67. > > Because this patch eliminates the mode which has a high pixel clock, probably > it can't meet Rod's requirement. > > Actually Rod wants to use reduced timing while mode is 1600x1200. > > Before, I clamped the pixel clock to 135Mhz in mode probe function, and this > patch will decrease the refresh rate because pixel clock gets lower, for > instance, 1600x1200@60Hz, pixel clock is 162M, when fresh rate is 50.9Hz, the > pixel clock get 135Mhz, but this fresh rate (50.9Hz) may not be supported by > all monitors, although a handy DELL monitor can support it. > Doing that seems almost as problematic as allowing the higher clock modes to begin with. Digital monitors can be very picky about the clock they get. Seems like a better solution would be to disable modes with clocks over 135 Mhz and let the user override them with reduced-clock modes if they work with their system, then at least you should get a working monitor by default.
(In reply to comment #4) > > Actually Rod wants to use reduced timing while mode is 1600x1200. Sorry this was a bit of a miscommunication. I see that Windows Server 2003 uses a reduced blanking mode for 1600x1200@60Hz on the same equipment, so having a mode like this in Linux would be **nice to have**. But the key thing is to eliminate any DVI modes >135Mhz while still respecting the monitor EDID. I'd like to test the solution mentioned here. Cooper, can you build me a driver that would work under SLES 11 ?
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.