Conference mvblab::alphaserver_4100

    
    I'm not sure I understand the situation fully.
    
    Does the machine still fail with a 670 MCheck?
    
    mo

    PALcode is *always* updated at the same time console is updated when
    LFU is used to do the update. The LFU and console are indelibly linked.
    If you are running V3.0-10 console, you are definitely running V1.12-14
    UNIX PALcode.
    
    Your note mentioned V3.0-6 console. This must be a typo? The released
    version is V3.0-10. I've included more info on passing PAL revision to
    UNIX and DECevent below..
    
    You should update your DECevent to V2.3 with the appropriate KNL files
    for the 4100/4000. Many improvements have been made to this version.
    V2.3 DECevent should be able to decode the bits correctly and provide
    better diagnosis capability.
    
    Let me know what you find..
    
    BC
    
    More on PAL revisions..
    
    At the SRM console prompt, you can type the following to look at where
    console stores console and PAL revision data.. Force a boot halt so the
    HWRPB data structure will be built by console.
    
      P00>>>b -h <device> -flags <flags> -filename <filename>
      .
      .
      P00>>>e -n -q 10 2350
      pmem:             2350 0000000400000408 
      pmem:             2358 0004000500010113 
      pmem:             2360 0004001200020115 
      P00>>>continue                   # continue boot sequence
    
    The three quadwords correspond to console revision, VMS PAL revision,
    and UNIX PAL revision. These fields are Alpha SRM, HWRPB-defined
    fields passed to UNIX and VMS.
    
    As a for instance, on a V4.8-4 console (soon to be released), location
    2360 translates to:
    
       0004 : version of PAL supports up to four CPUs
       0012 : hex 12 = dec 18 = PAL dash variation
       0002 : UNIX PALcode rev quadword identifier is 2 (1 is VMS)
       0115 : Major version 1; minor version hex 15 = dec 21.
    
    The UNIX PAL revision for V4.8-4 console is V1.21-18. This would be the
    same revision you'd see if you typed SHOW PAL at the SRM console prompt
    on a V4.8 SRM console..
    
    P00>>>show pal
    pal              OpenVMS PALcode V1.19-5, Digital UNIX PALcode V1.21-18
    P00>>>
    
    Digital UNIX gets its PAL from the console, so if you see the correct
    version of PAL via the console SHOW PAL command, then the UNIX machine
    is definitely running the correct version of UNIX PALcode.
    

    
    Hello
    
    	Thank you for you good response .2.
    
    	I ask to FSE to upgrade Decevent V2.3 + KNL and if the problem is
    	again,then you  will be inform by Michel Semedo.
    
    	Nota:7th week I am in training in Netherland.
                          
    	Best regards
    
    	Olivier Cavailhe.

    
    Hello
    
    The 21th march,the customer has just upgraded with the last SRM console
    V4.8-6 & pal code Unix V1.21-18.
    
    When the user gives a special parameter in his mathematical application
    the system crashes in Machine check type 670 with Machine check reason
    8E=pal bugcheck.
    
    Nota,Decevent V2.3 with the last Knl gives always palcode revision
    V1.21-3.
    
    I transmit this call to central support center.
    
    Best regards,
    
    Olivier Cavailhe,CSC_France.

    I've forwarded your note off to the UNIX and DECevent folks. Will let
    you know what I find out. As for the 670 MCHK halt, are you aware that
    you can gather info about what caused the error halt by reading through
    and using the methodolgy described in nots 413.*. If dropped back to
    the console prompt, you can use the INFO (4,5,8) commands directly. If
    dropped into XDELTA, you can use the couple/few XDELTA commands to
    examine and record the contents of memory (PALcode's MCHK logout and
    IMPURE areas).

Bill -

Well, as noted, the mchk code of 8E is used when PAL hits a 'bugcheck'
condition.  There are a number of such conditions, so you'd want to 
find out which one.  Examples are unaligned references made from PALcode,
OPCDEC traps while in PAL, Arithmetic traps while in PAL, etc.  I belive
the PC of the machine check should be a PALcode address, which would 
point to the specific condition encountered.  Hey, here's a case where
the PALtemps in the logout frame might be useful, too.

I've never seen one of these before...

/dave

PALcode field is not being decoded correctly.  A IPMT case is being entered
for to correct this problem.

Thanks

Gary

    Just an update.  The fix for this will be in the DECevent release
    scheduled for 15-May-1997
    
    Gary