From owner-freebsd-arm@freebsd.org Sun Mar 15 07:49:35 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 41F0A2623F7 for ; Sun, 15 Mar 2020 07:49:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (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 48gBR158R2z4Qqq for ; Sun, 15 Mar 2020 07:49:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: .zJQKb4VM1mWd52P9M6i0IQB75fydAcFSMIJMSXJkVDJqiv8gY8C1LsY_4h8H1D iQcJ6YppbU8Ypq5fS0eSJ9W07XY2QJ9SHciXV7kLDrK4yF1WNB4ZtPhynH8t9KuFkbf3n2E.g_9_ sdQURdm64RWwZHi6RxQZckoWp34cY9lbxNxc6OPj2wJSsZUIzECJ01OlHUFLlEvMxYI0SzJsLzhf szj_jM.A1OrdntuFbMzUpshXWEU1IJCXAwgGKnWKKFSycKGD8UTJmUzfUP6sHGphUHc5Bg64hU22 zt6.A6yWZftbojhvimLVEHXclfRZtjKKHBtk8ujPdlhGCxjQ2DrLtx553YQAQVlb.C8zcHgG8PUp 6wtESrqk1bkYGp1egil9_eyJrzUlPdVMjRlHlntdyfl0YyElfoU01dCZX8PAHIFU1r.IOLKykmV1 c5jIifkUjnwMPF.pzzPEWskiHf8K5GxQStJ_RP9bLTkF_04niOPvEXa5ozoyveQ_fNU31rigJ1i5 Y35WY_rd7zs6ESCjqWaIiRwsp7u4fDzuwbeJs2Epi_d0eRugfRqWDao_qqTuyGdGQ05O6dSX7olo mHmGBi_2rKah5xBbYM1kCpJHUSbqw_wfd8cWHsAJn9oJhI9FB_Vo92EMEggnyd_3SGy_4JmZN9At BMp8XFAu5wZsXLCinryFZuOZo2go1x0li3iSQDu_BKxHuOqgIfru5BCHEr6X5oxMNfRPqP5p2hAd w65OmVsBnicX7xKJ_KOI0ORb3K4L9lERnBwdGgx1NEEpDvuecaYIDkduZzIbLXgIOrZ2I_17BLpT AWzDU5FmFWITN5EWMMTNwWSSFARVMcGYJEP4n8i7Rlw7VG2VxyRsA8oN0YD5.hBODFakof7Mq3td ZmiAh4c16nKC66c8GNApsko8AOhlBNxn3LtI2qAeUKNgUldNRhosBflKA6fXR_iF8MDW_NyUn4TB zxa8faRB0GdO7n7BacJGYzJl1wE2z09Yhx0xHBlXR56oHd4.kgNfX741sjQ2t.AfMnTgSGfwRJRV MB9TgmlXZTjIVZK0zshdzNOx.5rYLH3lhBMFXDnUA9VyFkv2zlNWy2.d2MOL179lJ1VdLYA2fvH5 N3d_Q.qqQxnSFB2iBcTSXLEtkbTtLzKla6L9GW.0pX7CwH4vZUrGFIduSbteio5TpiYl2L4sAYzy iN7hy5rvwctYVBASosBM_ZB5OgYjN0Ba.rf.tSm2x.88G1dm10R7ysXOttQE.7HcuMSEgWO4W783 9hoMkWfduDQbDu8a.BOwnf8CD0Wec0dcIap3JNFcAWwyR4EDXQlhZiF1lAh4z5GrMs7aXYhO7ZLu Yl1Xugy7JfpXxszLpydKJhPt8RM8Eva6MKEWWgqXdD5glo1eDLbSfn5N71bM4JeNbAsmOpaLRRw0 F Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 15 Mar 2020 07:49:31 +0000 Received: by smtp410.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 3f66cc85a23549825c9a27b79d6c0c1d; Sun, 15 Mar 2020 07:49:28 +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: Pine64+2GB status? Is anyone else having the following sort of panic problem? Message-Id: <521CDF7F-8F5F-4E92-8BFE-3E39E1A00586@yahoo.com> Date: Sun, 15 Mar 2020 00:49:26 -0700 To: freebsd-arm X-Mailer: Apple Mail (2.3608.60.0.2.5) References: <521CDF7F-8F5F-4E92-8BFE-3E39E1A00586.ref@yahoo.com> X-Rspamd-Queue-Id: 48gBR158R2z4Qqq X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.46 / 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:36647, ipnet:98.137.64.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)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_MEDIUM(0.96)[0.961,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE_FREEMAIL(0.00)[]; IP_SCORE(0.00)[ip: (5.44), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; NEURAL_SPAM_LONG(1.00)[0.997,0]; RCVD_IN_DNSWL_NONE(0.00)[146.69.137.98.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: Sun, 15 Mar 2020 07:49:35 -0000 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)