Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

From: John Baldwin <jhb_at_FreeBSD.org>
Date: Fri, 17 Aug 2018 07:17:40 +0100
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)?

-- 
John Baldwin
Received on Fri Aug 17 2018 - 04:17:43 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:17 UTC