On 8/17/18 9:54 AM, Michael Gmelin wrote: > > >> On 17. Aug 2018, at 08:17, John Baldwin <j...@freebsd.org> wrote: >> >>> On 8/16/18 1:58 PM, Michael Gmelin wrote: >>> >>> >>>> On 15. Aug 2018, at 15:55, Konstantin Belousov <kostik...@gmail.com >>>> <mailto:kostik...@gmail.com>> wrote: >>>> >>>>> On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote: >>>>> >>>>> >>>>>>> On 15. Aug 2018, at 15:04, Konstantin Belousov <kostik...@gmail.com >>>>>>> <mailto:kostik...@gmail.com>> wrote: >>>>>>> >>>>>>> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin wrote: >>>>>>> Reviving this old thread, since I just updated to r337818 and a similar >>>>>>> problem is happening again. Since the fix in r334799 (review >>>>>>> https://reviews.freebsd.org/D15675) (mp_)machdep.c have been touched, >>>>>>> so maybe this is related >>>>>>> (https://svnweb.freebsd.org/base?view=revision&revision=334799). >>>>>>> >>>>>>> Please see the screenshot of the panic below: >>>>>>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658 >>>>>>> >>>>>>> This is me not digging any deeper, hoping that this is something >>>>>>> obvious. Please let me know if you need more input. >>>>>> >>>>>> I do not see how recent mp_machdep.c changes could affect this. >>>>>> Can you try newest kernel but old loader ? >>>>> >>>>> I will try (but that will take a while). Oh, also, it still boots in save >>>>> mode/with smp disabled. >>>> >>>> Right, this is because the access to that address through DMAP is only >>>> needed when configuring AP startup resources. >>>> >>>> Also, I think it is safe to suggest that the bisect is needed. >>> >>> Using an older loader didn’t help, but I identified the problem: >>> >>> https://svnweb.freebsd.org/base?view=revision&revision=334952 >>> >>> modified the code you introduced in >>> >>> https://svnweb.freebsd.org/base?view=revision&revision=334799 >>> >>> By correcting units to pages it also broke booting the Chromebook as a side >>> effect - so the previous fix just worked due to a bug it seems. >>> >>> Is there an easy way to output the content of physmap at that point >>> (debug.late_console=0 doesn’t work) - like an existing buffer I could use, >>> or would this be more elaborate (I did something complicated last time but >>> didn’t save it, so any simple solution would be preferred). >> >> How about reverting the commit for now so you get a working console >> and print out the physmap array values along with Maxmem later in >> the boot (or just use kgdb to examine them once the system is running)? >> > > This is before the system has a working console (part of calling getmem...), > disabling late console makes it hang, physmap changes afterwards, so running > kgdb later doesn’t help. Last time I kept a copy of physmap and logged it > later to know the original content. I can do that again, I just thought maybe > there is a simple mechanism I’m not aware of that would save me some time.
I thought we only modified phys_avail[], but saving a copy of physmap[] and dumping it from kgdb is probably the simplest thing to do. -- John Baldwin _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
