From owner-freebsd-hackers Tue Aug 13 16:07:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA19112 for hackers-outgoing; Tue, 13 Aug 1996 16:07:04 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA19106 for ; Tue, 13 Aug 1996 16:07:03 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA27932; Tue, 13 Aug 1996 16:01:27 -0700 From: Terry Lambert Message-Id: <199608132301.QAA27932@phaeton.artisoft.com> Subject: Re: Rebooting and related topics.. To: julian@whistle.com (Julian Elischer) Date: Tue, 13 Aug 1996 16:01:26 -0700 (MST) Cc: terry@lambert.org, hackers@freebsd.org In-Reply-To: <3211014E.2781E494@whistle.com> from "Julian Elischer" at Aug 13, 96 03:27:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Think about priority based insertion and maintaining a front/end/middle > > (middle = don't care) insertion order. > > you know, I don't think this is that important.. it complicates things.. > > I migh tadd 2 calls. at_reboot() and at_reboot_last() but that would be > the limit of it I think.. KISS I was talking architecture; you are talking implementation. I didn't want to say anthing about implementation, in case I offended you because you already had it all written before you posted. 8-). > > That way the actual attempts at keyboard reset, etc., can be put into > > the same list as call-outs. > > why reset a keyboard at reboot? Reset *using* the keyboard, as opposed to resetting via triple fault. Order: 1) APM interface (shut machine power off -- new Micron boxes and old non-Intel boxes from everyone else support this. 2) Bus-based reset: PCI-specific, EISA specific, MCA specific 3) Keyboard controller based reset attempt 4) Triple fault reset attempt 5) Hang there with pages unmapped looking stupid until a human hits the reset button. 8-). > > You may also want to add a parameter to the calldowns that supports > > the type of shutdown (halt/reboot/boot_to_dos, etc.). > > I already do,, > the args to the function are func(arg1,howto) > where howto is the usual RB_ flags word.. This is good; if you are doing a halt (hard reset required) or a power control (power on required), then you can speed things up by not setting non-FIFO mode on the UART's, etc., so non-BSD OS's can use them safely. Most BIOS' don't implement FIFO reset in their serial port initialization code, and without it, the FIFO mode can remain on and cause problems. The same for ethernet card interrupts, etc. (though most drivers have been hacked to avoid that, already). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.