[Regression] MacBook Pro - suspend does not power off - reaches dangerously hot temps

[Regression] MacBook Pro - suspend does not power off - reaches dangerously hot temps

[Eric Blau]

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.

Thanks,
Eric Blau

Re: [Regression] MacBook Pro - suspend does not power off - reaches dangerously hot temps

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

Hi!

You may want to cc maintainers...

M:      "Rafael J. Wysocki" <rjw@rjwysocki.net>
M:      Pavel Machek <pavel@ucw.cz>
L:      linux-pm@vger.kernel.org

> 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.

If you are able to push the CPU over 100C, it is a hardware
bug. Hardware should protect itself.

> 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.

You may want to try latest 5.3-rc and -next... And perform basic
debugging such as making sure that normal suspend works and normal
poweroff works.

But yes, if you can bisect it, it will make stuff easy...

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [Regression] MacBook Pro - suspend does not power off - reaches dangerously hot temps

[Eric Blau]

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