linux-kernel - Re: disabling secondary CPU hangs / system fails to suspend with kernel 4.19+

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]

Date:   Fri, 15 Mar 2019 21:21:02 +0100
From:   Thomas Müller <thomas@...htm.de>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: disabling secondary CPU hangs / system fails to suspend with
 kernel 4.19+

Hi,

Am 15.03.19 um 13:15 schrieb Peter Zijlstra:
> On Fri, Mar 15, 2019 at 12:41:00PM +0100, Thomas Müller wrote:
> 
>>> What .config do you have?
>> The one packaged by Fedora. I've attached the one for 4.20.15 as reference.
> 
> Thanks, I'll have a poke, see what, if anything, is different from the
> kernels I ran.
> 
>>> And what, if anything do you see on the
>>> console when it goes funny?
>> Nothing unfortunately.
>> When trying to suspend the display immediately goes blank, the system becomes unresponsive and the
>> status LED within the power button start flashing rapidly (just like it does when the power cord is
>> attached).
>>
>>
>>> I think you wrote that hot-un-plug never completes? Is there anything in
>>> dmesg when it's stuck in:
>>>
>>>   echo 0 > /sys/devices/system/cpu/cpu1/online
>>>
>>> ?
>> I've just tried that again and the system immediately froze.
> 
> Hmm, I tought you said the system remained semi usable, just that reboot
> stopped working thereafter and it needed a power cycle.
> 
>> `journalctl -f` was running in a second window but it had no chance to output anything... :/
> 
> Ah, you're using a GUI!
> 
> Stop doing that ;-)
Easier said than done ;)

> See if you can use the VGA console; not a FB console or a DRM console,
> but the real ancient, proper text mode, VGA console.
I've just re-tested with runlevel 3.
Not a real VGA console, but at least no Wayland or Gnome to interfere...

`echo 0 > /sys/...` just blocks and no message whatsoever is visible in dmesg.

I've executed `echo 0 > ...` in the background to keep my console functional and I can e.g. echo
something to /dev/kmsg and it shows up, so reading/updating the log buffer appears to be working
just fine.
A power cycle is still necessary to recover the system.


> Now, don't ask me how to do that, because I don't know, I've been
> running on pure serial console output for the past 10 years or so, heck
> I don't even have systemd.
> 
> And you might have to do something like: dmesg -n8, to get the console
> to print the kernel messages or something.
>