From owner-freebsd-current  Tue Apr 18 18:21:10 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id SAA29447
          for current-outgoing; Tue, 18 Apr 1995 18:21:10 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA29439
          for <current@freebsd.org>; Tue, 18 Apr 1995 18:20:59 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id LAA15783; Wed, 19 Apr 1995 11:15:30 +1000
Date: Wed, 19 Apr 1995 11:15:30 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199504190115.LAA15783@godzilla.zeta.org.au>
To: current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com
Subject: Re: Fix for motherboards that don't reboot.
Sender: current-owner@FreeBSD.org
Precedence: bulk

>I spent some time talking with a BIOS engineer today about the problem
>of FreeBSD not rebooting on some motherboards and have come up with
>the following patch that fixes the problem on the board I have here.

>  void
>  cpu_reset() {
>+ 
>+ 	/* Attempt to do a CPU reset via the keyboard controller */
>+ 	outb(IO_KBD + 4, 0xFE);

This is what I implemented for Minix about (sigh) 6 years ago.  I found
that outputting 0xFC works better.  AFAIR 0xFE strobes the CPU reset
line and 0xFC additionally strobes GateA20.  Both methods worked in
protected mode on the machines that I had access to, but in real mode,
(with A20 forced to 0) several machines hung, apparently due to a bad
fetch of the first instruction after reset.  The first instruction was
usually invalid and jumped to the BIOS invalid instruction handler,
which was braindamaged and looped.  Trapping it with a debugger and
jumping to the correct reset vector worked.  I suspect the reset worked
better in protected mode only because the invalid instruction handler
was invalid and the system eventually got reset better after a triple
fault.

Bruce