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