The Question is:
One of the V6.2 VAX systems I look after crashed today with a BADPAGFILA
I looked this up in DSN and it seems that the real reason for the crash was
that I'd run out of available balance set slots so VMS decided to bounce one
of my processes into a swap/page file. The system will crash with a BADPAGFILA
bugcheck if the chosen
process has a working set quota bigger than 65536 pages. Fair enough; from
looking at the dump, at the time of attempted outswap the process's quota was
65539. Moreover, the value for WSQUOTA in SYSUAF for this particular user was
also far above 65536.
The bit that's confusing me stems from a related article that says "user
authorisation quotas, WSQUOTA and WSDEFAULT, when greater than 65536, are
truncated to less than 65536 when the user logs on to the system". From this
I'd assume that the "too high"
value acquired from SYSUAF has been overridden. When a process is being readied
for outswap the SWAPPER reduces its working set size back to WSQUOTA - which
should now be less than 65536, except that it obviously wasn't.
Am I missing a fundamental trick here or does the outswap candidate have some
additional metadata attached to itself that forces the quota size above 65536 ?
I know the fix to this is straightforward. I just have to increase BALSETCNT
and/or reduce WSQUOTA ("do you feel lucky, punk ?"), but I'd like to get the
The Answer is :
OpenVMS Engineering has no current plans to address this problem
on OpenVMS VAX due to the complexity of the code change and the
adverse impact that the change may have on other functionality.
WSQUOTA should be restricted to 65000. This further restriction
precludes the chances of large WSQUOTA values causing a BADPAGFILA
On-going work in various OpenVMS Alpha releases permits working
sets of up to 4GB (WSMAX) in V7, and OpenVMS Engineering expects
to further increase the permitted OpenVMS Alpha working set size
in future OpenVMS Alpha releases. (The upper limit on the OpenVMS
VAX working set size is 32 megabytes.)
If you wish to further discuss this limit and the particular
behaviour of the limit (non)enforcement in LOGINOUT and SYSUAF
and the BADPAGFILA bugcheck, please contact the Compaq Customer
Support Center directly.