[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6d0169ca8c9e417308d3b9f96cd0ef446ee36fe7.camel@mengyan1223.wang>
Date: Wed, 05 Jan 2022 19:51:14 +0800
From: Xi Ruoyao <xry111@...gyan1223.wang>
To: Huacai Chen <chenhuacai@...il.com>
Cc: Huacai Chen <chenhuacai@...ngson.cn>,
Arnd Bergmann <arnd@...db.de>,
Andy Lutomirski <luto@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
David Airlie <airlied@...ux.ie>,
Jonathan Corbet <corbet@....net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-arch <linux-arch@...r.kernel.org>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Xuefeng Li <lixuefeng@...ngson.cn>,
Yanteng Si <siyanteng@...ngson.cn>,
Jiaxun Yang <jiaxun.yang@...goat.com>
Subject: Re: [PATCH V5 00/22] arch: Add basic LoongArch support
On Wed, 2022-01-05 at 17:40 +0800, Huacai Chen wrote:
> Hi, Ruoyao,
>
> The problem still exists in 5.16-rc8, can you try to change
> cpu_relax() definition to smp_mb()? It seems can fix the problem.
Is there any workload which can triggers the panic? I can't trigger it
by building and testing GCC, or building the kernel anymore.
And is your "stable" issue the same one I'd encountered? To me changing
barrier() to smp_mb() may fix some deadlock, but not a panic. (I'm not
an expert on CPU architecture or kernel programming, so maybe I'm wrong
here.)
I'll put my 3A5000 machine into a loop building kernel and see if I can
trigger the panic again...
--
Xi Ruoyao <xry111@...gyan1223.wang>
School of Aerospace Science and Technology, Xidian University
Powered by blists - more mailing lists