Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!usc!bufo.usc.edu!vorbrueg From: vorbrueg@bufo.usc.edu (Jan Vorbrueggen) Newsgroups: comp.arch Subject: Re: Instruction (dis)continuation Message-ID: <20260@usc.edu> Date: 2 Oct 89 22:47:34 GMT Reply-To: vorbrueg@bufo.usc.edu (Jan Vorbrueggen) Organization: University of Southern California, Los Angeles, CA Lines: 46 In article <477@ctycal.UUCP> ingoldsb@ctycal.COM (Terry Ingoldsby) writes: > >As an alternative, do the following: > MOV addr1,R1 (ie Move data found at addr1 into register R1) > STO R1,addr2 (store register contents in addr2) >Even if the fault occurs during the read of addr1 (a bit odd since >peripheral memory locations are usually non-pageable) then the access will >still only occur once. If the page fault occurs during the store then >we similarly don't care since addr2 will also only be accessed once (in my >example its just memory but could conceivably be another peripheral). But what if the pagetables mapping addr1 or addr2 are pageable? This is the case on VAXen, where a process' pagetables (for its private virtual address space called P0 or P1) reside in the virtual address space shared by all processes (called S0). The pagetables for S0, of course, are stored in contiguous physical memory, at a physical address recorded in a processor register. So, a pagefault can occur for two reasons: the page referenced is invalid (not in the working set), or the pagetable page is invalid. Naturally, the pagetable page for a valid (in-working set) page has to be valid. However, VMS since (at least) V2.3 and probably until today has a bug where pages mapped to physical memory (e.g., I/O registers), though by definition always valid, don't increment the reference count of the pagetable page. In a memory-tight situation (in this case, the process was only allowed 100 pages in its working set), VMS will kindly recuperate unused memory by performing a so-called dead pagetable scan. It proceeds to remove the pagetable mapping the device, and next time the process references it, bang: down goes the system! (Pagefaults are not allowed in certain situations.) Another nice situation happens when you debug an application using a memory-mapped device. Say your application sadly has a bug and accesses an address where there is no device. It will get an access violation fault. So you fire up the debugger and single-step through it. This is implemented by using special trace bits which will return control to the debugger after every instruction. The program writes to that non-existant location and gets its trace-pending trap, calling a priviledged-mode routine to handle the trap. Some instructions (or 10 microseconds) later, the bus tells the cpu that it couldn't perform the write. Now the access violation seems to have occured in the priviledged mode - and a crash occurs... Jan Vorbrueggen