From owner-freebsd-arm@freebsd.org Mon Jun 29 04:54:21 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 04CB835DCAE for ; Mon, 29 Jun 2020 04:54:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.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 49wFWv5kzTz4JdR for ; Mon, 29 Jun 2020 04:54:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: EyC2U9sVM1mRX8TQFFsc6qIpFZB3aFD74jgD6bdQQ8SMNNTGe1loQaZsoGf8ICA F9CF4obZTM.hMfKG0Ruhvot1.2g7L9FQK9U9oBeOfPZxeDyJmbl0.JY2GEM5lxA5LfZyzvdX2FU6 RwjCDAAQlZv46GU3JQrZLUozE3DlArIDBwMlf4lOpZTlSmCSLELtKbVTkhdY_iR3CibpQaAmAA1a WgqLT_dqcazLangJlHZD_CS8oR.ByLQMvltWymZeWH03FvsTphZ2JLYyHtA.59WAtHnz2jsHFLuH wgoaQzNU9Kt4vOQfXg7UsyphflmFB2ElfjYK0y0buy.n6sgVk6eLd7GxyBrCRIrwFXlaL_AY1pZ7 d9qACrII2z7GZCfVSjqTXWyltVCyYKKjoNMJSmEshrxBtSzOPbD0aN1_zNNDRt84tb6JmL.JEgl1 ..A4gH8aTuqc_nFI6_6uOPGVz6Q0XnEa9.LIoCpKVg9F7njKew7.J8SJvE8uPQo2jApJ3CQPksWB zt36vayne0ZdUkcNixZ522nZlxQJbNZyn1wvYY1F9Kr16Xh3tuIZ6TsD52Kn5a0Axa4bP5QkLy.3 5u1Xft5_fY8f04_sUzPzbdwyK80s3HKYcphVzM5nTWjDswS8HymFxxzg9xhimwgr8MCvThhO5HBC yZe.7bxjAtvNO0rwnvOtKFiGZTIfaDnnYPuNtsfq6Oil6OYxt7iM.EpH4UdbOdWJHY93VTcaFI.e wG4SjlOHuoVaeHCUIbii1RT7nUp2a6vPFA.HkVSgeZDCZcalWPLyFMAvZCAz5e6MhByWNBwAVZ9t lHxmdtNIZyF1mSuF2Qj93NjPtJHXpCJCUAbiyBwbEB.f5Qu.MXO.62bylAncyajEGhMlU0GV.b7s a1Mdkn7.rbxbi6WMo_GfkPBCq_Mm00xgJb_wtwkzcvnZBqEIkNfgic4S1u_UbOVXQopqoSjhVzpJ nA61FNpYh7XKaySgLcMmdoTHgPrGrqxgNr67RrfO_ip2sUjcJYVLXLMcChxBMBx8BC8Zxg33yQDA epj2GnUndPWxCmN14rItfG1.jxXNUBu2lOd09JbNDVaSnMN9w9G9JBK1ofpNPK0Y2wF8qZX8cFSy ld.hdTXYXd0k5vA9stWVkkEeKBVj_ok76rCKgqGgl3YT2aw9cqphlzEcMyuZeUCZMLnHpbI_.n58 0xJbnqOZa.jOHgQ6MGUWmQKyKKwgL.c.hvfFSWV6CG9eO6dEfhRHehVS0byD8jn3hp07vxvDpycU .48I72YwCIt1U6WxpN8M7ePrUi5NhmuzVIVDoN8ngtOeuDs9FCRk8f5K9YJ9fc.rYYKeQ4jrbrto UZjNJhrLXAn6OVZ9m2u5MAiVhwnRjA8f4_en_bf8CXv6O6wX.CYz1Tg5I8Y2q2S30fdHfeJSPjR5 YFlH2UoN18pmyZllDM11nMbOI0A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Mon, 29 Jun 2020 04:54:18 +0000 Received: by smtp427.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8c08bebe47b4809dd7f3ae2f8de5dc35; Mon, 29 Jun 2020 04:54:13 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: panic: non-current pmap on RPI3 on CURRENT (GENERIC) #4 r356366 From: Mark Millard In-Reply-To: <20200629011123.GB10909@www.zefox.net> Date: Sun, 28 Jun 2020 21:54:12 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <5174EF62-E48B-4AB1-B11D-EAF5E08C74DB@yahoo.com> References: <20200108235630.GA17485@www.zefox.net> <20200109115123.GZ23031@kib.kiev.ua> <20200109172314.GA20008@www.zefox.net> <20200628195043.GA10909@www.zefox.net> <875C12B8-1E71-4808-AD3E-1B44D0AD9AF4@yahoo.com> <20200629011123.GB10909@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49wFWv5kzTz4JdR X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.41 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.146:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-0.96)[-0.957]; NEURAL_HAM_MEDIUM(-0.96)[-0.963]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.146:from]; NEURAL_HAM_SHORT(-0.99)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 04:54:21 -0000 On 2020-Jun-28, at 18:11, bob prohaska wrote: > On Sun, Jun 28, 2020 at 05:21:33PM -0700, Mark Millard wrote: >> On 2020-Jun-28, at 12:50, bob prohaska wrote: >> >>> I'll update OS sources and try again, if somebody can tell me >>> how to capture more useful information I'll try that. >> >> Do you have your system set up to allow it to >> dump to the swap/paging space for panics and >> then to put a copy in the /var/crash/ area during >> the next boot? Konstantin B. was asking for >> information from such a dump. >> > Ahh, that might be a little beyond my skill level.... > The system is basically default -current, no kernel > options. In fact, I'm no longer sure where to put them > when using buildkernel. Actually, head (i.e, current) by default builds a debug kernel. stable and release do not. (My builds usually have the debug disabled, but I explicitly cause that.) >> Note: A dump can be requested at the db> prompt >> by typing a "dump" command at the prompt, if you >> have set up to have a dump target identified, >> usually a swap/paging partition. If it works, the >> next boot would take some time putting material >> into /var/crash. >> > I'll try next time it happens. Looks like the system > defaults turn on dumpdev and savecore. Your swap partition where dumpdev points needs to be big enough. From past experience, your likely are. >> Do you have devel/gdb installed? It supplies a >> /usr/local/bin/kgdb for looking at such vmcore.* >> files. > > Not yet. These days head based builds do not provide their own kgdb support. It can be a good idea to have devel/gdb installed even if you do not normally use it. It gets messy if something goes wrong such that building and installing devel/gdb ends up then being a difficulty after the fact. >> >> It is important that the kernel debug information >> still match the vmcore as I understand, even if >> that means needing to boot a different, >> sufficiently-working kernel that does not match the >> debug information in order to get the /var/crash >> materials in place and to inspect them. >> >> I'm not sure you could do as Konstantin requested >> based on a non-debug kernel build done the usual >> way, even with debug information present. >> > One step at a time..... 8-) Looks like you have a debug kernel build, likely with the debug information. And your problem does not prevent you from booting the same kernel that panicked and using the system after that. >> Are you using a non-debug kernel? A debug-kernel? > > The embarrasing truth is I don't know. Whatever is > default in -current for the Pi3. Debug-kernel. >> You might need to try reproducing with a debug >> kernel. (But that likely will make builds >> take longer.) >> > Any sense of how much longer? A chromium build, > when it worked, took a week. You have already seen the time frames because you have been using the debug kernel. If you have noticed stable being faster then head, the kernel being non-debug for stable by default vs. debug for head by default is likely part of the issue. Witness checks, asserts, etc. take extra time. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)