Date: Sun, 15 Mar 2020 00:49:26 -0700 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: Pine64+2GB status? Is anyone else having the following sort of panic problem? Message-ID: <521CDF7F-8F5F-4E92-8BFE-3E39E1A00586@yahoo.com> References: <521CDF7F-8F5F-4E92-8BFE-3E39E1A00586.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?521CDF7F-8F5F-4E92-8BFE-3E39E1A00586>