From owner-freebsd-arm@freebsd.org Wed Mar 18 22:35:48 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8E0D026F6FA for ; Wed, 18 Mar 2020 22:35:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-22.consmr.mail.ne1.yahoo.com (sonic306-22.consmr.mail.ne1.yahoo.com [66.163.189.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48jPyB2Yrvz4TmH for ; Wed, 18 Mar 2020 22:35:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ZxkKI.EVM1l22__0lG6dyanLfEaX_kyvTPxXrc_YDWWjr8axklaAGs7kOwExi3P _wKCzbZ.fKaZCiQY.JBGVSSUMyEKRZT51FEoxG3vrNAWkweExjlBhm.PEuDZL_18Reab2737ACq7 bSnVH.WFLosOv3ybYfLaehEuH5DuBzBHdCygiH0zHK3p0CBPXmM_WLyV2Ae2pide0Xq4GHi8j6_u KLfLHWTwTQusVGlCep0tKFUO2SWFn6JZ0Y8Jqd5oIJUH9thwM9SVAjSheg2GO9z2Rr.VlNWYfeCS vholfg8Nd2CZhsKFt_vEypmHBD3kx4aKfCjak2FOdGNUz1ae0nBO7b2HWZNEhYIpuxsMlNQKEnVT 6DOpGe_v7In0mGjDDw0.dwtZPmXXpXSgMbdwSOLVz19aKHMZsz_f0_h746xV5GpahJDw9wt594SK WC1ah8VPndbgwG0ccrEO2kWBVyUTfR.adOw2DwV0OrEGrQehvGk7qkzlEe6b1SZml376H0Cidq7Q hSgpOUhJVP4OK8YuXwPurxKoH8c1hR9n6GM5VbBU3DnZQ_gWUVmXLhGUgQf6xhicFhvJAFtf1Tsl MC8JacIra_5j.nhzL3vkBHqjnGnAV5oS6i0eYx0x5XrNQxWukZMiM2EJfJeUhHAEVjF0vFFzF5R7 dUKrAwhGyZLYwJwaoech2E7hoPcRPZTK6564HHxlPssBtkXPm3V_d8D6MeuuOY.m_La9om0h7cfV OtI1GtT14BFhYwyQ8AQ.1wj7tnoWb8CPSxbLXEm5EsJhDePWYQlRjA9Ck_k.jsvLOSXY8oBkXagQ zEcQ7ngf_G7GTfH1uRpILhjv9b9EwluUFxiVWyHRpZPktEVjp1hdfBgtLX5paBQY.BTjAkHve7G7 0CwwNhbmnbRY.xUtjAOO_IDS0aN8oY43Yj_sqM6j_djeUxnetQkdwi.0IaAF3vQwFcw2k.MscHKW o.RwSeHU5qCgHQnynpxOjzQdOwfRtTdspZs_QnuE6QfzPH8zzhQHI2sFbq56pjkTDKalTz52e4QX jTm7OHxzMPaYnem7Zc6gAI1D5rmj6vRXoxl7gi5F0MwCi562cMe.FEtXtiNC.IzEcCxJpKOG4XM8 dvVZoFO1w9V8Jti0kY1Xy2nUP6Vc.fgQXduv3iM.ZY2r9cFCAgNQFtRraylL5YS6EPpWh51fYRkc .LBANWR4Pe1_PjAdZAJmdZcpe7IcO65msXjm2yxmN4HbyHgpPxPasjOwhN7__Ioj.sNlWP_YTcNi N3UQ_4S6MLMzNTq3K_9oS3ozdhh2RGMCWUAP5sD3gpgaLyGRXTygr4v73OtAlZnoLUesZnxrCBd9 _ofZdJzvEmbAep30zP4xtH2xnEWCKsNFM7X0ukevwZehLOQVJkjs.dTMdZrHd_9FAQsRZfdAY5X1 e1zBPOQGAICiaAb6o39XNRHwzr2HJX_fLqFEqAoUHIbqS Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Wed, 18 Mar 2020 22:35:44 +0000 Received: by smtp432.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 96196b576e3d1439bbe225da48ffbe40; Wed, 18 Mar 2020 22:35:41 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: Pine64+2GB status? Is anyone else having the following sort of panic problem? Date: Wed, 18 Mar 2020 15:35:40 -0700 References: <521CDF7F-8F5F-4E92-8BFE-3E39E1A00586@yahoo.com> <3B9DF93B-6E7E-49B2-B253-DE268317323E@yahoo.com> To: freebsd-arm In-Reply-To: <3B9DF93B-6E7E-49B2-B253-DE268317323E@yahoo.com> Message-Id: <23F8584A-56F6-4D94-B5B5-4E673269F479@yahoo.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Rspamd-Queue-Id: 48jPyB2Yrvz4TmH X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.49 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_NEUTRAL(0.00)[84.189.163.66.rep.mailspike.net : 127.0.0.13]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.994,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE_FREEMAIL(0.00)[]; IP_SCORE(0.00)[ip: (4.01), ipnet: 66.163.184.0/21(1.18), asn: 36646(0.94), country: US(-0.05)]; NEURAL_SPAM_LONG(1.00)[1.000,0]; RCVD_IN_DNSWL_NONE(0.00)[84.189.163.66.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 22:35:48 -0000 On 2020-Mar-17, at 11:59, Mark Millard wrote: > On 2020-Mar-15, at 00:49, Mark Millard 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)