More VMS 7.3-2 PQL_WS issue

[Doug Phillips]

From the manual:
##
VAX and Alpha systems allocate and deallocate memory for processes in units called pages. A page on a VAX system is 512 bytes. On Alpha systems, the page size will be one of four values: 8KB (8192 bytes), 16KB, 32KB, or 64KB. A particular Alpha system will implement only one of the four page sizes and the initial set of machines use an 8KB page.

In most cases, Alpha systems present to users, and accept from users, units of memory in a 512-byte quantity called a pagelet. Thus, one pagelet is the same size as one VAX page. Also, on an Alpha 8KB computer, 16 pagelets equal 1 Alpha page. The following conversion table shows the relationship between pages, pagelets, and bytes:

One Alpha pagelet = one VAX page = 512 bytes
One Alpha page = 16 Alpha pagelets = 16 VAX pages = 8192 bytes
##

How does this differ from what I said??? It looks like VMS hasn't changed since I learned this.

Now we all understand pagelets and pages, but noone still seems to understand the N*PAGESIZE+32 problem.

Doug

[Antoniov.]

Hi Doug,
no difference from you said previous, but now I can't understand your formula:
N*PAGESIZE+32 where
N what means?
PAGESIZE what means? Page or Pagelets?

@Antoniov

[Doug Phillips]

Antoniov,

It is not my formula. Again, I'll refer you to the original thread. Read to whole thread.

##

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=574666

So for instance, our settings for WSDEFAULT and WSQUOTA were 65535. This worked out to be 65535/8192 or 7.99. The correct number to work around this problem would then be 8*8192+32 or 65568.


##

I posted a new thread to continue the old one so I could give points to people who answered. I don't understand the formula as it has been explained so far. Please re-read what I have posted here previously.

In question are the values of PQL_DWSQUOTA and PQL_DWSDEFAULT. These values are in PAGELETS. Saying that this value must not be on an even page boundry doesn't explain the problem because (as we remember, 1 AXP PAGE = 16 AXP PAGELETS):

the value of 65568 stated in the original thread as being correct and not causing the system to crash on boot, converted to pages is: 65568/16 = 4098 pages. Looks like an even page boundary to me.

You ask whether the formula refers to bytes or pagelets or pages or what and that is what I have been asking here. The formula doesn't make sense. Re-read my postings here.

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:-(

Doug

[Antoniov.]

Sorry Doug,
I remember old thread.
I agree wit you: formula is non sense for me too. I asked you apparently but I ask to some vms engineer.

@Antoniov

[John Eerenberg]

Antoniov,

> "John,"
> "sorry, I disagree with you; you posted:"
> ""Alpha pages are always 8KB""
> "this was true in first version of Alpha Vms; now the size of page may be 4 values;"
Please reread my post. You did not quote me completely; I called out the exact page sizes being 8, 16, 32, and 64KB. Further I go on to say that 8KB is the only pagesize implemented and that unless something changes (i.e., the Alpha is brought back from the dead), 8KB is the only page size there ever will be.

> "alpha/vms, pagelet could be 4k too, but I'm not sure of this."
Simply read the Alpha AXP Architecture Reference Manual. 4KB never existed.

> "However, the pagelet cannot never be 512 bytes, too small for AXP."
You might be confusing VAX pages and Alpha pages. Both the VAX and Alpha architecture manauls will help in this area.

john

[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