If a program violates its instruction path and/or memory data the OS halts it with some message due to the program running in the 'virtual machine' like space of the OS and its unable to determine its next instruction.
The OS in tern is also a program, sharing the machine resources as any other program and can halt in a similar fashion but it's sometimes healthy enough to display some debugging info and blue screen. So as a programmer I'm thinking, if I can do that - emit debugging info and make the screen blue why wouldn't I be able to try to recover the OS altogether instead of requiring a cold reboot ? After all its the OS - it's supposed to be the rock solid foundation (not talking about Windows of course) of all software, if the space shuttle ran Windows then what would happen - it won't recover ?:)
So: is it only that MS hasn't taken care of trying everything to recover to the point that a reboot is not required or is it some other more deeper problem that has stop companies like MS to be unable to do that ?
It's nothing specific to Microsoft; Linux has a kernel panic mechanism, OS X has a kernel panic mechanism. I expect every non-toy operating system kernel has a panic mechanism of some sort when internal corruption is detected. The corruption could come from faulty hardware, faulty software, gamma rays hitting the memory boards just right, who knows.
The whole point behind the kernel panic is a recognition that something that shouldn't go wrong has gone wrong. What else might be invalid? Depending upon where the crash happened, it might not be safe to sync and unmount the filesystems because that might scribble corrupt data over good data on the drives.
Writing to the video card is a good way to inform the user of events (many systems have monitors attached, anyway) and writing to the video card isn't likely to corrupt on-disk data: it would take quite an error for the IOMMU or page tables to be so corrupted that they refer instead to on-disk files and most operating systems will refuse to write to block devices after a kernel panic to try to protect user data at all cost.
Consider what you could do to bring the system back up to a running state? You'd need to tear down all applications that might be associated with corrupted kernel data structures. You'd need to restart applications, in the right order, to bring system services back up. And a reboot is a very easy way to reliably do both those things.
You can't recover the OS for the same reasons a user-space program can't recover -- when certain types of errors are seen it means that your program is in an undefined state and therefore can't recover. Even if the problem in some sense isn't fatal (i.e. doesn't cause the program to immediately die), it's not safe to continue because things are or are likely corrupted.
For example, be it a user-space program or the OS kernel, say a buffer overrun or an messed up pointer causes the stack to be corrupted. How is the program supposed to recover from that? With a blown stack when the function that is currently executing ends, where will it return to? The return address is likely gone. Now what?
And it's not just Microsoft. Ever hear of a "kernel panic" in Unix?
Related
I was given this exact question on a quiz.
Question
Answer
Does the question make any sense? My understanding is that the OS schedules a process and manages what instructions it needs the processor to execute next. This is because the OS is liable to pull all sorts of memory management tricks, especially in main memory where fragmentation is a way of life. I remember that there is supposed to be a special register on the processor called the program counter. In light of the scheduler and memory management done by the OS I have trouble figuring out the purpose of this register unless it is just for the OS. Is the concept of the Stored Program Computer really relevant to how a modern computer operates?
Hardware fetches machine code from main memory, at the address in the program counter (which increments on its own as instructions execute, or is modified by executing a jump or call instruction).
Software has to load the code into RAM (main memory) and start the process with its program counter pointing into that memory.
And yes, if the OS wants to page that memory out to disk (or lazily load it in the first place), hardware will trigger a page fault when the CPU tries to fetch code from an unmapped page.
But no, the OS does not feed instructions to the CPU one at a time.
(Unless you're debugging a program by putting the CPU into "single step" mode when returning to user-space for that process, so it traps after executing one instruction. Like x86's trap flag, for example. Some ISAs only have software breakpoints, not HW support for single stepping.)
But anyway, the OS itself is made up of machine code that runs on the CPU. CPU hardware knows how to fetch and execute instructions from memory. An OS is just a fancy program that can load and manage other programs. (Remember, in a von Neumann architecture, code is data.)
Even the OS has to depend on the processing architecture. Memory today often is virtualized. That means the memory location seen by the program is not the real physical location, but is indirected by one or more tables describing the actual location and some attributes (e.g. read/write/execute allowed or not) for memory accesses. If the accessed virtual memory has not been loaded into main memory (these tables say so), an exception is generated, and the address of an exception handler is loaded into the program counter. This exception handler is by the OS and resides in main memory. So the program counter is quite relevant with today's computers, but the next instruction can be changed by exceptions (exceptions are also called for thread or process switching in preemptive multitasking systems) on the fly.
Does the question make any sense?
Yes. It makes sense to me. It is a bit imprecise, but the meanings of each of the alternatives are sufficiently distinct to be able to say that D) is the best answer.
(In theory, you could create a von Neumann computer which was able to execute instructions out of secondary storage, registers or even the internet ... but it would be highly impractical for various reasons.)
My understanding is that the OS schedules a process and manages what instructions it needs the processor to execute next. This is because the OS is liable to pull all sorts of memory management tricks, especially in main memory where fragmentation is a way of life.
Fragmentation of main memory is not actually relevant. A modern machine uses special hardware (and page tables) to deal with that. From the perspective of executing code (application or kernel) this is all hidden. The code uses virtual addresses, and the hardware maps them to physical addresses. (This is even true when dealing with page faults, though special care will be taken to ensure that the code and page table entries for the page fault handler are in RAM pages that are never swapped out.)
I remember that there is supposed to be a special register on the processor called the program counter. In light of the scheduler and memory management done by the OS I have trouble figuring out the purpose of this register unless it is just for the OS.
The PC is fundamental. It contains the virtual memory address of the next instruction that the CPU is to execute. For application code AND for OS kernel code. When you switch between the application and kernel code, the value in the PC is updated as part of the context switch.
Is the concept of the Stored Program Computer really relevant to how a modern computer operates?
Yes. Unless you are working on a special custom machine where (say) the program has been transformed into custom silicon.
I find that during TLB missing process, some architecture use hardware to handle it while some use the OS. But when it comes to page fault, most of them use the OS instead of hardware.
I tried to find the answer but didn't find any article explains why.
Could anyone help with this?
Thanks.
If the hardware could handle it on its own, it wouldn't need to fault.
The whole point is that the OS hasn't wired the page into the hardware page tables, e.g. because it's not actually in memory at all, or because the OS needs to catch an attempt to write so the OS can implement copy-on-write.
Page faults come in three categories:
valid (the process logically has the memory mapped, but the OS was lazy or playing tricks):
hard: the page needs to be paged in from disk, either from swap space or from a disk file (e.g. a memory mapped file, like a page of an executable or shared library). Usually the OS will schedule another task while waiting for I/O.
soft: no disk access required, just for example allocating + zeroing a new physical page to back a virtual page that user-space just tried to write. Or copy-on-write of a writeable page that multiple processes had mapped, but where changes by one shouldn't be visible to the other (like mmap(MAP_PRIVATE)). This turns a shared page into a private dirty page.
invalid: There wasn't even a logical mapping for that page. A POSIX OS like Linux will deliver SIGSEGV signal to the offending process/thread.
The hardware doesn't know which is which, all it knows was that a page walk didn't find a valid page-table entry for that virtual address, so it's time to let the OS decide what to do next. (i.e. raise a page-fault exception which runs the OS's page-fault handler.) valid/invalid are purely software/OS concepts.
These example reasons are not an exhaustive list. e.g. an OS might remove the hardware mapping for a page without actually paging it out, just to see if the process touches it again soon. (In which case it's just a cheap soft page fault. But if not, then it might actually page it out to disk. Or drop it if it's clean.)
For HW to be able to fully handle a page fault, we'd need data structures with a hardware-specified layout that somehow lets hardware know what to do in some possible situations. Unless you build a whole kernel into the CPU microcode, it's not possible to have it handle every page fault, especially not invalid ones which require reading the OS's process / task-management data structures and delivering a signal to user-space. Either to a signal handler if there is one, or killing the process.
And especially not hard page faults, where a multi-tasking OS will let some other process run while waiting for the disk to DMA the page(s) into memory, before wiring up the page tables for this process and letting it retry the faulting load or store instruction.
I was just wondering whether the switch between the kernel mode and the user mode in an operating system is done by the hardware or the os itself.
I understand that when a user process wants to get into kernel mode it can make a system call and execute some kernel code. When the system call is made, the process goes into the kernel mode and now all memory becomes accessible, etc. In order for this to happen, I would assume that the interrupt handler needs to switch or alter the page table. Is this true? If not, how does the CPU know, that it is running in the kernel mode and does not need to page fault when accessing restricted (unaccessible to the user process) memory?
Thanks!
The last answer is actually not true....
Changing to kernel mode doesn't go through 'Real mode'. Actually after finishing the boot process, the computer never goes back to real mode.
In normal x86 systems, changing to kernel mode involves calling 'sysenter' (after setting parameters in some registers), which causes jumping a predefined address (saved in the MISR register of the CPU), that was set when the computer booted, because it can be done only from kernel mode (it is a 'privileged' command).
So it basically involves executing a software command, that the hardware responds to, by the way it was set, when it was in kernel mode
This is kind of a broad question - each hardware platform is going to do things slightly differently, but I think the basic answer is that it's done w/ software that leverages hardware facilities for memory protection, etc.
When a user process wants to do a system call, it executes a special CPU instruction, and the CPU switches from virtual mode (for user processes, has page tables specific to processes) to real mode (for the kernel) and jumps to the OS syscall handler. The kernel can then do what it likes.
CPU support for this is required. The CPU keeps track of which mode it is in, where the page tables are located, jumping the instruction pointer, etc. It is triggered by the user software doing the syscall, and is dependent on the kernel providing support for whatever it is trying to do. As with all computation, it's always both hardware and software. I cannot be done solely with software however, because then there would be no way to prevent a process making a syscall from abusing the privelages it gains, e.g. it could start reading /etc/shadow.
Modern x86 computers have a special instruction just for doing system calls. Earlier x86 processors, and some current RISC ones, have an instruction to trigger an interrupt. Older architecures had other ways of switching control.
I am working on a Windows game and while rendering, some computers will experience intermittent pauses ("hitches" for lack of a better term). When profiled they appear in seemingly random places in the code. Eventually I noticed that it wasn't just my process that was affected, but (seemingly) every process on the system. All of the threads in my application hitch at once. The CPU utilization drops during these hitches and it appears as if most processes make no progress.
This leads me to believe this may be an Operating System or Driver issue, but it only occurs while playing the game (and only on some systems). What sort of operations might the operating system be doing that would require the kernel to pause all user threads and block. Some kind of I/O? At first I thought of paging but my impression is that would only affect a single process, no?
Some systems in use: Windows, DirectX (3d), nVidia cards (unknown if replicates on ATI), using overlapped io for streaming
If you have a lot of graphics in use, it may be paging graphics memory into the swap file.
Or perhaps the stream is getting buffered on disk?
It's worth seeing if the hitches coincide with the PC's disk activity LED.
Heavy use of memory mapped IO. This of course includes the system pagefile, but can also include user applications that use mmio heavily (gcc for one)
RESOLVED
After much confusion and frustration, I finally got my hard disk to interrupt. :D It basically came down to the fact that I kept reading the status register instead of the alternate status register. A few other things were messed up to boot, but the point is my hard disk driver is finally starting to take shape. Now, for others I will leave the original post.
P.S. For further clarification, I didn't need to issue any sort of reset command. All I did was the following:
Select the device (didn't want to kill the Solaris OS on the other disk)
clear the nIEN bit in the DEVICE CONTROL register
issue an IDENTIFY DEVICE command***
Actually, I am not sure if the IDENTIFY DEVICE command is need because I left the lab happy before I could test the code without issuing the command. However, the main point is that I needed to be sure to read the alternate status register and have the nIEN bit cleared without the need for a reset. The BIOS apparently takes care of most stuff.
I am currently trying to write a disk driver for a hobby OS being developed at my school. I currently have routines to read/write data in the PCI configuration space and assembly routines to do port IO with the various registers defined by ATA/ATAPI-7. Now, my question is, specifically how will I get an IDE hard drive to start generating interrupts? I have been looking through all this documentation and is hasn't become clear to me what I am doing wrong.
Can someone explain exactly what causes an IDE hard drive to start generating interrupts? I already have an interrupts service routine ready to test, but am having difficulty getting the interrupts in the first place. Can this be accomplished through the ATA SOFT RESET?
Thanks!
UPDATE: Ok, I was able to get the secondary channel, an ATAPI CDROM to generate interrupts by setting the SRST bit in the DEVICE CONTROL register for a soft reset. This does not work for the hard disk on the primary channel. What I have noticed so far is that when I set the SRST bit for the HDD, it sets the BSY bit and leaves it set. From there I don't know what to do.
This reference should help you a fair bit: Kenos description of programming ATA/ATAPI.
The basic mechanism to enable interrupts is to clear nIEN in the DCR (Device Control Register):
nIEN: Drive Interrupt Enable bit. The enable bit for the drive interrupt to the host. When nIEN is 0 or the drive is selected the host interrupt signal INTRQ is enabled through a tri state buffer to the host. When nIEN is 1 or the drive is not selected the host interrupt signal INTRQ is in a high impedance state regardless of the presence or absence of a pending interrupt.
This www.ata-atapi.com is a good jumping-off point to find way more info about ATA/PATA/SATA/ATAPI than you want to know... Note that the official ATA-6/7/etc specs cost $$ from T13, though you can download current drafts of ATA-8 from them.
This link describes a few of the many ways ATA devices vary from the specs. (I used to write SCSI and ATA/ATAPI drivers for Commodore/Amiga, way back when, as well as help with qualifying drives - or more accurately, figuring out what idiocies drive makers had done.)
if this is just a hobby OS, why not use the BIOS interrupt (int 13h)? admittedly not as fast as direct disk access but safer for your hard drive (I've put a read head through a plate before messing with disk I/O).