On Thu, Aug 31, 2023 at 10:28:45AM +0200, Jeremie Courreges-Anglas wrote:
>
> First kernel crash during this ports bulk build, I have rebooted the
> machine. No idea whether this is the usual memory corruption I see on
> this hardware.
>
> OpenBSD/riscv64 (riscv64-4.ports.openbsd.org) (console)
>
> login: t[0] == 0x00000033635ab000
> t[1] == 0xffffffc0005ab43e
> t[2] == 0x000000000038af62
> t[3] == 0x0000000000000000
> t[4] == 0x00000000d47cf178
> t[5] == 0x00000000ee7c6af0
> t[6] == 0x000000007c967e3f
> s[0] == 0xffffffc322730bd0
> s[1] == 0x0000000000000002
> s[2] == 0xffffffc333664210
> s[3] == 0xffffffc338961ef8
> s[4] == 0x0000000000000001
> s[5] == 0x0000000000000002
> s[6] == 0xffffffc333664210
> s[7] == 0x0000000000000012
> s[8] == 0xffffffc333664250
> s[9] == 0x0000000000000011
> s[10] == 0xffffffffffffffff
> s[11] == 0x0000000000000001
> a[0] == 0xff00ffc333bb9120
> a[1] == 0xffffffc338961f00
> a[2] == 0x0000000000000001
> a[3] == 0x0000000000000001
> a[4] == 0x0000000000000010
> a[5] == 0x0000000000000202
> a[6] == 0x0000000000000012
> a[7] == 0xffffffc023ad8f44
> sepc == 0xffffffc0005aa9a2
> sstatus == 0x0000000200000120
> stval == 0x0000004333bb9120
> scause == 0x000000000000000d
> panic: Fatal page fault at 0xffffffc0005aa9a2: 0x4333bb9120
> Stopped at panic+0x106: addi a0,zero,256 TID PID UID
> PR
> FLAGS PFLAGS CPU COMMAND
> 141098 68043 55 0x3000002 0x4000000 0 compile
> 364938 9101 55 0x1000002 0 1 meinproc5
> * 8477 5653 55 0x1000002 0 3 c++
> 74488 43163 55 0x1000002 0 2 cc
> panic() at panic+0x106
> do_trap_supervisor() at do_trap_supervisor+0x1e8
> cpu_exception_handler_supervisor() at cpu_exception_handler_supervisor+0x7a
> amap_wiperange_chunk() at amap_wiperange_chunk+0x80
> amap_pp_adjref() at amap_pp_adjref+0x23a
> amap_adjref_anons() at amap_adjref_anons+0xbc
> uvm_unmap_detach() at uvm_unmap_detach+0x6a
> sys_munmap() at sys_munmap+0x108
> svc_handler() at svc_handler+0x28a
> do_trap_user() at do_trap_user+0x15c
> cpu_exception_handler_user() at cpu_exception_handler_user+0x7c
> end of kernel
> end trace frame: 0xd47cef4a, count: 4
>
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
I looked into this a little bit but noticed my QEMU riscv64 is just too slow.
One thing I noticed is that the state of objdump is horrendous on the RV64
systems if given the go-ahead I'd like to look into this, but I can only find
time in 2 weeks.
oceans# pkg_info -E /usr/local/riscv64-unknown-elf/bin/objdump
/usr/local/riscv64-unknown-elf/bin/objdump: riscv-elf-binutils-2.40p1
riscv-elf-binutils-2.40p1 binutils for riscv-elf cross-development
I'm using this one since the one in base is unuseable. Also in the riscv
port objdump they mix up add op codes with addi op codes, ie.
oceans# grep f8840513 kernel.dump | head
ffffffc00023c74c: f8840513 add a0,s0,-120
ffffffc0002470e8: f8840513 add a0,s0,-120
these are definitely addi op codes as this test program shows:
int
main(void)
{
u_long var = 0xf8840513;
if ((var & 0x707f) == 0x13)
printf("if you see this it's an addi op code\n");
if ((var & 0xfe00707f) == 0x33)
printf("if you see this it's an add op code\n");
}
Best Regards,
-peter
--
Over thirty years experience on Unix-like Operating Systems starting with QNX.
