[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87bjwtlnqb.fsf@DESKTOP-5N7EMDA>
Date: Mon, 30 Dec 2024 13:54:36 +0800
From: "Huang, Ying" <ying.huang@...ux.alibaba.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Feng Tang <feng.tang@...ux.alibaba.com>, rafael@...nel.org, Len Brown
<lenb@...nel.org>, James Morse <james.morse@....com>, Tony Luck
<tony.luck@...el.com>, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org, Ira Weiny <ira.weiny@...el.com>, Dave
Jiang <dave.jiang@...el.com>, Dan Williams <dan.j.williams@...el.com>,
Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH] acpi/ghes: Make ghes_panic_timeout adjustable as a
parameter
Hi, Boris,
Borislav Petkov <bp@...en8.de> writes:
> On December 27, 2024 10:54:22 AM GMT+01:00, Feng Tang <feng.tang@...ux.alibaba.com> wrote:
>>There is a problem report that when debugging a hard-to-reproduce panic
>>issue, user wanted the kernel to not reboot by adding "panic=0" in
>>kernel cmdline, so that the panic context could be kept, say the panic
>>was caught randomly in the mid-night, and user hoped to check it in
>>the morning. GHES panic handler may overwrite that user setting and
>>force to reboot after 'ghes_panic_timeout'(30) seconds.
>
> Why doesn't the ghes panic handler honor a panic=0 setting?
It appears that I introduced the ghes_panic_timeout originally.
panic() is used for software errors, while ghes is used for hardware
errors. They may have different requirements. For example, it may be
OK to wait forever for a software error, but it may be better to reboot
the system to contain the influence of the hardware error for some
hardware errors. So, we introduced another knob for that.
---
Best Regards,
Huang, Ying
Powered by blists - more mailing lists