[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJZ5v0iTu7nq9cR3iDsmf2=Nn7Z8YcvCLjvehKee+zMbV+iA7w@mail.gmail.com>
Date: Wed, 6 Feb 2019 23:44:10 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Pavel Machek <pavel@....cz>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
Ярослав Семченко
<ukrkyi@...il.com>, Greg KH <greg@...ah.com>,
kernel list <linux-kernel@...r.kernel.org>,
Thomas Martitz <kugel@...kbox.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
Johan Hovold <johan@...nel.org>,
Rafael Wysocki <rafael.j.wysocki@...el.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Len Brown <len.brown@...el.com>,
Linux PM <linux-pm@...r.kernel.org>
Subject: Re: REGRESSION - System does not resume from suspend
On Wed, Feb 6, 2019 at 11:32 PM Pavel Machek <pavel@....cz> wrote:
>
> On Wed 2019-02-06 23:19:18, Rafael J. Wysocki wrote:
> > On Wed, Feb 6, 2019 at 10:20 PM Pavel Machek <pavel@....cz> wrote:
> > >
> > > Hi!
> > >
> > > > Since kernel version 4.19, my computer is unable to resume from suspend to
> > > > RAM. I've run git bisect and filed bug report at
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=201519
> > > > three months ago, however, I received no reaction. Bug is still present in
> > > > 5.0-rc5 kernel version. Is there any possibility to fix this?
> > >
> > > Thanks for all the work bisecting / etc... Note that you can get patch
> > > reverted if it causes regression, but it needs to be done over
> > > email. (If maintainer does not reply, up-to Linus).
> > >
> > > For the record, patch is:
> > >
> > > git bisect output:
> > > c62ec4610c40bcc44f2d3d5ed1c312737279e2f3 is the first bad commit
> > > commit c62ec4610c40bcc44f2d3d5ed1c312737279e2f3
> > > Author: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > > Date: Tue May 22 13:02:17 2018 +0200
> > >
> > > PM / core: Fix direct_complete handling for devices with no
> > > callbacks
> > > ...
> > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=199693
> > > Fixes: 08810a4119aa (PM / core: Add NEVER_SKIP and
> > > SMART_PREPARE driver flags)
> > > Reported-by: Thomas Martitz <kugel@...kbox.org>
> > > Tested-by: Thomas Martitz <kugel@...kbox.org>
> > > Cc: 4.15+ <stable@...r.kernel.org> # 4.15+
> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > > Reviewed-by: Ulf Hansson <ulf.hansson@...aro.org>
> > > Reviewed-by: Johan Hovold <johan@...nel.org>
> > >
> > > And the patch was tagged for stable, which sounds like a lot of fun.
> >
> > Not really. This just restored previous behavior as the commit log says.
> >
> > If the system breaks after this one, it most likely didn't work before
> > commit 08810a4119aa which was in 4.15 and c62ec4610c40bcc44f2 first
> > appeared in 4.17-rc1.
> >
> > Unfortunately, it cannot be reverted without breaking other systems
> > that used to work before commit 08810a4119aa.
>
> So what is going on there?
>
> If some devices need one behaviour and other devices need second
> behaviour, we can just add the flag for the driver, right?
Yes.
> Because we know that Jaroslav's system can suspend, so this is fixable.
>
> Jaroslav -- can you find out which device has problem?
I have followed up in the BZ, we'll try to find the problematic device.
Powered by blists - more mailing lists