linux-kernel - Re: Resume from suspend broken in 3.15. (bisected)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140529232115.GA15301@milliways>
Date:	Fri, 30 May 2014 00:21:15 +0100
From:	Ken Moffat <zarniwhoop@...world.com>
To:	Alex Deucher <alexdeucher@...il.com>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	Dave Airlie <airlied@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Resume from suspend broken in 3.15. (bisected)

On Thu, May 29, 2014 at 10:57:20PM +0200, Daniel Vetter wrote:
> On Thu, May 29, 2014 at 10:47 PM, Alex Deucher <alexdeucher@...il.com> wrote:
> > On Thu, May 29, 2014 at 2:03 AM, Dan Carpenter <dan.carpenter@...cle.com> wrote:
> >> On Wed, May 28, 2014 at 08:26:53PM -0400, Alex Deucher wrote:
> >>> On Wed, May 28, 2014 at 7:49 PM, Ken Moffat <zarniwhoop@...world.com> wrote:
> >>> > On Wed, May 28, 2014 at 06:25:21PM +0100, Ken Moffat wrote:
> >>> >> Hi Daniel,
> >>> >>
> >>> >
> >>> >  [ correcting details, confirming that reverting this does fix the
> >>> > problem, adding Cc:s ]
> >>> >
> >>> >>  I've only started full testing of 3.15 on one of my machines now
> >>> >> that -rc7 has been released (this one had two issues in the radeon
> >>> >> code, second was fixed in rc7).  Unfortunately, suspend to RAM
> >>> >> (pm-suspend), or rather the wake-up, is broken on this box [ my
> >>> >> other two boxes are fine in rc7 ].
> >>> >>
> >>> >> Bisection identified one of your commits -
> >>> >>
> >>> >> commit 25f397a429dfa43f22c278d0119a60a343aa568f
> >>> >> Author: Daniel Vetter <daniel.vetter@...ll.ch>
> >>> >> Date:   Fri Jul 19 18:57:11 2013 +0200
> >>> >>
> >>> >>     drm/crtc-helper: explicit DPMS on after modeset
> >>> >>
> >>> >>     Atm the crtc helper implementation of set_config has really
> >>> >>     inconsisten semantics: If just an fb update is good enough, dpms state
> >>> >>     will be left as-is, but if we do a full modeset we force everything to
> >>> >>     dpms on.
> >>> >>
> >>> >>     This change has already been applied to the i915 modeset code in
> >>> >>
> >>> >> ('git show' stops at that point)
> >>> >
> >>> >  update : I've no idea what was going on there, nor for the problem
> >>> > with attempting to revert it.  I've now gone back into git,
> >>> > extracted the full commit to a file with 'git show', and then used
> >>> > git apply -R to revert it from 3.15-rc7.  That version wakes up from
> >>> > suspend to RAM, 3.15-rc7 itself did not.
> >>> >
> >>> >  Maybe I was still in git log when I thought I was on the command
> >>> > line.  Anyway, snipping git's view of my failed attempt to revert
> >>> > it, and adding Dan and Alex who were CC'd on the commit.
> >>> >
> >>>
> >>> Duplicate of:
> >>> https://bugzilla.kernel.org/show_bug.cgi?id=74751
> >>> and also reported here:
> >>> https://lkml.org/lkml/2014/5/2/388
> >>> Unless there is a good reason to keep the commit, I'd say let's just revert it.
> >>>
> >>
> >> Yes.  Let's revert it.
> >
> > The actual bad commit is 177cf92de4aa97ec1435987e91696ed8b5023130, but
> > for some reason git bisect always comes up with
> > 25f397a429dfa43f22c278d0119a60a343aa568f which has been in the tree
> > for almost a year now.  I don't know why.
> 
> Quick patch which is worth a shot before we revert 177cf.
> -Daniel
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
> index c2edb2d14030..cf5d299cc623 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1534,11 +1534,6 @@ int radeon_resume_kms(struct drm_device *dev, bool resume, bool fbcon)
>  
>  	radeon_restore_bios_scratch_regs(rdev);
>  
> -	if (fbcon) {
> -		radeon_fbdev_set_suspend(rdev, 0);
> -		console_unlock();
> -	}
> -
>  	/* init dig PHYs, disp eng pll */
>  	if (rdev->is_atom_bios) {
>  		radeon_atom_encoder_init(rdev);
> @@ -1563,6 +1558,12 @@ int radeon_resume_kms(struct drm_device *dev, bool resume, bool fbcon)
>  	}
>  
>  	drm_kms_helper_poll_enable(dev);
> +
> +	if (fbcon) {
> +		radeon_fbdev_set_suspend(rdev, 0);
> +		console_unlock();
> +	}
> +
>  	return 0;
>  }
>  
 Thanks, Daniel.

 That works for me (with -rc7) on my A4 Trinity (Radeon HD7480D).  I
also tested it on my other radeon (RS780L - Radeon 3000) and saw no
problems in suspend-resume.  If useful, you can add my tested-by.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/