Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Aug 1996 16:01:26 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        julian@whistle.com (Julian Elischer)
Cc:        terry@lambert.org, hackers@freebsd.org
Subject:   Re: Rebooting and related topics..
Message-ID:  <199608132301.QAA27932@phaeton.artisoft.com>
In-Reply-To: <3211014E.2781E494@whistle.com> from "Julian Elischer" at Aug 13, 96 03:27:26 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.



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