Date: Sun, 28 Jun 2020 21:54:12 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: panic: non-current pmap on RPI3 on CURRENT (GENERIC) #4 r356366 Message-ID: <5174EF62-E48B-4AB1-B11D-EAF5E08C74DB@yahoo.com> In-Reply-To: <20200629011123.GB10909@www.zefox.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Jun-28, at 18:11, bob prohaska <fbsd at www.zefox.net> wrote: > On Sun, Jun 28, 2020 at 05:21:33PM -0700, Mark Millard wrote: >> On 2020-Jun-28, at 12:50, bob prohaska <fbsd at www.zefox.net> 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5174EF62-E48B-4AB1-B11D-EAF5E08C74DB>