Fatal trap 12: page fault on Acer Chromebook 720 (peppy)
Michael Gmelin
freebsd at grem.de
Fri Aug 17 08:54:53 UTC 2018
> 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.
Thanks,
Michael
More information about the freebsd-current
mailing list