On Fri, Mar 23, 2018 at 4:19 PM, Konstantin Belousov
wrote:
> On Fri, Mar 23, 2018 at 04:06:23PM -0700, Mark Peek wrote:
> > I ran into the original issue with r330539 on a Fusion VM. Trying this
> > patch causes a different panic:
> >
> > https://people.freebsd.org/~mp/r330539-patched.png
> >
>
On Fri, Mar 16, 2018 at 2:56 AM, Konstantin Belousov
wrote:
> On Thu, Mar 15, 2018 at 09:38:56PM -0500, Peter Lei wrote:
> > Some recent UEFI implementations have begun to leave the CPU with page
> > write protection enabled in CR0.
> >
> > With r330539 which enables kernel page protections, inte
On Fri, Mar 23, 2018 at 04:44:36PM -0700, Mark Peek wrote:
> On Fri, Mar 23, 2018 at 4:19 PM, Konstantin Belousov
> wrote:
>
> > On Fri, Mar 23, 2018 at 04:06:23PM -0700, Mark Peek wrote:
> > > I ran into the original issue with r330539 on a Fusion VM. Trying this
> > > patch causes a different p
On Fri, Mar 23, 2018 at 04:06:23PM -0700, Mark Peek wrote:
> I ran into the original issue with r330539 on a Fusion VM. Trying this
> patch causes a different panic:
>
> https://people.freebsd.org/~mp/r330539-patched.png
>
> Thoughts?
r331290 should fixed this issue. What is your kernel sources
On Thu, Mar 15, 2018 at 09:38:56PM -0500, Peter Lei wrote:
> Some recent UEFI implementations have begun to leave the CPU with page
> write protection enabled in CR0.
>
> With r330539 which enables kernel page protections, interesting things
> happen during boot (aka panic) when protection is alre
Some recent UEFI implementations have begun to leave the CPU with page
write protection enabled in CR0.
With r330539 which enables kernel page protections, interesting things
happen during boot (aka panic) when protection is already enabled,
including a write protection fault from an explicit .tex
