greg (02/25/83)
We have a vs11 (Dec Graphics Device) for which we have written a driver which had a serious flaw; it "vslocked" pages which it never unlocked. Once this was brought to my attention I added the appropriate code to do the unlocking only to see "panic: dup page unlock" as my system sunk. Looking more closely at bio.c's usage of vslock and vsunlock I verified that I was using the call correctly (reading mem implies writing page and vice versa) and fineally resorted to the inevitable kernal printf to find out what was going wrong. Having found all driver associated variables which control the lock/unlock parameters to be doing the correct thing I looked at the kernal to verify that no other routines could be unlocking pages I have locked. Then to be sure I put in printf' in the vmmem.c vslock and vsunlock routines. The result of all this is: The same page which was locked was unlocked (both by the vs11 driver) and yet the system panicked each time with a "dup page unlock". What gives???? Are there some "hidden" incantations or limitations of using vslock and unlock. Thanks Greg Hidley