[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <kyprjdilgyz3xgw3slnrsemptnpp6h75mipv6a3lgp2dmwqekg@s7azbepy7nu2>
Date: Tue, 15 Jul 2025 03:20:35 -0700
From: Breno Leitao <leitao@...ian.org>
To: Borislav Petkov <bp@...en8.de>
Cc: "Luck, Tony" <tony.luck@...el.com>,
"Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>, James Morse <james.morse@....com>,
"Moore, Robert" <robert.moore@...el.com>, "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "acpica-devel@...ts.linux.dev" <acpica-devel@...ts.linux.dev>,
"kernel-team@...a.com" <kernel-team@...a.com>
Subject: Re: [PATCH] ghes: Track number of recovered hardware errors
Hello Borislav,
On Tue, Jul 15, 2025 at 10:29:39AM +0200, Borislav Petkov wrote:
> We have all of that info in rasdaemon. If the machine explodes, one can simply
> read out its database from the core file.
>
> And if you don't run rasdaemon, you can read out dmesg from the vmcore where
> the errors should have been dumped anyway.
I approach this from a slightly different perspective, given my
experience overseeing millions of servers and having to diagnose kernel
problems across such a massive fleet.
To be candid, when you’re operating at that scale, kernel crashes and
hardware errors are unfortunately a common occurrence.
For instance, If every investigation (as you suggested above) take just
a couple of minutes, there simply wouldn’t be enough hours in the day,
even working 24x7, to keep up with the volume.
Thanks for the review and suggestions,
--breno
Powered by blists - more mailing lists