Pine64+2GB status? Is anyone else having the following sort of panic problem?

[Mark Millard]

In recent times I've had access to the Pine64+ 2GB again
and when lots of data is being copied to the mmcsd0
UFS partition (various new and old mmcsd media examples)
I eventually get the following sort of failure:

aw_mmc0: controller timeout
mmcsd0: Error indicated: 1 Timeout
panic: vm_fault_lookup: fault on nofault entry, addr: 0xffff00004ee1c000
cpuid = 1
time = 1584255814
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
         pc = 0xffff00000082617c  lr = 0xffff00000010aec0
         sp = 0xffff0000402ece30  fp = 0xffff0000402ed040

db_trace_self_wrapper() at vpanic+0x194
         pc = 0xffff00000010aec0  lr = 0xffff00000046e120
         sp = 0xffff0000402ed050  fp = 0xffff0000402ed0f0

vpanic() at panic+0x44
         pc = 0xffff00000046e120  lr = 0xffff00000046df88
         sp = 0xffff0000402ed100  fp = 0xffff0000402ed180

panic() at vm_fault+0x1ff4
         pc = 0xffff00000046df88  lr = 0xffff0000007b4d1c
         sp = 0xffff0000402ed190  fp = 0xffff0000402ed2c0

vm_fault() at vm_fault_trap+0x64
         pc = 0xffff0000007b4d1c  lr = 0xffff0000007b2c14
         sp = 0xffff0000402ed2d0  fp = 0xffff0000402ed310

vm_fault_trap() at data_abort+0x108
         pc = 0xffff0000007b2c14  lr = 0xffff000000844dec
         sp = 0xffff0000402ed320  fp = 0xffff0000402ed3d0

data_abort() at do_el1h_sync+0x144
         pc = 0xffff000000844dec  lr = 0xffff000000843e38
         sp = 0xffff0000402ed3e0  fp = 0xffff0000402ed410

do_el1h_sync() at handle_el1h_sync+0x78
         pc = 0xffff000000843e38  lr = 0xffff000000828878
         sp = 0xffff0000402ed420  fp = 0xffff0000402ed530

handle_el1h_sync() at bounce_bus_dmamap_sync+0x210
         pc = 0xffff000000828878  lr = 0xffff0000008246a0
         sp = 0xffff0000402ed540  fp = 0xffff0000402ed620

bounce_bus_dmamap_sync() at aw_mmc_request+0x3d0
         pc = 0xffff0000008246a0  lr = 0xffff0000007f1188
         sp = 0xffff0000402ed630  fp = 0xffff0000402ed670

aw_mmc_request() at mmc_wait_for_request+0x12c
         pc = 0xffff0000007f1188  lr = 0xffff0000001f2b80
         sp = 0xffff0000402ed680  fp = 0xffff0000402ed6d0

mmc_wait_for_request() at mmcsd_rw+0x198
         pc = 0xffff0000001f2b80  lr = 0xffff0000001fc010
         sp = 0xffff0000402ed6e0  fp = 0xffff0000402ed810

mmcsd_rw() at mmcsd_task+0x2b0
         pc = 0xffff0000001fc010  lr = 0xffff0000001fabe8
         sp = 0xffff0000402ed820  fp = 0xffff0000402ed940

mmcsd_task() at fork_exit+0x90
         pc = 0xffff0000001fabe8  lr = 0xffff00000041fd78
         sp = 0xffff0000402ed950  fp = 0xffff0000402ed980

fork_exit() at fork_trampoline+0x10
         pc = 0xffff00000041fd78  lr = 0xffff000000843b6c
         sp = 0xffff0000402ed990  fp = 0x0000000000000000

KDB: enter: panic
[ thread pid 20 tid 100078 ]
Stopped at      arm64_dcache_wb_range+0x18:     undefined       d50b7a20

I've never had this happen quickly or for a small amount
of data.

The same operations done with the same examples of media
work fine in the Rock64 (same buildworld and buildkernel
results installed, booted, and operating for both boards).

Both boards have fans and heatsinks and such.

The specific example is from head -r358510 but I've seen
it on -r358132 as well. (I'd not used the Pine64+2GB in
a long time prior to that so I've no useful clue when
this started.)

Is anyone else seeing such oddities?

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)