[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:Welcome to the Digital UNIX Conference
Moderator:SMURF::DENHAM
Created:Thu Mar 16 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:10068
Total number of notes:35879

9302.0. "HSZ40 mirror start leads to panic" by LEXSS1::GINGER (Ron Ginger) Wed Mar 26 1997 14:14

    I have an 8400 with many HSZ40s on it. We use LSM to mirror across
    HSZ's, but for some interesting reasons of backup speed, we make an
    extra HSZ40 mirror each night, then break that off to backup.
    
    When we issue the commands to the HSZ40's to add a unit to the mirror
    we observe that the system pauses for a few seconds. I have verified
    from the HSZ40 gorup that it does stop processing I/O for a few seconds
    while this mirror add is started. Sometimes we see a scsi bus reset
    occur during this time, which we assume Unix issues because it is not
    getting a reply fast enough from the HSZ.
    
    We have been doing this for severl months, with no problems other than
    the occassional scsi bus reset.
    
    Today we kicked off a start mirror operation while the system was
    extremly busy- a very high batch load, lots of I/O
    
    The system promptly panicd with 'simple_lock: time limit exceeded.'
    
    We have a dump, and the stack trace shows that update was trying to do
    I/o, and that cam_disk.c was the routine that called the lock.
    
    Is it expected that we should panic when i/o is paused like this? Have
    w esimply been lucky in not seeing this previously, when system was
    load was lower? 
     
T.RTitleUserPersonal
Name
DateLines
9302.1SMURF::KNIGHTFred KnightWed Mar 26 1997 17:396
> Is it expected that we should panic when i/o is paused like this?

NO.  Panics should not be expected nor considered acceptable.
Please file a problem report (QAR, IPMT, or whatever is appropriate).

	Fred