> On 17. Aug 2018, at 12:13, Konstantin Belousov <kostikbel_at_gmail.com> wrote: > >> On Fri, Aug 17, 2018 at 10:02:08AM +0100, John Baldwin wrote: >>> On 8/17/18 9:54 AM, Michael Gmelin wrote: >>> >>> >>>>> On 17. Aug 2018, at 08:17, John Baldwin <jhb_at_FreeBSD.org> wrote: >>>>> >>>>> On 8/16/18 1:58 PM, Michael Gmelin wrote: >>>>> >>>>> >>>>>>> On 15. Aug 2018, at 15:55, Konstantin Belousov <kostikbel_at_gmail.com <mailto:kostikbel_at_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 <kostikbel_at_gmail.com <mailto:kostikbel_at_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. > UP boot works ? > Well, I can boot if I remove atop(...) (reverting the patch). If this is what you mean.Received on Fri Aug 17 2018 - 10:19:56 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:17 UTC