Message-Id: <199704031226.OAA16009@math.amu.edu.pl> Comments: Authenticated sender is From: "Mark Habersack" Organization: PPP (Pesticide Powered Pumpkins) To: Eli Zaretskii Date: Thu, 3 Apr 1997 14:27:05 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Interrupt handlers and page locking Reply-to: grendel AT hoth DOT amu DOT edu DOT pl CC: djgpp AT delorie DOT com References: In-reply-to: Once upon a time (on 2 Apr 97 at 11:20) Eli Zaretskii said: > > > Also, in my program, I -know- I don't have some parts of the interrupt > > > handler code and data locked, yet I never get page fault errors. How do > > > I force a page fault if it is possible to happen? > > > > > > > Try loading lots of TSR's, and run your program under a debugger. > > No amount of TSRs will cause your DJGPP program to page, because TSRs all > load into conventional memory whereas the absolute majority of DJGPP > installations use extended memory to load data and code of DJGPP programs. With DPMI 1.0 it would be possible to allocate a single page, mark it as non-present or not-commited and then reference the memory area - this would generate a page fault. Probably (I haven't tried it) it is possible to do it with DPMI 0.9 as well: allocate some linear memory (__dpmi_allocate_memory), allocate LDT descriptor and set its base to match the linear address of the just allocated memory, deallocate memory (which *should* only mark the page as available!) and reference the segment. This **should** cause PF but may also generate a mere GPF (I don't think so, but it might). Again, I haven't tried it - it's taken off the top of my head. ================================================== Stand straight, look me in the eye and say goodbye Stand straight, we drifted past the point of reasons why. Yesterday starts tommorow, tommorow starts today And the problems seem to be we're picking up the pieces of a ricochet...