Date: Wed, 18 Mar 2020 15:35:40 -0700 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Pine64+2GB status? Is anyone else having the following sort of panic problem? Message-ID: <23F8584A-56F6-4D94-B5B5-4E673269F479@yahoo.com> In-Reply-To: <3B9DF93B-6E7E-49B2-B253-DE268317323E@yahoo.com> References: <521CDF7F-8F5F-4E92-8BFE-3E39E1A00586@yahoo.com> <3B9DF93B-6E7E-49B2-B253-DE268317323E@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Mar-17, at 11:59, Mark Millard <marklmi at yahoo.com> wrote: > 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) . . . > Well, I tried setting up the Pine64+ 2GB to have the /boot/loader.conf on the microsd card use vfs.root.mountfrom to redirect to an external USB SDD drive, a configuration I'd used for years previously. (Same equipment as back then --but it has been a significant time since I'd done that.) I'm not claiming a common cause with the microsd card context, but the result of sitting idle eventually had problems with writing to the USB SSD: some writes with retries until failure. This did not crash the Pine but /var/log/messasges logging the notices was one of the files that had failed I/O. (It ended up with some blocks of '\0' characters where the console had shown notices.) I've still no clue of if the Pine64+ 2GB is having hardware related problems (such as, say, power) or if there are problems relative to software. With both microsd cards and USB drives being unreliable, it is not obvious that further activity with the Pine64+ 2GB is worthwhile. I do not have a good means of isolating the issue. (It was my 2 GiByte RAM example for aarch64 FreeBSD.) === 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?23F8584A-56F6-4D94-B5B5-4E673269F479>