Conference vaxaxp::vmsnotes

667.0. "AS 255/233 forced crash inconsistency" by HAN::HALLE (Volker Halle MCS @HAO DTN 863-5216) Mon Jun 02 1997 03:07

    
    In an attempt to troubleshoot a 'MOUNT hang' in an OpenVMS cluster, we
    forced a couple of crashes on AlphaStation 255/233 systems. When
    examining the dumps, I recognized some unusual symptoms (system ALWAYS
    had lost cluster connections, the ethernet adapter had ALWAYS just done
    a restart due to 3-XmtTimeout or 9-HardwreErr).
    
    We then did a couple of tests and forced crashes with the following
    methods:
    
    - forced crash through AMDS 
    - use >>> CRASH command
    - use >>> D PC ffffffffffffffff & >>> D PS 1f00
    
    In all those forced crashes, I see the SAME symptoms, although the
    system was running without problems until the crash had been forced:
    
    - cluster connections lost
    - most cluster nodes seen in reconnect or wait
    - some VCs have just been re-established
    - ethernet interface restarted (couple of seconds ago)
    
    These symptoms also could NOT be found in a recent AMDS-forced crash of a
    TurboLaser system in that cluster.
    
    It's hard to analyse MOUNT-related hangs, if - after a forced crash - all
    the disks are in mount-verify, because the cluster-connections have
    been broken due to the forced crash.
    
    QUESTION:
    
    Is there any problem with producing CONSISTENT forced crashes with
    AlphaStations 255/233 ?
    
    Volker.

    
    Would anybody agree, that this is an 'unusual and unexpected' behaviour ?
    
    Could this be some CPU-specific code, which is lowering IPL before
    writing the dump ?
    
    Any other ideas ?
    
    Volker.