[Discuss] Kernel interpretation of pressing the reset button?

[Alan W. Irwin]

On 2018-06-13 11:28-0700 Darren Duncan wrote:

> On 2018-06-13 10:07 AM, Alan W. Irwin wrote:
>> On 2018-06-12 22:37-0700 Darren Duncan wrote:
>> [...]
>>> On all the computers I've used for a long time, holding down the power 
>>> button for like 4+ seconds performs a reset, where pressing and letting it 
>>> go, or holding it only for a shorter time, will signal the OS.
>> 
>> I believe in this sentence you have confused reset with power off.
>> For example, <https://en.wikipedia.org/wiki/Reset_button> states
>> "on most computers the power button can remove power immediately if
>> held down for a few seconds", and I also have observed that behaviour
>> (i.e., powering down the equipment when you hold the power button down
>> long enough) on a number of computers (including my latest) over the
>> years.
>
> You are right, the button hold actually shuts the computer off.  But for all 
> practical purposes its the same thing.  You hold to shut off the computer, 
> and then after a few seconds press again normally to turn it on again.  The 
> separate shut-off and turn-on actually gives the user more choices.  Is there 
> any purpose for which what I proposed is not giving all of the practical 
> value of the reset button?

My understanding is that reset is a little less tough on the
electronics since there is no change in power levels.  But on the
other hand, some PC users turn off their equipment every night and
those PC's survive many such power cycles without issues.  So the real
issue is I have discovered the reset is not always reliable when the
kernel is locked up for my new computer.  I could just ignore that and
use power off instead, but I like the hardware on my computer to work
properly, and as Cy has claimed (and I agree that is a possibility)
there could be some bad consequences to a reset hardware failure.

So (likely this evening) I plan to discover experimentally (by tests
from the grub menu environment where the kernel is not active at all)
if that unreliability is an issue with the reset hardware or simply a
strange artifact of the kernel lock up.  Cy claims the latter is not
possible (i.e., the kernel cannot detect the hardware reset and do
something different if it is already locked up), and I generally agree
that makes sense, but if the experiment finds, say, 20 straight
non-kernel resets all working perfectly (i.e., POSTing the computer
from the grub menu environment), I think we have to eliminate most if
not all hardware issues as a possible explanation of reset
unreliability when the kernel is locked up.  But if the non-kernel
reset experiment shows unreliable resets, then I will take the
computer in to Mother Computers for repair.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________