Bug 24727

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! :)