Created attachment 107428 [details] Screen image, dmesg ,lspci and kernel config I have just upgraded this machine from kernel 3.8.13 to 3.11 and I have discovered that the VGA output has become unstable (see attached). The dmesg output shows a number of issues/warnings which may be associated with the problem but that may just be speculation on my part. Please advise.
Created attachment 107430 [details] possible fix Does the attached patch fix the issue?
(In reply to Alex Deucher from comment #1) > Created attachment 107430 [details] > possible fix > > Does the attached patch fix the issue? Sorry Alex the patch made no difference.
Can you bisect? Also just to be sure, the monitor in qestion is connected to the integrated chip, not the dGPU correct? Does disabling dpm fix the issue?
(In reply to Alex Deucher from comment #3) > Can you bisect? Also just to be sure, the monitor in qestion is connected > to the integrated chip, not the dGPU correct? Does disabling dpm fix the > issue? The monitor is connected to the integrated chip on the motherboard (760G [Radeon 3000]) Disabling dpm does fix the problem (radeon.dpm=0 on lilo append line, the patch is still included). dmesg now reports: [drm] radeon: power management initialized as apposed to [drm] radeon: dpm initialized There is no mention of any power mangement on the RV516 [Radeon X1300/X1550 Series] is that correct ? The problem is present in vanilla 3.11-rc1.
(In reply to Stuart Foster from comment #4) > (In reply to Alex Deucher from comment #3) > > Can you bisect? Also just to be sure, the monitor in qestion is connected > > to the integrated chip, not the dGPU correct? Does disabling dpm fix the > > issue? > > The monitor is connected to the integrated chip on the motherboard (760G > [Radeon 3000]) Disabling dpm does fix the problem (radeon.dpm=0 on lilo > append line, the patch is still included). So disabling pdm fixes the issue? It would be nice to know if it's also fixed with dpm disabled and without the patch. > > dmesg now reports: > > [drm] radeon: power management initialized > > as apposed to > > [drm] radeon: dpm initialized > > There is no mention of any power mangement on the RV516 [Radeon X1300/X1550 > Series] is that correct ? Correct. dpm is only supported on r6xx and newer asics. > > The problem is present in vanilla 3.11-rc1. You mean 3.12-rc1?
(In reply to Alex Deucher from comment #5) > (In reply to Stuart Foster from comment #4) > > (In reply to Alex Deucher from comment #3) > > > Can you bisect? Also just to be sure, the monitor in qestion is > connected > > > to the integrated chip, not the dGPU correct? Does disabling dpm fix the > > > issue? > > > > The monitor is connected to the integrated chip on the motherboard (760G > > [Radeon 3000]) Disabling dpm does fix the problem (radeon.dpm=0 on lilo > > append line, the patch is still included). > > So disabling pdm fixes the issue? It would be nice to know if it's also > fixed with dpm disabled and without the patch. > > > > > dmesg now reports: > > > > [drm] radeon: power management initialized > > > > as apposed to > > > > [drm] radeon: dpm initialized > > > > There is no mention of any power mangement on the RV516 [Radeon X1300/X1550 > > Series] is that correct ? > > Correct. dpm is only supported on r6xx and newer asics. > > > > > The problem is present in vanilla 3.11-rc1. > > You mean 3.12-rc1? No having found that turning dpm off fixed the problem I went back to the first 3.11-rc which introduced the radeon dpm code. The problem is fixed with the patch removed and with dpm turn off.
Created attachment 108131 [details] debugging output Can you attach your dmesg output with this patch applied?
Created attachment 108311 [details] Dmesg output
The dmesg is from a vanilla 3.11 kernel with dpm turned on and patch kbug60857.diff applied.
Created attachment 108321 [details] skip_set_power_state Here are two patches to test. Test them independently and let me know if either one helps.
Created attachment 108331 [details] skip_clock_scaling
(In reply to Alex Deucher from comment #11) > Created attachment 108331 [details] > skip_clock_scaling Both patches appear to work ok.
Great. I'll push the skip_clock_scaling patch upstream.
(In reply to Alex Deucher from comment #13) > Great. I'll push the skip_clock_scaling patch upstream. Ok thank you. Stuart
Created attachment 108661 [details] Output from dmesg from vanilla kernel 3.12-rc1 Alex With the release of kernel 3.12-rc1 I took the opportunity look at the display stability of the kernel with non of the patches we discussed applied and I was surprised to see that the display was unexpectedly stable. However I am wondering if dpm is actually active for some reason and masking my original issue. The following extracts from the attached dmesg log are what give me grounds for concern: Kernel command line: BOOT_IMAGE=Trial ro root=813 nf_conntrack.acct=1 userpte=nohigh radeon.modeset=1 radeon.agpmode=-1 radeon.audio=1 iommu=pt iommu=1 radeon.dpm=1 Booting kernel: `-1' invalid for parameter `radeon.agpmode' [drm] radeon: power management initialized what do you think ?
(In reply to Stuart Foster from comment #15) > [drm] radeon: power management initialized > > what do you think ? dpm is not enabled. You should see: [drm] radeon: dpm initialized
removing the radeon.agpmode=-1 from the command line enabled the radeon dpm to be initialized.
Github says e40210cca98068835acd5a4fe760bf96b3a1aa48 landed in 3.12-rc2. Is this fixed now?