[Discuss] Kernel interpretation of pressing the reset button?

[Cy Schubert]

In message <nycvar.QRO.7.76.1806111132110.14758 at zreyva.zlyna.ubzr>, "Alan W. Ir
win" writes:
> On 2018-06-09 12:19-0700 Cy Schubert wrote:
>
> > In message <4E6AE5F528744E479C4F2AC326FFF840024809C57E at EX10MBX01.intra.c
> > amosun.
> > bc.ca>, "Deryk Barker (Honorary Colleague)" writes:
> >> Alan, unless things have changed recently, the reset button simply asserts
>  a
> >> reset line/signal on the bus (not that PCIe is really a bus any more).
> >>
> >> If the OS is totally locked up and not even sampling the bus lines...
> >
> > There is no sampling of the bus. The reset pin on the CPU is also
> > asserted when the bus is.
>
> @Cy:
>
> The details are important of course, but so is the overview.  Can I
> conclude from what Deryk and you have said that the Linux kernel has
> complete control of how pressing the reset button is interpreted?

No. The reset pin resets the CPU. 

>
> If so, that would explain how badly knackered kernel ==> no result
> from pressing the reset button.  Beyond that general conclusion, if
> the kernel is working sufficiently well so the reset button works, why
> is the result always a dirty shutdown that requires a journal replay
> on the next boot that is typically accompanied by removal of inodes?
> Is such a dirty shutdown considered safer than the alternative of
> doing a clean shutdown when you have lost control of your computer
> sufficiently so the reset button has to be hit to regain control?  And
> is that inode removal (which I assume means removal of all files that
> were memory resident but still needed to be written out to disk at the
> time the reset button is hit) anything to worry about or does it mean,
> for example, that effectively only a few lines of some log file that
> was being actively written are missing on the new system rather than
> the entire log file going missing.
>
> I have never thought about these questions before because I have very
> rarely (until the last several weeks) ever had to hit the system reset
> button, and I only have a general knowledge of exactly what an inode
> means, and I don't know, for example, whether a dirty file in memory
> that corresponds to a log file that has had some lines added in memory
> has a different inode than the old version of the log file.  Anyhow, I
> would appreciate replies (from the overview perspective) to my
> questions.

 https://www.intel.com/content/dam/www/public/us/en/documents/guides/core-i5-3610me-qm77-development-kit-guide.pdf

The CPU is reset and registers cleared. Then it branches to FFFFFFF0h (BIOS).
Either you have a hardware issue or a bug in your MMU.

When the motherboard is reset, memory is cleared  in addition reset asserted.
The process has been thoroughly documented by Intel and AMD.

For me personally, the only time reset switch ever failed was with a flaky power
supply a couple of years ago. In that case replacing the power supply resolved
the issue.


-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.