crashes on orangepi pc2

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

crashes on orangepi pc2

s_graf
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 ---



ddb{2}> ps
   PID     TID   PPID    UID  S       FLAGS  WAIT          COMMAND
*73332  447051  66123      0  7      0x1015                perl
 66123  301648  69755      0  3        0x93  wait          perl
 69755  400945  48651      0  3    0x10008b  pause         ksh
 48651  495874      1   1000  3    0x10008b  pause         ksh
 35558  423930      1      0  3    0x100098  poll          cron
 35507  486900      1     99  3    0x100090  poll          sndiod
 93542  173791      1    110  3    0x100090  poll          sndiod
 76660  188425   5928     95  3    0x100092  kqread        smtpd
 24534  223432   5928    103  3    0x100092  kqread        smtpd
 55986  404358   5928     95  3    0x100092  kqread        smtpd
 40304  117938   5928     95  3    0x100092  kqread        smtpd
 43487  257183   5928     95  3    0x100092  kqread        smtpd
 81531   16489   5928     95  3    0x100092  kqread        smtpd
  5928  166887      1      0  3    0x100080  kqread        smtpd
 63142  460171      1      0  3        0x80  select        sshd
 76618  493288  47025     83  3    0x100092  poll          ntpd
 47025  467628  71748     83  3    0x100092  poll          ntpd
 71748  323042      1      0  3    0x100080  poll          ntpd
 70311  170700  62331     74  3    0x100092  bpf           pflogd
 62331  318256      1      0  3        0x80  netio         pflogd
 97516  362922  57122     73  3    0x100090  kqread        syslogd
 57122  197764      1      0  3    0x100082  netio         syslogd
 32500   70571  31883    115  3    0x100092  kqread        slaacd
 70918  419781  31883    115  3    0x100092  kqread        slaacd
 31883  181933      1      0  3    0x100080  kqread        slaacd
 20531  497351      0      0  3     0x14200  pgzero        zerothread
 53695   30102      0      0  3     0x14200  aiodoned      aiodoned
 69049   52407      0      0  3     0x14200  syncer        update
 50364   59551      0      0  3     0x14200  cleaner       cleaner
 90564  514760      0      0  3     0x14200  reaper        reaper
 82380   94116      0      0  3     0x14200  pgdaemon      pagedaemon
 84148  309419      0      0  3     0x14200  bored         crynlk
 85699  195231      0      0  3     0x14200  bored         crypto
 56966  328136      0      0  7  0x40014200                idle3
 87184  510810      0      0  3  0x40014200                idle2
  4599   25775      0      0  7  0x40014200                idle1
  2911  126482      0      0  3     0x14200  usbtsk        usbtask
 80146  290413      0      0  3     0x14200  usbatsk       usbatsk
 49983   41787      0      0  3     0x14200  mmctsk        sdmmc0
 73044   12145      0      0  3     0x14200  bored         softnet
 77270  495746      0      0  3     0x14200  bored         systqmp
 86500  235751      0      0  3     0x14200  bored         systq
 51546  302611      0      0  3  0x40014200  bored         softclock
  4874  386030      0      0  7  0x40014200                idle0
 88072  347022      0      0  3     0x14200  kmalloc       kmthread
     1  288377      0      0  3        0x82  wait          init
     0       0     -1      0  3     0x10200  scheduler     swapper


ddb{2}> mach ddbcpu 1
Stopped at      ampintc_ipi_ddb+0x1c:   db_enter() at ampintc_ipi_ddb+0x18
ampintc_ipi_ddb() at handle_el1h_irq+0x6c
handle_el1h_irq() at sched_idle+0x224
sched_idle() at proc_trampoline+0x10
ddb{1}> trace
db_enter() at ampintc_ipi_ddb+0x18
ampintc_ipi_ddb() at handle_el1h_irq+0x6c
handle_el1h_irq() at sched_idle+0x224
sched_idle() at proc_trampoline+0x10



ddb{1}> mach ddbcpu 2
Stopped at      panic+0x148:    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
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 ---



ddb{2}> mach ddbcpu 3
Stopped at      ampintc_ipi_ddb+0x1c:   db_enter() at ampintc_ipi_ddb+0x18
ampintc_ipi_ddb() at handle_el1h_irq+0x6c
handle_el1h_irq() at sched_idle+0x224
sched_idle() at proc_trampoline+0x10
ddb{3}> trace
db_enter() at ampintc_ipi_ddb+0x18oppcsobsd
ampintc_ipi_ddb() at handle_el1h_irq+0x6c
handle_el1h_irq() at sched_idle+0x224
sched_idle() at proc_trampoline+0x10



ddb{3}> mach ddbcpu 0

*** no output and ddb no longer responds



bsd.sp

oppcsobsd# pkg_add wget
quirks-3.83 signed on 2019-01-17T20:44:02Z
No pkgname in packing-list for gettext-0.19.8.1p3
quirks-3.83: ok
Collision in libiconv-1.14p3: the following files already exist
        /usr/local/bin/iconv from libiconv-1.14p3 (different checksum)
        /usr/local/include/iconv.h from libiconv-1.14p3 (different checksum)
        /usr/local/include/libcharset.h from libiconv-1.14p3 (different
checksum)
        /usr/local/include/localcharset.h from libiconv-1.14p3 (different
checksum)
        /usr/local/lib/charset.alias from libiconv-1.14p3 (different
checksum)
        /usr/local/lib/libcharset.a from libiconv-1.14p3 (different
checksum)
        /usr/local/lib/libcharset.la from libiconv-1.14p3 (different
checksum)
        /usr/local/lib/libcharset.so.1.1 from libiconv-1.14p3 (different
checksum)
        /usr/local/lib/libiconv.a from libiconv-1.14p3 (different checksum)
        /usr/local/lib/libiconv.la from libiconv-1.14p3 (different checksum)
        /usr/local/lib/libiconv.so.6.0 from libiconv-1.14p3 (different
checksum)
        /usr/local/man/man1/iconv.1 from libiconv-1.14p3 (different
checksum)
        /usr/local/man/man3/iconv.3 from libiconv-1.14p3 (different
checksum)
        /usr/local/man/man3/iconv_close.3 from libiconv-1.14p3 (different
checksum)
        /usr/local/man/man3/iconv_open.3 from libiconv-1.14p3 (different
checksum)
        /usr/local/man/man3/iconv_open_into.3 from libiconv-1.14p3
(different checksum)
        /usr/local/man/man3/iconvctl.3 from libiconv-1.14p3 (different
checksum)
        /usr/local/share/doc/libiconv/iconv.1.html from libiconv-1.14p3
(different checksum)
        /usr/local/share/doc/libiconv/iconv.3.html from libiconv-1.14p3
(different checksum)
        /usr/local/share/doc/libiconv/iconv_close.3.html from
libiconv-1.14p3 (different checksum)
        /usr/local/share/doc/libiconv/iconv_open.3.html from libiconv-1.14p3
(different checksum)
        /usr/local/share/doc/libiconv/iconv_open_into.3.html from
libiconv-1.14p3 (different checksum)
        /usr/local/share/doc/libiconv/iconvctl.3.html from libiconv-1.14p3
(different checksum)
It seems to be a missing package registration
Repair ? [y/N/a] y
wget-1.19.5:libiconv-1.14p3 (installing)|*****                            |
15%panic: amap_pp_adjref: negative reference count
Stopped at      panic+0x148:        TID    PID    UID     PRFLAGS     PFLAGS
C
PU  COMMAND
*521842  88112      0      0x1015          0    0  perl
db_enter() at panic+0x144
panic() at uvm_unmap_detach+0x64
uvm_unmap_detach() at uvmspace_exec+0x1d0
uvmspace_exec() at sys_execve+0x5a8
sys_execve() at svc_handler+0x20c
svc_handler() at do_el0_sync+0x17c
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> trace
db_enter() at panic+0x144
panic() at uvm_unmap_detach+0x64
uvm_unmap_detach() at uvmspace_exec+0x1d0
uvmspace_exec() at sys_execve+0x5a8
sys_execve() at svc_handler+0x20c
svc_handler() at do_el0_sync+0x17c
do_el0_sync() at handle_el0_sync+0x74
handle_el0_sync() at 0x2337329d38
address 0x7ffffb74f8 is invalid
--- trap ---


ddb> ps
   PID     TID   PPID    UID  S       FLAGS  WAIT          COMMAND
*88112  521842  78597      0  7      0x1015                perl
 78597  458040  89830      0  2        0x13                perl
 89830  206285  23938      0  3    0x10008b  pause         ksh
 23938   22210      1   1000  3    0x10008b  pause         ksh
 14882  460327      1      0  3    0x100098  poll          cron
 85486   10741      1     99  3    0x100090  poll          sndiod
 85760  521856      1    110  3    0x100090  poll          sndiod
 55964  331004  76779     95  3    0x100092  kqread        smtpd
 18575  271679  76779    103  3    0x100092  kqread        smtpd
 50245  332907  76779     95  3    0x100092  kqread        smtpd
 57128  284121  76779     95  3    0x100092  kqread        smtpd
 17067  478610  76779     95  3    0x100092  kqread        smtpd
  6515   78250  76779     95  3    0x100092  kqread        smtpd
 76779  324982      1      0  3    0x100080  kqread        smtpd
 44127  287999      1      0  3        0x80  select        sshd
 72640  283337  12072     83  3    0x100092  poll          ntpd
 12072  388328  46170     83  3    0x100092  poll          ntpd
 46170   11871      1      0  3    0x100080  poll          ntpd
 96091  437137  21881     74  2    0x100492                pflogd
 21881  298776      1      0  3        0x80  netio         pflogd
 25113  391453  11975     73  3    0x100090  kqread        syslogd
 11975   77065      1      0  3    0x100082  netio         syslogd
 60708  293516  24166    115  3    0x100092  kqread        slaacd
 46579  121101  24166    115  3    0x100092  kqread        slaacd
 24166  364366      1      0  3    0x100080  kqread        slaacd
 98077  239107      0      0  2     0x14200                zerothread
 82871   12183      0      0  3     0x14200  aiodoned      aiodoned
 81714  490217      0      0  3     0x14200  syncer        update
 91949  160279      0      0  3     0x14200  cleaner       cleaner
 13151  382825      0      0  3     0x14200  reaper        reaper
 74497   27405      0      0  3     0x14200  pgdaemon      pagedaemon
 74901  349518      0      0  3     0x14200  bored         crynlk
 57623  169669      0      0  3     0x14200  bored         crypto
 89199  204862      0      0  3     0x14200  usbtsk        usbtask
 26703  302587      0      0  3     0x14200  usbatsk       usbatsk
 32140   61477      0      0  3     0x14200  mmctsk        sdmmc0
 63754  488745      0      0  3     0x14200  bored         softnet
 20364  195848      0      0  3     0x14200  bored         systqmp
 25109  144889      0      0  3     0x14200  bored         systq
 25371  422926      0      0  3  0x40014200  bored         softclock
 45094   81838      0      0  3  0x40014200                idle0
 82775   24882      0      0  3     0x14200  kmalloc       kmthread
     1   19526      0      0  3        0x82  wait          init
     0       0     -1      0  3     0x10200  scheduler     swapper


ddb> show uvm
Current UVM status:
  pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12
  216443 VM pages: 12907 active, 4385 inactive, 0 wired, 159110 free (19886
zer
o)
  min  10% (25) anon, 10% (25) vnode, 5% (12) vtext
  freemin=7214, free-target=9618, inactive-target=0, wired-max=72147
  faults=223955, traps=0, intrs=0, ctxswitch=3008776 fpuswitch=0
  softint=88841, syscalls=180282, kmapent=13
  fault counts:
    noram=0, noanon=0, noamap=0, pgwait=0, pgrele=0
    ok relocks(total)=14626(14629), anget(retries)=85471(0), amapcopy=88319
    neighbor anon/obj pg=7076/74388, gets(lock/unlock)=74338/14629
    cases: anon=72850, anoncow=12621, obj=68766, prcopy=5569, przero=64149
  daemon and swap counts:
    woke=0, revs=0, scans=0, obscans=0, anscans=0
    busy=0, freed=0, reactivate=0, deactivate=0
    pageouts=0, pending=0, nswget=0
    nswapdev=1
    swpages=263967, swpginuse=0, swpgonly=0 paging=0
  kernel pointers:
    objs(kern)=0xffffff8000b11248


ddb> show bcstats
Current Buffer Cache status:
numbufs 6896 busymapped 0, delwri 51
kvaslots 2705 avail kva slots 2705
bufpages 27578, dmapages 27578, dirtypages 204
pendingreads 0, pendingwrites 0
highflips 0, highflops 0, dmaflips 0

Reply | Threaded
Open this post in threaded view
|

Re: crashes on orangepi pc2

Mark Kettenis
> From: <[hidden email]>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: crashes on orangepi pc2

Patrick Wildt-3
On Thu, Jan 31, 2019 at 11:26:48AM +0100, Mark Kettenis wrote:

> > From: <[hidden email]>
> > 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.
>

My NanoPi Neo2, which is H5 based as well, is also rather unstable.

Reply | Threaded
Open this post in threaded view
|

Re: crashes on orangepi pc2

s_graf
In reply to this post by Mark Kettenis
It seems to be related to network usage, although I cannot confirm that.

As to the unstableness, I loaded Armbian, download, installed and ran xfce and Firefox, all without problems.

Something else that I notice is that the boot sometimes fails and I have to power off and on again to get it going.

Stops after this:

U-Boot SPL 2019.01 (Jan 27 2019 - 23:00:53 -0700)
DRAM: 1024 MiB
Trying to boot from MMC1

I am going to experiment with different u-boots and dtbs.

Should the dtb be put into the dos partition in the allwinner directory?

-----Original Message-----
From: [hidden email] <[hidden email]> On Behalf Of Patrick Wildt
Sent: January 31, 2019 7:11 AM
To: Mark Kettenis <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: crashes on orangepi pc2

On Thu, Jan 31, 2019 at 11:26:48AM +0100, Mark Kettenis wrote:

> > From: <[hidden email]>
> > 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.
>

My NanoPi Neo2, which is H5 based as well, is also rather unstable.


Reply | Threaded
Open this post in threaded view
|

Re: crashes on orangepi pc2

Mark Kettenis
> From: <[hidden email]>
> Date: Thu, 31 Jan 2019 11:04:25 -0800
>
> It seems to be related to network usage, although I cannot confirm that.

Interesting...

The crash always seems to involve perl as far as I can tell.  I've
seen it crash in the daily job as well.  That doesn't rule out there
is some network-related corrpution going on though.

> As to the unstableness, I loaded Armbian, download, installed and
> ran xfce and Firefox, all without problems.
>
> Something else that I notice is that the boot sometimes fails and I
> have to power off and on again to get it going.

I think I've seen that as well.  Seems U-Boot/ATF doesn't properly
reset the SoC.  I believe this is fixed in newer ATF versions.

> Stops after this:
>
> U-Boot SPL 2019.01 (Jan 27 2019 - 23:00:53 -0700)
> DRAM: 1024 MiB
> Trying to boot from MMC1
>
> I am going to experiment with different u-boots and dtbs.
>
> Should the dtb be put into the dos partition in the allwinner directory?

Yes.

> -----Original Message-----
> From: [hidden email] <[hidden email]> On Behalf Of Patrick Wildt
> Sent: January 31, 2019 7:11 AM
> To: Mark Kettenis <[hidden email]>
> Cc: [hidden email]; [hidden email]
> Subject: Re: crashes on orangepi pc2
>
> On Thu, Jan 31, 2019 at 11:26:48AM +0100, Mark Kettenis wrote:
> > > From: <[hidden email]>
> > > 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.
> >
>
> My NanoPi Neo2, which is H5 based as well, is also rather unstable.
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: crashes on orangepi pc2

Artturi Alm
On Thu, Jan 31, 2019 at 08:20:21PM +0100, Mark Kettenis wrote:

> > From: <[hidden email]>
> > Date: Thu, 31 Jan 2019 11:04:25 -0800
> >
> > It seems to be related to network usage, although I cannot confirm that.
>
> Interesting...
>
> The crash always seems to involve perl as far as I can tell.  I've
> seen it crash in the daily job as well.  That doesn't rule out there
> is some network-related corrpution going on though.
>
> > As to the unstableness, I loaded Armbian, download, installed and
> > ran xfce and Firefox, all without problems.
> >
> > Something else that I notice is that the boot sometimes fails and I
> > have to power off and on again to get it going.
>
> I think I've seen that as well.  Seems U-Boot/ATF doesn't properly
> reset the SoC.  I believe this is fixed in newer ATF versions.
>

H5 has some known issues, some u-boots might come w/correct combination
of voltage+freq(cpu+ddr), but apparently[0] ppl hacking on these with
linux aren't yet sure about what it is either, and it's likely not the
same for all revisions(later revs have the voltage adjustable via gpio).

-Artturi

ps. these issues have been chatted about for some time, i just linked
to the most recent one from today i saw.

[0]:
https://freenode.irclog.whitequark.org/linux-sunxi/2019-01-31#23970760;

> > Stops after this:
> >
> > U-Boot SPL 2019.01 (Jan 27 2019 - 23:00:53 -0700)
> > DRAM: 1024 MiB
> > Trying to boot from MMC1
> >
> > I am going to experiment with different u-boots and dtbs.
> >
> > Should the dtb be put into the dos partition in the allwinner directory?
>
> Yes.
>
> > -----Original Message-----
> > From: [hidden email] <[hidden email]> On Behalf Of Patrick Wildt
> > Sent: January 31, 2019 7:11 AM
> > To: Mark Kettenis <[hidden email]>
> > Cc: [hidden email]; [hidden email]
> > Subject: Re: crashes on orangepi pc2
> >
> > On Thu, Jan 31, 2019 at 11:26:48AM +0100, Mark Kettenis wrote:
> > > > From: <[hidden email]>
> > > > 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.
> > >
> >
> > My NanoPi Neo2, which is H5 based as well, is also rather unstable.
> >
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: crashes on orangepi pc2

s_graf
In reply to this post by Mark Kettenis
I borrowed the dtb from the Armbian system (attached file) and it ran for
quite a bit longer than with the
stock dtb, but then crashed in the middle of adding php.  It got through
adding nano and wget.

The Armbian dtb also exposed the temperature sensors and the gpio voltage
controller:

sypwr0 at iic0 addr 0x65: 1.20 VDC

oppc2obsd$ sysctl hw.sensors
hw.sensors.sxitemp0.temp0=35.54 degC (CPU)
hw.sensors.sxitemp0.temp1=36.61 degC (GPU)

I am now getting

oppc2obsd$ dwxe_watchdog

and the lan connection no loner works.
I had set up ntpd to set the time on boot which worked.

oppc2obsd$ tail /var/log/daemon
Jan 31 12:42:52 oppc2obsd ntpd[85416]: set local clock to Thu Jan 31
12:42:52 PST 2019 (offset 594.341118s)
Jan 31 12:42:53 oppc2obsd savecore: no core dump
Jan 31 12:43:11 oppc2obsd ntpd[98046]: peer 204.11.201.12 now valid
Jan 31 12:43:14 oppc2obsd ntpd[98046]: peer 38.229.71.1 now valid
Jan 31 12:43:15 oppc2obsd ntpd[98046]: peer 45.79.187.10 now valid
Jan 31 12:43:17 oppc2obsd ntpd[98046]: peer 23.131.160.7 now valid
Jan 31 12:43:40 oppc2obsd ntpd[98046]: peer 45.79.187.10 now invalid
Jan 31 12:43:41 oppc2obsd ntpd[98046]: peer 38.229.71.1 now invalid
Jan 31 12:43:42 oppc2obsd ntpd[98046]: peer 204.11.201.12 now invalid
Jan 31 12:43:48 oppc2obsd ntpd[98046]: peer 23.131.160.7 now invalid
oppc2obsd$

-----Original Message-----
From: Artturi Alm <[hidden email]>
Sent: January 31, 2019 11:46 AM
To: Mark Kettenis <[hidden email]>
Cc: [hidden email]; [hidden email]; [hidden email]
Subject: Re: crashes on orangepi pc2

On Thu, Jan 31, 2019 at 08:20:21PM +0100, Mark Kettenis wrote:

> > From: <[hidden email]>
> > Date: Thu, 31 Jan 2019 11:04:25 -0800
> >
> > It seems to be related to network usage, although I cannot confirm that.
>
> Interesting...
>
> The crash always seems to involve perl as far as I can tell.  I've
> seen it crash in the daily job as well.  That doesn't rule out there
> is some network-related corrpution going on though.
>
> > As to the unstableness, I loaded Armbian, download, installed and
> > ran xfce and Firefox, all without problems.
> >
> > Something else that I notice is that the boot sometimes fails and I
> > have to power off and on again to get it going.
>
> I think I've seen that as well.  Seems U-Boot/ATF doesn't properly
> reset the SoC.  I believe this is fixed in newer ATF versions.
>
H5 has some known issues, some u-boots might come w/correct combination
of voltage+freq(cpu+ddr), but apparently[0] ppl hacking on these with
linux aren't yet sure about what it is either, and it's likely not the
same for all revisions(later revs have the voltage adjustable via gpio).

-Artturi

ps. these issues have been chatted about for some time, i just linked
to the most recent one from today i saw.

[0]:
https://freenode.irclog.whitequark.org/linux-sunxi/2019-01-31#23970760;

> > Stops after this:
> >
> > U-Boot SPL 2019.01 (Jan 27 2019 - 23:00:53 -0700)
> > DRAM: 1024 MiB
> > Trying to boot from MMC1
> >
> > I am going to experiment with different u-boots and dtbs.
> >
> > Should the dtb be put into the dos partition in the allwinner directory?
>
> Yes.
>
> > -----Original Message-----
> > From: [hidden email] <[hidden email]> On Behalf Of Patrick
Wildt

> > Sent: January 31, 2019 7:11 AM
> > To: Mark Kettenis <[hidden email]>
> > Cc: [hidden email]; [hidden email]
> > Subject: Re: crashes on orangepi pc2
> >
> > On Thu, Jan 31, 2019 at 11:26:48AM +0100, Mark Kettenis wrote:
> > > > From: <[hidden email]>
> > > > 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.
> > >
> >
> > My NanoPi Neo2, which is H5 based as well, is also rather unstable.
> >
> >
> >
>

sun50i-h5-orangepi-pc2.dtb (39K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: crashes on orangepi pc2

Krystian Lewandowski
Wiadomość napisana przez [hidden email] w dniu 31.01.2019, o godz. 21:57:

>
> I borrowed the dtb from the Armbian system (attached file) and it ran for
> quite a bit longer than with the
> stock dtb, but then crashed in the middle of adding php.  It got through
> adding nano and wget.
>
> The Armbian dtb also exposed the temperature sensors and the gpio voltage
> controller:
>
> sypwr0 at iic0 addr 0x65: 1.20 VDC
>
> oppc2obsd$ sysctl hw.sensors
> hw.sensors.sxitemp0.temp0=35.54 degC (CPU)
> hw.sensors.sxitemp0.temp1=36.61 degC (GPU)

Please see my post on ports@ group (I posted a patch for A64 enabling sxitemp),
It should work for H5 with no additional changes, if you really want to have it.

>
> I am now getting
>
> oppc2obsd$ dwxe_watchdog

I am not using separate DTB just the one built into u-boot-sunxi-with-spl.bin
flashed on to SD card, I do not have any dump from serial console but I think I
saw this one a few times on Pine A64+.  I switched to WiFi dongle anyway and it
is fine now.

Other than that A64+ is stable.

>
> and the lan connection no loner works.
> I had set up ntpd to set the time on boot which worked.
>
> oppc2obsd$ tail /var/log/daemon
> Jan 31 12:42:52 oppc2obsd ntpd[85416]: set local clock to Thu Jan 31
> 12:42:52 PST 2019 (offset 594.341118s)
> Jan 31 12:42:53 oppc2obsd savecore: no core dump
> Jan 31 12:43:11 oppc2obsd ntpd[98046]: peer 204.11.201.12 now valid
> Jan 31 12:43:14 oppc2obsd ntpd[98046]: peer 38.229.71.1 now valid
> Jan 31 12:43:15 oppc2obsd ntpd[98046]: peer 45.79.187.10 now valid
> Jan 31 12:43:17 oppc2obsd ntpd[98046]: peer 23.131.160.7 now valid
> Jan 31 12:43:40 oppc2obsd ntpd[98046]: peer 45.79.187.10 now invalid
> Jan 31 12:43:41 oppc2obsd ntpd[98046]: peer 38.229.71.1 now invalid
> Jan 31 12:43:42 oppc2obsd ntpd[98046]: peer 204.11.201.12 now invalid
> Jan 31 12:43:48 oppc2obsd ntpd[98046]: peer 23.131.160.7 now invalid
> oppc2obsd$
>
> -----Original Message-----
> From: Artturi Alm <[hidden email]>
> Sent: January 31, 2019 11:46 AM
> To: Mark Kettenis <[hidden email]>
> Cc: [hidden email]; [hidden email]; [hidden email]
> Subject: Re: crashes on orangepi pc2
>
> On Thu, Jan 31, 2019 at 08:20:21PM +0100, Mark Kettenis wrote:
>>> From: <[hidden email]>
>>> Date: Thu, 31 Jan 2019 11:04:25 -0800
>>>
>>> It seems to be related to network usage, although I cannot confirm that.
>>
>> Interesting...
>>
>> The crash always seems to involve perl as far as I can tell.  I've
>> seen it crash in the daily job as well.  That doesn't rule out there
>> is some network-related corrpution going on though.
>>
>>> As to the unstableness, I loaded Armbian, download, installed and
>>> ran xfce and Firefox, all without problems.
>>>
>>> Something else that I notice is that the boot sometimes fails and I
>>> have to power off and on again to get it going.
>>
>> I think I've seen that as well.  Seems U-Boot/ATF doesn't properly
>> reset the SoC.  I believe this is fixed in newer ATF versions.
>>
>
> H5 has some known issues, some u-boots might come w/correct combination
> of voltage+freq(cpu+ddr), but apparently[0] ppl hacking on these with
> linux aren't yet sure about what it is either, and it's likely not the
> same for all revisions(later revs have the voltage adjustable via gpio).
>
> -Artturi
>
> ps. these issues have been chatted about for some time, i just linked
> to the most recent one from today i saw.
>
> [0]:
> https://freenode.irclog.whitequark.org/linux-sunxi/2019-01-31#23970760;
>
>>> Stops after this:
>>>
>>> U-Boot SPL 2019.01 (Jan 27 2019 - 23:00:53 -0700)
>>> DRAM: 1024 MiB
>>> Trying to boot from MMC1
>>>
>>> I am going to experiment with different u-boots and dtbs.
>>>
>>> Should the dtb be put into the dos partition in the allwinner directory?
>>
>> Yes.
>>
>>> -----Original Message-----
>>> From: [hidden email] <[hidden email]> On Behalf Of Patrick
> Wildt
>>> Sent: January 31, 2019 7:11 AM
>>> To: Mark Kettenis <[hidden email]>
>>> Cc: [hidden email]; [hidden email]
>>> Subject: Re: crashes on orangepi pc2
>>>
>>> On Thu, Jan 31, 2019 at 11:26:48AM +0100, Mark Kettenis wrote:
>>>>> From: <[hidden email]>
>>>>> 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.
>>>>
>>>
>>> My NanoPi Neo2, which is H5 based as well, is also rather unstable.
>>>
>>>
>>>
>>
> <sun50i-h5-orangepi-pc2.dtb>

Reply | Threaded
Open this post in threaded view
|

Re: crashes on orangepi pc2

Sebastian Benoit-3
In reply to this post by Mark Kettenis
Mark Kettenis([hidden email]) on 2019.01.31 20:20:21 +0100:

> > From: <[hidden email]>
> > Date: Thu, 31 Jan 2019 11:04:25 -0800
> >
> > It seems to be related to network usage, although I cannot confirm that.
>
> Interesting...
>
> The crash always seems to involve perl as far as I can tell.  I've
> seen it crash in the daily job as well.  That doesn't rule out there
> is some network-related corrpution going on though.

Its not just perl. I could trigger it just by building a kernel. But perl
triggers it much faster, to the point of making pkg_add russian roulette.

> > As to the unstableness, I loaded Armbian, download, installed and
> > ran xfce and Firefox, all without problems.
> >
> > Something else that I notice is that the boot sometimes fails and I
> > have to power off and on again to get it going.
>
> I think I've seen that as well.  Seems U-Boot/ATF doesn't properly
> reset the SoC.  I believe this is fixed in newer ATF versions.
>
> > Stops after this:
> >
> > U-Boot SPL 2019.01 (Jan 27 2019 - 23:00:53 -0700)
> > DRAM: 1024 MiB
> > Trying to boot from MMC1
> >
> > I am going to experiment with different u-boots and dtbs.
> >
> > Should the dtb be put into the dos partition in the allwinner directory?
>
> Yes.
>
> > -----Original Message-----
> > From: [hidden email] <[hidden email]> On Behalf Of Patrick Wildt
> > Sent: January 31, 2019 7:11 AM
> > To: Mark Kettenis <[hidden email]>
> > Cc: [hidden email]; [hidden email]
> > Subject: Re: crashes on orangepi pc2
> >
> > On Thu, Jan 31, 2019 at 11:26:48AM +0100, Mark Kettenis wrote:
> > > > From: <[hidden email]>
> > > > 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.
> > >
> >
> > My NanoPi Neo2, which is H5 based as well, is also rather unstable.
> >
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: crashes on orangepi pc2

s_graf
In reply to this post by Mark Kettenis
I managed to change the Armbian dtb to set the cpu voltage to 1.3v:

sypwr0 at iic0 addr 0x65: 1.30 VDC

But it did not change anything - still crashes in perl when trying to add
packages.

Does the openbsd kernel change cpu power and speed to minimize power
consumption?

-----Original Message-----
From: [hidden email] <[hidden email]>
Sent: January 31, 2019 12:58 PM
To: 'Artturi Alm' <[hidden email]>; 'Mark Kettenis'
<[hidden email]>
Cc: '[hidden email]' <[hidden email]>; '[hidden email]'
<[hidden email]>
Subject: RE: crashes on orangepi pc2

I borrowed the dtb from the Armbian system (attached file) and it ran for
quite a bit longer than with the
stock dtb, but then crashed in the middle of adding php.  It got through
adding nano and wget.

The Armbian dtb also exposed the temperature sensors and the gpio voltage
controller:

sypwr0 at iic0 addr 0x65: 1.20 VDC

oppc2obsd$ sysctl hw.sensors
hw.sensors.sxitemp0.temp0=35.54 degC (CPU)
hw.sensors.sxitemp0.temp1=36.61 degC (GPU)

I am now getting

oppc2obsd$ dwxe_watchdog

and the lan connection no loner works.
I had set up ntpd to set the time on boot which worked.

oppc2obsd$ tail /var/log/daemon
Jan 31 12:42:52 oppc2obsd ntpd[85416]: set local clock to Thu Jan 31
12:42:52 PST 2019 (offset 594.341118s)
Jan 31 12:42:53 oppc2obsd savecore: no core dump
Jan 31 12:43:11 oppc2obsd ntpd[98046]: peer 204.11.201.12 now valid
Jan 31 12:43:14 oppc2obsd ntpd[98046]: peer 38.229.71.1 now valid
Jan 31 12:43:15 oppc2obsd ntpd[98046]: peer 45.79.187.10 now valid
Jan 31 12:43:17 oppc2obsd ntpd[98046]: peer 23.131.160.7 now valid
Jan 31 12:43:40 oppc2obsd ntpd[98046]: peer 45.79.187.10 now invalid
Jan 31 12:43:41 oppc2obsd ntpd[98046]: peer 38.229.71.1 now invalid
Jan 31 12:43:42 oppc2obsd ntpd[98046]: peer 204.11.201.12 now invalid
Jan 31 12:43:48 oppc2obsd ntpd[98046]: peer 23.131.160.7 now invalid
oppc2obsd$

-----Original Message-----
From: Artturi Alm <[hidden email]>
Sent: January 31, 2019 11:46 AM
To: Mark Kettenis <[hidden email]>
Cc: [hidden email]; [hidden email]; [hidden email]
Subject: Re: crashes on orangepi pc2

On Thu, Jan 31, 2019 at 08:20:21PM +0100, Mark Kettenis wrote:

> > From: <[hidden email]>
> > Date: Thu, 31 Jan 2019 11:04:25 -0800
> >
> > It seems to be related to network usage, although I cannot confirm that.
>
> Interesting...
>
> The crash always seems to involve perl as far as I can tell.  I've
> seen it crash in the daily job as well.  That doesn't rule out there
> is some network-related corrpution going on though.
>
> > As to the unstableness, I loaded Armbian, download, installed and
> > ran xfce and Firefox, all without problems.
> >
> > Something else that I notice is that the boot sometimes fails and I
> > have to power off and on again to get it going.
>
> I think I've seen that as well.  Seems U-Boot/ATF doesn't properly
> reset the SoC.  I believe this is fixed in newer ATF versions.
>

H5 has some known issues, some u-boots might come w/correct combination
of voltage+freq(cpu+ddr), but apparently[0] ppl hacking on these with
linux aren't yet sure about what it is either, and it's likely not the
same for all revisions(later revs have the voltage adjustable via gpio).

-Artturi

ps. these issues have been chatted about for some time, i just linked
to the most recent one from today i saw.

[0]:
https://freenode.irclog.whitequark.org/linux-sunxi/2019-01-31#23970760;

> > Stops after this:
> >
> > U-Boot SPL 2019.01 (Jan 27 2019 - 23:00:53 -0700)
> > DRAM: 1024 MiB
> > Trying to boot from MMC1
> >
> > I am going to experiment with different u-boots and dtbs.
> >
> > Should the dtb be put into the dos partition in the allwinner directory?
>
> Yes.
>
> > -----Original Message-----
> > From: [hidden email] <[hidden email]> On Behalf Of Patrick
Wildt

> > Sent: January 31, 2019 7:11 AM
> > To: Mark Kettenis <[hidden email]>
> > Cc: [hidden email]; [hidden email]
> > Subject: Re: crashes on orangepi pc2
> >
> > On Thu, Jan 31, 2019 at 11:26:48AM +0100, Mark Kettenis wrote:
> > > > From: <[hidden email]>
> > > > 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.
> > >
> >
> > My NanoPi Neo2, which is H5 based as well, is also rather unstable.
> >
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: crashes on orangepi pc2

s_graf
In reply to this post by Mark Kettenis
How is the cpu voltage and cpu clock speed set on arm64? How can I tell what
is set?
 I would like to try running the orangepi pc2 with a higher voltage and
lower speed to see if it becomes stable.

As Artturi pointed out there is much discussion about the speed capabilities
or lack thereof on the h5 SOC.

-----Original Message-----
From: [hidden email] <[hidden email]>
Sent: January 31, 2019 11:05 PM
To: 'Artturi Alm' <[hidden email]>; 'Mark Kettenis'
<[hidden email]>
Cc: '[hidden email]' <[hidden email]>; '[hidden email]'
<[hidden email]>
Subject: RE: crashes on orangepi pc2

I managed to change the Armbian dtb to set the cpu voltage to 1.3v:

sypwr0 at iic0 addr 0x65: 1.30 VDC

But it did not change anything - still crashes in perl when trying to add
packages.

Does the openbsd kernel change cpu power and speed to minimize power
consumption?

-----Original Message-----
From: [hidden email] <[hidden email]>
Sent: January 31, 2019 12:58 PM
To: 'Artturi Alm' <[hidden email]>; 'Mark Kettenis'
<[hidden email]>
Cc: '[hidden email]' <[hidden email]>; '[hidden email]'
<[hidden email]>
Subject: RE: crashes on orangepi pc2

I borrowed the dtb from the Armbian system (attached file) and it ran for
quite a bit longer than with the
stock dtb, but then crashed in the middle of adding php.  It got through
adding nano and wget.

The Armbian dtb also exposed the temperature sensors and the gpio voltage
controller:

sypwr0 at iic0 addr 0x65: 1.20 VDC

oppc2obsd$ sysctl hw.sensors
hw.sensors.sxitemp0.temp0=35.54 degC (CPU)
hw.sensors.sxitemp0.temp1=36.61 degC (GPU)

I am now getting

oppc2obsd$ dwxe_watchdog

and the lan connection no loner works.
I had set up ntpd to set the time on boot which worked.

oppc2obsd$ tail /var/log/daemon
Jan 31 12:42:52 oppc2obsd ntpd[85416]: set local clock to Thu Jan 31
12:42:52 PST 2019 (offset 594.341118s)
Jan 31 12:42:53 oppc2obsd savecore: no core dump
Jan 31 12:43:11 oppc2obsd ntpd[98046]: peer 204.11.201.12 now valid
Jan 31 12:43:14 oppc2obsd ntpd[98046]: peer 38.229.71.1 now valid
Jan 31 12:43:15 oppc2obsd ntpd[98046]: peer 45.79.187.10 now valid
Jan 31 12:43:17 oppc2obsd ntpd[98046]: peer 23.131.160.7 now valid
Jan 31 12:43:40 oppc2obsd ntpd[98046]: peer 45.79.187.10 now invalid
Jan 31 12:43:41 oppc2obsd ntpd[98046]: peer 38.229.71.1 now invalid
Jan 31 12:43:42 oppc2obsd ntpd[98046]: peer 204.11.201.12 now invalid
Jan 31 12:43:48 oppc2obsd ntpd[98046]: peer 23.131.160.7 now invalid
oppc2obsd$

-----Original Message-----
From: Artturi Alm <[hidden email]>
Sent: January 31, 2019 11:46 AM
To: Mark Kettenis <[hidden email]>
Cc: [hidden email]; [hidden email]; [hidden email]
Subject: Re: crashes on orangepi pc2

On Thu, Jan 31, 2019 at 08:20:21PM +0100, Mark Kettenis wrote:

> > From: <[hidden email]>
> > Date: Thu, 31 Jan 2019 11:04:25 -0800
> >
> > It seems to be related to network usage, although I cannot confirm that.
>
> Interesting...
>
> The crash always seems to involve perl as far as I can tell.  I've
> seen it crash in the daily job as well.  That doesn't rule out there
> is some network-related corrpution going on though.
>
> > As to the unstableness, I loaded Armbian, download, installed and
> > ran xfce and Firefox, all without problems.
> >
> > Something else that I notice is that the boot sometimes fails and I
> > have to power off and on again to get it going.
>
> I think I've seen that as well.  Seems U-Boot/ATF doesn't properly
> reset the SoC.  I believe this is fixed in newer ATF versions.
>

H5 has some known issues, some u-boots might come w/correct combination
of voltage+freq(cpu+ddr), but apparently[0] ppl hacking on these with
linux aren't yet sure about what it is either, and it's likely not the
same for all revisions(later revs have the voltage adjustable via gpio).

-Artturi

ps. these issues have been chatted about for some time, i just linked
to the most recent one from today i saw.

[0]:
https://freenode.irclog.whitequark.org/linux-sunxi/2019-01-31#23970760;

> > Stops after this:
> >
> > U-Boot SPL 2019.01 (Jan 27 2019 - 23:00:53 -0700)
> > DRAM: 1024 MiB
> > Trying to boot from MMC1
> >
> > I am going to experiment with different u-boots and dtbs.
> >
> > Should the dtb be put into the dos partition in the allwinner directory?
>
> Yes.
>
> > -----Original Message-----
> > From: [hidden email] <[hidden email]> On Behalf Of Patrick
Wildt

> > Sent: January 31, 2019 7:11 AM
> > To: Mark Kettenis <[hidden email]>
> > Cc: [hidden email]; [hidden email]
> > Subject: Re: crashes on orangepi pc2
> >
> > On Thu, Jan 31, 2019 at 11:26:48AM +0100, Mark Kettenis wrote:
> > > > From: <[hidden email]>
> > > > 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.
> > >
> >
> > My NanoPi Neo2, which is H5 based as well, is also rather unstable.
> >
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: crashes on orangepi pc2

Mark Kettenis
> From: <[hidden email]>
> Date: Fri, 1 Feb 2019 14:29:28 -0800
>
> How is the cpu voltage and cpu clock speed set on arm64? How can I tell what
> is set?
>  I would like to try running the orangepi pc2 with a higher voltage and
> lower speed to see if it becomes stable.
>
> As Artturi pointed out there is much discussion about the speed capabilities
> or lack thereof on the h5 SOC.

Changing the CPU clock frequency and voltage is supported on arm64 if:

1. The CPU nodes in the DT have a "operating-points-v2" property.

2. There is a driver that implements setting the frequency of
   associated clock.

3. There is a driver that implements setting the voltage of the
   associated voltage regulator.

I implemented 3) in sxiccmu(4), and sypwr(4) implements 2 for the
OrangePi PC2.  So if your DT has 1), it should work.

You can change the speed using sysctl hw.serperf.  This is a
percentage between 0 and 100.  You can see the resulting clock speed
by using sysctl hw.cpuspeed.  If you want to change the operating
points you'll have to edit the DT.

Cheers,

Mark

> -----Original Message-----
> From: [hidden email] <[hidden email]>
> Sent: January 31, 2019 11:05 PM
> To: 'Artturi Alm' <[hidden email]>; 'Mark Kettenis'
> <[hidden email]>
> Cc: '[hidden email]' <[hidden email]>; '[hidden email]'
> <[hidden email]>
> Subject: RE: crashes on orangepi pc2
>
> I managed to change the Armbian dtb to set the cpu voltage to 1.3v:
>
> sypwr0 at iic0 addr 0x65: 1.30 VDC
>
> But it did not change anything - still crashes in perl when trying to add
> packages.
>
> Does the openbsd kernel change cpu power and speed to minimize power
> consumption?
>
> -----Original Message-----
> From: [hidden email] <[hidden email]>
> Sent: January 31, 2019 12:58 PM
> To: 'Artturi Alm' <[hidden email]>; 'Mark Kettenis'
> <[hidden email]>
> Cc: '[hidden email]' <[hidden email]>; '[hidden email]'
> <[hidden email]>
> Subject: RE: crashes on orangepi pc2
>
> I borrowed the dtb from the Armbian system (attached file) and it ran for
> quite a bit longer than with the
> stock dtb, but then crashed in the middle of adding php.  It got through
> adding nano and wget.
>
> The Armbian dtb also exposed the temperature sensors and the gpio voltage
> controller:
>
> sypwr0 at iic0 addr 0x65: 1.20 VDC
>
> oppc2obsd$ sysctl hw.sensors
> hw.sensors.sxitemp0.temp0=35.54 degC (CPU)
> hw.sensors.sxitemp0.temp1=36.61 degC (GPU)
>
> I am now getting
>
> oppc2obsd$ dwxe_watchdog
>
> and the lan connection no loner works.
> I had set up ntpd to set the time on boot which worked.
>
> oppc2obsd$ tail /var/log/daemon
> Jan 31 12:42:52 oppc2obsd ntpd[85416]: set local clock to Thu Jan 31
> 12:42:52 PST 2019 (offset 594.341118s)
> Jan 31 12:42:53 oppc2obsd savecore: no core dump
> Jan 31 12:43:11 oppc2obsd ntpd[98046]: peer 204.11.201.12 now valid
> Jan 31 12:43:14 oppc2obsd ntpd[98046]: peer 38.229.71.1 now valid
> Jan 31 12:43:15 oppc2obsd ntpd[98046]: peer 45.79.187.10 now valid
> Jan 31 12:43:17 oppc2obsd ntpd[98046]: peer 23.131.160.7 now valid
> Jan 31 12:43:40 oppc2obsd ntpd[98046]: peer 45.79.187.10 now invalid
> Jan 31 12:43:41 oppc2obsd ntpd[98046]: peer 38.229.71.1 now invalid
> Jan 31 12:43:42 oppc2obsd ntpd[98046]: peer 204.11.201.12 now invalid
> Jan 31 12:43:48 oppc2obsd ntpd[98046]: peer 23.131.160.7 now invalid
> oppc2obsd$
>
> -----Original Message-----
> From: Artturi Alm <[hidden email]>
> Sent: January 31, 2019 11:46 AM
> To: Mark Kettenis <[hidden email]>
> Cc: [hidden email]; [hidden email]; [hidden email]
> Subject: Re: crashes on orangepi pc2
>
> On Thu, Jan 31, 2019 at 08:20:21PM +0100, Mark Kettenis wrote:
> > > From: <[hidden email]>
> > > Date: Thu, 31 Jan 2019 11:04:25 -0800
> > >
> > > It seems to be related to network usage, although I cannot confirm that.
> >
> > Interesting...
> >
> > The crash always seems to involve perl as far as I can tell.  I've
> > seen it crash in the daily job as well.  That doesn't rule out there
> > is some network-related corrpution going on though.
> >
> > > As to the unstableness, I loaded Armbian, download, installed and
> > > ran xfce and Firefox, all without problems.
> > >
> > > Something else that I notice is that the boot sometimes fails and I
> > > have to power off and on again to get it going.
> >
> > I think I've seen that as well.  Seems U-Boot/ATF doesn't properly
> > reset the SoC.  I believe this is fixed in newer ATF versions.
> >
>
> H5 has some known issues, some u-boots might come w/correct combination
> of voltage+freq(cpu+ddr), but apparently[0] ppl hacking on these with
> linux aren't yet sure about what it is either, and it's likely not the
> same for all revisions(later revs have the voltage adjustable via gpio).
>
> -Artturi
>
> ps. these issues have been chatted about for some time, i just linked
> to the most recent one from today i saw.
>
> [0]:
> https://freenode.irclog.whitequark.org/linux-sunxi/2019-01-31#23970760;
>
> > > Stops after this:
> > >
> > > U-Boot SPL 2019.01 (Jan 27 2019 - 23:00:53 -0700)
> > > DRAM: 1024 MiB
> > > Trying to boot from MMC1
> > >
> > > I am going to experiment with different u-boots and dtbs.
> > >
> > > Should the dtb be put into the dos partition in the allwinner directory?
> >
> > Yes.
> >
> > > -----Original Message-----
> > > From: [hidden email] <[hidden email]> On Behalf Of Patrick
> Wildt
> > > Sent: January 31, 2019 7:11 AM
> > > To: Mark Kettenis <[hidden email]>
> > > Cc: [hidden email]; [hidden email]
> > > Subject: Re: crashes on orangepi pc2
> > >
> > > On Thu, Jan 31, 2019 at 11:26:48AM +0100, Mark Kettenis wrote:
> > > > > From: <[hidden email]>
> > > > > 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.
> > > >
> > >
> > > My NanoPi Neo2, which is H5 based as well, is also rather unstable.
> > >
> > >
> > >
> >
>
>