| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2981.1 | RMS is the VICTIM of a failing VMS QIO IO$M_ERASE ?! | EPS::VANDENHEUVEL | Hein | Mon Nov 04 1996 12:27 | 153 |
| 2981.2 | ... have seen the same some weeks ago on an Alphaserver 1000 | FRSTSC::TLAUER | "Everything is relative!" - "Yes, absolutely." | Tue Nov 05 1996 02:31 | 22 |
| 2981.3 | | EPS::VANDENHEUVEL | Hein | Tue Nov 05 1996 08:57 | 16 |
| 2981.4 | Erase ($ERAPAT) Doesn't Always Zero... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Tue Nov 05 1996 13:05 | 11 |
| 2981.5 | | CSC64::BLAYLOCK | If at first you doubt,doubt again. | Tue Nov 05 1996 16:16 | 15 |
| 2981.6 | I'm convinced this is caused by X25 | EPS::VANDENHEUVEL | Hein | Wed Nov 27 1996 09:31 | 11 |
| 2981.7 | EXE$GL_ERASEPB | CSC32::M_DIFABIO | MOVL #OPINION,EXE$GL_BLAKHOLE | Fri Dec 27 1996 15:57 | 15 |
| 2981.8 | tell me X25 isn't running and i still don't believe it | FRSBOG::TLAUER | "I've been designed multi-asking." | Mon Dec 30 1996 02:55 | 9 |
| 2981.9 | Nope, no X25 | CSC32::M_DIFABIO | MOVL #OPINION,EXE$GL_BLAKHOLE | Tue Dec 31 1996 11:40 | 10 |
| 2981.10 | | FRSBOG::TLAUER | "I've been designed multi-asking." | Thu Jan 02 1997 01:36 | 9 |
| 2981.11 | | CSC32::M_DIFABIO | MOVL #OPINION,EXE$GL_BLAKHOLE | Mon Jan 06 1997 15:07 | 7 |
| 2981.12 | EXE$GL_ERASEPPT | CSC32::M_DIFABIO | MOVL #OPINION,EXE$GL_BLAKHOLE | Mon Jan 06 1997 15:13 | 4 |
| 2981.13 | SYS$PKQDRIVER and unaligned reads | CSC32::M_DIFABIO | MOVL #OPINION,EXE$GL_BLAKHOLE | Thu Feb 06 1997 11:43 | 35 |
| 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. (I use the BLAKHOLE page on reads
for the residual data, since we don't need the data.)
So this is one more thing to check when we see RMS corruption on
creation of a file. (Or note corruption in the ERASEPB.) Apparently
Oracle uses this buffer as well, as several escalations surrounding
this issue have been from Oracle sites.
Tracking this down was not the easiest thing to do. Since the driver
grabbed the PFN from the ERASEPPT, changing the Page protection to no
write access didn't help detect the culprit. The following people were
of great help in resolving this particular issue:
Mark Hopkins
Geoff Judd
Mark Morris
Karen Rochford
Rick Desko
Bob Maclean
Not a one person show by any means.
Mark d.
|
| 2981.14 | When is new driver release ?? | ZPOVC::CHINGYUE | | Tue Feb 18 1997 04:17 | 10 |
| Hi,
My customer running Alpha OVMS V6.2 with ALPSCSI02 patch is facing the
same problem.
When would the new SYS$PKQDRIVER.EXE be ready ?
What is the time frame before the test driver is release to field ?
regards,
ching-U
|
| 2981.15 | Me, too ! | COMICS::MILLSS | "Jump! Jump now!" ...Kosh | Mon Mar 03 1997 05:43 | 7 |
| I also have a customer with this problem. Can anyone shed any light on a
timescale for the fix to be issued ?
Many thanks,
Simon R. Mills
OpenVMS Group, UK CSC
|
| 2981.16 | SCSI | STAR::EWOODS | | Mon Mar 03 1997 08:38 | 4 |
| There is a fix. IPMT the problem to get it because it is not available
through TIMA yet. (NOTE: Remember this is a SCSI not an RMS problem.)
-- Elinor
|
| 2981.17 | Assumptions Around Erasure? | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Tue May 27 1997 15:25 | 10 |
|
: There is a fix. IPMT the problem to get it because it is not available
: through TIMA yet. (NOTE: Remember this is a SCSI not an RMS problem.)
It would appear there are *two* problems here... The first is the
SCSI driver clobbering the pattern buffer. The other -- and more
insidious -- problem is that RMS (or the XQP) appears to assume the
pattern buffer will always return nulls... (Corallary: is RMS/XQP
asking for a null pattern buffer, or is it assuming one...)
|
| 2981.18 | IO$M_ERASE function modifier | EVMS::EWOODS | | Wed May 28 1997 11:24 | 18 |
| << It would appear there are *two* problems here... The first is the
<< SCSI driver clobbering the pattern buffer. The other -- and more
<< insidious -- problem is that RMS (or the XQP) appears to assume the
<< pattern buffer will always return nulls... (Corallary: is RMS/XQP
<< asking for a null pattern buffer, or is it assuming one...)
RMS does a $QIO with a function code of "IO$_WRITEVBLK OR IO$M_ERASE."
And very importantly, it specifies a P1 of zero. The I/O REF manual
instructions for IO$M_ERASE function modifier indicate that "if the
P1 address is 0, a longword of 0 will be used as the erase pattern."
(If the P1 address is nonzero, the contents of the 4-bytes starting
at that address are used as the erase pattern.)
So RMS has specified exactly what the erase pattern should be and is
correct in assuming that a zero erase pattern will be used by the I/O
subsystem.
-- Elinor
|