More VMS 7.3-2 PQL_WS issue

[John Eerenberg]

Doug,

> "Can someone please actually explain the bug and answer _any_ of the questions I've asked in this thread? I'm beginning to think noone can:-("

I can't help you in detail. I have the source listings for VMS V7.3-1. From your desciption (or rather, the orginating thread that spawn this discussion), this is a bug introduced in VMS V7.3-2.

Hmmmm. . . For that matter, the person who helped you should be able to get this information in detail (or whoever they asked, probably someone on the engineering team). This looks like a bug. It just doesn't make sense that you can't use even page boundaries when converting from pagelets to pages. :-(

Oh well. I too am wondering about an answer.

john

[Doug Phillips]

John,

I am not the person who was helped in the original thread. The person who was helped was given N*PAGESIZE+32 formula and the "page boundary" explanation of the problem.

That seems to be it for the explanation so far. The posters in the original thread (some of whom have posted in this one) have accepted it.

As I've said over and over and over until I'm really tired of hearing myself (:-O), the formula and all of the different explanations so far do not make sense to me.

I find HP's silence here disappointing.

Doug

[Ian Miller.]

The bug is new in VMS 7.3-2 due to a change where working set lists are kept in virtual memory. My understanding of the workaround is that PQL_DWSDEFAULT is set to a value just more than a multiple of pagesize 8k. As memory is allocated in pages this means the value is effectively rounded up and an extra page is allocated but mostly not used.
I am surprised somebody from VMS engineering has not added a comment.

[Doug Phillips]

Thanks, Ian.

I guess I should have used a different subject line. The original thread was titled:

"VMS V7.3-2 Crashes Right After Upgrade"

That spawned another thread called:

"VMS 7.3-2 PQL_WS issue"

I copied that subject line and put the word "More" in front. I guess I should have made it something like:

"VMS 7.3-2 Bug that crashes system"

to get draw their attention;-()

Doug

[Guy Peleg]

Hi Doug,

I added few comments in the original
thread about the upcoming fix and a
temporary workaround.

Regards,

Guy Peleg
OpenVMS Engineering

[Doug Phillips]

Thank you, Guy. But....


The critical parameter during the boot is
PQL_WSDEFAULT.

booting a system with SYSGEN parameter
PQL_DWSDEFAULT set to 16384 or 32768 (or a
value slightly less than these and rounded
up during SYSBOOT initialization) can cause
the system to crash.

If the working set list parameters are near
or at the 8192 byte boundary, raising the
SYSGEN parameter just 1 beyond that boundary
should allow the system to boot normally
(ie, 16385 and 32769), providing a
workaround.

Again, VMS732_SYS-V0300 will fix this.


Are you saying that for PQL_WSDEFAULT the 16384 and 32768 pagelet page boundaries are the only ones we have to worry about?

You mention 8192 bytes in reference to a SYSGEN parameter that is expressed in pagelets. In "PQL" speak, one page is 16 pagelets. Page boundaries are multiples of 16. What is "magic" about 8192 pagelets.

Would you please explain this so my little brain can understand? :-)

Doug

[John Eerenberg · Accepted solution]

Doug,

Here are the release notes on the matter (I happen to be in training and my instructor is the person who analyzed this crash -- how lucky can one get?).

If you want more detail, I can get it. The way I understand it, the WSL being created at process creation time is shorted one page (16 pagelets) when the PQL parameter is at the (below) mentioned power-of-2. Think of it as starting a loop from one as opposed to starting from zero and that final entry isn't there.
When the PTE didn't get created, but the process thought it had it, wham, down it goes. Refer to process creation in the IDSM and picture these data structures in S2 space. Makes sense and is easily corrected; but painful to experience.

Here are the release notes:

TITLE: V7.3-2 Boot-Time INVEXCEPTN Bugcheck At SYS$VM+17014,
SWAPPER Current


OP/SYS: OpenVMS Alpha

COMPONENT: SYSBOOT.EXE


SOURCE: Hewlett-Packard Corporation


SYMPTOM:

A V7.3-2 system crashes early during boot with an INVEXCEPTN at SYS$VM+17014. The current process is the SWAPPER. The failing virtual address is on a page boundary in S2 space (FFFFFEFE.000A2000).

The crash is 100% reproducible with the SYSGEN parameter(s) PQL_MWSDEFAULT/PQL_DWSDEFAULT set to either 16384 or 32768 pagelets.

ANALYSIS:

In OpenVMS Alpha 7.3-2 the process working set list was moved from the process header (PHD) into a separate area in S2 space. This change makes it possible to have a large setting for WSMAX along with a large and "dynamic" setting for BALSETCNT. In previous versions of OpenVMS, a large WSMAX could force AUTOGEN to reduce BALSETCNT in order to have enough 32-bit system space (S0/S1 space).

There was a minor flaw in the algorithm used to allocate this working set area in S2 space when either PQL_MWSDEFAULT or PQL_DWSDEFAULT were set to 16384, 32768 or other nice power-of-2 values. The actual settings that can cause this problem can be slightly less than 16384 or 32768, because SYSBOOT may round the actual setting up to the nearest power-of-2 boundary.


WORKAROUND:

Change the setting of the SYSGEN parameters PQL_MWSDEFAULT and PQL_DWSDEFAULT. Values of either 16385 or 32769 allow the system to boot. Also check the settings for PQL_MWSQUOTA and PQL_DWSQUOTA. A process' working set default can not be larger than its working set quota, therefore SYSBOOT minimizes the settings of PQL_MWSDEFAULT and PQL_DWSDEFAULT against PQL_MWSQUOTA and PQL_DWSQUOTA. For example, the following parameter settings will result in a system crash because SYSBOOT will adjust PQL_MWSDEFAULT and PQL_DWSDEFAULT to be 16384.

PQL_MWSDEFAULT = 24000
PQL_DWSDEFAULT = 24000
PQL_MWSQUOTA = 16384
PQL_DWSQUOTA = 16384


SOLUTION:

OpenVMS Engineering has addressed this problem and will provide a new SYSBOOT.EXE image in a future V7.3-2 remedial kit. The fix is NOT included in the recently released VMS732_UPDATE-V0100 kit.

[Doug Phillips]

John,

Thank you very much.

Doug