Re: riscv64: panic: Fatal page fault in _dmamap_sync

On Tue, Apr 28, 2026 at 07:15:37PM -0700, Nick Owens wrote:
> hello,
> 
> excited by the new orangepi rv2 support i immediately installed a
> snapshot. i also have a riscv64 snapshot qemu tcg vm on my amd64 desktop
> under libvirt on linux, and a hardware accelerated qemu vm hosted on
> milk-v megrez also under libvirt on linux.
> 
> i setup dpb with an nfs share mounted for /usr/ports, and started
> building a few things. the vm in the megrez is the dpb host, and tcg vm
> and the orangepi rv2 are dpb workers.
> 
> the first oddity that only happened on the orangepi rv2 is that some
> port source files would get corrupted when extracted. this only happned
> to one file and not on every run. here is an example for archivers/zip:

oops

> --- zip30/crc32.c	Sun May  4 09:51:40 2008
> +++ /usr/ports/pobj/zip-3.0/zip30/crc32.c	Sun May  4 09:51:40 2008
> @@ -384,11 +384,9 @@
>      0xe9c6f9b3L, 0x8ca1450bL, 0x620ef019L, 0x07694ca1L, 0xbe519b3cL,
>      0xdb362784L, 0x35999296L, 0x50fe2e2eL, 0x99b95426L, 0xfcdee89eL,
>      0x12715d8cL, 0x7716e134L, 0xce2e36a9L, 0xab498a11L, 0x45e63f03L,
> -    0x208183bbL, 0x7691e0e3L, 0x13f65c5bL, 0xfd59e949L, 0x983e55f1L,
> -    0x2106826cL, 0x44613ed4L, 0xaace8bc6L, 0xcfa9377eL, 0x38417fd6L,
> -    0x5d26c36eL, 0xb389767cL, 0xd6eecac4L, 0x6fd61d59L, 0x0ab1a1e1L,
> -    0xe41e14f3L, 0x8179a84bL, 0xd769cb13L, 0xb20e77abL, 0x5ca1c2b9L,
> -    0x39c67e01L, 0x80fea99cL, 0xe5991524L, 0x0b36a036L, 0x6e511c8eL,
> +    0x208183bbL, 0x7691e0e3L, 0x13f65c5bL, 0xfd59e949L, 0x983e55f���0
�M1Ð?����ŸÏsräj��������+B�����������d÷M�����������	‹������	‹/***********************************************************************/
> +/*                                                                     */
> +/* Front-end EXEC to set up linkage 0b36a036L, 0x6e511c8eL,
>      0xa7166686L, 0xc271da3eL, 0x2cde6f2cL, 0x49b9d394L, 0xf0810409L,
>      0x95e6b8b1L, 0x7b490da3L, 0x1e2eb11bL, 0x483ed243L, 0x2d596efbL,
>      0xc3f6dbe9L, 0xa6916751L, 0x1fa9b0ccL, 0x7ace0c74L, 0x9461b966L,
> 
> here there is some garbage followed by a fragment of a completely different
> file from the same distfile. i'm not sure if this is a separate issue from the
> panic.

[...]

> a little later, the rv2 panic'd with the following:
> panic: Fatal page fault at 0xffffffc000507e4e: 0xffffffc01408d000
> Stopped at      panic+0xfc:     addi    a0,zero,256    TID    PID    UID     PR
> FLAGS     PFLAGS  CPU  COMMAND
>   59831  13211     55   0x1000002          0    3  c++
>  332074  48314     73   0x1100010          0    1  syslogd
> *282201  30269      0     0x14000      0x200    4  softnet0
> panic() at panic+0xfc
> do_trap_supervisor() at do_trap_supervisor+0x1f4
> cpu_exception_handler_supervisor() at cpu_exception_handler_supervisor+0x7a
> _dmamap_sync() at _dmamap_sync+0x13a
> smte_encap() at smte_encap+0x84
> smte_start() at smte_start+0xbc
> ifq_serialize() at ifq_serialize+0x98
> taskq_thread() at taskq_thread+0x70
> proc_trampoline() at proc_trampoline+0xc
> end trace frame: 0x0, count: 6
> https://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports.  Insufficient info makes it difficult to find and fix bugs.
> ddb{4}> show panic
> *cpu4: Fatal page fault at 0xffffffc000507e4e: 0xffffffc01408d000

I think I've seen this before on my milk-v jupiter but it's not part
of the reports I extracted and sent on this ml:
https://marc.info/?l=openbsd-bugs&m=177651846230680&w=2

-- 
jca