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

[Vivian Wang]

Hi Артем Макєєв,

On 5/18/26 00:45, Артем Макєєв wrote:
> Hi all. Want to say that it's my first report, so if you have
> complaints about style writing, I will be happy to read how to improve
> myself. Also I don't really good at English. Sorry beforehand.
>
> I am experiencing a consistent Kernel Panic when compiling
> sys-devel/gcc-16.1.0 AND sys-kernel/gentoo-sources-7.0.8 on a StarFive
> JH7110 (Pine64 Star64) board running Gentoo Linux.
>
> The crash occurs during compilation (or file operations like rm or
> cp), but forces the entire system into a kernel panic. It reproduces
> both with Zram enabled and disabled, and -j1..-j4 flags.
>
> Hardware: Pine64 Star64 (SoC JH7110, 8GB RAM)
> Kernel version: 6.19.12-gentoo and 7.0.8-gentoo (that I have
> crosscompiled with LLVM=1)
> Spl, opensbi, u-boot: some prebuiled LTS version

I would indeed appreciate the version information of these components,
and more details of your boot flow, because...

> [ 2119.492086] CPU: 1 UID: 250 PID: 3573 Comm: cc1plus Not tainted 6.19.12-gentoo-inori-risc-v #4 NONE
> [ 2119.492095] Hardware name: Pine64 Star64 (DT)
> [ 2119.492098] epc : __memset+0x60/0xfc
> [ 2119.492112]  ra : handle_mm_fault+0x7a0/0x100c
> [ 2119.492124] epc : ffffffff80bd1584 ra : ffffffff802123cc sp : ffffffc603ddbd40
> [ 2119.492128]  gp : ffffffff8183c798 tp : ffffffd6c7a6b000 t0 : ffffffd600000000
> [ 2119.492131]  t1 : 0000000000000001 t2 : ffffffffffffffff s0 : ffffffc603ddbe70
> [ 2119.492135]  s1 : ffffffc500000000 a0 : ffffffd600000000 a1 : 0000000000000000
> [ 2119.492139]  a2 : 0000000000001000 a3 : ffffffd600001000 a4 : 0000000000000000
> [ 2119.492142]  a5 : 0000000000000000 a6 : ffffffffffffffff a7 : 00000000001fffff
> [ 2119.492146]  s2 : ffffffff81390b88 s3 : 0000000000001255 s4 : 0000003f23ab4000
> [ 2119.492150]  s5 : ffffffd6c7a59380 s6 : ffffffff81390d24 s7 : ffffffff81390d20
> [ 2119.492154]  s8 : 0000000000000800 s9 : ffffffc603ddbde8 s10: ffffffd6c7a59380
> [ 2119.492157]  s11: 0000000000000000 t3 : 0000000000000001 t4 : 0000000000000001
> [ 2119.492160]  t5 : 0000000000000004 t6 : dead000000000040
> [ 2119.492163] status: 0000000200000120 badaddr: ffffffd600000000 cause: 0000000000000007
> [ 2119.492168] [<ffffffff80bd1584>] __memset+0x60/0xfc
> [ 2119.492175] [<ffffffff8001eb8a>] handle_page_fault+0x1a2/0x4a0
> [ 2119.492186] [<ffffffff80bd23ba>] do_page_fault+0x1e/0x3c
> [ 2119.492191] [<ffffffff80bddcf8>] handle_exception+0x148/0x156
> [ 2119.492207] Code: 1007 82b3 40e2 0797 0000 8793 00e7 8305 97ba 8782 (b023) 00b2
> [ 2119.492213] ---[ end trace 0000000000000000 ]---
> [ 2119.492219] Kernel panic - not syncing: Fatal exception in interrupt
> [ 2119.492222] SMP: stopping secondary CPUs
> [ 2119.685321] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---

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.

Well, OpenSBI itself should mark that region as reserved before
continuing onwards, but it is likely that something else in your boot
flow is failing to copy that info further to let Linux know.

I'm not sure what you mean by "pre-built LTS version", but if it's the
firmware your board shipped with, it could be lacking the code handling
this. I would appreciate if you could try out a more recent mainline
version of U-Boot and OpenSBI. See U-Boot docs [1] for details, but do
note that 2025.10 onwards no longer support firmware-on-SD-card, and you
may need to adjust your boot config to do extlinux boot (I don't know
what Gentoo does).

It would also help if you could provide these information:

  * Version information of U-Boot, OpenSBI, etc, as they would
    self-report on serial port on boot.
  * Full boot time kernel logs. It doesn't have to be all the way to the
    panic; just up to a normal startup is enough.

Vivian "dramforever" Wang

[1]: https://docs.u-boot.org/en/latest/board/starfive/pine64_star64.html