Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!uunet!cis.ohio-state.edu!python.cis.ohio-state.edu!cermak From: cermak@python.cis.ohio-state.edu (gerald cermak) Subject: Re: [386BSD] 16550 Not Resetting. Message-ID: <1992Dec2.042010.10243@cis.ohio-state.edu> Sender: news@cis.ohio-state.edu (NETnews ) Organization: The Ohio State University Dept. of Computer and Info. Science References: <1992Nov28.115716.8219@runx.oz.au> <CGD.92Nov28202543@eden.CS.Berkeley.EDU> <1992Dec1.202945.10779@fcom.cc.utah.edu> Date: Wed, 2 Dec 1992 04:20:10 GMT Lines: 61 In article <1992Dec1.202945.10779@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: [...much stuff deleted...] >It isn't the BIOS's job to know what hardware is in the machine -- it's the >machines job. The very idea of a "probe" routine is a dodo from a long >time ago, and is only necessitated by a stupid bus architecture (and we're >going to have to continue living with it for the forseeable future). > >IMHO, it's the hardware designer who has fallen down on the job, since a >bus reset should return all devices to power-on state, and it doesn't do >this for 16550 based serial cards... ie: the hardware design is inapropriate >for the stupid bus architecture. IMHO, replace "stupid" with old: the original PC bus came to market around 1980, 640k memory addressability (micro's at the time only had 64k - an order of magnitude improvement!), open architecture (from proprietary IBM?!?!), and usable/productive software, all with a resonable price/feature ratio. We wouldn't be having these gripes about the AT bus (the 16-bit downward compatible bus) if it weren't for the success of the original. A great selling feature of the PC was the modularity the PC bus provided. Broken boards were cheaply replaced by anyone half competent with a screw-driver, any ma-and-pa electronics shop could design a widget board to accomplish some fancy whatchamjigger. Competition kept hardware prices low. More PC's were bought, more PC add-on cards were bought...proliferation. As far as soft resets go: pressing CTL-ALT-DEL causes a soft reset, far jumping to the 80386 reset vector causes a soft reset also (with maybe a memory check added). _THIS HAS USEFULLNESS_: memory is still intact after a soft reset, i.e., the DMA channel is still refreshing the dynamic rams at the much needed ~2 mSec rate. One could potentially peek around memory after a lockup and subsequent CTL-ALT-DEL. Pressing the RESET button of the unit will most surely stop the DMA refresh cycles long enough to corrupt RAM. I think the only hardware shortcoming in this situation with resets is not the bus (it has a reset line), but the motherboard lacking some port bit location that could allow the CPU/software to, at will, fire the bus reset line to effect the desired hardware reset states. As for Terry's recommendation for having shutdown routines for various hardware devices - very symmetrical idea. Compare to C's atexit(), or closing disk files before exitting an application. What is needed is functionality somewhere to provide "atexit()" type hardware closure. Each device, at start-up should register, if needed, some atexit()-style process to return itself to a rebootable state.... Gerry Cermak cermak@cis.ohio-state.edu student at The Ohio State University