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

[Mark Millard]

On 2020-Mar-15, at 00:49, Mark Millard <marklmi at yahoo.com> wrote:

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

Leaving the Pine64+2GB powered on and booted but
idle (but for default background processing that
happens) still can get such crashes. The example
below is from head -r358966 .

Sometimes there is more than one timeout notice
first . . .

aw_mmc0: controller timeout
mmcsd0: Error indicated: 1 Timeout
aw_mmc0: controller timeout
mmcsd0: Error indicated: 1 Timeout
aw_mmc0: controller timeout
mmcsd0: Error indicated: 1 Timeout
panic: vm_fault_lookup: fault on nofault entry, addr: 0xffff00004eacc000
cpuid = 2
time = 1584440665
KDB: stack backtrace:
. . . (I'll not repeat the backtrace) . . .


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