Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CADU241M42pe_vFD4QriuVm_CjnpQe0LyBUDihaDkxm5k6o7X3g@mail.gmail.com>
In-Reply-To: <CADU241M42pe_vFD4QriuVm_CjnpQe0LyBUDihaDkxm5k6o7X3g@mail.gmail.com>
From:   Eric Blau <eblau@eblau.com>
Date:   Wed, 25 Sep 2019 08:04:46 -0400
Message-ID: <CADU241PET6bV=FaDN=OiX=QF13PQywSWKbOSLBkamT-iMefk6g@mail.gmail.com>
Subject: Re: [Regression] MacBook Pro - suspend does not power off - reaches
 dangerously hot temps
To:     linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Aug 12, 2019 at 5:44 PM Eric Blau <eblau@eblau.com> wrote:
>
> Hi all,
>
> I have a MacBook Pro 12,1 model where I've hit a regression since
> upgrading to 5.2.x. When I enter hybrid-sleep mode with "systemctl
> hybrid-sleep", the laptop appears to enter suspend (screen turns off
> and keyboard backlights go out) but actually is still on with the CPU
> fan powered off.
>
> When I first noticed this, I had put my laptop away in my bag and
> noticed it got extremely hot to the point of being dangerously close
> to a fire hazard. It was too hot to touch and would not resume
> successfully either from suspend or, after powering off, from
> hibernate.
>
> I've had no issues on 5.1 through 5.1.16 but every version of 5.2.x
> I've tried (5.2 through 5.2.8) has exhibited this problem. Is there a
> known regression in suspend handling in the kernel? I noticed some
> traffic about suspend and NVMe devices but I do not have an NVMe
> drive.
>
> If nobody else has reported this issue, I would be glad to do a bisect
> to help resolve it.

I guess nobody else has hit this issue. The problem still occurs with 5.3.

I started a bisect and was able to determine that the problem is not
present in 5.2 but was introduced in a later 5.2.x stable update and
is present in 5.3. I will report my results when the bisect it
complete but it takes several hybrid-sleep/resume cycles to be sure
the issue does not exist in a given commit. If anyone else is
observing this problem or has any ideas, please let me know.

Thanks,
Eric Blau