Talk:Reboot

"Rebooting (computing)" or just "Rebooting"?

Currently, rebooting goes to the reboot dab page; the only item on that page that's "rebooting" other than "reboot" is this page. Should this page just be "Rebooting", perhaps with an "other uses" link to the "Reboot" page? Guy Harris (talk) 18:34, 21 June 2011 (UTC)

No, I think people have talked about "rebooting" a TV/movie/comic book/etc. franchise. Guy Harris (talk) 00:32, 22 January 2013 (UTC)

Cold Boot

Perhaps I show my age here, but I was trained that a "cold boot" is any time the computer is turned off the whole way. Often, everything is shut down in a orderly manner (not just flipping of the power switch, but going through a proper shutdown). I tagged with {{fact}} to see if anyone can find a reference to support what is currently written. --Nouniquenames (talk) 03:30, 18 June 2012 (UTC)

Here you go. Socrates2008 (Talk) 08:55, 18 June 2012 (UTC)

A hardware reset doesn't provoke a soft reboot

If, for example, you press a button that forcibly resets the hardware (or perhaps, on microcoded machines, invokes microcode that resets the hardware), that is not a "soft reboot" in the sense described in the article - software isn't told about the reset, it Just Happens out from under the software.

Most of the reboot process in that case is similar to the power-cycle case. However, it's sufficiently different, in that power isn't lost to any of the circuits, that, whilst it probably should be described in the "hard boot" section, the differences should be mentioned.

I'm not sure whether there's a standard term for this. "Warm reload" appears to be used in this Cisco document to refer to a "soft boot", rather than a hit-the-reset-button reload. Similarly, Intel appears to be using "warm reboot" in this EFI document to refer to a firmware/software-controlled reboot, although rebooting from EFI might not be as "soft" as rebooting from the operating system. (And what I found when Googling for "lukewarm reboot" mainly seems to talk about another form of reboot.) Guy Harris (talk) 00:30, 22 January 2013 (UTC)

Not all hardware resets involve power-cycling

There are forms of hardware reset that do not involve turning the power on and off. See reset (computing). — Preceding unsigned comment added by Guy Harris (talk • contribs) 18:30, 22 January 2013 (UTC)

Hi. Such reboots are not hard (or cold). In a hard (or cold) reboot, power must be cut, then reconnected. The means of such action (e.g. a circuit, a chip, a push button, a toggle button, a cord, etc. or a complex combination of all of these) is not important.

As for reset (computing), I don't think even the article itself knows what it is talking about. We can discuss about it separately, but I prefer we focus on this problem for now.

Best regards,

Codename Lisa (talk) 08:18, 23 January 2013 (UTC)

They're not soft, either. A "soft reboot" is one where the OS does whatever is necessary to cause a reboot; a reset-button reboot yanks control out from under the OS, rather than allowing the OS to gracefully shut down and restart when it's done. Guy Harris (talk) 09:25, 23 January 2013 (UTC)

Hi.

To what does "they" refer? AFAIK a soft (or warm) reboot may also be initiated by firmware (e.g. BIOS, UEFI, etc.), hypervisor or CPU (by its own decision instead of a command). The only difference with a hard reboot is the power not getting cut. Other differences are situational.

Best regards,

Codename Lisa (talk) 10:09, 23 January 2013 (UTC)

There are reboots in which the operating system shuts down gracefully and does whatever it needs to do to reboot the machine (hit an ACPI register or the keyboard controller on a PC; poke the hypervisor or do some dance that looks as if it does in software what the IPL button does in hardware/firmware on S/3x0, etc.); there are reboots where the CPU jumps to firmware (e.g. as the result of a non-maskable interrupt that is either directly vectored to a firmware routine or is vectored to an OS routine that does a quick "jump to the firmware") and then a firmware command that does a reboot is performed without the OS doing any cleanup; and there are reboots wherein, for example, a hardware reset is performed on the CPU and it performs the same sequence of operations that are performed as a result of a power-on reset, again without the OS doing any cleanup.

So there are several characteristics that can describe a particular type or reboot, including:

• whether power was removed from the hardware (well, with the exception of whatever power a system battery might continuously apply to components of the system) or not;
• whether the OS did a more-or-less graceful shutdown (whether "a reboot system call executed out from under userland without any notification to userland, but at least it got to sync the file systems" to "at least it sent userland code a "time to shut down" signal and waited a bit to let it finish" to "it went through the full fancy sequence including letting GUI applications pop up "save your work?" dialogs");
• whether software was involved in the process or whether a hardware reset invoked it;
• the gory details of "graceful" as mentioned in the second item above.

The first two of those are definitely important - a reboot where the OS got to do something, even if it's just sync the file systems, is different from one where the reboot was done out from under the OS. The third is probably important only to the extent that it can reset a machine even if, for example, the path to the firmware goes through the OS and the OS isn't letting you get there. The fourth might be important as well, in that there's system state that could be inconsistent or work that could be lost even if the file systems didn't get synced, but it also might be more detail than we want to give here. Guy Harris (talk) 20:06, 23 January 2013 (UTC)

Hi. I agree so far. (In fact I said in my previous message that I agree.) However, none of these are distinguishing features of a cold (or hard) reboot. The only distinguishing feature is power being cut, then reconnected. Best regards, Codename Lisa (talk) 11:25, 24 January 2013 (UTC)

So a page that says only that there are hard reboots, in which the power is cut, and some other type of reboot, in which the power is not cut, is incomplete. In many ways, whether the OS gets to be involved in the reboot before the machine is restarted, and thus can make the reboot somewhat graceful, or doesn't get to be involved, is more important than whether the power was cut or not. Guy Harris (talk) 19:00, 24 January 2013 (UTC)

This distinction is largely off-topical, since all details about physical interrupting of normal computer functioning belong to the reset (computing) article. The concept of reboot does not depend on it. The life of an operating system becomes broken – it is the focus of the article. Possible scenarios can be roughly classified to an OS-assisted rebooting (an OS-controlled shutdown and subsequent boot) and asynchronousinsurmountable causes (power loss, hardware reset, CPU or motherboard failures). The latter group of causes should be covered by reset (computing). Incnis Mrsi (talk) 19:20, 24 January 2013 (UTC)

Not necessarily asynchronous, because a processor failure can be induced by incorrect functioning of the software. Incnis Mrsi (talk) 19:33, 24 January 2013 (UTC)

I assume by "this distinction" you're referring to the distinction between reboots that involve power being cut and reboots that don't. If that's the case, I agree with you; the major differences between different types of reboots are "how much involvement did software have in the shutdown process" (did the reboot have to happen without the cooperation of perhaps-misbehaving software, i.e. power-cycling or hitting a reset button or possibly hitting an NMI button and doing a reset from a PROM monitor command prompt if the OS is locked up, and how much cleanup, if any, did the software get to do if it was involved).

"Asynchronously-caused" (or whatever term is appropriate) reboots (the ones that happened with no more OS cooperation than perhaps catching the NMI and jumping to the PROM monitor) should be discussed in the article. The details of how that happens should, perhaps, be discussed in not just the reset (computing) article, but in the power-cycling page as well. Guy Harris (talk) 19:40, 24 January 2013 (UTC)

Hi. I also agree with that. We never disputed this. In fact, I also agree with the title: Not all hardware resets involve power-cycling. True again. What I don't agree with is what I said the very first: Such reboots are not cold (or hard) reboots. (And I had a reason for making this comment: Guy's edit in the article.) The only difference between a cold reboot and a warm reboot is that in the former, components are powered down. In the latter, no. In both, the contents memory gets erased or marked as erased and a boot sequence is started. Best regards, Codename Lisa (talk) 04:18, 25 January 2013 (UTC)

P.S. I am starting to feel I am not even sure what is a "hardware reset" or "hardware reboot". Guy, you are using these two terms very freely and I am starting to think maybe you think since the word "hardware" has "hard" in it, then a cold reboot (also known as hard reboot) may have strong association with hardware. That is not the case. (Again, your edit in the article has become a factor.) Best regards, Codename Lisa (talk) 04:29, 25 January 2013 (UTC)

"The only difference between a cold reboot and a warm reboot is that in the former, components are powered down." Actually, the cold boot attack paper (you'll have to follow the "Full research paper" link yourself, as Wikipedia won't allow that link in a Wikipedia page) says, in the "Simple reboots" section on page 7, "A warm boot, invoked with the operating system’s restart procedure, will normally ensure that the memory has no chance to decay, though software will have an opportunity to wipe sensitive data prior to shutdown. A cold boot, initiated using the system’s restart switch or by briefly removing and restoring power, will result in little or no decay depending on the memory’s retention time." It sounds as if they're speaking of a "cold reboot" as being any reboot that bypasses the OS, whether it involves power cycling or not, and a "warm reboot" as being any reboot caused by the OS being told to reboot. Do you have any citations of documents that say a "hard reboot" is one that involves power-cycling the hardware and a "soft reboot" is any other reboot, even if it involves a hardware reset? If so, do you have any that say the same for "cold" and "warm" reboots? Guy Harris (talk) 19:22, 25 January 2013 (UTC)

"I am starting to feel I am not even sure what is a "hardware reset" or "hardware reboot"." A "hardware reset" is a reset caused by a hardware signal such as RSTIN# on the Intel Xeon C5500/C3500. Note that they call a reset through that line a "warm reset", so they appear to be drawing a different distinction between "cold" and "warm" than are the Princeton folks, perhaps because the datasheet is targeted towards hardware folks, to whom the OS's involvement in the process would be less interesting than whether power is removed from the chip or not, and the paper cares whether the software had a chance to erase the memory or not.

"I am starting to think maybe you think since the word "hardware" has "hard" in it, then a cold reboot (also known as hard reboot) may have strong association with hardware". I'd suggest you stop thinking that, as I do not, in fact, think that a hard reboot has a strong association with hardware merely because "hardware" has "hard" in it. Having been a developer of OS kernel-level code since the 1970's, I tend to view the distinction between reboots where the OS gets to have some involvement in the matter (even if it's a panic and all it gets to do is sync the file systems) and reboots where it doesn't as more significant than the distinction between reboots that involve a power loss and those that don't, and think that's the main distinction the article should draw, *even if the majority of sources use "hard"/"cold" vs. "soft"/"warm" to make the other distinction*; in the latter case, the article should, in the section on reboots where the OS doesn't get involved (except perhaps in the NMI-to-the-monitor case), make the distinction between reboots of that sort that are "hard"/"cold" and reboots of that sort that are "soft"/"warm". Guy Harris (talk) 19:48, 25 January 2013 (UTC)

Hi. I have an assortment of sources (technical books mostly) but I am unable to comprehend for what do you want a source. I am getting confused down here and the number of questions that I would like to ask (but have to hold back) is mounting. So far I perfectly agree that "Not all hardware resets involve power-cycling". Please clarify: In your opinion, what constitutes the difference between a cold reboot and a warm reboot? Please answer, and I will see which source I should use in reply. Best regards, Codename Lisa (talk) 07:19, 26 January 2013 (UTC)

I want additional sources for the claim that the term "hard reboot" applies only to a reboot where the power is cut and restored and the term "soft reboot" applies to all other types of reboot, even one where, for example, the CPU's reset line is signaled, and additional sources for the claim that the same applies to "cold reboot" and "warm reboot". So far, I've seen the "cold boot attack" paper say that a "cold reboot" is one where the OS's reboot code doesn't run (regardless of whether the power was cycled or not) and a "warm reboot" is one where it does run, and the Intel document which calls a reset by triggering #RSTIN a "warm reset" rather than a "cold reset"; I'd call that a tie. If the majority of sources agree that a "hard reboot" only occurs if the power is cycled, and everything else is a "soft reboot", then the article should say the same, and if they agree that "hard" = "cold" and "soft" = "warm", the article should say that (so that the section on hard reboots will not mention "otherwise forcibly resetting the state of the hardware" or the reset button, and the section on soft reboots will not say that they "[involve] restarting a computer "normally" under software control"). The article should also, then:

• also indicate that a soft reboot "may be caused by accident or deliberately as a last resort to reset an unresponsive system or in case of a critical error", as that's certainly true on, for example, hardware with a reset button that just triggers a reset line;
• have sections that discuss reboots that don't involve the OS restart code ("ungraceful reboots"?) and those that do ("graceful reboots"?), as a separate distinction between hard and soft reboots;
• have the second paragraph of the "Hard reboot" section moved to the section on reboots that don't involve the OS restart code, except for the last sentence, as the first two sentences apply to all "ungraceful reboot"s;
• have the third paragraph of the "Hard reboot" section moved to the section on reboots that don't involve the OS restart code, with "hard reboot" replaced with "ungraceful reboot" (or whatever the term used by most sources is) and with the bit about data remanence noted as applying only to hard reboots (which are always ungraceful) and not to ungraceful soft reboots. Guy Harris (talk) 12:17, 26 January 2013 (UTC)

Hi.

You are confusing me again. But your edit summary was clear and to the point. See:

Tulloch, Mitch; Tulloch, Ingrid (2002). Microsoft Encyclopedia of Networking (2nd ed.). Microsoft Press. p. 172. ISBN 0-7356-1378-8.

Best regards,

Codename Lisa (talk) 19:17, 26 January 2013 (UTC)

Hello again. I have been re-reading your message again (and again; and again; and again ...) and two other things come to my mind:

1. Wikipedia is not a football field or competition in which sources score off each other. Rather, in Wikipedia, we cover all major perspectives on a subject from a neutral point view; i.e. we cover them without passing judgments on them.

2. Can soft reboot be triggered by accident? Theoretically, there can be a soft reboot button on any hypothetical computer but is there?

Best regards,

Codename Lisa (talk) 00:25, 28 January 2013 (UTC)

(All major perspectives supported by reliable sources, presumably, at least for technical topics such as this one.)

The tower PC I had in 1998 had a reset button, but it wasn't an exposed button; it was behind a hole in the front cover, so you could press it with a bent paper clip, but you wouldn't press it if you accidentally bumped up against the machine. If you triggered it, it would restart the machine, going through the BIOS startup procedure; it may have skipped some of the sections performed on a power up, such as some of the tests (I recently gave the machine away to be recycled), but the rest of the start-up process was the same as on a power up. I don't know whether any PCs had easy-to-hit reset buttons; for the machines without easy-to-hit reset buttons, the intent was presumably to prevent users from accidentally ungracefully rebooting their machines and losing their work.

Some older machines had reset buttons that didn't initiate a reboot - those machines, as I remember, also didn't automatically boot when powered up; instead, after being powered up they entered a stopped state, and a boot was initiated with another button, which could also be used to initiate a reboot after a reset. Some also had a stop button, which would halt the processor without performing a reset; a boot could be done at that point as well. For example:

• The original model of the PDP-10, the KA10, had a RESET key, not so hidden (similar to other buttons; see the picture on page 2-84 of Book1 of the PDP-10 Reference Handbook), which stopped the processor ("If RUN is on duplicate the action of the STOP key before clearing") and "[Cleared] all IO devices and [cleared] the processor including all flags"; see page 2-87 of the aforementioned PDP-10 Reference Handbook. The RESET key doesn't start a reboot; the READ IN key would have to be used after that.

• The IBM 1130 also had a Reset switch, which "resets all input/output and machine registers, cycle and control triggers, and status indicators" (see page 15 of IBM 1130 Operating Procedures). That also doesn't start a reboot; the Program Load switch starts a reboot.

• The IBM System/360 architecture specifies that one operator function in all models of System/360 is a System Reset function, with a System-Reset key, which "[causes] a system reset". That also does not start a reboot; that is performed by the Load key. See the System/360 Principles of Operation, pages 122 through 126.

so, on those machines, you could, if sufficiently incautious, hit the reset button when you intended to hit some other button; the machine wouldn't restart, but enough state would have been lost that there's not much point in doing something other than restarting. Guy Harris (talk) 07:43, 28 January 2013 (UTC)

Hi. Just an update: I just read "Lest We Remember: Cold Boot Attacks on Encryption Keys" and I could not find that definition that you attributed to it. Please specify page number or direct quotation. Best regards, Codename Lisa (talk) 01:26, 28 January 2013 (UTC)

Section 4.2 "Imaging attacks", starting at the bottom of page 6, says, at the beginning of the text on page 7:

Simple reboots The simplest attack is to reboot the machine and configure the BIOS to boot the imaging tool. A warm boot, invoked with the operating system’s restart procedure, will normally ensure that the memory has no chance to decay, though software will have an opportunity to wipe sensitive data prior to shutdown. A cold boot, initiated using the system’s restart switch or by briefly removing and restoring power, will result in little or no decay depending on the memory’s retention time. Restarting the system in this way denies the operating system and applications any chance to scrub memory before shutting down.

so a "cold boot" can be done with a "restart switch" of some unspecified form. It's distinguished, in that paragraph, from a "warm boot", which involves the OS's restart procedure, and which is therefore different not only from a power-cycle reboot but also from a reset-button reboot, a halt-and-hit-the-boot-button reboot, or a jump-to-the-monitor-firmware-and-do-a-restart-command reboot. Guy Harris (talk) 09:00, 28 January 2013 (UTC)

Hi. You misinterpreted the source. The sentence, "A warm boot, invoked with the operating system’s restart procedure" refers to a very specific type of warm reboot, i.e. a graceful one. But you have taken it to be a definition of warm reboot, which is wrong. Same goes for cold boot sentence. In other words, you have taken comma to mean "defined as" while it actually means "that is".

As a matter of fact, page 2 has a paraphrased version of this sentence. Look for "The simplest is to reboot the machine and..." in paragraph 2. Best regards, Codename Lisa (talk) 10:19, 28 January 2013 (UTC)

It's a bit odd that they don't just say "a warm boot" and "a cold boot", unless their intent is to deliberately not say anything about what happens if, say, you have a machine where there's an NMI button that normally triggers a jump to a firmware prompt from which you can directly reboot out from under the OS (as on at least some Open Firmware machines).

That procedure isn't a warm boot that is invoked with the operating system's restart procedure; unless the NMI button is deemed a restart switch (even though it doesn't provoke a reboot, just a jump to the firmware monitor prompt), it isn't a cold boot that is initiated using the system's restart switch or by briefly removing and restoring power. (It's also probably the easiest way to grab stuff from memory, as the OS doesn't get to scrub memory, and as the power isn't removed. Heck, if you're at the monitor prompt, it might let you directly read the memory with a command, or even, in the case of Open Firmware, write a Forth program to get the data you want.)

So I'm not sure what they're saying here; did they mean "a {warm,cold} boot, which is...", or "a {warm,cold} boot that is..."? I could see either interpretation being valid. Guy Harris (talk) 10:51, 28 January 2013 (UTC)

Hi.

I think you are forgetting a tiny little detail: They are talking about data remnance here. So, no, both interpretation cannot be correct because only a graceful warm restart and ungraceful cold reboot (sudden power interruption) are suitable for the attack. Ungraceful warm reboots are impossible in Windows; a graceful cold reboot (involving Windows shutdown) only lengthens the reboot. Did you not read the paper?

Best regards,

Codename Lisa (talk) 12:00, 28 January 2013 (UTC)

If you're trying to grab the contents of DRAM main memory, the memory must not lose power for so long a period that it decays to the ground state, and no program that trashes the contents of memory (by clearing, testing, etc.) must have a chance to run before you try to grab it.

Unless there's a detectable difference between the state of a DRAM cell containing 1 and overwritten with 0 and a DRAM cell containing 0 and "overwritten" with 0 (which could be the case, although, if that is the case it might require that you can examine that state from outside), data remanence is relevant only if power is cut to the DRAM.

Power will be cut to the DRAM either if it's physically cut (which, in "battery-powered" mobile machines such as phones, tablets, and laptops, might require that the machine be opened up and batteries removed or disconnected - unplugging from a wall socket won't do it) or if some (possibly firmware-controlled) component cuts it electronically (as might happen in "battery-powered" machines in which "powering the machine off" really means "hibernate and power off everything other than the components that respond to the power button and possibly some communications devices to support wake-on-{LAN, phone call, SMS}).

So you want to make sure that, if the power is cut, you restore power to the DRAM "soon enough". If the power isn't cut, that doesn't matter.

As for memory-trashing by firmware or software, if you get to control what software runs after a restart, the only memory-trashing you need worry about is memory-trashing by firmware. If you can physically remove the memory after halting the machine (which involves physically cutting power to the DRAM unless it can get power from some other source while you move it, but, as the paper notes, moving it doesn't have to take so long that the DRAM loses data if you can chill the chips), you can then plug them into a machine whose firmware you can control as well. If you can't move the memory, you need to arrange that the firmware not trash the memory; if the firmware has a memory-trashing memory test or memory clear pass, and can't be configured to completely disable that pass, but knows whether it's invoked after a power-up or just after a processor restart or callback from the OS, and only runs the memory-trashing pass after a power-up, then a power-cycle restart makes it harder, not easier, to get the data. If you can disable that pass, then it doesn't matter whether it's a power-cycle restart or not, as long as the data survives the power-cycle process - the firmware won't trash the memory in either case, and, if you control the software that it boots, it also won't trash the memory in either case.

So, either:

• you can remove the memory, and there's no reboot involved;

• you can't remove the memory, but you can configure the firmware not to trash memory on a restart:

• and the OS won't trash memory before the reboot, in which case the type of reboot doesn't matter;

• but the OS will trash memory before the reboot, in which case you need an ungraceful reboot, whether it involves a power-cycle or not, to keep the OS's hands off the memory;

• you can't remove the memory, and you can't configure the firmware not to trash memory on a restart, but it will do so if it's starting up from a power-down:

• and the OS won't trash memory before the reboot, in which case you need to do a non-power-cycle reboot, graceful or ungraceful, to keep the firmware from trashing memory;

• but the OS will trash memory before the reboot, in which case you need an ungraceful non-power-cycle reboot, to keep the firmware's and the OS's hands off the memory;

• you can't remove the memory, and you can't prevent the firmware from trashing memory on a restart, in which case you're stuck.

See section 8 "Countermeasures and their limitations", subsection "Scrubbing memory", for some discussion of the last of those cases. Section 3.4 "BIOS footprints and memory wiping" also discusses this.

As for "Ungraceful warm reboots are impossible in Windows", that's a function of the hardware, not the OS. If the processor has a reset line (as did the processor in the tower PC I mentioned earlier, and as does the processor in the machine on which I'm typing this - RESET# in both cases), and if it's wired up to a button that you can get at, you can reset the processor out from under the OS without turning the power off, so, if a "warm reboot" is a reboot that doesn't involve cutting the power, and an "ungraceful reboot" is a reboot out from under the OS, that's how you do it. I no longer have the documentation for the motherboard of the tower PC in question, so I don't know whether its reset button just pulsed RESET# or temporarily cut power (I think the power button may have been wired to cause an interrupt by default, to support "soft power-down", but that you could force a harder power-down), but I definitely hit that button while Windows was running and got back to the BIOS. I doubt Apple's wired up RESET# to any user-visible button on my laptop; the power button causes an interrupt by default, so that OS X pops up the "do you want to shut down" dialog by default, and will instead jump to a kernel debugger stub if you've configured the it to do that, but it's one of those "battery-powered" mobile devices, and the System Management Controller ultimately controls power running to other components of the machine. Guy Harris (talk) 21:51, 28 January 2013 (UTC)

Too long; didn't read. (And probably off topic too.) Codename Lisa (talk) 11:00, 29 January 2013 (UTC)

Shorter version: both "only a graceful warm restart and ungraceful cold reboot (sudden power interruption) are suitable for the attack" and "Ungraceful warm reboots are impossible in Windows" are false statements. Read the long version if you want to know why. Guy Harris (talk) 20:36, 29 January 2013 (UTC)

Hi. I don't want to know. (And I still don't want to read the long version either.) What I want to know is: Why are we discussing? We do not seem to have a dispute that I can take to DRN. So, I am unwatching this page. Make up your mind about what we should discuss and then if you really wanted to discuss it, ping me in my talk page. Best regards, Codename Lisa (talk) 11:46, 30 January 2013 (UTC)

Hi. Another update: I just scanned over Intel Xeon Processor C5500 / C3500 Series Datasheet Volume 1. This document does not speak about warm and cold (re)boot at all. But page 370 classifies CPU reset types into six groups: Warm, CPU Warm (or CPU Only), Power Good, PCI Express, SMBus and QPI Link. Judging from the rest of it, this hardly concerns this article but gives me a better view of what Reset (computing) is talking about. The document also talks about Hot vs. Cold reset for various components but that again seems to concern Reset (computing). Best regards, Codename Lisa (talk) 02:45, 28 January 2013 (UTC)

* Comment: In response to the RFC and without replying in detail (heaven forbid!!!) to the RWAR flood here foregoing, I just emphasise the following points almost at random:

• At one time there were: hardware (cold) reboot, software reboot (reloading the system by re-reading the current or subsequent OS and possibly new tasks or programs), and warm start (typically by an interrupt prompted by reset button). Already then there were different nomenclatures in practically every brand of machine shop. So forgive me if I refuse to take the current differences in nomenclature seriously.
• Even then there were differences between machines with volatile memory such as various delay lines, and those with magnetic core memory, some of which functionally retained their memory and program states, including the operating system and running programs, when rebooted after either a reset or a power failure. Some had options for wiping everything either automatically or on request, but I apologise for not remembering real-life examples; I do not remember having had occasion for using anything of the kind. The usefulness of such memory retention varied with the nature of the running program; for example, if you were in the middle of a lot of files, including print, card, tape and disk, your chances of an acceptable restart were poor, although application checkpointing of various degrees of sophistication could be applied on some systems. Nomenclature was applied with religious precision, but would you believe, every culture (usually vendor-related) had its own!
• Nowadays the number of technical dimensions to the situation is larger, so forget a proper nomenclature; no matter how erudite or elegant, it won't stand still long enough to stay useful.
• Recommendation Drop this futile nomenclature firefight for a while and constitute an ego-free team that have been through the wars and survived them to the point of keeping up-to-date. Collect a set of elementary variables as as complete as may be (memory and file volatility, interrupt-mediated, interpretive- vs hardware-based processors etc...) and tabulate the number of conceptually relevant and distinct forms of associated interruptions and restarts that reflect the forms of their supporting systems. Don't at first give them names, just numbers or similar codes. Establish which of them exist in some significant or interesting form in real (computing) life. Etc. then decide what to do about terminology. Satisfactory? OF COURSE NOT! But a lot better than what we have!

Good luck. JonRichfield (talk) 15:23, 8 February 2013 (UTC)

Also from the RfC, also I have not read it all (having some sort of questions, instead of a wall of text, would help). Anyway, JonRichfield's suggestions sounds quite sound: list all kinds of them without caring about the nomenclature. I simply add that when going for the nomenclature you do not try to get *the* name for that process, but instead list the all the (sourced) names used. Probably the problem arises from different sources calling different things the same name, and same things different names. Do not try to decide who is correct (that is not what WP is mainly about), instead document all uses (that is more what WP is about) - Nabla (talk) 13:17, 12 February 2013 (UTC)

Warm / hot reboot

Hi, is there any difference between warm and hot reboot ? Teuxe (talk) 08:52, 26 August 2014 (UTC)

I don't think so, at least not in modern operating systems. In DOS you could reboot only the OS without rebooting the BIOS by an Int 13h call. This was often used by Windows 9x to speed up reboots after driver installations or other system updates. But I don't know, if this was ever called a "hot reboot" in contrast to a "normal" "warm reboot" with Int 19h. --MrBurns (talk) 14:31, 10 April 2017 (UTC)

Reading this just now... Well, this is mixing up a lot of things... What you mean is called "quick boot", but I don't think it was performed by Windows 95 (unless you meant something differently). It was provided and performed by some memory managers including QEMM, though.

Either way, there is no such INT 13h call, and the purpose of INT 19h is not as you describe. INT 19h is a BIOS rather than a DOS service. It can be used by boot loaders or real-mode OSes before they intercept any hardware interrupts, but once they do, they would have to intercept INT 19h and restore the original state (that is, reset interrupt vectors to their previous state, zero-pad the first 32 bytes of the (dummy) VDISK header at FFFFh:0010h, activate gate A20, etc.), before passing down INT 19h. That's why the system would normally just hang instead of rebooting if you would issue an INT 19h from within applications.

The only portable method for a DOS application on any XT+ machines to perform a reboot is to flush all caches, wait until they have finished writing out their data, and emulate a CTRL+ALT+DEL keypress through INT 15h/AH=4Fh (this does not exist on the original PC, so you would also have to make sure the vector is initialized before calling it). This would be monitored by loaded drivers which can do their necessary cleanup in preparation of a reboot. Only, if this broadcast returns (which only happens if none of the interceptors performed the reboot), the application (or driver), who issued the broadcast, can perform the reboot by itself by clearing all except for the extended keyboard bit 4 in the keyboard state at 40h:96h, clear the CPU's direction bit (CLD) and interrupt flags (CLI), set 40h:72h to either 0000h (include POST for a "cold boot") or 1234h (skip POST for a "warm boot") (there are a few more magic values, but these two are the two most important ones) and jump to FFFFh:0000h directly (this is, what a DOS keyboard driver does on actual CTRL+ALT+DEL presses). Applications must never issue an INT 19h and they must not jump to that reset vector before trying the described INT 15h method first - it would likely lead to data loss, file system corruption or hangs, but not a reboot (or only indirecty through the system crash). In protected mode, the jump will be intercepted by the memory manager, which would switch to real mode, restore the old IVT, reset special hardware, reset some of the CPU registers with their initial values and then either issue a INT 19h or jump to FFFFh:0000h or toggle a hardware reset through the keyboard controller (this depends on the memory manager, its configuration and the underlying type of system). I have left out some (even more obscure) details, but the bottom line is: INT 19h is not for applications.

See also: https://marc.info/?l=freedos-dev&m=101783474625117

--Matthiaspaul (talk) 13:22, 11 February 2022 (UTC)

Requested move 4 March 2018

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: Pages moved. (non-admin closure)  samee  ^talk 19:33, 11 March 2018 (UTC)

---

• Reboot (computing) → Reboot
• Reboot → Reboot (disambiguation)

– The clear WP:PRIMARYTOPIC for the term. The name of the film term was obviously based on the computing term, and nothing else comes close in terms of long-term significance. _{ZXCVBNM (TALK)} 11:46, 4 March 2018 (UTC)

• Support per norm. --Tisanophile (talk) 16:24, 4 March 2018 (UTC)
• Support, clear primary topic by historic importance; all others are named after the concept in computing. bd2412 T 03:51, 5 March 2018 (UTC)
• Oppose – ambiguous term with 10 articles should go to the disambig page; no primarytopic grab is indicated. Dicklyon (talk) 05:22, 8 March 2018 (UTC)
• Support per bd2412 and nom. --Izno (talk) 01:19, 10 March 2018 (UTC)
• support clear primary topic because it is the source of other naming schemes and bigger impac.t— Preceding unsigned comment added by Artix Kreiger (talk • contribs)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Merge power cycling

I propose power cycling be merged into this article. These seem to be two different names for the same underlying concept and don't deserve two separate articles. * Pppery * _{it has begun...} 16:40, 22 February 2024 (UTC)

One item in power cycling says:

On all Apollo missions to the moon, the landing radar was required to acquire the surface before a landing could be attempted. But on Apollo 14, the landing radar was unable to lock on. Mission control told the astronauts to cycle the power. They did, the radar locked on just in time, and the landing was completed.

That doesn't clearly indicate that some form of device with a CPU in it was power-cycled, and I didn't see anything in the reference to indicate whether what was power-cycled was analog circuitry. As such, it's not clear to me that power cycling discusses the same underlying concept; power-cycling a device that boots up to some form of firmware or software probably causes a reboot (although if you have non-volatile main memory - magnetic core or battery-backed semiconductor - and the CPU gets told that power has failed and is running firmware or software that saves CPU state and restores it when power is restored, perhaps it doesn't cause a reboot). Guy Harris (talk) 18:17, 22 February 2024 (UTC)

References