Virtual Memory Management implements a logging function that records successful attempts to lock and unlock memory pages.
Memory locking and unlocking is implemented by the Memory Management routines: VMLockMem and VMUnlock. This routine is available directly to all kernel components and indirectly to device drivers through:
DevHlp_Lock
DevHlp_Unlock
DevHlp_VMLock
DevHlp_VMUnlock
and to file system drivers through:
MFSH_Lock
MFSH_Unlock
The VM lock trace is activated by setting bit 0 of the VM log flag double-word to 1. The flag double word is located at symbol: _VMLogFlags. Since no function is currently assigned to the other bit positions so the lock log may be effectively turned on by setting the byte a _VMLogFlags to 0xff as in the following example:
e _vmlogflags %fff0127c 00. ff ##g L base fff32 size 2 flags 1 hob 16 hptda 3b9 ret fff3e551 L base 15e0 size 1 flags 4 hob 4a4 hptda 91 ret fff5a93c L base 3f size 1 flags 4 hob 188 hptda 91 ret fff5a93c U base 15e0 size 1 flags 4 hob 4a4 hptda 91 ret fff5a983 U base 3f size 1 flags 4 hob 188 hptda 91 ret fff5a983 L base 15e0 size 1 flags 4 hob 4a4 hptda 91 ret fff5a93c L base 3f size 1 flags 4 hob 188 hptda 91 ret fff5a93c U base 15e0 size 1 flags 4 hob 4a4 hptda 91 ret fff5a983 U base 3f size 1 flags 4 hob 188 hptda 91 ret fff5a983 L base fff35 size 3 flags 1 hob 16 hptda 4a4 ret fff3e551 L base fe79c size 4 flags 0 hob 3 hptda 380 ret fff49ec6 U base fe79c size 4 flags 0 hob 3 hptda 380 ret fff3d173
The fields displayed in each lock trace entry are formatted from the constituent parts of the corresponding lock handle. They are defined as follows:
L
┌──────────┬────────────────────────────────────────┐ │Bit value │Description │ ├──────────┼────────────────────────────────────────┤ ├──────────┼────────────────────────────────────────┤ │0x01 │Lock is a long-term │ ├──────────┼────────────────────────────────────────┤ │0x02 │Verify lock call │ ├──────────┼────────────────────────────────────────┤ │0x04 │Lock originated from a DevHlp │ └──────────┴────────────────────────────────────────┘hob
Note:
The return address is unfortunately of limited use since most calls to VMLockMem are made via a limited number of interface routines. In particular, DevHlp lock requests are made via dhw_VMLock and SegLockDM. Unless one can trace in addition the SS:ESP on entry to VMLock, the lock trace alone will be insufficient to solve memory locking problem. One possible way of providing more information is to supplement the lock trace with following breakpoint commands:
##bp _vmunlock+1,"k ss:sp;g" ##bp _vmlockmem+1,"k ss:sp;g" ##g 0170:fff3e551 fff32d68 00001281 10000000 ffe0068f CodeLockProc + 7c L base fff32 size 2 flags 1 hob 16 hptda 3b9 ret fff3e551 0170:fff5a93c 015f0000 0000000e 40000000 fe7958c6 _dhw_VMLock + dc 0170:fff3db40 40000000 015f0000 0000000e fe7958c6 0170:00000155 01550000 62d61a84 00000003 5ab40000 L base 15f0 size 1 flags 4 hob 5de hptda 91 ret fff5a93c 0170:fff5a93c 0003f198 0000000b 40000000 fe795be0 _dhw_VMLock + dc 0170:fff3db40 40000000 0003f198 0000000b fe795be0 0170:00000055 00550000 62d61a84 00000003 5ab40000 L base 3f size 1 flags 4 hob 196 hptda 91 ret fff5a93c 0170:fff5a983 fe7958c6 00002796 083082fc fe7958c6 _dhw_VMUnlock + 3a 0170:fff3db4c fe7958c6 00001af0 00001100 00000056 0170:00000003 5b030000 08300000 f2a40000 08489254 U base 15f0 size 1 flags 4 hob 5de hptda 91 ret fff5a983 0170:fff5a983 fe795be0 000008c6 0830823f fe795be0 _dhw_VMUnlock + 3a 0170:fff3db4c fe795be0 00001af0 00001100 0000ff56 0170:00000003 5b030000 08300000 f2a40000 08489254 U base 3f size 1 flags 4 hob 196 hptda 91 ret fff5a983 0170:fff5a93c 015f0000 00000dd6 40000000 fe7958c6 _dhw_VMLock + dc 0170:fff3db40 40000000 015f0000 00000dd6 fe7958c6 0170:00000155 01550000 62d61a84 00000003 5ab40000 L base 15f0 size 1 flags 4 hob 5de hptda 91 ret fff5a93c 0170:fff5a93c 0003f198 0000000b 40000000 fe795be0 _dhw_VMLock + dc 0170:fff3db40 40000000 0003f198 0000000b fe795be0 0170:00000055 00550000 62d61a84 00000003 5ab40000 L base 3f size 1 flags 4 hob 196 hptda 91 ret fff5a93c 0170:fff5a983 fe7958c6 00002796 083082fc fe7958c6 _dhw_VMUnlock + 3a 0170:fff3db4c fe7958c6 00001af0 00001100 0000ff56 0170:00000003 5b030000 08300000 f2a40000 08489254 U base 15f0 size 1 flags 4 hob 5de hptda 91 ret fff5a983 0170:fff5a983 fe795be0 000008c6 0830823f fe795be0 _dhw_VMUnlock + 3a 0170:fff3db4c fe795be0 00001af0 00001100 0000ff56 0170:00000003 5b030000 08300000 f2a40000 08489254 U base 3f size 1 flags 4 hob 196 hptda 91 ret fff5a983 0170:fff3e551 fff351dc 000022f5 10000000 ffe0053f CodeLockProc + 7c L base fff35 size 3 flags 1 hob 16 hptda 3b9 ret fff3e551 0170:fff4a218 ffe0053f ffe0052b 00082006 00000000 _CodeLockHook + 2c 0170:fff42df7 ffffffff ffffffff 7b71ff40 7b71ff40 KMDispatchHook + a3 U base fff35 size 3 flags 1 hob 16 hptda 3b9 ret fff4a218 0170:fff4a218 ffe0068f ffe0067b 00082006 00000006 _CodeLockHook + 2c 0170:fff42df7 ffffffff ffffffff 7b71ff40 7b71ff40 KMDispatchHook + a3 U base fff32 size 2 flags 1 hob 16 hptda 3b9 ret fff4a218
Given that the K command rapidly looses synchronisation with the correct stack frame pointer one may have to resort to using:
##bp _vmunlock+1,"dw ss:sp l80;g" ##bp _vmlockmem+1,"dw ss:sp l80;g"
Refer to the Kernel Debugger K command and BP command for further information.
Related information on memory locking may be found under the description of the Kernel Debugger .MO command.
The latest versions of OS/2 2.11 and OS/2 3.0 have implmented a new Kernel Debugger command that facilitates an alternative method for analysing memory locking problems. See the Kernel Debugger .MK command command for details.