From owner-freebsd-current Tue Apr 18 19:05:20 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA00807 for current-outgoing; Tue, 18 Apr 1995 19:05:20 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id TAA00796 for ; Tue, 18 Apr 1995 19:05:09 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id TAA00702; Tue, 18 Apr 1995 19:00:35 -0700 From: "Rodney W. Grimes" Message-Id: <199504190200.TAA00702@gndrsh.aac.dev.com> Subject: Re: Fix for motherboards that don't reboot. To: bde@zeta.org.au (Bruce Evans) Date: Tue, 18 Apr 1995 19:00:35 -0700 (PDT) Cc: current@FreeBSD.org In-Reply-To: <199504190115.LAA15783@godzilla.zeta.org.au> from "Bruce Evans" at Apr 19, 95 11:15:30 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1493 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. > Thanks for the input, I will talk to this person again at a meeting I have on Thursday evening. I will bring the issue of GateA20 up with him and see what he says about it. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD