> On 17. Aug 2018, at 12:13, Konstantin Belousov <kostik...@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 <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.
> UP boot works ?
>
Well, I can boot if I remove atop(...) (reverting the patch). If this is what
you mean.
_______________________________________________
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"