Created attachment 375276 [details] xorg.conf used after first failures with kms in force Description of problem: An upgrade of machine running Fedora 11 with a decent video turned it into something with only two resolutions available. An output from xrandr looked like that: Screen 0: minimum 320 x 200, current 800 x 600, maximum 4096 x 4096 DVI-0 connected 800x600+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 800x600 60.3* 56.2 640x480 59.9 S-video disconnected (normal left inverted right x axis y axis) A monitor used is 'NEC AccuSync 95F' and it actually does 1600x1200 without any problems. A desired resolution to use is 1280x1024 with a decent refresh rate. A new /etc/X11/xorg.conf written with a help of system-config-display with monitor parameters turned out to be of no use as it was completely ignored and available resolutions remained as above. It is attached. Adding 'nomodeset' to boot parameters improved the situation somewhat as this time (the previous xorg.conf still present) X came up in a wanted resolution but with an awful flicker resulting from a 60Hz refresh while I happen to know that this hardware setup works fine with 85Hz (and that apparently what Fedora 11 was bringing). This time xrandr started to report: Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 3200 x 1280 DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1280x1024 59.9*+ 1280x960 59.9 1152x864 60.0 1024x768 59.9 800x600 59.9 S-video disconnected (normal left inverted right x axis y axis) None of these refresh rates is something which one would want to use. Only after asking gtf to calculate a decent Modeline and modifying xorg.conf accordingly, and with 'nomodeset', something watchable was restored. xrandr this time said that: Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 3200 x 1280 DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1280x1024_85 85.0*+ 1280x1024 59.9 1280x960 59.9 1152x864 60.0 1024x768 59.9 800x600 59.9 S-video disconnected (normal left inverted right x axis y axis) This is a distinct regression from Fedora 11 and one needs to hack xorg.conf again like many years ago. I am afraid that an "art of calculating modelines" will be probably lost on most of "regular users" (although thanks to gtf for helping with that). Version-Release number of selected component (if applicable): xorg-x11-drv-ati-6.13.0-0.11.20091119git437113124.fc12
Created attachment 375278 [details] dmesg from booting 2.6.31.5-127.fc12.i686 in a "default state" Note multiple [drm:edid_is_valid] *ERROR* Raw EDID: interspersed with radeon 0000:01:00.0: DVI-I-1: EDID invalid.
Created attachment 375279 [details] Xorg.0.log from an attempt to bring a display up with KMS in force
Created attachment 375280 [details] dmesg for 2.6.31.5-127.fc12.i686 with "nomodeset" Note nice "metacity[2757]: segfault at 1 ip 004b79e1 sp bf96aa70 error 6 in libSM.so.6.0.0[4b6000+7000]00000000e0000000 - 00000000f0000000 (reserved)" at the bottom of this file
Created attachment 375281 [details] Xorg.0.log from booting with "nomodeset" but without an express Modeline in xorg.conf
Created attachment 375282 [details] xorg.conf as ultimately used with an expressly calculated Modeline One would hope to get a "decent" refresh rate but this is apparently not the case and an "insider knowledge" is required even if HorizSync and VertRefresh are explicitely provided.
Created attachment 375283 [details] Xorg.log after boot with "nomodeset" and xorg.conf from the previous attachment
Looks like all logs aboard. Assigned to airlied, cc:d to ajax, set triaged keyword, setting status to ASSIGNED (Fedora 12) This bug has been triaged -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Michal please update to a newer kernel and report back if with lastest one KMS works or not. Thanks.
(In reply to comment #8) > Michal please update to a newer kernel and report back if with lastest one KMS > works or not. Thanks. Could you please be more specific what "a newer kernel" means in the context? The current released will do? As it happens this is not my machine or the whole setup. I can ask somebody to run some tests here, likely in two days or so, but nothing vague, like "try something", will work.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I do not have an access to that particular hardware combination anymore. A request from comment 9 was left unanswered.
(In reply to comment #11) > I do not have an access to that particular hardware combination anymore. A > request from comment 9 was left unanswered. I am very much sorry for missing on this comment. I meant just yum update --enablerepo=updates-testing. Once again, I am sorry.