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

Conference ssag::ask_ssag

Title:Ask the Storage Architecture Group
Notice:Check out our web page at http://www-starch.shr.dec.com
Moderator:SSAG::TERZAN
Created:Wed Oct 15 1986
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6756
Total number of notes:25276

6113.0. "RMS errors on Raid 200 controller!" by MAASUP::TURRO (Make it so number 1) Mon Oct 28 1996 14:30

T.RTitleUserPersonal
Name
DateLines
6113.1IO$M_ERASE function not properly done by VMS/Driver?EPS::VANDENHEUVELHeinMon Oct 28 1996 15:3557
6113.2program to clear relative files with multiple large QIOsEPS::VANDENHEUVELHeinWed Oct 30 1996 15:13107
6113.3Still a problemUKAOS::OVERMEYERFacts, the enemy of truthFri Dec 27 1996 07:3033
6113.4EXE$GL_ERASEPBCSC32::M_DIFABIOMOVL #OPINION,EXE$GL_BLAKHOLEFri Dec 27 1996 13:5814
6113.5EPS::VANDENHEUVELHeinThu Jan 02 1997 09:2436
6113.6SYS$PKQDRIVER issueCSC32::M_DIFABIOMOVL #OPINION,EXE$GL_BLAKHOLEThu Feb 06 1997 09:4232
    Just an update on the ERASEPB corruption issue:
    
       While I'm not sure if the 1000A has the SCSI QLogic controller in 
    it (SYS$PKQDRIVER), an instance of corruption has been tracked to 
    SYS$PKQDRIVER. V6.2 will not see it, unless ALPSCSI02 or later is
    installed. V7.1 will see it. It only occurs with unaligned reads.
    
      Following is the info I placed in the RMS notesfile. I'm still
    waiting to here back from the site mentioned in this notesfile to
    see if it is using SYS$PKQDRIVER. If so, it may not be a SWXCR 
    issue after all. If they don't, well... guess we'll update this again
    when we find out it's issue.
    
       Well, finally found the cause of the ERASEPB corruption issue. (At
    least one cause, that is.) V6.2-V7.0 systems using SYS$PKQDRIVER that
    are running ALPSCSI02 or later, and V7.1 systems with SYS$PKQDRIVER
    can see this problem. SYS$PKQDRIVER started using the ERASEPPT for
    unaligned transfers. (Instead of 512 bytes, 700 bytes) This is fine
    for writes, as we use the ERASEPB nulls to pad the rest of the 'block'.
    For reads, what happens is the extra 312 bytes from the second block
    of the transfer end up in the ERASEPB. It's easy to reproduce, just
    issue a QIO READLBLK with a bytecnt of 700 bytes. Then check your
    EXE$GL_ERASEPB buffer. It will contain the residual data.
    
       A new SYS$PKQDRIVER is currently being tested at these sites to
    verify no other issues are present. While I won't repeat it here, 
    a list of people that helped track this one down is in the RMS
    notesfile, note 2981. Their help is greatly appreciated.
    
                          Mark d.