Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Apr 2007 17:29:28 -0400
From:      Kris Kennaway <kris@obsecurity.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org
Subject:   Re: cvs commit: src/sys/amd64/amd64 vm_machdep.c src/sys/i386/i386 vm_machdep.c
Message-ID:  <20070424212927.GA39974@xor.obsecurity.org>
In-Reply-To: <200704241721.46689.jhb@freebsd.org>
References:  <200704242117.l3OLHjRn017578@repoman.freebsd.org> <200704241721.46689.jhb@freebsd.org>

index | next in thread | previous in thread | raw e-mail

On Tue, Apr 24, 2007 at 05:21:46PM -0400, John Baldwin wrote:
> On Tuesday 24 April 2007 05:17:45 pm John Baldwin wrote:
> > jhb         2007-04-24 21:17:45 UTC
> > 
> >   FreeBSD src repository
> > 
> >   Modified files:
> >     sys/amd64/amd64      vm_machdep.c 
> >     sys/i386/i386        vm_machdep.c 
> >   Log:
> >   Fix the triple fault used as a last resort during a reboot to actually
> >   fault.  The previous method zero'd out the page tables, invalidated the
> >   TLB, and then entered a spin loop.  The idea was that the instruction 
> after
> >   the TLB invalidate would result in a page fault and the page fault and
> >   subsequent double fault wouldn't be able to determine the physical page
> >   for their fault handlers' first instruction.  This stopped working when
> >   PGE (PG_G PTE/PDE bit) support was added as a TLB invalidate via %cr3
> >   reload doesn't clear TLB entries with PG_G set.  Thus, the CPU was still
> >   able to map the virtual address for the spin loop and happily performed
> >   its infinite loop.
> >   
> >   The triple fault now uses a much more deterministic sledge-hammer approach
> >   to generate a triple fault.  First, the IDT descriptor is set to point to
> >   an empty IDT, so any interrupts (including a double fault) will instantly
> >   fault.  Second, we trigger a int 3 breakpoint to force an interrupt and
> >   kick off a triple fault.
> >   
> >   MFC after:      3 days
> 
> This and the other changes to support more methods for kicking off a reset 
> might fix problems people have with machines not rebooting but just hanging.  
> IIRC, there was a problem on some Dell 1950s that wouldn't reboot properly, 
> so they might be a good candidate for this.  I ran into this at work on a 
> machine that didn't have a functional keyboard controller, so it didn't 
> reboot when the keyboard reset failed, but just hung.

Some of my newer machines sometimes fail to reboot without power
cycling, so I'll keep an eye out.

Kris


home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070424212927.GA39974>