Created attachment 30679 [details] HD2400 Pro BIOS My issue here is very much similar to the issue reported in http://bugs.freedesktop.org/show_bug.cgi?id=24313 My setup is as follows: - ATI Radeon HD2400 Pro (1x DVI-I, 1x VGA, 1x HDMI) - Dell 3007WFP 30" at DVI-0 (2560x1600 @ 60Hz) - Iiyama Vision Master Pro 510 (22" CRT) at VGA-0 (1600x1200 @ 85Hz) - Kubuntu 9.04 - no KMS After upgrading the radeon driver through xorg-edgers PPA (23.10.2009) my primary display which is the big Dell LCD doesn't come up in KDM. The logs are all fine. There seems to be no problem. If I start in cloned mode the secondary display (the CRT) displays fine the 2560x1600 @60 Hz (yes it's a good one, looks a bit odd 16:10 vs. 4:3) but is usable and behaves as expected. So all things are fine on the VGA-0 connector.
Looks like you attached your vbios. Please also attach your xorg log and config. What was the last version of the driver that worked properly on your chip?
Created attachment 30682 [details] xorg.conf Sorry, yes, that was the BIOS I still had around from another bug. I don't have access to that machine atm. but will post the rest of the information as soon as I get to it tomorrow.
Created attachment 30688 [details] Xorg.0.log The last version that worked correctly was this one: 1:6.12.99+git20091022.66b194a7-0ubuntu0tormod~jaunty The version that fails is the version build later on the same day: 1:6.12.99+git20091022.e57b54da-0ubuntu0tormod~jaunty I just made another update to version: 1:6.12.99+git20091024.f0d9d80f-0ubuntu0tormod~jaunty The DVI-0 some kind of "works" when I press Alt-E at the KDM login screen. Then the display comes up, but not properly as it seems because I see corruptions of the display (not seen in screenshots) and sometimes the display goes blank and comes up again after a few seconds. It's some kind of noise that appears in single pixel lines. The corruptions occur in all colors but a single pixel seem to be either completely red, blue or green. In addition the more display content is changed the more corruptions occur up to large block corruptions and finally display going blank and coming back again (e.g. if I scroll by pages through a man page inside a 'konsole' window). I also noticed similar corruptions with the radeonhd driver. With that the display comes up immediately with a huge amount of those corruptions and if I press Alt-E then they get reduced a lot but still noticeably (although it's just green pixels and never block corruptions or display blanks). Thanx, Ancoron
The loading screen for my Kubuntu is working correctly, no corruptions. dmesg shows the following: [ 45.292920] pci 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 45.416890] [drm] Initialized drm 1.1.0 20060810 [ 45.459882] pci 0000:01:00.0: setting latency timer to 64 [ 45.460042] [drm] Initialized radeon 1.29.0 20080528 on minor 0 [ 45.461881] mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining [ 45.717494] mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining [ 45.717566] mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining [ 45.717606] mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining [ 45.829789] [drm] Setting GART location based on new memory map [ 45.845312] [drm] Loading RV610 CP Microcode [ 45.845497] [drm] Loading RV610 PFP Microcode [ 45.860424] [drm] Resetting GPU [ 45.860482] [drm] writeback test succeeded in 1 usecs [ 51.128013] virbr0: no IPv6 routers present --> Alt-E pressed (was out for a smoke in the meantime) --> [ 664.950034] [drm] Resetting GPU [ 665.037223] mtrr: no MTRR for c0000000,10000000 found [ 665.133711] mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining [ 665.133778] mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining [ 665.355718] mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining [ 665.355782] mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining [ 665.355824] mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining [ 665.387431] [drm] Setting GART location based on new memory map [ 665.402949] [drm] Loading RV610 CP Microcode [ 665.403116] [drm] Loading RV610 PFP Microcode [ 665.418032] [drm] Resetting GPU [ 665.418088] [drm] writeback test succeeded in 1 usecs Anything unusual here?
Created attachment 30691 [details] Xorg.0.log.old This might be interesting. As far as I can say this may be the first startup of KDM (although I wonder why the secondary monitor comes up properly then in the first place).
Does reverting: 4cf06dfba617529291ce4b4c306c4fc1bba110ee help?
(In reply to comment #6) > Does reverting: > 4cf06dfba617529291ce4b4c306c4fc1bba110ee > help? > No, it doesn't. And this time 'Alt-E' doesn't work either.
Can you use git bisect to track down the problematic change?
I've tracked it down to commit 66b194a78c470cb3978f310828dd96c3f3e96944. After reverting that all is fine, no corruptions, just as it should be.
(In reply to comment #9) > I've tracked it down to commit 66b194a78c470cb3978f310828dd96c3f3e96944. > > After reverting that all is fine, no corruptions, just as it should be. > Can you attach the log with that commit reverted?
Created attachment 30703 [details] Xorg.0.log with commit 66b194a78c470cb3978f310828dd96c3f3e96944 reverted
Created attachment 30745 [details] [review] don't reduce pll_out range Limiting the pll output range is a good thing in most cases as it limits the number of matching pll combinations which makes it easier on the driver to pick one that makes most monitors happy, however, your monitor seem to prefer a combination that would be limited by this. This may need to be revisited per chip family.
(In reply to comment #12) > Created an attachment (id=30745) [details] > don't reduce pll_out range > > Limiting the pll output range is a good thing in most cases as it limits the > number of matching pll combinations which makes it easier on the driver to pick > one that makes most monitors happy, however, your monitor seem to prefer a > combination that would be limited by this. This may need to be revisited per > chip family. > Thanks a lot! That works perfectly. You saved my day! :)
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.