> From: <s_g...@telus.net> > Date: Wed, 30 Jan 2019 23:11:00 -0800 > > I thought I would give openbsd arm64 a try and purchased an orangepi pc2. > I followed the INSTALL directions and the install of the system went > smoothly. > I used the lan connection at 1000Mbps to load the system install packages. > > Simple things like top and df worked fine. Then I tried to add a package > which resulted in the crash detailed below. > Since the kernel on the miniroot seemed to download the installation > packages I rebooted to the > bsd.sp kernel and tested again with the same results. File systems had to be > repaired and it looks like the pkg db was corrupted also. > But the crash was very similar. See bsd.sp below. > > Has anyone have any experiences with the orangepi pc2? The documentation > suggests that it is a targeted machine. > > I noticed that the boot complains about the dtb when booting from power up: > > Scanning mmc 0:1... > Found EFI removable media binary efi/boot/bootaa64.efi > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > Scanning disks on usb... > > Is this because there is no longer a dtb on the dos partition after the > install recreates the partition? > > > > bsd.mp crash > > oppcsobsd# pkg_add nano > quirks-3.83 signed on 2019-01-17T20:44:02Z > quirks-3.83: ok > nano-3.2:libiconv-1.14p3: ok > nano-3.2:gettext-0.19.8.1p3: ok > > > > panic: amap_pp_adjref: negative reference count > Stopped at panic+0x148: TID PID UID PRFLAGS PFLAGS > C > PU COMMAND > *447051 73332 0 0x1015 0 2K perl > db_enter() at panic+0x144 > panic() at uvm_unmap_detach+0x7c > uvm_unmap_detach() at uvmspace_exec+0x1d0 > uvmspace_exec() at sys_execve+0x5a8 > sys_execve() at svc_handler+0x264 > svc_handler() at do_el0_sync+0x1b0 > do_el0_sync() at handle_el0_sync+0x74 > 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{2}> > ddb{2}> > ddb{2}> > ddb{2}> trace > db_enter() at panic+0x144 > panic() at uvm_unmap_detach+0x7c > uvm_unmap_detach() at uvmspace_exec+0x1d0 > uvmspace_exec() at sys_execve+0x5a8 > sys_execve() at svc_handler+0x264 > svc_handler() at do_el0_sync+0x1b0 > do_el0_sync() at handle_el0_sync+0x74 > handle_el0_sync() at 0x1859d328e0 > address 0x7ffffdd418 is invalid > --- trap ---
I see the exact same error on my Orange Pi PC2. It is still unclear to me if this issue is specific to that board or a generic issue with the Allwinner H5 SoC. I've never seen the error on the Allwinner A64 though.
