linux-kernel - Re: linux 5.12 - fails to boot - soft lockup - CPU#0 stuck for 23s!

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 19 May 2021 13:12:02 +0200
From:   Borislav Petkov <bp@...e.de>
To:     James Feeney <james@...ealm.net>
Cc:     linux-smp@...r.kernel.org, Jens Axboe <axboe@...nel.dk>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: linux 5.12 - fails to boot - soft lockup - CPU#0 stuck for 23s!
 - RIP smp_call_function_single

On Tue, May 18, 2021 at 09:58:46PM -0600, James Feeney wrote:
> Hmm - I am naively supposing that "the bisect is the bisect". No
> matter what commit initiates a problem, it's still a problem. It would
> be useful to investigate, and introspect the calling functions in the
> Call Trace. No?

I'd like to know that the source you're looking at is the same source
I'm looking at.

And yes, AFAIK, Arch kernels are simply the upstream kernels but
still...

> Attached:
> bootlog.7bb39313cd62
> bootlog.4f432e8bb15b
>
> The later with the "soft lockup" repeating four times. The kernel
> command line has loglevel=5 and console=ttyS0,115200.

Those are not the full boot messages - they should look like
dmesglog.7bb39313cd62 but probably you cannot log into the box after the
softlockup happens to dump them. That's why I meant to try the serial
connection...

Anyway, let's start somewhere.

1. Take a pristine 5.12 upstream kernel from git, build it using your
bisectconfig and try booting it with

debug ignore_loglevel log_buf_len=16M no_console_suspend systemd.log_target=null console=ttyS0,115200 console=tty0

on the kernel command line. Then save a full dmesg, if you can. If you
ocan catch ot ver serial, then that would be awesomer.

2. Use the exact same kernel but this time disable

CONFIG_X86_THERMAL_VECTOR

in its .config and do the same thing.

Send me both dmesg files then.

Thx.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg