Bug 60857 - Unstable display with Radeon 760G (ASUS M4A78L-M LE)
Summary: Unstable display with Radeon 760G (ASUS M4A78L-M LE)
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: i386 Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-05 10:40 UTC by Stuart Foster
Modified: 2017-10-17 17:24 UTC (History)
3 users (show)

See Also:
Kernel Version: 3.11
Tree: Mainline
Regression: No


Attachments
Screen image, dmesg ,lspci and kernel config (352.91 KB, application/unix-tar)
2013-09-05 10:40 UTC, Stuart Foster
Details
possible fix (1.54 KB, patch)
2013-09-05 13:34 UTC, Alex Deucher
Details | Diff
debugging output (782 bytes, patch)
2013-09-11 20:35 UTC, Alex Deucher
Details | Diff
Dmesg output (42.49 KB, text/plain)
2013-09-13 09:11 UTC, Stuart Foster
Details
skip_set_power_state (462 bytes, patch)
2013-09-13 13:49 UTC, Alex Deucher
Details | Diff
skip_clock_scaling (465 bytes, patch)
2013-09-13 13:50 UTC, Alex Deucher
Details | Diff
Output from dmesg from vanilla kernel 3.12-rc1 (40.26 KB, text/plain)
2013-09-17 07:44 UTC, Stuart Foster
Details

Description Stuart Foster 2013-09-05 10:40:19 UTC
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.
Comment 1 Alex Deucher 2013-09-05 13:34:26 UTC
Created attachment 107430 [details]
possible fix

Does the attached patch fix the issue?
Comment 2 Stuart Foster 2013-09-05 14:12:51 UTC
(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.
Comment 3 Alex Deucher 2013-09-05 14:24:34 UTC
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?
Comment 4 Stuart Foster 2013-09-05 16:27:27 UTC
(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.
Comment 5 Alex Deucher 2013-09-05 16:34:26 UTC
(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?
Comment 6 Stuart Foster 2013-09-05 17:53:20 UTC
(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.
Comment 7 Alex Deucher 2013-09-11 20:35:07 UTC
Created attachment 108131 [details]
debugging output

Can you attach your dmesg output with this patch applied?
Comment 8 Stuart Foster 2013-09-13 09:11:07 UTC
Created attachment 108311 [details]
Dmesg output
Comment 9 Stuart Foster 2013-09-13 09:13:47 UTC
The dmesg is from a vanilla 3.11 kernel with dpm turned on and patch kbug60857.diff applied.
Comment 10 Alex Deucher 2013-09-13 13:49:45 UTC
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.
Comment 11 Alex Deucher 2013-09-13 13:50:08 UTC
Created attachment 108331 [details]
skip_clock_scaling
Comment 12 Stuart Foster 2013-09-13 14:41:27 UTC
(In reply to Alex Deucher from comment #11)
> Created attachment 108331 [details]
> skip_clock_scaling

Both patches appear to work ok.
Comment 13 Alex Deucher 2013-09-13 15:09:31 UTC
Great.  I'll push the skip_clock_scaling patch upstream.
Comment 14 Stuart Foster 2013-09-13 15:12:07 UTC
(In reply to Alex Deucher from comment #13)
> Great.  I'll push the skip_clock_scaling patch upstream.

Ok thank you.

Stuart
Comment 15 Stuart Foster 2013-09-17 07:44:45 UTC
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 ?
Comment 16 Alex Deucher 2013-09-17 13:09:43 UTC
(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
Comment 17 Stuart Foster 2013-09-17 15:12:28 UTC
removing the radeon.agpmode=-1 from the command line enabled the radeon dpm to be initialized.
Comment 18 mirh 2017-10-17 17:24:00 UTC
Github says e40210cca98068835acd5a4fe760bf96b3a1aa48 landed in 3.12-rc2. 
Is this fixed now?

Note You need to log in before you can comment on or make changes to this bug.