Kernel Panic: Oops - store (or AMO) access fault in __memset during gcc/gentoo-sources compilation on riscv64 (JH7110 / Star64)

[Vivian Wang]

[ +cc linux-riscv ]

Hi Артем,

On 5/18/26 17:15, Артем Макєєв wrote:
> On Mon, May 18, 2026 at 6:25 AM Vivian Wang <wangruikang at iscas.ac.cn> wrote:
>> I believe this is caused by some of your firmware components failing to
>> reserve the beginning of RAM for OpenSBI. This would cause crashes when
>> Linux tries to allocate that part of RAM, since OpenSBI protects itself
>> somewhat in that region with PMP. This is also consistent with your
>> reporting this as easily reproducible during heavy filesystem or
>> compilation tasks, since these tasks would use a lot of RAM for
>> computation or as filesystem cache.
> About > would use a lot of RAM <. At the moment of panic below, htop
> wrote about using 3.5G/8G.
> Yesterday I caught panic merely at the start, when make was making
> some checks (and there was "Comm: cp" in panic log)
>
> [... log removed in case of private information ]

The address is still start of RAM, and the stack trace indicates that
it's newly allocating memory, so this is still consistent with the
firmware problem where the start of memory is not reserved. It also
makes sense that it's not necessarily using all of RAM at this point,
since RAM allocation is somewhat random and not guaranteed to use the
start of RAM last.

As a side note, it would be better to reply in public, keeping Cc of the
mailing list. Your email client might have a "Reply all" or "Reply list"
button that would be suitable for this purpose. This way, all the
discussion can be recorded and benefit anyone running into a similar
problem in the future. If you have long logs where redaction of private
information might be impractical, then it may make sense to reply in
private, but that should be the special case.

Vivian "dramforever" Wang