From: Bob Canup <rcanup@go2fax.com>
To: mtd@imladris.mvhi.com
Subject: power down
Date: Fri, 03 Dec 1999 13:28:42 -0600 [thread overview]
Message-ID: <384819EA.5AEB1F19@go2fax.com> (raw)
The reason that I said that expecting anything to work during power down
is wishful thinking is this: once the voltage to a digital chip goes
below the minimum specification of the chip, the behavior of the chip
becomes indeterminate.
For example: the old Western Digital 1791 double density disk controller
chip would sometimes glitch in such a way during power down that it
would write to the floppy - you could see the floppy light blink when
this happened.
Unless chips are specifically designed to handle power down conditions
this sort of thing happens. For example - any competently designed
Flash memory has to refuse to write if the voltage is below spec.
As to flushing the buffers and doing a shutdown when a power fail
condition occurs - I believe that Linux already has code to handle a
power down such as I described. What I have described is very similar to
a UPS signaling the kernel that power is going down. Linux can do an
ordered shutdown when it receives the signal.
Qualifying digital circuitry with a POWER GOOD signal is very similar to
protecting the circuitry with a typical 'SCR over voltage crowbar
circuit': it makes the engineer feel good - but it doesn't actually do
much of anything.
Why doesn't the crowbar work? After all, it is a text book circuit. The
answer is that the SCR is a power device which takes on the order of 10
microseconds to turn on while the delicate chips are destroyed by a few
nanoseconds of over voltage. The result is that the SCR never turns on -
the fuse blows because the weakest digital chip shorts the power supply
to ground. One could "protect" SCR's with digital chips, but not the
other way around.
Another example of "feel good engineering" is the power on self test
which most computers have. One can only test non critical sections of
the machine: if anything critical is broken the POST won't run - and a
tech will have to figure out what is wrong. It's a bit like asking
yourself "Am I alive?" If you can ask the question the answer is always
"Yes".
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
next reply other threads:[~1999-12-03 19:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-12-03 19:28 Bob Canup [this message]
-- strict thread matches above, loose matches on Subject: below --
1999-12-08 0:58 Power Down Oron Ogdan
1999-12-08 9:54 ` David Woodhouse
1999-12-10 10:41 ` Stephen C. Tweedie
1999-12-08 8:57 Oron Ogdan
1999-12-08 14:55 Bob Canup
1999-12-08 15:04 ` David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=384819EA.5AEB1F19@go2fax.com \
--to=rcanup@go2fax.com \
--cc=mtd@imladris.mvhi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox