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
