Page Fault Error Codes
Contents |
Stack-Segment Fault 1.1.8 General Protection Fault 1.1.9 Page Fault 1.1.9.1 Error code 1.1.10 x87 Floating-Point Exception 1.1.11 Alignment Check 1.1.12 SIMD Floating-Point Exception 1.2 Traps exception 13 general protection fault 1.2.1 Debug 1.2.2 Breakpoint 1.2.3 Overflow 1.3 Aborts 1.3.1 Double Fault 1.3.2
General Protection Fault Error Code
Machine Check 1.3.3 Triple Fault 2 Selector Error Code 2.1 Legacy 2.1.1 FPU Error Interrupt 2.1.2 Coprocessor Segment
X86 Exceptions
Overrun 3 See Also 3.1 External Links Exceptions as described in this article are generated by the CPU when an 'error' occurs. Some exceptions are not really errors in
Invalid Opcode Exception X64 Exception Type 06
most cases, such as page faults. Exceptions are a type of interrupt. Exceptions are classified as: Faults: These can be corrected and the program may continue as if nothing happened. Traps: Traps are reported immediately after the execution of the trapping instruction. Aborts: Some severe unrecoverable error. Some exceptions will push a 32-bit "error code" on to the top linux general protection fault of the stack, which provides additional information about the error. This value must be pulled from the stack before returning control back to the currently running program. (i.e. before calling IRET) Name Vector nr. Type Mnemonic Error code? Divide-by-zero Error 0 (0x0) Fault #DE No Debug 1 (0x1) Fault/Trap #DB No Non-maskable Interrupt 2 (0x2) Interrupt - No Breakpoint 3 (0x3) Trap #BP No Overflow 4 (0x4) Trap #OF No Bound Range Exceeded 5 (0x5) Fault #BR No Invalid Opcode 6 (0x6) Fault #UD No Device Not Available 7 (0x7) Fault #NM No Double Fault 8 (0x8) Abort #DF Yes (Zero) Coprocessor Segment Overrun 9 (0x9) Fault - No Invalid TSS 10 (0xA) Fault #TS Yes Segment Not Present 11 (0xB) Fault #NP Yes Stack-Segment Fault 12 (0xC) Fault #SS Yes General Protection Fault 13 (0xD) Fault #GP Yes Page Fault 14 (0xE) Fault #PF Yes Reserved 15 (0xF) - - No x87 Floating-Point Exception 16 (0x10) Fault #MF No Alignment Check 17 (0x11) Fault #AC Yes Machine Check 18 (0x12) Abort #MC No SIMD Fl
EiB). Paging is a system which allows each process to see the full virtual address space, without actually requiring the full amount osdev page fault of physical memory to be available or present. In fact, current x86 exception handling implementations of x86-64 have a limit of 1 TiB and a theoretical limit of 4 PiB of gpf not handled opcode from v86 physical RAM. In addition to this, paging introduces the benefit of page-level protection. In this system, user processes can only see and modify data which is paged in on http://wiki.osdev.org/Exceptions their own address space, providing hardware-based isolation. System pages are also protected from user processes. On the x86-64 architecture, page-level protection now completely supersedes Segmentation as the memory protection mechanism. On the IA-32 architecture, both paging and segmentation exist, but segmentation is now considered 'legacy'. Once an Operating System has paging, it can also make use of http://wiki.osdev.org/Paging other benefits and workarounds, such as linear framebuffer simulation for memory-mapped IO and paging out to disk, where disk storage space is used to free up physical RAM. Contents 1 MMU 1.1 Page Directory 1.2 Page Table 1.3 Example 2 Enabling 3 Physical Address Extension 4 Usage 4.1 Virtual Address Spaces 4.2 Virtual Memory 5 Manipulation 6 Page Faults 6.1 Handling 7 INVLPG 8 Paging Tricks 9 See Also 9.1 Articles 9.2 External Links MMU Paging is achieved through the use of the MMU (temporary: article 1, article 2). On the x86, the MMU maps memory through a series of tables, two to be exact. They are the paging directory (PD), and the paging table (PT). Both tables contain 1024 4-byte entries, making them 4 KiB each. In the page directory, each entry points to a page table. In the page table, each entry points to a physical address that is then mapped to the virtual address found by calculating the offset within the directory and the offset with
1 /* 2 * Copyright (C) 1995 Linus Torvalds 3 * Copyright (C) 2001, 2002 Andi Kleen, SuSE Labs. 4 * Copyright (C) 2008-2009, Red Hat Inc., Ingo Molnar 5 */ 6 #include
and fix critical bugs. The start of a typical Oops message may look like the following:kernel BUG at kernel/signal.c:1599!Unable to handle kernel NULL pointer dereference at virtual address 00000000pc = 84427f6a*pde = 00000000Oops: 0001 [#1]The 4 digit value after the "Oops:" message dumps out the page fault error code in hexadecimal which in turn can help one deduce what caused the oops. The page fault error code is encoded as follows:bit 0 - 0 = no page found, 1 = protection faultbit 1 - 0 = read access, 1 = write accessbit 2 - 0 = kernel-mode access, 1 = user mode accessbit 3 - 0 = n/a, 1 = use of reserved bit detectedbit 4 - 0 = n/a, 1 = fault was an instruction fetchSo, in the above example, the Oops error code was 0x0001 which means it was a page protection fault, read access in kernel mode.A lot of Oops error codes are 0x0000, which means a page was not found by a read access in kernel mode.For more information, consult arch/x86/mm/fault.c at Monday, February 15, 2010 Posted by Colin Ian King Labels: debugging Reactions: Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest No comments: Post a Comment Newer Post Older Post Home Subscribe to: Post Comments (Atom) Links Google Plus GitHub repos My LaunchPad Page My profile at LinkedIn Twitter Homepage Kernel Team Wiki Page Blog Archive ► 2016 (12) ► August (1) ► July (1) ► June (1) ► May (1) ► April (1) ► March (1) ► February (3) ► January (3) ► 2015 (29) ► December (4) ► November (3) ► October (1) ► September (5) ► August (2) ► July (3) ► June (4) ► May (5) ► February (1) ► January (1) ► 2014 (16) ► December (3) ► November (2) ► October (1) ► July (2) ► June (2) ► May (1) ► March (3) ► February (1) ► January (1) ► 2013 (16) ► December (4) ► November (1) ► October (1) ► September (2) ► August (1) ► July (2) ► May (2) ► April (2) ► March (1) ► 2012 (24) ► December (3) ► November (4) ► October (1) ► September (1) ► August (3) ► July (1) ► June (2) ► Ma