subject:"Fatal trap 12\: page fault on Acer Chromebook 720 \(peppy\)"

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

2018-08-29 Thread Michael Gmelin




On Wed, 29 Aug 2018 11:21:05 +0200
Michael Gmelin  wrote:

> On Sun, 26 Aug 2018 16:04:35 +0300
> Konstantin Belousov  wrote:
> 
> > On Sat, Aug 25, 2018 at 07:21:28PM +0200, Michael Gmelin wrote:  
> > > Now, with the patch applied correctly, the machine actually boots.
> > > 
> > > Before calling init_ops.mp_bootaddress in
> > > getmemsize (machdep.c), physmap looks like this:
> > > 
> > > physmap_idx: 8
> > > i mem atop
> > > 0 0x0 0x0
> > > 1 0x3 0x30
> > > 2 0x4 0x40
> > > 3 0x9e400 0x9e
> > > 4 0x10 0x100
> > > 5 0xf0 0xf00
> > > 6 0x100 0x1000
> > > 7 0x7bf7a000 0x7bf7a
> > > 8 0x1 0x10
> > > 9 0x10060 0x100600
> > > 10 0x0 0x0
> > > 
> > > With your patch, it looks like this now
> > > (after calling getmemsize)
> > > 
> > > 0 0x0 0x0
> > > 1 0x3 0x30
> > > 2 0x4 0x40
> > > 3 0x9e400 0x9e
> > > 4 0x10 0x100
> > > 5 0xf0 0xf00
> > > 6 0x100 0x1000
> > > 7 0x7bf77000 0x7bf77
> > > 8 0x1 0x10
> > > 9 0x10060 0x100600
> > > 10 0x0 0x0
> > > PAGETABLES is 0x7bf77000
> > > 
> > > So I guess this means that the gap is now at the last three pages
> > > of [0x1000, 0x7bf7a[.
> > > 
> > > If this is what was intended, I guess it's good, as the machine
> > > boots okay now.
> > 
> > It triggered the new code to chomp at the end of the suitable range,
> > instead of the start. Anyway, to do that, it must evaluated the
> > start of the range as intersecting with the kernel text, which I
> > interpret as success.
> > 
> > I put a review with the change at D16907.
> >   
> > > 
> > > Sorry again for the extra roundtrip, the patched file was simply
> > > in the wrong path.
> > 
> > No problem.  
> 
> Just to close the loop on this: This was fixed in r338858, thanks to
> kib@ for analyzing the problem and creating a patch and to jhb@ for
> reviewing it.
> 

The actual revision this was fixed in is r338356
(https://svnweb.freebsd.org/base?view=revision&revision=338356), I
tested r338358 (world+kernel) to verify the fix.

Best,
Michael

-- 
Michael Gmelin
___
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"

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

2018-08-29 Thread Michael Gmelin




On Sun, 26 Aug 2018 16:04:35 +0300
Konstantin Belousov  wrote:

> On Sat, Aug 25, 2018 at 07:21:28PM +0200, Michael Gmelin wrote:
> > Now, with the patch applied correctly, the machine actually boots.
> > 
> > Before calling init_ops.mp_bootaddress in
> > getmemsize (machdep.c), physmap looks like this:
> > 
> > physmap_idx: 8
> > i mem atop
> > 0 0x0 0x0
> > 1 0x3 0x30
> > 2 0x4 0x40
> > 3 0x9e400 0x9e
> > 4 0x10 0x100
> > 5 0xf0 0xf00
> > 6 0x100 0x1000
> > 7 0x7bf7a000 0x7bf7a
> > 8 0x1 0x10
> > 9 0x10060 0x100600
> > 10 0x0 0x0
> > 
> > With your patch, it looks like this now
> > (after calling getmemsize)
> > 
> > 0 0x0 0x0
> > 1 0x3 0x30
> > 2 0x4 0x40
> > 3 0x9e400 0x9e
> > 4 0x10 0x100
> > 5 0xf0 0xf00
> > 6 0x100 0x1000
> > 7 0x7bf77000 0x7bf77
> > 8 0x1 0x10
> > 9 0x10060 0x100600
> > 10 0x0 0x0
> > PAGETABLES is 0x7bf77000
> > 
> > So I guess this means that the gap is now at the last three pages
> > of [0x1000, 0x7bf7a[.
> > 
> > If this is what was intended, I guess it's good, as the machine
> > boots okay now.  
> 
> It triggered the new code to chomp at the end of the suitable range,
> instead of the start. Anyway, to do that, it must evaluated the start
> of the range as intersecting with the kernel text, which I interpret
> as success.
> 
> I put a review with the change at D16907.
> 
> > 
> > Sorry again for the extra roundtrip, the patched file was simply in
> > the wrong path.  
> 
> No problem.

Just to close the loop on this: This was fixed in r338858, thanks to
kib@ for analyzing the problem and creating a patch and to jhb@ for
reviewing it.

Yours,
Michael

-- 
Michael Gmelin
___
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"

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

2018-08-26 Thread Konstantin Belousov

On Sat, Aug 25, 2018 at 07:21:28PM +0200, Michael Gmelin wrote:
> Now, with the patch applied correctly, the machine actually boots.
> 
> Before calling init_ops.mp_bootaddress in
> getmemsize (machdep.c), physmap looks like this:
> 
> physmap_idx: 8
> i mem atop
> 0 0x0 0x0
> 1 0x3 0x30
> 2 0x4 0x40
> 3 0x9e400 0x9e
> 4 0x10 0x100
> 5 0xf0 0xf00
> 6 0x100 0x1000
> 7 0x7bf7a000 0x7bf7a
> 8 0x1 0x10
> 9 0x10060 0x100600
> 10 0x0 0x0
> 
> With your patch, it looks like this now
> (after calling getmemsize)
> 
> 0 0x0 0x0
> 1 0x3 0x30
> 2 0x4 0x40
> 3 0x9e400 0x9e
> 4 0x10 0x100
> 5 0xf0 0xf00
> 6 0x100 0x1000
> 7 0x7bf77000 0x7bf77
> 8 0x1 0x10
> 9 0x10060 0x100600
> 10 0x0 0x0
> PAGETABLES is 0x7bf77000
> 
> So I guess this means that the gap is now at the last three pages of [0x1000, 
> 0x7bf7a[.
> 
> If this is what was intended, I guess it's good, as the machine boots okay 
> now.

It triggered the new code to chomp at the end of the suitable range,
instead of the start. Anyway, to do that, it must evaluated the start
of the range as intersecting with the kernel text, which I interpret as
success.

I put a review with the change at D16907.

> 
> Sorry again for the extra roundtrip, the patched file was simply in the wrong 
> path.

No problem.
___
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"

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

2018-08-25 Thread Michael Gmelin

>> On 24. Aug 2018, at 22:39, Konstantin Belousov  wrote:
>> 
>> On Fri, Aug 24, 2018 at 10:32:06PM +0200, Michael Gmelin wrote:
>> 
>> 
>>> On 24. Aug 2018, at 21:59, Konstantin Belousov  wrote:
>>> Please apply the following debugging patch on top of the previous 'fix'.
>>> You need debug.late_console=0.
>> 
>> Unfortunately debug.late_console=0 doesn???t work on this machine (no more 
>> output on the console), I tried that earlier in this thread - hence the 
>> slightly complicated debugging code I had to add to see the contents of 
>> physmap.
>> 
>> I could run this code after boot (feeding it an identical physmap) to get 
>> debug output, would this make sense?
> Yes, with exactly the same physmap[].
> 
> Really, I do not need exactly the output from my patch, but just make it
> clear why is_kernel_paddr() did not triggered selection from different
> location.

I have to apologize, something went wrong
when I applied your previous fix, so it was never really used when I tested.

Now, with the patch applied correctly, the machine actually boots.

Before calling init_ops.mp_bootaddress in
getmemsize (machdep.c), physmap looks like this:

physmap_idx: 8
i mem atop
0 0x0 0x0
1 0x3 0x30
2 0x4 0x40
3 0x9e400 0x9e
4 0x10 0x100
5 0xf0 0xf00
6 0x100 0x1000
7 0x7bf7a000 0x7bf7a
8 0x1 0x10
9 0x10060 0x100600
10 0x0 0x0

With your patch, it looks like this now
(after calling getmemsize)

0 0x0 0x0
1 0x3 0x30
2 0x4 0x40
3 0x9e400 0x9e
4 0x10 0x100
5 0xf0 0xf00
6 0x100 0x1000
7 0x7bf77000 0x7bf77
8 0x1 0x10
9 0x10060 0x100600
10 0x0 0x0
PAGETABLES is 0x7bf77000

So I guess this means that the gap is now at the last three pages of [0x1000, 
0x7bf7a[.

If this is what was intended, I guess it's good, as the machine boots okay now.

Sorry again for the extra roundtrip, the patched file was simply in the wrong 
path.

Yours,
Michael

p.s. Please see below the patched version of
mp_machdep.c I used for testing (should match yours):

...
#defineAP_BOOTPT_SZ(PAGE_SIZE * 3)

externstruct pcpu __pcpu[];

/* Temporary variables for init_secondary()  */
char *doublefault_stack;
char *mce_stack;
char *nmi_stack;
char *dbg_stack;

/*
* Local data and functions.
*/

static intstart_ap(int apic_id);

static bool
is_kernel_paddr(vm_paddr_t pa)
{

 return (pa >= trunc_2mpage(btext - KERNBASE) &&
pa < round_page(_end - KERNBASE));
}

static bool
is_mpboot_good(vm_paddr_t start, vm_paddr_t end)
{

 return (start + AP_BOOTPT_SZ <= GiB(4) &&
 end >= start + AP_BOOTPT_SZ && atop(end) < Maxmem);
}

/*
* Calculate usable address in base memory for AP trampoline code.
*/
void
mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx)
{
 vm_paddr_t start, end;
 unsigned int i;
 bool allocated;

 alloc_ap_trampoline(physmap, physmap_idx);

 /*
  * Find a memory region big enough below the 4GB boundary to
  * store the initial page tables.  Region must be mapped by
  * the direct map.
  *
  * Note that it needs to be aligned to a page boundary.
  */
 allocated = false;
 for (i = *physmap_idx; i <= *physmap_idx; i -= 2) {
 /*
  * First, try to chomp at the start of the physmap region.
  * Kernel binary might claim it already.
  */
 start = round_page(physmap[i]);
 end = trunc_page(physmap[i + 1]);
 if (is_mpboot_good(start, end) &&
 !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) {
 allocated = true;
 physmap[i] = start + AP_BOOTPT_SZ;
 break;
 }

 /*
  * Second, try to chomp at the end.  Again, check
  * against kernel.
  */
 end = trunc_page(physmap[i + 1]);
 start = end - AP_BOOTPT_SZ;
 if (start >= physmap[i] && is_mpboot_good(start, end) &&
 !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) {
 allocated = true;
 physmap[i + 1] = start;
 break;
 }
 }
 if (allocated) {
 mptramp_pagetables = start;
 if (physmap[i] == physmap[i + 1] && *physmap_idx != 0) {
 memmove(&physmap[i], &physmap[i + 2],
 sizeof(*physmap) * (*physmap_idx - i + 2));
 *physmap_idx -= 2;
 }
 } else {
 mptramp_pagetables = trunc_page(boot_address) - AP_BOOTPT_SZ;
 if (bootverbose)
 printf(
"Cannot find enough space for the initial AP page tables, placing them at %#x",
 mptramp_pagetables);
 }
}
...

___
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"

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

2018-08-24 Thread Konstantin Belousov

On Fri, Aug 24, 2018 at 10:32:06PM +0200, Michael Gmelin wrote:
> 
> 
> > On 24. Aug 2018, at 21:59, Konstantin Belousov  wrote:
> > Please apply the following debugging patch on top of the previous 'fix'.
> > You need debug.late_console=0.
> 
> Unfortunately debug.late_console=0 doesn???t work on this machine (no more 
> output on the console), I tried that earlier in this thread - hence the 
> slightly complicated debugging code I had to add to see the contents of 
> physmap.
> 
> I could run this code after boot (feeding it an identical physmap) to get 
> debug output, would this make sense?
> 
Yes, with exactly the same physmap[].

Really, I do not need exactly the output from my patch, but just make it
clear why is_kernel_paddr() did not triggered selection from different
location.


___
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"

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

2018-08-24 Thread Michael Gmelin



> On 24. Aug 2018, at 21:59, Konstantin Belousov  wrote:
> 
>> On Thu, Aug 23, 2018 at 12:10:34AM +0200, Michael Gmelin wrote:
>> 
>> 
 On 22. Aug 2018, at 23:15, Konstantin Belousov  wrote:
 
 On Wed, Aug 22, 2018 at 10:03:54PM +0200, Michael Gmelin wrote:
 
 
>> On 22. Aug 2018, at 17:46, Konstantin Belousov  
>> wrote:
>> 
>> On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote:
>> 
>> 
 On 20. Aug 2018, at 17:09, Konstantin Belousov  
 wrote:
 
 On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
 
 See here for a screenshot (also including the output of "show pte
 0xf8000100"):
 
 https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
>>> It is too early for ddb routines to register.
>>> Ok can you try the following debugging patch, to verify my guess ?
>>> 
>>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
>>> index 18777d23f09..cd05fdb763f 100644
>>> --- a/sys/amd64/amd64/pmap.c
>>> +++ b/sys/amd64/amd64/pmap.c
>>> @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
>>> pd_p = (pd_entry_t *)DMPDkernphys;
>>> for (i = 0; i < (NPDEPG * nkdmpde); i++)
>>> pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
>>> -X86_PG_M | X86_PG_A | pg_nx |
>>> -bootaddr_rwx(i << PDRSHIFT);
>>> +X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
>>> for (i = 0; i < nkdmpde; i++)
>>> pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
>>> X86_PG_V;
>> 
>> With this change it boots okay (mptramp_pagetables is 0x100, as 
>> expected).
> 
> Can you apply the following on top of the previous debugging patch and 
> show
> me the line printed ?
> 
> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> index 3d70532b7fd..613fa9f2165 100644
> --- a/sys/amd64/amd64/pmap.c
> +++ b/sys/amd64/amd64/pmap.c
> @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap)
>  pmap->pm_pcids[i].pm_gen = 1;
>  }
>  pmap_activate_boot(pmap);
> +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx 
> etext %#lx KERNBASE %#lx\n", 0x100UL, bootaddr_rwx(0x100UL), 
> (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, 
> (uintptr_t)etext, (uintptr_t)KERNBASE);
> }
> 
> void
 
 bootaddr addr 0x100 rwx 0 btext 0x80342000 _end 
 0x823cf840 brwsection #81a0 etext 0x812041e4 
 KERNBASE 0x8000
 
>>> 
>>> Try this, please.  Revert all debugging pmap.c patches that I provided
>>> before.
>>> 
>>> diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
>>> index 4ca2e07e578..2ee8f862854 100644
>>> --- a/sys/amd64/amd64/mp_machdep.c
>>> +++ b/sys/amd64/amd64/mp_machdep.c
>>> @@ -87,6 +87,8 @@ __FBSDID("$FreeBSD$");
>>> 
>>> #define GiB(v)(v ## ULL << 30)
>>> 
>>> +#defineAP_BOOTPT_SZ(PAGE_SIZE * 3)
>>> +
>>> externstruct pcpu __pcpu[];
>>> 
>>> /* Temporary variables for init_secondary()  */
>>> @@ -101,45 +103,78 @@ char *dbg_stack;
>>> 
>>> static intstart_ap(int apic_id);
>>> 
>>> +static bool
>>> +is_kernel_paddr(vm_paddr_t pa)
>>> +{
>>> +
>>> +return (pa >= trunc_2mpage(btext - KERNBASE) &&
>>> +   pa < round_page(_end - KERNBASE));
>>> +}
>>> +
>>> +static bool
>>> +is_mpboot_good(vm_paddr_t start, vm_paddr_t end)
>>> +{
>>> +
>>> +return (start + AP_BOOTPT_SZ <= GiB(4) &&
>>> +end >= start + AP_BOOTPT_SZ && atop(end) < Maxmem);
>>> +}
>>> +
>>> /*
>>> * Calculate usable address in base memory for AP trampoline code.
>>> */
>>> void
>>> mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx)
>>> {
>>> +vm_paddr_t start, end;
>>>   unsigned int i;
>>>   bool allocated;
>>> 
>>>   alloc_ap_trampoline(physmap, physmap_idx);
>>> 
>>> +/*
>>> + * Find a memory region big enough below the 4GB boundary to
>>> + * store the initial page tables.  Region must be mapped by
>>> + * the direct map.
>>> + *
>>> + * Note that it needs to be aligned to a page boundary.
>>> + */
>>>   allocated = false;
>>>   for (i = *physmap_idx; i <= *physmap_idx; i -= 2) {
>>>   /*
>>> - * Find a memory region big enough below the 4GB
>>> - * boundary to store the initial page tables.  Region
>>> - * must be mapped by the direct map.
>>> - *
>>> - * Note that it needs to be aligned to a page
>>> - * boundary.
>>> + * First, try to chomp at the start of the physmap region.
>>> + * Kernel binary might claim it already.
>>> + */
>>> +start = round_page(physmap[i]);
>>> +end = trunc_page(physmap[i + 1]);
>>> +if (is_mpboot_good(start, end) &&

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

2018-08-24 Thread Konstantin Belousov

On Thu, Aug 23, 2018 at 12:10:34AM +0200, Michael Gmelin wrote:
> 
> 
> > On 22. Aug 2018, at 23:15, Konstantin Belousov  wrote:
> > 
> >> On Wed, Aug 22, 2018 at 10:03:54PM +0200, Michael Gmelin wrote:
> >> 
> >> 
>  On 22. Aug 2018, at 17:46, Konstantin Belousov  
>  wrote:
>  
>  On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote:
>  
>  
> >> On 20. Aug 2018, at 17:09, Konstantin Belousov  
> >> wrote:
> >> 
> >> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
> >> 
> >> See here for a screenshot (also including the output of "show pte
> >> 0xf8000100"):
> >> 
> >> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
> > It is too early for ddb routines to register.
> > Ok can you try the following debugging patch, to verify my guess ?
> > 
> > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> > index 18777d23f09..cd05fdb763f 100644
> > --- a/sys/amd64/amd64/pmap.c
> > +++ b/sys/amd64/amd64/pmap.c
> > @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
> >  pd_p = (pd_entry_t *)DMPDkernphys;
> >  for (i = 0; i < (NPDEPG * nkdmpde); i++)
> >  pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
> > -X86_PG_M | X86_PG_A | pg_nx |
> > -bootaddr_rwx(i << PDRSHIFT);
> > +X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
> >  for (i = 0; i < nkdmpde; i++)
> >  pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
> >  X86_PG_V;
>  
>  With this change it boots okay (mptramp_pagetables is 0x100, as 
>  expected).
> >>> 
> >>> Can you apply the following on top of the previous debugging patch and 
> >>> show
> >>> me the line printed ?
> >>> 
> >>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> >>> index 3d70532b7fd..613fa9f2165 100644
> >>> --- a/sys/amd64/amd64/pmap.c
> >>> +++ b/sys/amd64/amd64/pmap.c
> >>> @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap)
> >>>   pmap->pm_pcids[i].pm_gen = 1;
> >>>   }
> >>>   pmap_activate_boot(pmap);
> >>> +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx 
> >>> etext %#lx KERNBASE %#lx\n", 0x100UL, bootaddr_rwx(0x100UL), 
> >>> (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, 
> >>> (uintptr_t)etext, (uintptr_t)KERNBASE);
> >>> }
> >>> 
> >>> void
> >> 
> >> bootaddr addr 0x100 rwx 0 btext 0x80342000 _end 
> >> 0x823cf840 brwsection #81a0 etext 0x812041e4 
> >> KERNBASE 0x8000
> >> 
> > 
> > Try this, please.  Revert all debugging pmap.c patches that I provided
> > before.
> > 
> > diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
> > index 4ca2e07e578..2ee8f862854 100644
> > --- a/sys/amd64/amd64/mp_machdep.c
> > +++ b/sys/amd64/amd64/mp_machdep.c
> > @@ -87,6 +87,8 @@ __FBSDID("$FreeBSD$");
> > 
> > #define GiB(v)(v ## ULL << 30)
> > 
> > +#defineAP_BOOTPT_SZ(PAGE_SIZE * 3)
> > +
> > externstruct pcpu __pcpu[];
> > 
> > /* Temporary variables for init_secondary()  */
> > @@ -101,45 +103,78 @@ char *dbg_stack;
> > 
> > static intstart_ap(int apic_id);
> > 
> > +static bool
> > +is_kernel_paddr(vm_paddr_t pa)
> > +{
> > +
> > +return (pa >= trunc_2mpage(btext - KERNBASE) &&
> > +   pa < round_page(_end - KERNBASE));
> > +}
> > +
> > +static bool
> > +is_mpboot_good(vm_paddr_t start, vm_paddr_t end)
> > +{
> > +
> > +return (start + AP_BOOTPT_SZ <= GiB(4) &&
> > +end >= start + AP_BOOTPT_SZ && atop(end) < Maxmem);
> > +}
> > +
> > /*
> >  * Calculate usable address in base memory for AP trampoline code.
> >  */
> > void
> > mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx)
> > {
> > +vm_paddr_t start, end;
> >unsigned int i;
> >bool allocated;
> > 
> >alloc_ap_trampoline(physmap, physmap_idx);
> > 
> > +/*
> > + * Find a memory region big enough below the 4GB boundary to
> > + * store the initial page tables.  Region must be mapped by
> > + * the direct map.
> > + *
> > + * Note that it needs to be aligned to a page boundary.
> > + */
> >allocated = false;
> >for (i = *physmap_idx; i <= *physmap_idx; i -= 2) {
> >/*
> > - * Find a memory region big enough below the 4GB
> > - * boundary to store the initial page tables.  Region
> > - * must be mapped by the direct map.
> > - *
> > - * Note that it needs to be aligned to a page
> > - * boundary.
> > + * First, try to chomp at the start of the physmap region.
> > + * Kernel binary might claim it already.
> > + */
> > +start = round_page(physmap[i]);
> > +end = trunc_page(physmap[i + 1]);
> > +if (is_mpboot_good(start, end) &&
> > +!is_kernel_paddr(start) && !is_kern

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

2018-08-22 Thread Michael Gmelin



> On 22. Aug 2018, at 23:15, Konstantin Belousov  wrote:
> 
>> On Wed, Aug 22, 2018 at 10:03:54PM +0200, Michael Gmelin wrote:
>> 
>> 
 On 22. Aug 2018, at 17:46, Konstantin Belousov  wrote:
 
 On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote:
 
 
>> On 20. Aug 2018, at 17:09, Konstantin Belousov  
>> wrote:
>> 
>> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
>> 
>> See here for a screenshot (also including the output of "show pte
>> 0xf8000100"):
>> 
>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
> It is too early for ddb routines to register.
> Ok can you try the following debugging patch, to verify my guess ?
> 
> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> index 18777d23f09..cd05fdb763f 100644
> --- a/sys/amd64/amd64/pmap.c
> +++ b/sys/amd64/amd64/pmap.c
> @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
>  pd_p = (pd_entry_t *)DMPDkernphys;
>  for (i = 0; i < (NPDEPG * nkdmpde); i++)
>  pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
> -X86_PG_M | X86_PG_A | pg_nx |
> -bootaddr_rwx(i << PDRSHIFT);
> +X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
>  for (i = 0; i < nkdmpde; i++)
>  pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
>  X86_PG_V;
 
 With this change it boots okay (mptramp_pagetables is 0x100, as 
 expected).
>>> 
>>> Can you apply the following on top of the previous debugging patch and show
>>> me the line printed ?
>>> 
>>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
>>> index 3d70532b7fd..613fa9f2165 100644
>>> --- a/sys/amd64/amd64/pmap.c
>>> +++ b/sys/amd64/amd64/pmap.c
>>> @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap)
>>>   pmap->pm_pcids[i].pm_gen = 1;
>>>   }
>>>   pmap_activate_boot(pmap);
>>> +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx 
>>> etext %#lx KERNBASE %#lx\n", 0x100UL, bootaddr_rwx(0x100UL), 
>>> (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, (uintptr_t)etext, 
>>> (uintptr_t)KERNBASE);
>>> }
>>> 
>>> void
>> 
>> bootaddr addr 0x100 rwx 0 btext 0x80342000 _end 
>> 0x823cf840 brwsection #81a0 etext 0x812041e4 
>> KERNBASE 0x8000
>> 
> 
> Try this, please.  Revert all debugging pmap.c patches that I provided
> before.
> 
> diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
> index 4ca2e07e578..2ee8f862854 100644
> --- a/sys/amd64/amd64/mp_machdep.c
> +++ b/sys/amd64/amd64/mp_machdep.c
> @@ -87,6 +87,8 @@ __FBSDID("$FreeBSD$");
> 
> #define GiB(v)(v ## ULL << 30)
> 
> +#defineAP_BOOTPT_SZ(PAGE_SIZE * 3)
> +
> externstruct pcpu __pcpu[];
> 
> /* Temporary variables for init_secondary()  */
> @@ -101,45 +103,78 @@ char *dbg_stack;
> 
> static intstart_ap(int apic_id);
> 
> +static bool
> +is_kernel_paddr(vm_paddr_t pa)
> +{
> +
> +return (pa >= trunc_2mpage(btext - KERNBASE) &&
> +   pa < round_page(_end - KERNBASE));
> +}
> +
> +static bool
> +is_mpboot_good(vm_paddr_t start, vm_paddr_t end)
> +{
> +
> +return (start + AP_BOOTPT_SZ <= GiB(4) &&
> +end >= start + AP_BOOTPT_SZ && atop(end) < Maxmem);
> +}
> +
> /*
>  * Calculate usable address in base memory for AP trampoline code.
>  */
> void
> mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx)
> {
> +vm_paddr_t start, end;
>unsigned int i;
>bool allocated;
> 
>alloc_ap_trampoline(physmap, physmap_idx);
> 
> +/*
> + * Find a memory region big enough below the 4GB boundary to
> + * store the initial page tables.  Region must be mapped by
> + * the direct map.
> + *
> + * Note that it needs to be aligned to a page boundary.
> + */
>allocated = false;
>for (i = *physmap_idx; i <= *physmap_idx; i -= 2) {
>/*
> - * Find a memory region big enough below the 4GB
> - * boundary to store the initial page tables.  Region
> - * must be mapped by the direct map.
> - *
> - * Note that it needs to be aligned to a page
> - * boundary.
> + * First, try to chomp at the start of the physmap region.
> + * Kernel binary might claim it already.
> + */
> +start = round_page(physmap[i]);
> +end = trunc_page(physmap[i + 1]);
> +if (is_mpboot_good(start, end) &&
> +!is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) {
> +allocated = true;
> +physmap[i] = start + AP_BOOTPT_SZ;
> +break;
> +}
> +
> +/*
> + * Second, try to chomp at the end.  Again, check
> + * against kernel.
> */
> -if (physmap[i] >= GiB(4) || physmap[i + 1] -
> -round_page(physmap[i]

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

2018-08-22 Thread Konstantin Belousov

On Wed, Aug 22, 2018 at 10:03:54PM +0200, Michael Gmelin wrote:
> 
> 
> > On 22. Aug 2018, at 17:46, Konstantin Belousov  wrote:
> > 
> >> On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote:
> >> 
> >> 
>  On 20. Aug 2018, at 17:09, Konstantin Belousov  
>  wrote:
>  
>  On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
>  
>  See here for a screenshot (also including the output of "show pte
>  0xf8000100"):
>  
>  https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
> >>> It is too early for ddb routines to register.
> >>> Ok can you try the following debugging patch, to verify my guess ?
> >>> 
> >>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> >>> index 18777d23f09..cd05fdb763f 100644
> >>> --- a/sys/amd64/amd64/pmap.c
> >>> +++ b/sys/amd64/amd64/pmap.c
> >>> @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
> >>>   pd_p = (pd_entry_t *)DMPDkernphys;
> >>>   for (i = 0; i < (NPDEPG * nkdmpde); i++)
> >>>   pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
> >>> -X86_PG_M | X86_PG_A | pg_nx |
> >>> -bootaddr_rwx(i << PDRSHIFT);
> >>> +X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
> >>>   for (i = 0; i < nkdmpde; i++)
> >>>   pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
> >>>   X86_PG_V;
> >> 
> >> With this change it boots okay (mptramp_pagetables is 0x100, as 
> >> expected).
> > 
> > Can you apply the following on top of the previous debugging patch and show
> > me the line printed ?
> > 
> > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> > index 3d70532b7fd..613fa9f2165 100644
> > --- a/sys/amd64/amd64/pmap.c
> > +++ b/sys/amd64/amd64/pmap.c
> > @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap)
> >pmap->pm_pcids[i].pm_gen = 1;
> >}
> >pmap_activate_boot(pmap);
> > +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx 
> > etext %#lx KERNBASE %#lx\n", 0x100UL, bootaddr_rwx(0x100UL), 
> > (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, (uintptr_t)etext, 
> > (uintptr_t)KERNBASE);
> > }
> > 
> > void
> 
> bootaddr addr 0x100 rwx 0 btext 0x80342000 _end 
> 0x823cf840 brwsection #81a0 etext 0x812041e4 
> KERNBASE 0x8000
> 

Try this, please.  Revert all debugging pmap.c patches that I provided
before.

diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
index 4ca2e07e578..2ee8f862854 100644
--- a/sys/amd64/amd64/mp_machdep.c
+++ b/sys/amd64/amd64/mp_machdep.c
@@ -87,6 +87,8 @@ __FBSDID("$FreeBSD$");
 
 #define GiB(v) (v ## ULL << 30)
 
+#defineAP_BOOTPT_SZ(PAGE_SIZE * 3)
+
 extern struct pcpu __pcpu[];
 
 /* Temporary variables for init_secondary()  */
@@ -101,45 +103,78 @@ char *dbg_stack;
 
 static int start_ap(int apic_id);
 
+static bool
+is_kernel_paddr(vm_paddr_t pa)
+{
+
+   return (pa >= trunc_2mpage(btext - KERNBASE) &&
+  pa < round_page(_end - KERNBASE));
+}
+
+static bool
+is_mpboot_good(vm_paddr_t start, vm_paddr_t end)
+{
+
+   return (start + AP_BOOTPT_SZ <= GiB(4) &&
+   end >= start + AP_BOOTPT_SZ && atop(end) < Maxmem);
+}
+
 /*
  * Calculate usable address in base memory for AP trampoline code.
  */
 void
 mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx)
 {
+   vm_paddr_t start, end;
unsigned int i;
bool allocated;
 
alloc_ap_trampoline(physmap, physmap_idx);
 
+   /*
+* Find a memory region big enough below the 4GB boundary to
+* store the initial page tables.  Region must be mapped by
+* the direct map.
+*
+* Note that it needs to be aligned to a page boundary.
+*/
allocated = false;
for (i = *physmap_idx; i <= *physmap_idx; i -= 2) {
/*
-* Find a memory region big enough below the 4GB
-* boundary to store the initial page tables.  Region
-* must be mapped by the direct map.
-*
-* Note that it needs to be aligned to a page
-* boundary.
+* First, try to chomp at the start of the physmap region.
+* Kernel binary might claim it already.
+*/
+   start = round_page(physmap[i]);
+   end = trunc_page(physmap[i + 1]);
+   if (is_mpboot_good(start, end) &&
+   !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) {
+   allocated = true;
+   physmap[i] = start + AP_BOOTPT_SZ;
+   break;
+   }
+
+   /*
+* Second, try to chomp at the end.  Again, check
+* against kernel.
 */
-   if (physmap[i] >= GiB(4) || physmap[i + 1] -

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

2018-08-22 Thread Michael Gmelin




> On 22. Aug 2018, at 17:46, Konstantin Belousov  wrote:
> 
>> On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote:
>> 
>> 
 On 20. Aug 2018, at 17:09, Konstantin Belousov  wrote:
 
 On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
 
 See here for a screenshot (also including the output of "show pte
 0xf8000100"):
 
 https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
>>> It is too early for ddb routines to register.
>>> Ok can you try the following debugging patch, to verify my guess ?
>>> 
>>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
>>> index 18777d23f09..cd05fdb763f 100644
>>> --- a/sys/amd64/amd64/pmap.c
>>> +++ b/sys/amd64/amd64/pmap.c
>>> @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
>>>   pd_p = (pd_entry_t *)DMPDkernphys;
>>>   for (i = 0; i < (NPDEPG * nkdmpde); i++)
>>>   pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
>>> -X86_PG_M | X86_PG_A | pg_nx |
>>> -bootaddr_rwx(i << PDRSHIFT);
>>> +X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
>>>   for (i = 0; i < nkdmpde; i++)
>>>   pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
>>>   X86_PG_V;
>> 
>> With this change it boots okay (mptramp_pagetables is 0x100, as 
>> expected).
> 
> Can you apply the following on top of the previous debugging patch and show
> me the line printed ?
> 
> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> index 3d70532b7fd..613fa9f2165 100644
> --- a/sys/amd64/amd64/pmap.c
> +++ b/sys/amd64/amd64/pmap.c
> @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap)
>pmap->pm_pcids[i].pm_gen = 1;
>}
>pmap_activate_boot(pmap);
> +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx 
> etext %#lx KERNBASE %#lx\n", 0x100UL, bootaddr_rwx(0x100UL), 
> (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, (uintptr_t)etext, 
> (uintptr_t)KERNBASE);
> }
> 
> void

bootaddr addr 0x100 rwx 0 btext 0x80342000 _end 0x823cf840 
brwsection #81a0 etext 0x812041e4 KERNBASE 
0x8000

Best,
Michael




___
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"

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

2018-08-22 Thread Konstantin Belousov

On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote:
> 
> 
> > On 20. Aug 2018, at 17:09, Konstantin Belousov  wrote:
> > 
> >> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
> >> 
> >> See here for a screenshot (also including the output of "show pte
> >> 0xf8000100"):
> >> 
> >> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
> > It is too early for ddb routines to register.
> > Ok can you try the following debugging patch, to verify my guess ?
> > 
> > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> > index 18777d23f09..cd05fdb763f 100644
> > --- a/sys/amd64/amd64/pmap.c
> > +++ b/sys/amd64/amd64/pmap.c
> > @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
> >pd_p = (pd_entry_t *)DMPDkernphys;
> >for (i = 0; i < (NPDEPG * nkdmpde); i++)
> >pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
> > -X86_PG_M | X86_PG_A | pg_nx |
> > -bootaddr_rwx(i << PDRSHIFT);
> > +X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
> >for (i = 0; i < nkdmpde; i++)
> >pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
> >X86_PG_V;
> 
> With this change it boots okay (mptramp_pagetables is 0x100, as expected).

Can you apply the following on top of the previous debugging patch and show
me the line printed ?

diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
index 3d70532b7fd..613fa9f2165 100644
--- a/sys/amd64/amd64/pmap.c
+++ b/sys/amd64/amd64/pmap.c
@@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap)
pmap->pm_pcids[i].pm_gen = 1;
}
pmap_activate_boot(pmap);
+printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx etext 
%#lx KERNBASE %#lx\n", 0x100UL, bootaddr_rwx(0x100UL), 
(uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, (uintptr_t)etext, 
(uintptr_t)KERNBASE);
 }
 
 void
___
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"

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

2018-08-20 Thread Michael Gmelin




> On 20. Aug 2018, at 17:09, Konstantin Belousov  wrote:
> 
>> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
>> 
>> See here for a screenshot (also including the output of "show pte
>> 0xf8000100"):
>> 
>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
> It is too early for ddb routines to register.
> Ok can you try the following debugging patch, to verify my guess ?
> 
> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> index 18777d23f09..cd05fdb763f 100644
> --- a/sys/amd64/amd64/pmap.c
> +++ b/sys/amd64/amd64/pmap.c
> @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
>pd_p = (pd_entry_t *)DMPDkernphys;
>for (i = 0; i < (NPDEPG * nkdmpde); i++)
>pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
> -X86_PG_M | X86_PG_A | pg_nx |
> -bootaddr_rwx(i << PDRSHIFT);
> +X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
>for (i = 0; i < nkdmpde; i++)
>pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
>X86_PG_V;

With this change it boots okay (mptramp_pagetables is 0x100, as expected).

Best,
Michael


___
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"

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

2018-08-20 Thread Konstantin Belousov

On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
> 
> See here for a screenshot (also including the output of "show pte
> 0xf8000100"):
> 
> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
It is too early for ddb routines to register.
Ok can you try the following debugging patch, to verify my guess ?

diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
index 18777d23f09..cd05fdb763f 100644
--- a/sys/amd64/amd64/pmap.c
+++ b/sys/amd64/amd64/pmap.c
@@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
pd_p = (pd_entry_t *)DMPDkernphys;
for (i = 0; i < (NPDEPG * nkdmpde); i++)
pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
-   X86_PG_M | X86_PG_A | pg_nx |
-   bootaddr_rwx(i << PDRSHIFT);
+   X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
for (i = 0; i < nkdmpde; i++)
pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
X86_PG_V;
___
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"

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

2018-08-19 Thread Michael Gmelin




On Sun, 19 Aug 2018 19:16:42 +0300
Konstantin Belousov  wrote:

> On Sun, Aug 19, 2018 at 04:59:51PM +0200, Michael Gmelin wrote:
> > 
> > 
> > On Fri, 17 Aug 2018 10:02:08 +0100
> > John Baldwin  wrote:
> >   
> > > On 8/17/18 9:54 AM, Michael Gmelin wrote:  
> > > > 
> > > > 
> > > >> On 17. Aug 2018, at 08:17, John Baldwin 
> > > >> wrote: 
> > > >>> On 8/16/18 1:58 PM, Michael Gmelin wrote:
> > > >>>
> > > >>>
> > >  On 15. Aug 2018, at 15:55, Konstantin Belousov
> > >  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
> > > >>> 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.
> > >   
> > 
> > Okay, so I had some time to investigate a bit more:
> > 
> > Before calling init_ops.mp_bootaddress in getmemsize (machdep.c),
> > physmap looks like this:
> > 
> > physmap_idx: 8
> > i mem atop
> > 0 0x0 0x0
> > 1 0x3 0x30
> > 2 0x4 0x40
> > 3 0x9e400 0x9e
> > 4 0x10 0x100
> > 5 0xf0 0xf00
> > 6 0x100 0x1000
> > 7 0x7bf7a000 0x7bf7a
> > 8 0x1 0x10
> > 9 0x10060 0x100600
> > 10 0x0 0x0
> > Maxmem: 0x10060 0x100600
> > 
> > Without using atop (the "buggy" version that actually boots without
> > crashing), the loop in mp_bootaddress looks like this:
> > 
> > i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem
> > 8 0x1 0x10060 0x100600 0x100600 
> > 6 0x100 0x7bf7a000 0x7bf7a 0x100600 
> > 4 0x10 0xf0 0xf00 0x100600 
> > 2 0x4 0x9e400 0x9e 0x100600 
> > 
> > And physmap looks like this afterwards:
> > 
> > physmap_idx: 8
> > i mem atop
> > 0 0x0 0x0
> > 1 0x3 0x30
> > 2 0x43000 0x43 <-- here
> > 3 0x9e400 0x9e
> > 4 0x10 0x100
> > 5 0xf0 0xf00
> > 6 0x100 0x1000
> > 7 0x7bf7a000 0x7bf7a
> > 8 0x1 0x10
> > 9 0x10060 0x100600
> > 10 0x0 0x0
> > mptra

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

2018-08-19 Thread Konstantin Belousov

On Sun, Aug 19, 2018 at 04:59:51PM +0200, Michael Gmelin wrote:
> 
> 
> On Fri, 17 Aug 2018 10:02:08 +0100
> John Baldwin  wrote:
> 
> > On 8/17/18 9:54 AM, Michael Gmelin wrote:
> > > 
> > >   
> > >> On 17. Aug 2018, at 08:17, John Baldwin  wrote:
> > >>  
> > >>> On 8/16/18 1:58 PM, Michael Gmelin wrote:
> > >>>
> > >>>  
> >  On 15. Aug 2018, at 15:55, Konstantin Belousov
> >  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
> > >>> 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.
> > 
> 
> Okay, so I had some time to investigate a bit more:
> 
> Before calling init_ops.mp_bootaddress in getmemsize (machdep.c),
> physmap looks like this:
> 
> physmap_idx: 8
> i mem atop
> 0 0x0 0x0
> 1 0x3 0x30
> 2 0x4 0x40
> 3 0x9e400 0x9e
> 4 0x10 0x100
> 5 0xf0 0xf00
> 6 0x100 0x1000
> 7 0x7bf7a000 0x7bf7a
> 8 0x1 0x10
> 9 0x10060 0x100600
> 10 0x0 0x0
> Maxmem: 0x10060 0x100600
> 
> Without using atop (the "buggy" version that actually boots without
> crashing), the loop in mp_bootaddress looks like this:
> 
> i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem
> 8 0x1 0x10060 0x100600 0x100600 
> 6 0x100 0x7bf7a000 0x7bf7a 0x100600 
> 4 0x10 0xf0 0xf00 0x100600 
> 2 0x4 0x9e400 0x9e 0x100600 
> 
> And physmap looks like this afterwards:
> 
> physmap_idx: 8
> i mem atop
> 0 0x0 0x0
> 1 0x3 0x30
> 2 0x43000 0x43 <-- here
> 3 0x9e400 0x9e
> 4 0x10 0x100
> 5 0xf0 0xf00
> 6 0x100 0x1000
> 7 0x7bf7a000 0x7bf7a
> 8 0x1 0x10
> 9 0x10060 0x100600
> 10 0x0 0x0
> mptramp_pagetables is 0x4
> 
> So a three page gap was made at 0x4 (atop(idx 2) is now 0x43
> instead of 0x40)
> 
> In the current version (using atop), the loop in mp_bootaddress
> looks like this:
> 
> i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem
> 8 0x1 0x10060 0x100600 0x100600 
> 6 0x100 0x7bf7a000 0x7bf7a 0x100600 
> 
> And physmap looks like this afterwards:
>

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

2018-08-19 Thread Michael Gmelin



On Fri, 17 Aug 2018 10:02:08 +0100
John Baldwin  wrote:

> On 8/17/18 9:54 AM, Michael Gmelin wrote:
> > 
> >   
> >> On 17. Aug 2018, at 08:17, John Baldwin  wrote:
> >>  
> >>> On 8/16/18 1:58 PM, Michael Gmelin wrote:
> >>>
> >>>  
>  On 15. Aug 2018, at 15:55, Konstantin Belousov
>  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
> >>> 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.
> 

Okay, so I had some time to investigate a bit more:

Before calling init_ops.mp_bootaddress in getmemsize (machdep.c),
physmap looks like this:

physmap_idx: 8
i mem atop
0 0x0 0x0
1 0x3 0x30
2 0x4 0x40
3 0x9e400 0x9e
4 0x10 0x100
5 0xf0 0xf00
6 0x100 0x1000
7 0x7bf7a000 0x7bf7a
8 0x1 0x10
9 0x10060 0x100600
10 0x0 0x0
Maxmem: 0x10060 0x100600

Without using atop (the "buggy" version that actually boots without
crashing), the loop in mp_bootaddress looks like this:

i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem
8 0x1 0x10060 0x100600 0x100600 
6 0x100 0x7bf7a000 0x7bf7a 0x100600 
4 0x10 0xf0 0xf00 0x100600 
2 0x4 0x9e400 0x9e 0x100600 

And physmap looks like this afterwards:

physmap_idx: 8
i mem atop
0 0x0 0x0
1 0x3 0x30
2 0x43000 0x43 <-- here
3 0x9e400 0x9e
4 0x10 0x100
5 0xf0 0xf00
6 0x100 0x1000
7 0x7bf7a000 0x7bf7a
8 0x1 0x10
9 0x10060 0x100600
10 0x0 0x0
mptramp_pagetables is 0x4

So a three page gap was made at 0x4 (atop(idx 2) is now 0x43
instead of 0x40)

In the current version (using atop), the loop in mp_bootaddress
looks like this:

i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem
8 0x1 0x10060 0x100600 0x100600 
6 0x100 0x7bf7a000 0x7bf7a 0x100600 

And physmap looks like this afterwards:

physmap_idx: 8
i mem atop
0 0x0 0x0
1 0x3 0x30
2 0x4 0x40
3 0x9e400 0x9e
4 0x10 0x100
5 0xf0 0xf00
6 0x1003000 0x1003 <-- here
7 0x7bf7a000 0x7bf7a
8 0x1 0x10
9 0x10060 0x100600
10 0x0 0x0
mptramp_pagetables: 0x100

So a three page gap was made at 0x100 (atop(idx 6) is now
0x1003 instead of 0x1000)

When chan

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

2018-08-17 Thread Michael Gmelin




> On 17. Aug 2018, at 12:13, Konstantin Belousov  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  wrote:
> 
> On 8/16/18 1:58 PM, Michael Gmelin wrote:
> 
> 
>>> On 15. Aug 2018, at 15:55, Konstantin Belousov >> > wrote:
>>> 
>>> On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
>>> 
>>> 
> On 15. Aug 2018, at 15:04, Konstantin Belousov  > 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"

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

2018-08-17 Thread Konstantin Belousov

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  wrote:
> >>
> >>> On 8/16/18 1:58 PM, Michael Gmelin wrote:
> >>>
> >>>
>  On 15. Aug 2018, at 15:55, Konstantin Belousov   > wrote:
> 
> > On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
> >
> >
> >>> On 15. Aug 2018, at 15:04, Konstantin Belousov  >>> > 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 ?

___
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"

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

2018-08-17 Thread John Baldwin

On 8/17/18 9:54 AM, Michael Gmelin wrote:
> 
> 
>> On 17. Aug 2018, at 08:17, John Baldwin  wrote:
>>
>>> On 8/16/18 1:58 PM, Michael Gmelin wrote:
>>>
>>>
 On 15. Aug 2018, at 15:55, Konstantin Belousov >>> > wrote:

> On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
>
>
>>> On 15. Aug 2018, at 15:04, Konstantin Belousov >> > 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"

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

2018-08-17 Thread Michael Gmelin



> On 17. Aug 2018, at 08:17, John Baldwin  wrote:
> 
>> On 8/16/18 1:58 PM, Michael Gmelin wrote:
>> 
>> 
>>> On 15. Aug 2018, at 15:55, Konstantin Belousov >> > wrote:
>>> 
 On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
 
 
>> On 15. Aug 2018, at 15:04, Konstantin Belousov > > 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


___
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"

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

2018-08-16 Thread John Baldwin

On 8/16/18 1:58 PM, Michael Gmelin wrote:
> 
> 
> On 15. Aug 2018, at 15:55, Konstantin Belousov  > wrote:
> 
>> On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
>>>
>>>
 On 15. Aug 2018, at 15:04, Konstantin Belousov >>> > 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
___
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"

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

2018-08-16 Thread Michael Gmelin

> On 15. Aug 2018, at 15:55, Konstantin Belousov  wrote:
> 
>> On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
>> 
>> 
 On 15. Aug 2018, at 15:04, Konstantin Belousov  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).

Thanks,
Michael 

___
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"

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

2018-08-15 Thread Konstantin Belousov

On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
> 
> 
> > On 15. Aug 2018, at 15:04, Konstantin Belousov  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.
___
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"

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

2018-08-15 Thread Michael Gmelin




> On 15. Aug 2018, at 15:04, Konstantin Belousov  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.

-m
___
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"

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

2018-08-15 Thread Konstantin Belousov

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 ?
___
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"

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

2018-08-14 Thread Michael Gmelin




On Wed, 6 Jun 2018 01:06:25 +0200
Michael Gmelin  wrote:

> On Tue, 5 Jun 2018 16:11:35 +0300
> Konstantin Belousov  wrote:
> 
> > On Mon, Jun 04, 2018 at 11:17:56PM +0200, Michael Gmelin wrote:  
> > > 
> > > 
> > > On Mon, 4 Jun 2018 14:06:55 +0300
> > > Konstantin Belousov  wrote:
> > > 
> > > > On Mon, Jun 04, 2018 at 12:46:32AM +0200, Michael Gmelin
> > > > wrote:
> > > > > 
> [...]
> > > > > > > > > This machine comes with it by default (my model was
> > > > > > > > > delivered with SeaBIOS 20131018_145217-build121-m2).
> > > > > > > > > So I didn't flash anything (didn't feel like bricking
> > > > > > > > > it). 
> > > > > > > > > >   
> > > > > > > > > > > kernel trap 12 with interrupts disabled
> > > > > > > > > > > 
> > > > > > > > > > > Fatal trap 12: page fault while in kernel mode 
> > > > > > > > > > > cpuid = 0; apic id = 00
> > > > > > > > > > > fault virtual address= 0xf8000100
> > > > > > > > > > > fault code   = supervisor write data,
> > > > > > > > > > > protection violation instruction pointer  =
> > > > > > > > > > > 0x20:Ox8102955f stack pointer=
> > > > > > > > > > > 0x28:0x82a79be0 frame pointer=
> > > > > > > > > > > 0x28:0x82a79c10 code segment =
> > > > > > > > > > > base Ox0, limit Oxf, type Ox1b = DPL 0, pres
> > > > > > > > > > > 1, long 1, def32 0, gran 1 processor
> > > > > > > > > > > eflags = resume, IOPL = 0 current
> > > > > > > > > > > process  = 0 () [ thread pid 0 tid 0 ]
> > > > > > > > > > > Stopped at  native_start_all_aps+0x08f:
> > > > > > > > > > > movq %rax,(%rsi)
> > > > > > > > > > Look up the source line number for this address.
> > > > > > > > > >   
> > > > > > > > > 
> > > > > > > > > I guess that's sys/amd64/amd64/support.S line 854 (in
> > > > > > > > > rdmsr), called by native_start_all_aps. Any additional
> > > > > > > > > hints how I can track it down?  
> > > > > > > > Why did you decided that this is rdmsr_safe() ? First,
> > > > > > > > native_start_all_aps() does not call rdmsr, second the
> > > > > > > > ddb report clearly indicates that the fault occured
> > > > > > > > acessing DMAP in native_start_all_aps().
> > > > > > > > 
> > > > > > > > Just look up the source line by the address
> > > > > > > > native_start_all_aps+0x08f.
> > > > > > > 
> > > > > > > Okay, according to kgbd this should be here:
> > > > > > > 
> > > > > > > https://svnweb.freebsd.org/base/head/sys/amd64/amd64/mp_machdep.c?revision=68&view=markup#l369
> > > > > > > 
> > > > > > > 364
> > > > > > > 365/* Create the initial 1GB replicated page tables */
> > > > > > > 366for (i = 0; i < 512; i++) {
> > > > > > > 367/* Each slot of the level 4 pages points to
> > > > > > > the same level 3 page */ 368pt4[i] =
> > > > > > > (u_int64_t)(uintptr_t)(mptramp_pagetables + PAGE_SIZE);
> > > > > > > 369 pt4[i] |= PG_V | PG_RW | PG_U; 370
> > > > > > > 371/* Each slot of the level 3 pages points to
> > > > > > > the same level 2 page */ 372pt3[i] =
> > > > > > > (u_int64_t)(uintptr_t)(mptramp_pagetables + (2 *
> > > > > > > PAGE_SIZE)); 373pt3[i] |= PG_V | PG_RW | PG_U;
> > > > > > > 374 375/* The level 2 page slots are mapped
> > > > > > > with 2MB pages for 1GB. */ 376pt2[i] = i * (2
> > > > > > > * 1024 * 1024); 377pt2[i] |= PG_V | PG_RW |
> > > > > > > PG_PS | PG_U; 378}
> > > > > > > 
> > > > > > > -m
> > > > > > You have fault on write due to read-only mapping of the
> > > > > > portion of the direct map, which maps the kernel text.  It
> > > > > > is consistent with the faulting address.  It is not clear
> > > > > > if it is something new on your machine, or before the
> > > > > > kernel text was silently corrupted, since ro protection is
> > > > > > somewhat recent.
> > > > > > 
> > > > > > It seems that mp_bootaddress() selected the bad place for
> > > > > > the bootstrap page tables. Even more, we do not include the
> > > > > > kernel text into the physmem[] array, so it is not clear
> > > > > > how did it happen. This code was also changed recently.
> > > > > > 
> > > > > > Can you add the print of the physmap[] array somewhere
> > > > > > before the panic, to see what is the kernel idea of the
> > > > > > available memory ? It should be already done if you have
> > > > > > serial console and set debug.late_console tunable to
> > > > > > 0.  
> > > > > 
> > > > > This is a sad little machine without any kind of serial
> > > > > console.
> > > > > 
> > > > > Physmap looks like this after calling getmemsize():
> > > > > 
> > > > > [0]: 0x1
> > > > > [1]: 0x3
> > > > > [2]: 0x4
> > > > > [3]: 0x9e000
> > > > > [4]: 0x10
> > > > > [5]: 0xf0
> > > > > [6]: 0x1003000
> > > > > [7]: 0x7bf7a000
> > > > > 
> > > > > Physical memory chunks logged in cpu_startup are:
> > > > >

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

2018-06-05 Thread Michael Gmelin




On Tue, 5 Jun 2018 16:11:35 +0300
Konstantin Belousov  wrote:

> On Mon, Jun 04, 2018 at 11:17:56PM +0200, Michael Gmelin wrote:
> > 
> > 
> > On Mon, 4 Jun 2018 14:06:55 +0300
> > Konstantin Belousov  wrote:
> >   
> > > On Mon, Jun 04, 2018 at 12:46:32AM +0200, Michael Gmelin wrote:  
> > > > 
> > > > 
> > > > On Sun, 3 Jun 2018 23:53:40 +0300
> > > > Konstantin Belousov  wrote:
> > > > 
> > > > > On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin
> > > > > wrote:
> > > > > > 
> > > > > > 
> > > > > > On Sun, 3 Jun 2018 18:04:23 +0300
> > > > > > Konstantin Belousov  wrote:
> > > > > >   
> > > > > > > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin
> > > > > > > wrote:  
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Sun, 3 Jun 2018 16:21:10 +0300
> > > > > > > > Konstantin Belousov  wrote:
> > > > > > > > 
> > > > > > > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael
> > > > > > > > > Gmelin wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > After upgrading CURRENT to r333992 (from something
> > > > > > > > > > at least a year old, quite some changes in
> > > > > > > > > > mp_machdep.c since), this machine crashes on boot:
> > > > > > > > > > 
> > > > > > > > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > > > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989,
> > > > > > > > > > 1991, 1992, 1993, 1994 The Regents of the
> > > > > > > > > > University of California. All rights reserved.
> > > > > > > > > > FreeBSD is a registered trademark of The FreeBSD
> > > > > > > > > > Foundation. FreeBSD 12.0-CURRENT #1 r333992: Tue
> > > > > > > > > > May 22 00:31:04 CEST 2018
> > > > > > > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy
> > > > > > > > > > amd64 FreeBSD clang version 6.0.0
> > > > > > > > > > (tags/RELEASE_600/final 326565) (based on LLVM
> > > > > > > > > > 6.0.0) WARNING: WITNESS option enabled, expect
> > > > > > > > > > reduced performance. VT(vga): resolution 640x480
> > > > > > > > > > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz
> > > > > > > > > > (1396.80-MHz K8-class CPU) Origin="GenuineIntel"
> > > > > > > > > > Id=0x40651 Family=0x6 Model=0x45 Stepping=1
> > > > > > > > > > Features=0xbfebfbff > > > > > > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > > > > > > > > Features2=0x4ddaebbf > > > > > > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > > > > > > > AMD
> > > > > > > > > > Features=0x2c100800
> > > > > > > > > > AMD Features2=0x21 Structured Extended
> > > > > > > > > > Features=0x2603
> > > > > > > > > > XSAVE Features=0x1 VT-x: (disabled in
> > > > > > > > > > BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state
> > > > > > > > > > invariant, performance statistics real memory  =
> > > > > > > > > > 4301258752 (4102 MB) avail memory = 1907572736
> > > > > > > > > > (1819 MB) Event timer "LAPIC" quality 600 ACPI APIC
> > > > > > > > > > Table:  > > > > > > > > > COREBOOT>  
> > > > > > > > > What does this mean ?  Did you flashed
> > > > > > > > > coreboot ?
> > > > > > > > 
> > > > > > > > This machine comes with it by default (my model was
> > > > > > > > delivered with SeaBIOS 20131018_145217-build121-m2). So
> > > > > > > > I didn't flash anything (didn't feel like bricking it).
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > kernel trap 12 with interrupts disabled
> > > > > > > > > > 
> > > > > > > > > > Fatal trap 12: page fault while in kernel mode 
> > > > > > > > > > cpuid = 0; apic id = 00
> > > > > > > > > > fault virtual address= 0xf8000100
> > > > > > > > > > fault code   = supervisor write data,
> > > > > > > > > > protection violation instruction pointer  =
> > > > > > > > > > 0x20:Ox8102955f stack pointer=
> > > > > > > > > > 0x28:0x82a79be0 frame pointer=
> > > > > > > > > > 0x28:0x82a79c10 code segment =
> > > > > > > > > > base Ox0, limit Oxf, type Ox1b = DPL 0, pres 1,
> > > > > > > > > > long 1, def32 0, gran 1 processor eflags =
> > > > > > > > > > resume, IOPL = 0 current process  = 0 ()
> > > > > > > > > > [ thread pid 0 tid 0 ]
> > > > > > > > > > Stopped at  native_start_all_aps+0x08f:
> > > > > > > > > > movq %rax,(%rsi)  
> > > > > > > > > Look up the source line number for this address.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > I guess that's sys/amd64/amd64/support.S line 854 (in
> > > > > > > > rdmsr), called by native_start_all_aps. Any additional
> > > > > > > > hints how I can track it down?
> > > > > > > Why did you decided that this is rdmsr_safe() ? First,
> > > > > > > native_start_all_aps() does not call rdmsr, second the ddb
> > > > > > > report clearly indicates that the fault occured acessing
> > > > > > > DMAP in native_start_all_aps().
> > > > > > > 
> > > > > > > Just look up the sou

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

2018-06-05 Thread Konstantin Belousov

On Mon, Jun 04, 2018 at 11:17:56PM +0200, Michael Gmelin wrote:
> 
> 
> On Mon, 4 Jun 2018 14:06:55 +0300
> Konstantin Belousov  wrote:
> 
> > On Mon, Jun 04, 2018 at 12:46:32AM +0200, Michael Gmelin wrote:
> > > 
> > > 
> > > On Sun, 3 Jun 2018 23:53:40 +0300
> > > Konstantin Belousov  wrote:
> > >   
> > > > On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin wrote:  
> > > > > 
> > > > > 
> > > > > On Sun, 3 Jun 2018 18:04:23 +0300
> > > > > Konstantin Belousov  wrote:
> > > > > 
> > > > > > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin
> > > > > > wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On Sun, 3 Jun 2018 16:21:10 +0300
> > > > > > > Konstantin Belousov  wrote:
> > > > > > >   
> > > > > > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin
> > > > > > > > wrote:  
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > After upgrading CURRENT to r333992 (from something at
> > > > > > > > > least a year old, quite some changes in mp_machdep.c
> > > > > > > > > since), this machine crashes on boot:
> > > > > > > > > 
> > > > > > > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991,
> > > > > > > > > 1992, 1993, 1994 The Regents of the University of
> > > > > > > > > California. All rights reserved. FreeBSD is a registered
> > > > > > > > > trademark of The FreeBSD Foundation. FreeBSD
> > > > > > > > > 12.0-CURRENT #1 r333992: Tue May 22 00:31:04 CEST 2018
> > > > > > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy
> > > > > > > > > amd64 FreeBSD clang version 6.0.0
> > > > > > > > > (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)
> > > > > > > > > WARNING: WITNESS option enabled, expect reduced
> > > > > > > > > performance. VT(vga): resolution 640x480 CPU: Intel(R)
> > > > > > > > > Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
> > > > > > > > > Origin="GenuineIntel"  Id=0x40651 Family=0x6
> > > > > > > > > Model=0x45 Stepping=1
> > > > > > > > > Features=0xbfebfbff > > > > > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > > > > > > > Features2=0x4ddaebbf > > > > > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > > > > > > AMD Features=0x2c100800
> > > > > > > > > AMD Features2=0x21 Structured Extended
> > > > > > > > > Features=0x2603
> > > > > > > > > XSAVE Features=0x1 VT-x: (disabled in BIOS)
> > > > > > > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant,
> > > > > > > > > performance statistics real memory  = 4301258752 (4102
> > > > > > > > > MB) avail memory = 1907572736 (1819 MB) Event timer
> > > > > > > > > "LAPIC" quality 600 ACPI APIC Table:  > > > > > > > > COREBOOT>
> > > > > > > > What does this mean ?  Did you flashed coreboot ?  
> > > > > > > 
> > > > > > > This machine comes with it by default (my model was
> > > > > > > delivered with SeaBIOS 20131018_145217-build121-m2). So I
> > > > > > > didn't flash anything (didn't feel like bricking it).
> > > > > > >   
> > > > > > > >   
> > > > > > > > > kernel trap 12 with interrupts disabled
> > > > > > > > > 
> > > > > > > > > Fatal trap 12: page fault while in kernel mode 
> > > > > > > > > cpuid = 0; apic id = 00
> > > > > > > > > fault virtual address= 0xf8000100
> > > > > > > > > fault code   = supervisor write data,
> > > > > > > > > protection violation instruction pointer  =
> > > > > > > > > 0x20:Ox8102955f stack pointer=
> > > > > > > > > 0x28:0x82a79be0 frame pointer=
> > > > > > > > > 0x28:0x82a79c10 code segment = base
> > > > > > > > > Ox0, limit Oxf, type Ox1b = DPL 0, pres 1, long 1,
> > > > > > > > > def32 0, gran 1 processor eflags = resume, IOPL
> > > > > > > > > = 0 current process  = 0 ()
> > > > > > > > > [ thread pid 0 tid 0 ]
> > > > > > > > > Stopped at  native_start_all_aps+0x08f:  movq
> > > > > > > > > %rax,(%rsi)
> > > > > > > > Look up the source line number for this address.
> > > > > > > >   
> > > > > > > 
> > > > > > > I guess that's sys/amd64/amd64/support.S line 854 (in
> > > > > > > rdmsr), called by native_start_all_aps. Any additional
> > > > > > > hints how I can track it down?  
> > > > > > Why did you decided that this is rdmsr_safe() ? First,
> > > > > > native_start_all_aps() does not call rdmsr, second the ddb
> > > > > > report clearly indicates that the fault occured acessing DMAP
> > > > > > in native_start_all_aps().
> > > > > > 
> > > > > > Just look up the source line by the address
> > > > > > native_start_all_aps+0x08f.
> > > > > 
> > > > > Okay, according to kgbd this should be here:
> > > > > 
> > > > > https://svnweb.freebsd.org/base/head/sys/amd64/amd64/mp_machdep.c?revision=68&view=markup#l369
> > > > > 
> > > > > 364
> > > > > 365/* Create the initial 1GB replicated page tables */
> > > > > 366for

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

2018-06-04 Thread Michael Gmelin




On Mon, 4 Jun 2018 14:06:55 +0300
Konstantin Belousov  wrote:

> On Mon, Jun 04, 2018 at 12:46:32AM +0200, Michael Gmelin wrote:
> > 
> > 
> > On Sun, 3 Jun 2018 23:53:40 +0300
> > Konstantin Belousov  wrote:
> >   
> > > On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin wrote:  
> > > > 
> > > > 
> > > > On Sun, 3 Jun 2018 18:04:23 +0300
> > > > Konstantin Belousov  wrote:
> > > > 
> > > > > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin
> > > > > wrote:
> > > > > > 
> > > > > > 
> > > > > > On Sun, 3 Jun 2018 16:21:10 +0300
> > > > > > Konstantin Belousov  wrote:
> > > > > >   
> > > > > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin
> > > > > > > wrote:  
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > After upgrading CURRENT to r333992 (from something at
> > > > > > > > least a year old, quite some changes in mp_machdep.c
> > > > > > > > since), this machine crashes on boot:
> > > > > > > > 
> > > > > > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991,
> > > > > > > > 1992, 1993, 1994 The Regents of the University of
> > > > > > > > California. All rights reserved. FreeBSD is a registered
> > > > > > > > trademark of The FreeBSD Foundation. FreeBSD
> > > > > > > > 12.0-CURRENT #1 r333992: Tue May 22 00:31:04 CEST 2018
> > > > > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy
> > > > > > > > amd64 FreeBSD clang version 6.0.0
> > > > > > > > (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)
> > > > > > > > WARNING: WITNESS option enabled, expect reduced
> > > > > > > > performance. VT(vga): resolution 640x480 CPU: Intel(R)
> > > > > > > > Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
> > > > > > > > Origin="GenuineIntel"  Id=0x40651 Family=0x6
> > > > > > > > Model=0x45 Stepping=1
> > > > > > > > Features=0xbfebfbff > > > > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > > > > > > Features2=0x4ddaebbf > > > > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > > > > > AMD Features=0x2c100800
> > > > > > > > AMD Features2=0x21 Structured Extended
> > > > > > > > Features=0x2603
> > > > > > > > XSAVE Features=0x1 VT-x: (disabled in BIOS)
> > > > > > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant,
> > > > > > > > performance statistics real memory  = 4301258752 (4102
> > > > > > > > MB) avail memory = 1907572736 (1819 MB) Event timer
> > > > > > > > "LAPIC" quality 600 ACPI APIC Table:  > > > > > > > COREBOOT>
> > > > > > > What does this mean ?  Did you flashed coreboot ?  
> > > > > > 
> > > > > > This machine comes with it by default (my model was
> > > > > > delivered with SeaBIOS 20131018_145217-build121-m2). So I
> > > > > > didn't flash anything (didn't feel like bricking it).
> > > > > >   
> > > > > > >   
> > > > > > > > kernel trap 12 with interrupts disabled
> > > > > > > > 
> > > > > > > > Fatal trap 12: page fault while in kernel mode 
> > > > > > > > cpuid = 0; apic id = 00
> > > > > > > > fault virtual address= 0xf8000100
> > > > > > > > fault code   = supervisor write data,
> > > > > > > > protection violation instruction pointer  =
> > > > > > > > 0x20:Ox8102955f stack pointer=
> > > > > > > > 0x28:0x82a79be0 frame pointer=
> > > > > > > > 0x28:0x82a79c10 code segment = base
> > > > > > > > Ox0, limit Oxf, type Ox1b = DPL 0, pres 1, long 1,
> > > > > > > > def32 0, gran 1 processor eflags = resume, IOPL
> > > > > > > > = 0 current process  = 0 ()
> > > > > > > > [ thread pid 0 tid 0 ]
> > > > > > > > Stopped at  native_start_all_aps+0x08f:  movq
> > > > > > > > %rax,(%rsi)
> > > > > > > Look up the source line number for this address.
> > > > > > >   
> > > > > > 
> > > > > > I guess that's sys/amd64/amd64/support.S line 854 (in
> > > > > > rdmsr), called by native_start_all_aps. Any additional
> > > > > > hints how I can track it down?  
> > > > > Why did you decided that this is rdmsr_safe() ? First,
> > > > > native_start_all_aps() does not call rdmsr, second the ddb
> > > > > report clearly indicates that the fault occured acessing DMAP
> > > > > in native_start_all_aps().
> > > > > 
> > > > > Just look up the source line by the address
> > > > > native_start_all_aps+0x08f.
> > > > 
> > > > Okay, according to kgbd this should be here:
> > > > 
> > > > https://svnweb.freebsd.org/base/head/sys/amd64/amd64/mp_machdep.c?revision=68&view=markup#l369
> > > > 
> > > > 364
> > > > 365/* Create the initial 1GB replicated page tables */
> > > > 366for (i = 0; i < 512; i++) {
> > > > 367/* Each slot of the level 4 pages points to the
> > > > same level 3 page */ 368pt4[i] =
> > > > (u_int64_t)(uintptr_t)(mptramp_pagetables + PAGE_SIZE); 369
> > > > pt4[i] |= PG_V | PG_RW | PG_U; 370
> > > > 3

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

2018-06-04 Thread Konstantin Belousov

On Mon, Jun 04, 2018 at 12:46:32AM +0200, Michael Gmelin wrote:
> 
> 
> On Sun, 3 Jun 2018 23:53:40 +0300
> Konstantin Belousov  wrote:
> 
> > On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin wrote:
> > > 
> > > 
> > > On Sun, 3 Jun 2018 18:04:23 +0300
> > > Konstantin Belousov  wrote:
> > >   
> > > > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin wrote:  
> > > > > 
> > > > > 
> > > > > On Sun, 3 Jun 2018 16:21:10 +0300
> > > > > Konstantin Belousov  wrote:
> > > > > 
> > > > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin
> > > > > > wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > After upgrading CURRENT to r333992 (from something at least
> > > > > > > a year old, quite some changes in mp_machdep.c since), this
> > > > > > > machine crashes on boot:
> > > > > > > 
> > > > > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991,
> > > > > > > 1992, 1993, 1994 The Regents of the University of
> > > > > > > California. All rights reserved. FreeBSD is a registered
> > > > > > > trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT
> > > > > > > #1 r333992: Tue May 22 00:31:04 CEST 2018
> > > > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > > > > > > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565)
> > > > > > > (based on LLVM 6.0.0) WARNING: WITNESS option enabled,
> > > > > > > expect reduced performance. VT(vga): resolution 640x480
> > > > > > > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz
> > > > > > > K8-class CPU) Origin="GenuineIntel"  Id=0x40651
> > > > > > > Family=0x6  Model=0x45 Stepping=1
> > > > > > > Features=0xbfebfbff > > > > > >   
> > > > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>  
> > > > > > > Features2=0x4ddaebbf > > > > > >   
> > > > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > > > >   
> > > > > > > AMD Features=0x2c100800 AMD
> > > > > > > Features2=0x21 Structured Extended
> > > > > > > Features=0x2603 XSAVE
> > > > > > > Features=0x1 VT-x: (disabled in BIOS)
> > > > > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant,
> > > > > > > performance statistics real memory  = 4301258752 (4102 MB)
> > > > > > > avail memory = 1907572736 (1819 MB) Event timer "LAPIC"
> > > > > > > quality 600 ACPI APIC Table:   
> > > > > > What does this mean ?  Did you flashed coreboot ?
> > > > > 
> > > > > This machine comes with it by default (my model was delivered
> > > > > with SeaBIOS 20131018_145217-build121-m2). So I didn't flash
> > > > > anything (didn't feel like bricking it).
> > > > > 
> > > > > > 
> > > > > > > kernel trap 12 with interrupts disabled
> > > > > > > 
> > > > > > > Fatal trap 12: page fault while in kernel mode 
> > > > > > > cpuid = 0; apic id = 00
> > > > > > > fault virtual address= 0xf8000100
> > > > > > > fault code   = supervisor write data, protection
> > > > > > > violation instruction pointer  = 0x20:Ox8102955f
> > > > > > > stack pointer= 0x28:0x82a79be0
> > > > > > > frame pointer= 0x28:0x82a79c10
> > > > > > > code segment = base Ox0, limit Oxf, type
> > > > > > > Ox1b = DPL 0, pres 1, long 1, def32 0, gran
> > > > > > > 1 processor eflags = resume, IOPL = 0
> > > > > > > current process  = 0 ()
> > > > > > > [ thread pid 0 tid 0 ]
> > > > > > > Stopped at  native_start_all_aps+0x08f:  movq
> > > > > > > %rax,(%rsi)  
> > > > > > Look up the source line number for this address.
> > > > > > 
> > > > > 
> > > > > I guess that's sys/amd64/amd64/support.S line 854 (in rdmsr),
> > > > > called by native_start_all_aps. Any additional hints how I can
> > > > > track it down?
> > > > Why did you decided that this is rdmsr_safe() ? First,
> > > > native_start_all_aps() does not call rdmsr, second the ddb
> > > > report clearly indicates that the fault occured acessing DMAP in
> > > > native_start_all_aps().
> > > > 
> > > > Just look up the source line by the address
> > > > native_start_all_aps+0x08f.  
> > > 
> > > Okay, according to kgbd this should be here:
> > > 
> > > https://svnweb.freebsd.org/base/head/sys/amd64/amd64/mp_machdep.c?revision=68&view=markup#l369
> > > 
> > > 364
> > > 365/* Create the initial 1GB replicated page tables */
> > > 366for (i = 0; i < 512; i++) {
> > > 367/* Each slot of the level 4 pages points to the same
> > > level 3 page */ 368pt4[i] =
> > > (u_int64_t)(uintptr_t)(mptramp_pagetables + PAGE_SIZE); 369
> > > pt4[i] |= PG_V | PG_RW | PG_U; 370
> > > 371/* Each slot of the level 3 pages points to the same
> > > level 2 page */ 372pt3[i] =
> > > (u_int64_t)(uintptr_t)(mptramp_pagetables + (2 * PAGE_SIZE));
> > > 373pt3[i] |= PG_V | PG_RW | PG_U; 374
> > > 375/* The level 2 page slots are ma

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

2018-06-03 Thread Michael Gmelin




On Sun, 3 Jun 2018 23:53:40 +0300
Konstantin Belousov  wrote:

> On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin wrote:
> > 
> > 
> > On Sun, 3 Jun 2018 18:04:23 +0300
> > Konstantin Belousov  wrote:
> >   
> > > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin wrote:  
> > > > 
> > > > 
> > > > On Sun, 3 Jun 2018 16:21:10 +0300
> > > > Konstantin Belousov  wrote:
> > > > 
> > > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin
> > > > > wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > After upgrading CURRENT to r333992 (from something at least
> > > > > > a year old, quite some changes in mp_machdep.c since), this
> > > > > > machine crashes on boot:
> > > > > > 
> > > > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991,
> > > > > > 1992, 1993, 1994 The Regents of the University of
> > > > > > California. All rights reserved. FreeBSD is a registered
> > > > > > trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT
> > > > > > #1 r333992: Tue May 22 00:31:04 CEST 2018
> > > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > > > > > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565)
> > > > > > (based on LLVM 6.0.0) WARNING: WITNESS option enabled,
> > > > > > expect reduced performance. VT(vga): resolution 640x480
> > > > > > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz
> > > > > > K8-class CPU) Origin="GenuineIntel"  Id=0x40651
> > > > > > Family=0x6  Model=0x45 Stepping=1
> > > > > > Features=0xbfebfbff > > > > >   
> > > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>  
> > > > > > Features2=0x4ddaebbf > > > > >   
> > > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > > >   
> > > > > > AMD Features=0x2c100800 AMD
> > > > > > Features2=0x21 Structured Extended
> > > > > > Features=0x2603 XSAVE
> > > > > > Features=0x1 VT-x: (disabled in BIOS)
> > > > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant,
> > > > > > performance statistics real memory  = 4301258752 (4102 MB)
> > > > > > avail memory = 1907572736 (1819 MB) Event timer "LAPIC"
> > > > > > quality 600 ACPI APIC Table:   
> > > > > What does this mean ?  Did you flashed coreboot ?
> > > > 
> > > > This machine comes with it by default (my model was delivered
> > > > with SeaBIOS 20131018_145217-build121-m2). So I didn't flash
> > > > anything (didn't feel like bricking it).
> > > > 
> > > > > 
> > > > > > kernel trap 12 with interrupts disabled
> > > > > > 
> > > > > > Fatal trap 12: page fault while in kernel mode 
> > > > > > cpuid = 0; apic id = 00
> > > > > > fault virtual address= 0xf8000100
> > > > > > fault code   = supervisor write data, protection
> > > > > > violation instruction pointer  = 0x20:Ox8102955f
> > > > > > stack pointer= 0x28:0x82a79be0
> > > > > > frame pointer= 0x28:0x82a79c10
> > > > > > code segment = base Ox0, limit Oxf, type
> > > > > > Ox1b = DPL 0, pres 1, long 1, def32 0, gran
> > > > > > 1 processor eflags = resume, IOPL = 0
> > > > > > current process  = 0 ()
> > > > > > [ thread pid 0 tid 0 ]
> > > > > > Stopped at  native_start_all_aps+0x08f:  movq
> > > > > > %rax,(%rsi)  
> > > > > Look up the source line number for this address.
> > > > > 
> > > > 
> > > > I guess that's sys/amd64/amd64/support.S line 854 (in rdmsr),
> > > > called by native_start_all_aps. Any additional hints how I can
> > > > track it down?
> > > Why did you decided that this is rdmsr_safe() ? First,
> > > native_start_all_aps() does not call rdmsr, second the ddb
> > > report clearly indicates that the fault occured acessing DMAP in
> > > native_start_all_aps().
> > > 
> > > Just look up the source line by the address
> > > native_start_all_aps+0x08f.  
> > 
> > Okay, according to kgbd this should be here:
> > 
> > https://svnweb.freebsd.org/base/head/sys/amd64/amd64/mp_machdep.c?revision=68&view=markup#l369
> > 
> > 364
> > 365/* Create the initial 1GB replicated page tables */
> > 366for (i = 0; i < 512; i++) {
> > 367/* Each slot of the level 4 pages points to the same
> > level 3 page */ 368pt4[i] =
> > (u_int64_t)(uintptr_t)(mptramp_pagetables + PAGE_SIZE); 369
> > pt4[i] |= PG_V | PG_RW | PG_U; 370
> > 371/* Each slot of the level 3 pages points to the same
> > level 2 page */ 372pt3[i] =
> > (u_int64_t)(uintptr_t)(mptramp_pagetables + (2 * PAGE_SIZE));
> > 373pt3[i] |= PG_V | PG_RW | PG_U; 374
> > 375/* The level 2 page slots are mapped with 2MB pages
> > for 1GB. */ 376pt2[i] = i * (2 * 1024 * 1024);
> > 377pt2[i] |= PG_V | PG_RW | PG_PS | PG_U;
> > 378}
> > 
> > -m  
> You have fault on write due to read-only mapping of the portion of
> the direct map, which maps the kerne

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

2018-06-03 Thread Konstantin Belousov

On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin wrote:
> 
> 
> On Sun, 3 Jun 2018 18:04:23 +0300
> Konstantin Belousov  wrote:
> 
> > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin wrote:
> > > 
> > > 
> > > On Sun, 3 Jun 2018 16:21:10 +0300
> > > Konstantin Belousov  wrote:
> > >   
> > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin wrote:  
> > > > > Hi,
> > > > > 
> > > > > After upgrading CURRENT to r333992 (from something at least a
> > > > > year old, quite some changes in mp_machdep.c since), this
> > > > > machine crashes on boot:
> > > > > 
> > > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992,
> > > > > 1993, 1994 The Regents of the University of California. All
> > > > > rights reserved. FreeBSD is a registered trademark of The
> > > > > FreeBSD Foundation. FreeBSD 12.0-CURRENT #1 r333992: Tue May 22
> > > > > 00:31:04 CEST 2018
> > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > > > > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565)
> > > > > (based on LLVM 6.0.0) WARNING: WITNESS option enabled, expect
> > > > > reduced performance. VT(vga): resolution 640x480 CPU: Intel(R)
> > > > > Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
> > > > > Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45
> > > > > Stepping=1
> > > > > Features=0xbfebfbff > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > > > Features2=0x4ddaebbf > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > > AMD Features=0x2c100800 AMD
> > > > > Features2=0x21 Structured Extended
> > > > > Features=0x2603 XSAVE
> > > > > Features=0x1 VT-x: (disabled in BIOS)
> > > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant,
> > > > > performance statistics real memory  = 4301258752 (4102 MB)
> > > > > avail memory = 1907572736 (1819 MB) Event timer "LAPIC" quality
> > > > > 600 ACPI APIC Table: 
> > > > What does this mean ?  Did you flashed coreboot ?  
> > > 
> > > This machine comes with it by default (my model was delivered with 
> > > SeaBIOS 20131018_145217-build121-m2). So I didn't flash anything
> > > (didn't feel like bricking it).
> > >   
> > > >   
> > > > > kernel trap 12 with interrupts disabled
> > > > > 
> > > > > Fatal trap 12: page fault while in kernel mode 
> > > > > cpuid = 0; apic id = 00
> > > > > fault virtual address= 0xf8000100
> > > > > fault code   = supervisor write data, protection
> > > > > violation instruction pointer  = 0x20:Ox8102955f
> > > > > stack pointer= 0x28:0x82a79be0
> > > > > frame pointer= 0x28:0x82a79c10
> > > > > code segment = base Ox0, limit Oxf, type Ox1b
> > > > >  = DPL 0, pres 1, long 1, def32 0, gran
> > > > > 1 processor eflags = resume, IOPL = 0
> > > > > current process  = 0 ()
> > > > > [ thread pid 0 tid 0 ]
> > > > > Stopped at  native_start_all_aps+0x08f:  movq
> > > > > %rax,(%rsi)
> > > > Look up the source line number for this address.
> > > >   
> > > 
> > > I guess that's sys/amd64/amd64/support.S line 854 (in rdmsr),
> > > called by native_start_all_aps. Any additional hints how I can
> > > track it down?  
> > Why did you decided that this is rdmsr_safe() ? First,
> > native_start_all_aps() does not call rdmsr, second the ddb
> > report clearly indicates that the fault occured acessing DMAP in
> > native_start_all_aps().
> > 
> > Just look up the source line by the address
> > native_start_all_aps+0x08f.
> 
> Okay, according to kgbd this should be here:
> 
> https://svnweb.freebsd.org/base/head/sys/amd64/amd64/mp_machdep.c?revision=68&view=markup#l369
> 
> 364
> 365/* Create the initial 1GB replicated page tables */
> 366for (i = 0; i < 512; i++) {
> 367/* Each slot of the level 4 pages points to the same
> level 3 page */ 368pt4[i] =
> (u_int64_t)(uintptr_t)(mptramp_pagetables + PAGE_SIZE); 369
> pt4[i] |= PG_V | PG_RW | PG_U; 370
> 371/* Each slot of the level 3 pages points to the same
> level 2 page */ 372pt3[i] =
> (u_int64_t)(uintptr_t)(mptramp_pagetables + (2 * PAGE_SIZE));
> 373pt3[i] |= PG_V | PG_RW | PG_U; 374
> 375/* The level 2 page slots are mapped with 2MB pages for
> 1GB. */ 376pt2[i] = i * (2 * 1024 * 1024);
> 377pt2[i] |= PG_V | PG_RW | PG_PS | PG_U;
> 378}
> 
> -m
You have fault on write due to read-only mapping of the portion of
the direct map, which maps the kernel text.  It is consistent with
the faulting address.  It is not clear if it is something new on
your machine, or before the kernel text was silently corrupted, since
ro protection is somewhat recent.

It seems that mp_bootaddress() selected the bad place for the bootstrap
page tables. Even more, we do not include the kernel text

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

2018-06-03 Thread Michael Gmelin




On Sun, 3 Jun 2018 18:04:23 +0300
Konstantin Belousov  wrote:

> On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin wrote:
> > 
> > 
> > On Sun, 3 Jun 2018 16:21:10 +0300
> > Konstantin Belousov  wrote:
> >   
> > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin wrote:  
> > > > Hi,
> > > > 
> > > > After upgrading CURRENT to r333992 (from something at least a
> > > > year old, quite some changes in mp_machdep.c since), this
> > > > machine crashes on boot:
> > > > 
> > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992,
> > > > 1993, 1994 The Regents of the University of California. All
> > > > rights reserved. FreeBSD is a registered trademark of The
> > > > FreeBSD Foundation. FreeBSD 12.0-CURRENT #1 r333992: Tue May 22
> > > > 00:31:04 CEST 2018
> > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > > > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565)
> > > > (based on LLVM 6.0.0) WARNING: WITNESS option enabled, expect
> > > > reduced performance. VT(vga): resolution 640x480 CPU: Intel(R)
> > > > Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
> > > > Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45
> > > > Stepping=1
> > > > Features=0xbfebfbff > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > > Features2=0x4ddaebbf > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > AMD Features=0x2c100800 AMD
> > > > Features2=0x21 Structured Extended
> > > > Features=0x2603 XSAVE
> > > > Features=0x1 VT-x: (disabled in BIOS)
> > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant,
> > > > performance statistics real memory  = 4301258752 (4102 MB)
> > > > avail memory = 1907572736 (1819 MB) Event timer "LAPIC" quality
> > > > 600 ACPI APIC Table: 
> > > What does this mean ?  Did you flashed coreboot ?  
> > 
> > This machine comes with it by default (my model was delivered with 
> > SeaBIOS 20131018_145217-build121-m2). So I didn't flash anything
> > (didn't feel like bricking it).
> >   
> > >   
> > > > kernel trap 12 with interrupts disabled
> > > > 
> > > > Fatal trap 12: page fault while in kernel mode 
> > > > cpuid = 0; apic id = 00
> > > > fault virtual address= 0xf8000100
> > > > fault code   = supervisor write data, protection
> > > > violation instruction pointer  = 0x20:Ox8102955f
> > > > stack pointer= 0x28:0x82a79be0
> > > > frame pointer= 0x28:0x82a79c10
> > > > code segment = base Ox0, limit Oxf, type Ox1b
> > > >  = DPL 0, pres 1, long 1, def32 0, gran
> > > > 1 processor eflags = resume, IOPL = 0
> > > > current process  = 0 ()
> > > > [ thread pid 0 tid 0 ]
> > > > Stopped at  native_start_all_aps+0x08f:  movq
> > > > %rax,(%rsi)
> > > Look up the source line number for this address.
> > >   
> > 
> > I guess that's sys/amd64/amd64/support.S line 854 (in rdmsr),
> > called by native_start_all_aps. Any additional hints how I can
> > track it down?  
> Why did you decided that this is rdmsr_safe() ? First,
> native_start_all_aps() does not call rdmsr, second the ddb
> report clearly indicates that the fault occured acessing DMAP in
> native_start_all_aps().
> 
> Just look up the source line by the address
> native_start_all_aps+0x08f.

Okay, according to kgbd this should be here:

https://svnweb.freebsd.org/base/head/sys/amd64/amd64/mp_machdep.c?revision=68&view=markup#l369

364
365/* Create the initial 1GB replicated page tables */
366for (i = 0; i < 512; i++) {
367/* Each slot of the level 4 pages points to the same
level 3 page */ 368pt4[i] =
(u_int64_t)(uintptr_t)(mptramp_pagetables + PAGE_SIZE); 369
pt4[i] |= PG_V | PG_RW | PG_U; 370
371/* Each slot of the level 3 pages points to the same
level 2 page */ 372pt3[i] =
(u_int64_t)(uintptr_t)(mptramp_pagetables + (2 * PAGE_SIZE));
373pt3[i] |= PG_V | PG_RW | PG_U; 374
375/* The level 2 page slots are mapped with 2MB pages for
1GB. */ 376pt2[i] = i * (2 * 1024 * 1024);
377pt2[i] |= PG_V | PG_RW | PG_PS | PG_U;
378}

-m

p.s. This machine uses quirks in biosmem.c, see

Type '?' for a list of command, 'help' for more detailed
help.
OK biosmem
bios_basemem: 0x9e400
bios_extmem: 0x3ff0
memtop: 0x3c00
high_heap_base: 0x3c00
high_heap_size: 0x400
bios_quirks: 0x01 BQ_DISTRUST_820_EXTMEM
b_bios_probed: 0x0a B_BASEMEM_12 B_EXTMEM_E801

-- 
Michael Gmelin

-- 
Michael Gmelin
___
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"

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

2018-06-03 Thread Konstantin Belousov

On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin wrote:
> 
> 
> On Sun, 3 Jun 2018 16:21:10 +0300
> Konstantin Belousov  wrote:
> 
> > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin wrote:
> > > Hi,
> > > 
> > > After upgrading CURRENT to r333992 (from something at least a year
> > > old, quite some changes in mp_machdep.c since), this machine crashes
> > > on boot:
> > > 
> > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
> > > 1994 The Regents of the University of California. All rights
> > > reserved. FreeBSD is a registered trademark of The FreeBSD
> > > Foundation. FreeBSD 12.0-CURRENT #1 r333992: Tue May 22 00:31:04
> > > CEST 2018 root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based
> > > on LLVM 6.0.0) WARNING: WITNESS option enabled, expect reduced
> > > performance. VT(vga): resolution 640x480
> > > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
> > >   Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45
> > > Stepping=1
> > > Features=0xbfebfbff > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > Features2=0x4ddaebbf > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > AMD Features=0x2c100800 AMD
> > > Features2=0x21 Structured Extended
> > > Features=0x2603 XSAVE
> > > Features=0x1 VT-x: (disabled in BIOS)
> > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance
> > > statistics real memory  = 4301258752 (4102 MB)
> > > avail memory = 1907572736 (1819 MB)
> > > Event timer "LAPIC" quality 600
> > > ACPI APIC Table:   
> > What does this mean ?  Did you flashed coreboot ?
> 
> This machine comes with it by default (my model was delivered with 
> SeaBIOS 20131018_145217-build121-m2). So I didn't flash anything
> (didn't feel like bricking it).
> 
> > 
> > > kernel trap 12 with interrupts disabled
> > > 
> > > Fatal trap 12: page fault while in kernel mode 
> > > cpuid = 0; apic id = 00
> > > fault virtual address= 0xf8000100
> > > fault code   = supervisor write data, protection
> > > violation instruction pointer  = 0x20:Ox8102955f
> > > stack pointer= 0x28:0x82a79be0
> > > frame pointer= 0x28:0x82a79c10
> > > code segment = base Ox0, limit Oxf, type Ox1b
> > >  = DPL 0, pres 1, long 1, def32 0, gran 1
> > > processor eflags = resume, IOPL = 0
> > > current process  = 0 ()
> > > [ thread pid 0 tid 0 ]
> > > Stopped at  native_start_all_aps+0x08f:  movq
> > > %rax,(%rsi)  
> > Look up the source line number for this address.
> > 
> 
> I guess that's sys/amd64/amd64/support.S line 854 (in rdmsr), called by
> native_start_all_aps. Any additional hints how I can track it down?
Why did you decided that this is rdmsr_safe() ? First,
native_start_all_aps() does not call rdmsr, second the ddb
report clearly indicates that the fault occured acessing DMAP in
native_start_all_aps().

Just look up the source line by the address native_start_all_aps+0x08f.
___
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"

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

2018-06-03 Thread Michael Gmelin




On Sun, 3 Jun 2018 16:21:10 +0300
Konstantin Belousov  wrote:

> On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin wrote:
> > Hi,
> > 
> > After upgrading CURRENT to r333992 (from something at least a year
> > old, quite some changes in mp_machdep.c since), this machine crashes
> > on boot:
> > 
> > Copyright (c) 1992-2018 The FreeBSD Project.
> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
> > 1994 The Regents of the University of California. All rights
> > reserved. FreeBSD is a registered trademark of The FreeBSD
> > Foundation. FreeBSD 12.0-CURRENT #1 r333992: Tue May 22 00:31:04
> > CEST 2018 root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based
> > on LLVM 6.0.0) WARNING: WITNESS option enabled, expect reduced
> > performance. VT(vga): resolution 640x480
> > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
> >   Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45
> > Stepping=1
> > Features=0xbfebfbff > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > Features2=0x4ddaebbf > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > AMD Features=0x2c100800 AMD
> > Features2=0x21 Structured Extended
> > Features=0x2603 XSAVE
> > Features=0x1 VT-x: (disabled in BIOS)
> > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance
> > statistics real memory  = 4301258752 (4102 MB)
> > avail memory = 1907572736 (1819 MB)
> > Event timer "LAPIC" quality 600
> > ACPI APIC Table:   
> What does this mean ?  Did you flashed coreboot ?

This machine comes with it by default (my model was delivered with 
SeaBIOS 20131018_145217-build121-m2). So I didn't flash anything
(didn't feel like bricking it).

> 
> > kernel trap 12 with interrupts disabled
> > 
> > Fatal trap 12: page fault while in kernel mode 
> > cpuid = 0; apic id = 00
> > fault virtual address= 0xf8000100
> > fault code   = supervisor write data, protection
> > violation instruction pointer  = 0x20:Ox8102955f
> > stack pointer= 0x28:0x82a79be0
> > frame pointer= 0x28:0x82a79c10
> > code segment = base Ox0, limit Oxf, type Ox1b
> >  = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags = resume, IOPL = 0
> > current process  = 0 ()
> > [ thread pid 0 tid 0 ]
> > Stopped at  native_start_all_aps+0x08f:  movq
> > %rax,(%rsi)  
> Look up the source line number for this address.
> 

I guess that's sys/amd64/amd64/support.S line 854 (in rdmsr), called by
native_start_all_aps. Any additional hints how I can track it down?

Thanks,
Michael

> > db>  
> > 
> > Any key press in the debugger will reboot the machine.
> > 
> > Booting with kern.smp.disabled=1 works.
> > 
> > Any ideas?
> > 
> > -m
> > 
> > -- 
> > Michael Gmelin
> > ___
> > 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"  
> ___
> 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"



-- 
Michael Gmelin
___
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"

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

2018-06-03 Thread Konstantin Belousov

On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin wrote:
> Hi,
> 
> After upgrading CURRENT to r333992 (from something at least a year
> old, quite some changes in mp_machdep.c since), this machine crashes
> on boot:
> 
> Copyright (c) 1992-2018 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>   The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 12.0-CURRENT #1 r333992: Tue May 22 00:31:04 CEST 2018
> root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 
> 6.0.0)
> WARNING: WITNESS option enabled, expect reduced performance.
> VT(vga): resolution 640x480
> CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45  Stepping=1
>   
> Features=0xbfebfbff CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>   
> Features2=0x4ddaebbf xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
>   AMD Features=0x2c100800
>   AMD Features2=0x21
>   Structured Extended Features=0x2603
>   XSAVE Features=0x1
>   VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> real memory  = 4301258752 (4102 MB)
> avail memory = 1907572736 (1819 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: 
What does this mean ?  Did you flashed coreboot ?

> kernel trap 12 with interrupts disabled
> 
> Fatal trap 12: page fault while in kernel mode 
> cpuid = 0; apic id = 00
> fault virtual address= 0xf8000100
> fault code   = supervisor write data, protection violation
> instruction pointer  = 0x20:Ox8102955f
> stack pointer= 0x28:0x82a79be0
> frame pointer= 0x28:0x82a79c10
> code segment = base Ox0, limit Oxf, type Ox1b
>  = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = resume, IOPL = 0
> current process  = 0 ()
> [ thread pid 0 tid 0 ]
> Stopped at  native_start_all_aps+0x08f:  movq %rax,(%rsi)
Look up the source line number for this address.

> db>
> 
> Any key press in the debugger will reboot the machine.
> 
> Booting with kern.smp.disabled=1 works.
> 
> Any ideas?
> 
> -m
> 
> -- 
> Michael Gmelin
> ___
> 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"
___
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"

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

2018-06-03 Thread Michael Gmelin

Hi,

After upgrading CURRENT to r333992 (from something at least a year
old, quite some changes in mp_machdep.c since), this machine crashes
on boot:

Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #1 r333992: Tue May 22 00:31:04 CEST 2018
root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 
6.0.0)
WARNING: WITNESS option enabled, expect reduced performance.
VT(vga): resolution 640x480
CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45  Stepping=1
  Features=0xbfebfbff
  
Features2=0x4ddaebbf
  AMD Features=0x2c100800
  AMD Features2=0x21
  Structured Extended Features=0x2603
  XSAVE Features=0x1
  VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 4301258752 (4102 MB)
avail memory = 1907572736 (1819 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
kernel trap 12 with interrupts disabled

Fatal trap 12: page fault while in kernel mode 
cpuid = 0; apic id = 00
fault virtual address= 0xf8000100
fault code   = supervisor write data, protection violation
instruction pointer  = 0x20:Ox8102955f
stack pointer= 0x28:0x82a79be0
frame pointer= 0x28:0x82a79c10
code segment = base Ox0, limit Oxf, type Ox1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = resume, IOPL = 0
current process  = 0 ()
[ thread pid 0 tid 0 ]
Stopped at  native_start_all_aps+0x08f:  movq %rax,(%rsi)
db>

Any key press in the debugger will reboot the machine.

Booting with kern.smp.disabled=1 works.

Any ideas?

-m

-- 
Michael Gmelin
___
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"

37 matches

Mail list logo