OpenVMS %INIT-F-DATACHECK, write check error

[Francesco Russo]

Hi All,
I have just find out on a .pdf took from the HP web-site that the HBA I have needs the following patch "OVMS721_FIBRECHAN_V0200", but I cannot find it anywhere on the HP web-site. Does anyone knows if this patch has been superseded with a new one maybe with a different name?

Best regards
Francesco

[Petr Spisek]

Hi,
the latest is VMS721_FIBRE_SCSI-V0600

http://www5.itrc.hp.com/service/patch/patchDetail.do?patchid=VMS721_FIBRE_SCSI-V0600&sel={openvms:alpha:7.2-1,}&BC=main|search|

Petr

[Andy Bustamante]

Francesco,

You're running OpenVMS 7.3-2, the patches referenced above are for OpenVMS 7.2-1, which is years out of support. You can check for patches here on ITRC under "Maintenance and support for Compaq products" or http://www1.itrc.hp.com/service/patch/search.do?BC=main|&pageOsid=openvms.

The installtion utility should keep you from installing the older patches successfully, unlike some lesser operating systems.


Andy

[Jur van der Burg]

I've seen this before a year ago when I worked for VMS engineering. This is for 99.9% sure a problem with the disk subsystem, and not a VMS issue.

Some comments from an old case (where I created a diagnostic driver to catch the problem:

The problem does not appear to be within VMS. A databuffer of 127 pages
is written to disk, and read back immediately. The data is then compared
in chunks, and the second chunk of data fails after 1040 (hex) bytes with
data which appears to be old data from the same type as what's in the file.
There's no crossing of page boundaries, the difference is in the middle
of a page.

All buffer mapping is for contiguous pages in memory, the fibrechannel
buffer descriptors are valid. Here we can see that the last request was
a scsi read command with the FUA bit set (this means that the controller
must go out to disk to fetch the data from disk, and is not allowed to
satisfy the read from cache). Both the write to disk and the read command
show no error.

So it appears that the data we've been writing to disk did not make it
to the disk, or that the data read back did not come from disk. In short,
this is not something VMS can do anyhing about. The problem could be
bad hardware. Since the adapter of the system has already been exchanged
with the adapter from another system without result it's fairly safe to say
that the adapter is not at fault. This leaves the problem to the fibre
switches or the disk controller. The fact that another system has no problem
with this does not exclude the controller or the switches.

Talk to the vendor of the disk subsystem.

Jur van der Burg
(Ex- fibrechannel/scsi/vms kernel)

[Francesco Russo]

Jur,
thanks for your very good explanation. It funny but I am working for the vendor!!! the subsystem has not problem at all (analyzed the subsystem trace, nothing there). I will raccommed to upgrade the HBA fw maybe it will help.

Thanks very much for your time.

Francesco

[Volker Halle]

Francesco,

you can check the Firmware of the KGPSA in the running system with:

$ ANAL/SYS
SDA> FC SHOW DEV FGA

The most recent Firmware for the DS10 is V7.2, it includes the following FC adapter versions:

o DS-KGPSA-CA (LP8000) - Firmware Revision 3.93A0
o DS-KGPSA-DA (LP9002) - Firmware Revision 3.93A0
o DS-KGPSA-EA (LP9802) - Firmware Revision 1.91X6

For further troubleshooting this probelm, you could:

- MOUNT/FOR the disk and DUMP various blocks with DUMP/BLOCK=(count:n,START:n) and see whether you get the same results, if you repeat that operation for the same blocks.

- write a little program to write blocks to the disk using QIO and the IO$M_DATACHECK function modifier. This would allow you to find out, if this problem is related to certain LBNs or areas on the disk.

- Use LDDRIVER in REPLACE mode and tracing to capture all IOs to the disk during INIT. If the problem is reproducable for a specific LBN, you could then use the LD WATCH command to cause a crash and you may be able to find the 2 buffers in the dump.

You can find information about LDDRIVER at:

http://www.digiater.nl/lddriver.html

Volker.

[Francesco Russo]

Hello Volker,

Thanks very much for your update.
We tried to mount the disk using the option FOR and it seems it is working. The only problem we have is the dga0:
$>mou/for $1$dga0:
%MOUNT-W-ALHOMINV, invalid alternate home block on _$1$DGA0:
%MOUNT-I-MOUNTED, TEST mounted on _$1$DGA0:

P.S. The HBA firmware was already up-to-date.

[Volker Halle]

Francesco,

MOUNT/FOR mounts the disk from OpenVMS without using the file system. It tries to check, whether the disk has a valid file system and thus warns you, that the alternate home block has an invalid format. This disk is probably one of those, where your INIT failed with a DATACHECK error, so it didn't finish initializing the file system data structures.

There is the DISKBLOCK utility on the OpenVMS Freeware CDs, which allows you to poke around in the file system metadata. You can download this utility from:

http://h71000.www7.hp.com/freeware/freeware80/diskblock/

Looks like it's possible to do a MOUNT/FOR/DATA=WRITE - this should cause all WRITE-IOs to be issued with a writecheck IO modifier. With the DISKBLOCK utility, you can select a foreign-mounted disk and read and re-write individual disk blocks. If you take one of your disk, which failed the INIT command, you could test writing blocks to that disk without destroying any data files on that disk.

This way, you may be able to demonstrate a DATACHECK error when writing certain blocks on the disk.

Volker.