[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZbvktYF7Oi53qpjx@a4bf019067fa.jf.intel.com>
Date: Thu, 1 Feb 2024 10:36:37 -0800
From: Ashok Raj <ashok.raj@...el.com>
To: Linux regressions mailing list <regressions@...ts.linux.dev>
CC: Mike Rapoport <rppt@...nel.org>, Linus Torvalds
<torvalds@...ux-foundation.org>, LKML Mailing List
<linux-kernel@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...el.com>, "Ingo
Molnar" <mingo@...nel.org>, Song Shuai <songshuaishuai@...ylab.org>, "Ashok
Raj" <ashok.raj@...el.com>
Subject: Re: [REGRESSION] Platforms supporting SGX fail to kexec due to
96c6b8f212a ("memblock: report failures when memblock_can_resize is not
set")
Hi Mike,
On Thu, Feb 01, 2024 at 11:38:38AM +0100, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 31.12.23 08:26, Mike Rapoport wrote:
> > On Thu, Dec 28, 2023 at 04:33:49PM -0800, Ashok Raj wrote:
> >> 96c6b8f212a ("memblock: report failures when memblock_can_resize is not set")
> >>
> >> Causes kexec failure. Backing out this change, kexec succeeds. Symptom is
> >> it appears to hang, possibly hung at the panic. Although I have the
> >> earlyprintk enabled, I don't see any console messages when new kernel
> >> boots.
> >>
> >> Also tested turning off CONFIG_X86_SGX, the kernel with this commit
> >> included also kexec's fine.
> >>
> >> Booting from warm/cold reset has no issues. Only kexec to new kernel with
> >> this change included and CONFIG_X86_SGX=y causes the kexec failure.
> >
> > Can you add memblock=debug to the kernel command line and send logs for
> > normal boot and kexec with CONFIG_X86_SGX=y and e96c6b8f212a reverted?
>
> Ashok, you afaics never replied. Did you forget about it? Or was the
> issue resolved later or never a regression in the first place? I for now
> assume it's one of the latter and stop tracking this:
Sorry I went AWOL on this.. I did try the newer kernel's (6.8-rc1) and its not
happening any more, and kexec seems to work well.
On the same problem kernel adding memblock=debug make it dissappear, and
even adding some code to that suspect area changed behavior.
I'm not able to reproduce it again. Sorry for the delay.
Cheers,
Ashok
Powered by blists - more mailing lists