From: Drew Fustini <fustini@kernel.org>
To: Paul Walmsley <pjw@kernel.org>
Cc: Guo Ren <guoren@kernel.org>, Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>, Arnd Bergmann <arnd@arndb.de>,
Chen Wang <unicorn_wang@outlook.com>,
Inochi Amaoto <inochiama@gmail.com>,
Leonardo Bras <leobras@redhat.com>,
Raj Vishwanathan4 <rvishwanathan@mips.com>,
Djordje Todorovic <djordje.todorovic@htecgroup.com>,
Alexandre Ghiti <alexghiti@rivosinc.com>,
Han Gao <gaohan@iscas.ac.cn>, Yao Zi <me@ziyao.cc>,
Xiaoguang Xing <xiaoguang.xing@sophgo.com>,
Aleksandar Rikalo <arikalo@gmail.com>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org, sophgo@lists.linux.dev
Subject: Re: [PATCH V5] riscv: errata: Add ERRATA_THEAD_WRITE_ONCE fixup
Date: Tue, 2 Jun 2026 10:08:09 -0700 [thread overview]
Message-ID: <ah8N+UThw4JnOdDb@x1> (raw)
In-Reply-To: <20260421143154.1590156-1-guoren@kernel.org>
On Tue, Apr 21, 2026 at 10:31:40AM -0400, guoren@kernel.org wrote:
> From: "Guo Ren (Alibaba DAMO Academy)" <guoren@kernel.org>
>
> The early version of XuanTie C910 core has a store merge buffer
> delay problem. The store merge buffer could improve the store queue
> performance by merging multi-store requests, but when there are not
> continued store requests, the prior single store request would be
> waiting in the store queue for a long time. That would cause
> significant problems for communication between multi-cores. This
> problem was found on sg2042 & th1520 platforms with the qspinlock
> lock torture test.
>
> So appending a fence w.o could immediately flush the store merge
> buffer and let other cores see the write result.
>
> This will apply the WRITE_ONCE errata to handle the non-standard
> behavior via appending a fence w.o instruction for WRITE_ONCE().
>
> This problem is only observed on the sg2042 hardware platform by
> running the lock_torture test program for half an hour. The problem
> was not found in the user space application, because interrupt can
> break the livelock.
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
> Reviewed-by: Leonardo Bras <leobras@redhat.com>
> Reviewed-by: Inochi Amaoto <inochiama@gmail.com>
> Tested-by: Han Gao <gaohan@iscas.ac.cn>
> Tested-by: Yao Zi <me@ziyao.cc>
> Cc: Chen Wang <unicorn_wang@outlook.com>
> Cc: Xiaoguang Xing <xiaoguang.xing@sophgo.com>
> Cc: Paul Walmsley <pjw@kernel.org>
> Signed-off-by: Guo Ren (Alibaba DAMO Academy) <guoren@kernel.org>
> ---
> Changelog
>
> v5:
> - Add Acked-by: Arnd Bergmann <arnd@arndb.de> for asm/generic
> - Add Reviewed-by: Inochi Amaoto <inochiama@gmail.com>
> - Rebase on v7.0
Hi Paul,
Han Gao (revy) let me know that there is now an errata entry for 'Writes
might stick in C910/C920v1 store buffer for too long' [1].
Does that address the concern you had about documenting the errata?
Thanks,
Drew
[1] https://github.com/revyos/xuantie-c900-bugs#writes-might-stick-in-c910c920v1-store-buffer-for-too-long
WARNING: multiple messages have this Message-ID (diff)
From: Drew Fustini <fustini@kernel.org>
To: Paul Walmsley <pjw@kernel.org>
Cc: Guo Ren <guoren@kernel.org>, Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>, Arnd Bergmann <arnd@arndb.de>,
Chen Wang <unicorn_wang@outlook.com>,
Inochi Amaoto <inochiama@gmail.com>,
Leonardo Bras <leobras@redhat.com>,
Raj Vishwanathan4 <rvishwanathan@mips.com>,
Djordje Todorovic <djordje.todorovic@htecgroup.com>,
Alexandre Ghiti <alexghiti@rivosinc.com>,
Han Gao <gaohan@iscas.ac.cn>, Yao Zi <me@ziyao.cc>,
Xiaoguang Xing <xiaoguang.xing@sophgo.com>,
Aleksandar Rikalo <arikalo@gmail.com>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org, sophgo@lists.linux.dev
Subject: Re: [PATCH V5] riscv: errata: Add ERRATA_THEAD_WRITE_ONCE fixup
Date: Tue, 2 Jun 2026 10:08:09 -0700 [thread overview]
Message-ID: <ah8N+UThw4JnOdDb@x1> (raw)
In-Reply-To: <20260421143154.1590156-1-guoren@kernel.org>
On Tue, Apr 21, 2026 at 10:31:40AM -0400, guoren@kernel.org wrote:
> From: "Guo Ren (Alibaba DAMO Academy)" <guoren@kernel.org>
>
> The early version of XuanTie C910 core has a store merge buffer
> delay problem. The store merge buffer could improve the store queue
> performance by merging multi-store requests, but when there are not
> continued store requests, the prior single store request would be
> waiting in the store queue for a long time. That would cause
> significant problems for communication between multi-cores. This
> problem was found on sg2042 & th1520 platforms with the qspinlock
> lock torture test.
>
> So appending a fence w.o could immediately flush the store merge
> buffer and let other cores see the write result.
>
> This will apply the WRITE_ONCE errata to handle the non-standard
> behavior via appending a fence w.o instruction for WRITE_ONCE().
>
> This problem is only observed on the sg2042 hardware platform by
> running the lock_torture test program for half an hour. The problem
> was not found in the user space application, because interrupt can
> break the livelock.
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
> Reviewed-by: Leonardo Bras <leobras@redhat.com>
> Reviewed-by: Inochi Amaoto <inochiama@gmail.com>
> Tested-by: Han Gao <gaohan@iscas.ac.cn>
> Tested-by: Yao Zi <me@ziyao.cc>
> Cc: Chen Wang <unicorn_wang@outlook.com>
> Cc: Xiaoguang Xing <xiaoguang.xing@sophgo.com>
> Cc: Paul Walmsley <pjw@kernel.org>
> Signed-off-by: Guo Ren (Alibaba DAMO Academy) <guoren@kernel.org>
> ---
> Changelog
>
> v5:
> - Add Acked-by: Arnd Bergmann <arnd@arndb.de> for asm/generic
> - Add Reviewed-by: Inochi Amaoto <inochiama@gmail.com>
> - Rebase on v7.0
Hi Paul,
Han Gao (revy) let me know that there is now an errata entry for 'Writes
might stick in C910/C920v1 store buffer for too long' [1].
Does that address the concern you had about documenting the errata?
Thanks,
Drew
[1] https://github.com/revyos/xuantie-c900-bugs#writes-might-stick-in-c910c920v1-store-buffer-for-too-long
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2026-06-02 17:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-21 14:31 [PATCH V5] riscv: errata: Add ERRATA_THEAD_WRITE_ONCE fixup guoren
2026-04-21 14:31 ` guoren
2026-06-02 17:08 ` Drew Fustini [this message]
2026-06-02 17:08 ` Drew Fustini
2026-06-26 8:41 ` Inochi Amaoto
2026-06-26 8:41 ` Inochi Amaoto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ah8N+UThw4JnOdDb@x1 \
--to=fustini@kernel.org \
--cc=alex@ghiti.fr \
--cc=alexghiti@rivosinc.com \
--cc=aou@eecs.berkeley.edu \
--cc=arikalo@gmail.com \
--cc=arnd@arndb.de \
--cc=djordje.todorovic@htecgroup.com \
--cc=gaohan@iscas.ac.cn \
--cc=guoren@kernel.org \
--cc=inochiama@gmail.com \
--cc=leobras@redhat.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=me@ziyao.cc \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=rvishwanathan@mips.com \
--cc=sophgo@lists.linux.dev \
--cc=unicorn_wang@outlook.com \
--cc=xiaoguang.xing@sophgo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.