linux-kernel - Re: [Regression] MacBook Pro - suspend does not power off

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] [day] [month] [year] [list]

Message-ID: <CADU241PET6bV=FaDN=OiX=QF13PQywSWKbOSLBkamT-iMefk6g@mail.gmail.com>
Date:   Wed, 25 Sep 2019 08:04:46 -0400
From:   Eric Blau <eblau@...au.com>
To:     linux-kernel@...r.kernel.org
Subject: Re: [Regression] MacBook Pro - suspend does not power off - reaches
 dangerously hot temps

On Mon, Aug 12, 2019 at 5:44 PM Eric Blau <eblau@...au.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