Received-SPF: pass (google.com: domain of linux-kernel+bounces-127739-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Tue, 2 Apr 2024 12:34:14 +0200
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: "John B. Wyatt IV" <jwyatt@redhat.com>
Cc: John Ogness <john.ogness@linutronix.de>, Petr Mladek <pmladek@suse.com>,
	Clark Williams <williams@redhat.com>,
	Juri Lelli <jlelli@redhat.com>, Derek Barbosa <debarbos@redhat.com>,
	Bruno Goncalves <bgoncalv@redhat.com>,
	"John B. Wyatt IV" <sageofredondo@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-rt-users <linux-rt-users@vger.kernel.org>
Subject: Re: NMIs reported by console_blast.sh with 6.6.20-rt25
Message-ID: <20240402103414.KkkX5RuV@linutronix.de>
References: <ZfSfrzak9WS0ZFv7@thinkpad2021>
 <20240322122921.U3WRsO4X@linutronix.de>
 <ZgSvVCDja6yFCC0Y@thinkpad2021>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <ZgSvVCDja6yFCC0Y@thinkpad2021>

On 2024-03-27 19:44:20 [-0400], John B. Wyatt IV wrote:
> > where is this output from? The `ret' opcode usually does not cause a
> > trap. My guess is that the machine has been interrupted by an external
> > user at this position.
>=20
> Just before the sysrq that crashes the system.

so this is intentional.

=E2=80=A6
> > Side note: This is using early_printk, correct?
>=20
> I believe so, but it might be preempted? This is the part it stopped in.
>=20
> static void io_serial_out(unsigned long addr, int offset, int value)
> {
> 	outb(value, addr + offset);
> }

The function is invoked in NMU context so it can't be preempted.

> > According to this, someone issued a `crash' via sysrq. Why?
> >=20
>=20
> This is part of the console_blast.sh script that John Ogness sent me.
>=20
> Please see below:
=E2=80=A6

Okay. Then everything works as it should=E2=80=A6

> > > NMI Backtrace for 6.6.20-rt25 no forced preemption with tuned through=
put-performance profile
> > > -----------------------------
> >=20
> > This and the following backtrace shows the same picture: The CPU is
> > crashing due to proc/sysrq request and does CPU-backtraces via NMI and
> > polls in early_printk, waiting for the UART to become idle (probably).
> >=20
> > I don't see an issue here so far.
>=20
> Luis Goncalves discussed it with me after reading your response. Thank
> you for your help. The NMI was needed to flush the buffers upon the
> system crashing itself. Does this part about NMI watchdog need to be
> documented?

Not sure about that one. There is an _a_ _lot_ to be printed from NMI
and the NMI watchdog might trigger if nothing is triggering the
NMI-watchdog during the print job. Also, the crash was requested.

Sebastian