Triple fault: Difference between revisions
Opencooper (talk | contribs) →See also: already in body (WP:SEEALSO) |
→Other uses: make both numbers milliseconds so that you can compare more easily |
||
| (4 intermediate revisions by 4 users not shown) | |||
| Line 12: | Line 12: | ||
<!--could be worked in here if find specific information: http://www.intel.com/cd/ids/developer/asmo-na/eng/197666.htm or pacifica --> |
<!--could be worked in here if find specific information: http://www.intel.com/cd/ids/developer/asmo-na/eng/197666.htm or pacifica --> |
||
In [[QEMU]], a triple fault produces a dump of the virtual machine in the console, with the instruction pointer set to the instruction that triggered the first exception. |
In [[QEMU]], a triple fault produces a dump of the virtual machine in the console, with the instruction pointer set to the instruction that triggered the first exception. |
||
In [[VirtualBox]], a triple fault causes a [[Guru Meditation]] error to be displayed to the user. A virtual machine in this state has most features disabled and cannot be restarted. If the VirtualBox Debugger is open, a message is printed indicating a Triple fault has occurred, followed by a register dump and [[Disassembler|disassembly]] of the last instruction executed, similar to the output of the <code>rg</code> debugger command. |
|||
When using [[Intel VT-x]], a triple fault causes a VM exit, with exit reason 2. The exit reason is saved to the VMCS and may be handled by the VMM software. |
When using [[Intel VT-x]], a triple fault causes a VM exit, with exit reason 2. The exit reason is saved to the VMCS and may be handled by the VMM software. |
||
==Other uses== |
==Other uses== |
||
The [[Intel 80286]] processor was the first x86 processor to introduce the now-ubiquitous [[protected mode]]. However, the 286 could not revert to the basic 8086-compatible "[[real mode]]" without resetting the processor, which can only be done using hardware external to the CPU. On the [[IBM Personal Computer AT|IBM AT]] and compatibles, the documented method of doing this was to use a special function on the [[Intel 8042]] keyboard controller, which would assert the RESET pin of the processor. However, intentionally triple-faulting the CPU was found to cause the transition to occur much faster and more cleanly, permitting multitasking operating systems to switch back and forth at high speed.<ref name="Osterman_2005_286"/> |
The [[Intel 80286]] processor was the first x86 processor to introduce the now-ubiquitous [[protected mode]]. However, the 286 could not revert to the basic 8086-compatible "[[real mode]]" without resetting the processor, which can only be done using hardware external to the CPU. On the [[IBM Personal Computer AT|IBM AT]] and compatibles, the documented method of doing this was to use a special function on the [[Intel 8042]] keyboard controller, which would assert the RESET pin of the processor. However, intentionally triple-faulting the CPU was found to cause the transition to occur much faster (0.8 milliseconds instead of 15+ milliseconds) and more cleanly, permitting multitasking operating systems to switch back and forth at high speed.<ref name="Osterman_2005_286"/> |
||
Some operating system kernels, such as [[Linux]], still use triple faults as a last effort in their rebooting process if an [[Advanced Configuration and Power Interface|ACPI]] reboot fails. This is done by setting the IDT register to 0 and then issuing an interrupt.<ref name="Collins_2000_Triple"/> Since the table now has length 0, all attempts to access it fail and the processor generates a triple fault. |
Some operating system kernels, such as [[Linux kernel|Linux]], still use triple faults as a last effort in their rebooting process if an [[Advanced Configuration and Power Interface|ACPI]] reboot fails. This is done by setting the IDT register to 0 and then issuing an interrupt.<ref name="Collins_2000_Triple"/> Since the table now has length 0, all attempts to access it fail and the processor generates a triple fault. |
||
==References== |
==References== |
||
{{Reflist|refs= |
{{Reflist|refs= |
||
<ref name="Collins_2000_Triple">{{cite web |author-first=Robert |author-last=Collins |title=Triple Faulting the CPU |date=2000 |work=Productivity Enhancements and Programming Tricks |url=http://www.rcollins.org/Productivity/TripleFault.html |access-date=2015-11-22 | |
<ref name="Collins_2000_Triple">{{cite web |author-first=Robert |author-last=Collins |title=Triple Faulting the CPU |date=2000 |work=Productivity Enhancements and Programming Tricks |url=http://www.rcollins.org/Productivity/TripleFault.html |access-date=2015-11-22 |url-status=live |archive-url=https://web.archive.org/web/20170909120639/http://www.rcollins.org/Productivity/TripleFault.html |archive-date=2017-09-09}}</ref> |
||
<ref name="Collins_2000_Reset">{{cite web |title=ELEGANT RESET |author-first=Robert |author-last=Collins |date=2000 |url=http://www.rcollins.org/ftp/source/3fault/reset.asm |access-date=2017-09-09 | |
<ref name="Collins_2000_Reset">{{cite web |title=ELEGANT RESET |author-first=Robert |author-last=Collins |date=2000 |url=http://www.rcollins.org/ftp/source/3fault/reset.asm |access-date=2017-09-09 |url-status=live |archive-url=https://web.archive.org/web/20170909113216/http://www.rcollins.org/ftp/source/3fault/reset.asm |archive-date=2017-09-09}}</ref> |
||
<ref name="Osterman_2005_286">{{cite web |title=Faster Syscall Trap redux |author-first=Larry |author-last=Osterman |date=2005-02-08 |work=Larry Osterman's WebLog |publisher=[[MSDN Blogs]] |url=https://blogs.msdn.microsoft.com/larryosterman/2005/02/08/faster-syscall-trap-redux/ |access-date=2010-07-23 | |
<ref name="Osterman_2005_286">{{cite web |title=Faster Syscall Trap redux |author-first=Larry |author-last=Osterman |date=2005-02-08 |work=Larry Osterman's WebLog |publisher=[[MSDN Blogs]] |url=https://blogs.msdn.microsoft.com/larryosterman/2005/02/08/faster-syscall-trap-redux/ |access-date=2010-07-23 |url-status=live |archive-url=https://web.archive.org/web/20170909113828/https://blogs.msdn.microsoft.com/larryosterman/2005/02/08/faster-syscall-trap-redux/ |archive-date=2017-09-09}}</ref> |
||
}} |
}} |
||
Latest revision as of 14:07, 27 September 2024
 | This article relies largely or entirely on a single source. (May 2012) |
On the x86 computer architecture, a triple fault is a special kind of exception generated by the CPU when an exception occurs while the CPU is trying to invoke the double fault exception handler, which itself handles exceptions occurring while trying to invoke a regular exception handler.
x86 processors beginning with the 80286 will cause a shutdown cycle to occur when a triple fault is encountered. This typically causes the motherboard hardware to initiate a CPU reset, which, in turn, causes the whole computer to reboot.[1][2]
Possible causes of triple faults
[edit]Triple faults indicate a problem with the operating system kernel or device drivers. In modern operating systems, a triple fault is typically caused by a buffer overflow or underflow in a device driver which writes over the interrupt descriptor table (IDT). If the IDT is corrupted, when the next interrupt happens, the processor will be unable to call either the needed interrupt handler or the double fault handler because the descriptors in the IDT are corrupted.[citation needed]
Virtual machines
[edit]In QEMU, a triple fault produces a dump of the virtual machine in the console, with the instruction pointer set to the instruction that triggered the first exception.
In VirtualBox, a triple fault causes a Guru Meditation error to be displayed to the user. A virtual machine in this state has most features disabled and cannot be restarted. If the VirtualBox Debugger is open, a message is printed indicating a Triple fault has occurred, followed by a register dump and disassembly of the last instruction executed, similar to the output of the rg debugger command.
When using Intel VT-x, a triple fault causes a VM exit, with exit reason 2. The exit reason is saved to the VMCS and may be handled by the VMM software.
Other uses
[edit]The Intel 80286 processor was the first x86 processor to introduce the now-ubiquitous protected mode. However, the 286 could not revert to the basic 8086-compatible "real mode" without resetting the processor, which can only be done using hardware external to the CPU. On the IBM AT and compatibles, the documented method of doing this was to use a special function on the Intel 8042 keyboard controller, which would assert the RESET pin of the processor. However, intentionally triple-faulting the CPU was found to cause the transition to occur much faster (0.8 milliseconds instead of 15+ milliseconds) and more cleanly, permitting multitasking operating systems to switch back and forth at high speed.[3]
Some operating system kernels, such as Linux, still use triple faults as a last effort in their rebooting process if an ACPI reboot fails. This is done by setting the IDT register to 0 and then issuing an interrupt.[1] Since the table now has length 0, all attempts to access it fail and the processor generates a triple fault.
References
[edit]- ^ a b Collins, Robert (2000). "Triple Faulting the CPU". Productivity Enhancements and Programming Tricks. Archived from the original on 2017-09-09. Retrieved 2015-11-22.
- ^ Collins, Robert (2000). "ELEGANT RESET". Archived from the original on 2017-09-09. Retrieved 2017-09-09.
- ^ Osterman, Larry (2005-02-08). "Faster Syscall Trap redux". Larry Osterman's WebLog. MSDN Blogs. Archived from the original on 2017-09-09. Retrieved 2010-07-23.