Conference vaxaxp::vmsnotes

451.0. "PROBEx Bug in V6.2" by TKTVFS::HAMADA_T (Tsuyoshi Hamada, TECM/CSC/MCS in Japan) Fri Apr 11 1997 03:19

If anyone know, could you please tell us about current status of the problem 
listed below ? Any suggestion would be highly appreciated.

If this problem is fixed by the future version, which version ?
If we escalate this problem to IPMT as high impact issue in V6.2,
can you correspond ? 

Tsuyoshi Hamada /TECM/CSC/MCS in Japan.

---------------------------------------------------------------------------

UNIQUE_IDENTIFIER: CTI_SRC951122006060
TITLE: [OpenVMS] PROBEx Unable To Access Some Memory From LIB$GET_VM
  EDITORIAL_REVIEWED,FIELD_READABLE,NOFLASH,TECHNICAL_REVIEWED,READY)
Copyright (c) Digital Equipment Corporation 1995, 1996. All rights reserved.

PRODUCT:    OpenVMS Alpha, Version 6.2

COMPONENT:  VMS Executive

SOURCE:     Digital Equipment Corporation
\
\ CAUTION:    This article is not customer accessible due to lack of
\             information.


SYMPTOM:

The main purpose of this SPR is to start building a case history and
get Engineering recommendations on how to proceed from here.

PROBEx occasionally fails on Alpha EV5 cpus.  The symptom appears as
an RMS error regarding a memory buffer.  The buffer exists and is
valid.


DIGITAL RESPONSE:

This problem has been reviewed by Engineering and has been determined
to be a design failure.  It has been escalated into the Engineering
Product cycle for consideration into a future release of the product.
The appendix of the release notes will identify if the solution has
been incorporated.
\
\
\ ENGINEERING RESPONSE:
\
\ A solution has been proposed:
\
\ By definition, Level 3, 4 & 5 cases have been categorized as minor
\ technical problems and suggestions escalated for incorporation (or
\ not) into a future release of the product.
\
\ It is important to note that a business decision to not "fix" a Level
\ 3 problem is legitimate. MCS and/or Engineering may negotiate this
\ decision with Product Management (PD&M), or identify MCS funding and
\ resources to resolve if appropriate.
\
\ Your escalation has had a first level review by engineering. It has
\ been escalated into the Engineering Product cycle for consideration
\ into a future release of the product. The appendix of the release
\ notice will identify if the solution has been incorporated.


WORKAROUND:

Write to the block of memory being probed (by RMS) first.
\
\
\ TESTING INFORMATION:
\
\ Has this issue been reproduced on CSC lab systems? No
\
\ Is this issue consistently reproducible at the customer site? No
\
\ Has this been reproduced on a VAX? No
\
\ Has this been reproduced on an AXP? No
\
\ Has this been reproduced on other hardware? No
\
\ Please include the exact steps to reproduce the behavior,
\ including any programs if the information is not already
\ included above.
\
\ Additional information from the customer:
\
\ We have a problem that occurs on Alpha EV5-based machines, but
\ not EV4s.  It has to do with the condition of memory that is
\ delivered to us by the LIB$GET_VM routine and what happens when
\ we ask RMS to read a file into it.
\
\ Our program allocates space, using LIB$GET_VM, and reads part of
\ a file into it, using the RMS routine, SYS$READ.  Sometimes,
\ SYS$READ returns the error:
\
\      186EC, %RMS-F-UBF, invalid user buffer
\
\ In testing on the EV5, I have found that a PROBER or PROBEW
\ command fails on that buffer whenever the SYS$READ does, so I
\ suspect that SYS$READ is testing it with the PROBEx commands.  In
\ fact, I have found that, in a buffer starting at virtual address
\ 1FF3A00, I can probe each byte and the errors start at address
\ 2000000 and continue to the end of the buffer.  In a buffer
\ starting at 27FE000, the errors begin at address 2800000 and
\ continue to the end.  As I said, this error only occurs
\ sometimes.  At other times, in the same execution of the image,
\ the exact same buffer can be just fine.
\
\ The strange thing is that I can write to the entire buffer (using
\ LIB$MOVC5) and that, after doing so, the SYS$READ call always
\ succeeds.  The same thing happens if I declare the memory zone to
\ be filled-on-get, rather than using LIB$MOVC5.
\
\ Both the EV5, where the problem occurs, and the EV4, where it
\ does not occur, are using VMS V6.2.
\
\
\ REFERENCES:
\
\ Escalations reported on this problem:
\
\      CHAMP/CSC Service Request (SRQ) #:  C951122-6060
\      Field Service Log #:  HPXQ18F28
\
\
\ CONTRIBUTORS:
\
\      Technical:
\           Scott Ledoux (079598)
\
\      Editorial:
\           Caroline Butterworth (302957)
\
\\ VMS SYS
\\ PROD=OPENVMS-AXP SPD=41.87 CAT=OPSYS GRP=OPENVMS-AXP OS=OPENVMS-AXP
\\ 079598
\\ HPXQ18F28 SRC951122006060
\\ EDIT_SRQ=C960117-4387 EDIT_SRQ=C960328-3398
\\ TYPE=KNOWN_PROBLEM TYPE=ESCALATION RESPONSE=CONSIDER RETEST

   This problem has already been elevated -- check with the IPMT tools
   for the status of the probem, via HPXQ18F28 or CTI_SRC951122006060
   ID numbers.  Or send some e-mail to Scott at CSC32::S_LEDOUX. 

   If you have a way to reproduce this, or more information on this, log
   another IPMT referencing this problem, including the information...

   Given that you have a good workaround, this is not a showstopper...