From owner-freebsd-current Fri Apr 21 12:47:02 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA17116 for current-outgoing; Fri, 21 Apr 1995 12:47:02 -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 MAA17110 for ; Fri, 21 Apr 1995 12:46:56 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id MAA09159; Fri, 21 Apr 1995 12:37:57 -0700 From: "Rodney W. Grimes" Message-Id: <199504211937.MAA09159@gndrsh.aac.dev.com> Subject: Re: Fix for motherboards that don't reboot. To: bde@zeta.org.au (Bruce Evans) Date: Fri, 21 Apr 1995 12:37:56 -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: 2172 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 brain damaged 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. I have gotten back one test report on my patch, it did not work for the person and he got the: Keyboard reset did not work, attempting CPU shutdown message I put in there. I had him change the 0xFE to 0xFC and it caused a processor exception (gating A20 off without the reset occurring sent the machine to god knows where) and did not output the above message. This is clearly either a defective MB or a bad design. But given the 2 values it looks as if 0xFE is safer since it allows us to at least attempt the CPU shutdown if the reset failed. The person I got the information from about doing this says that in fact 0xFE is the better value to use (this person writes BIOS'es for a living) and is suppose to dig out the official reason for me today. Once I here from him I will be committing my patch with additional comments with the 0xFE value. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD