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]
Message-ID: <2b1c85d3-d94b-1593-e30a-a32d97043579@mathtm.de>
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.
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ