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]
Message-ID: <YKTygvN0QNlExEQP@zn.tnic>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ