A VERY long time ago, I asked the following question:
>We recently added a Seagate ST15150N to a DEC 3000-800S running
>DEC OSF/1 v3.2 (no letters, numbers or dashes). This was added to
>the scsi1 (external bus) as device 0 lun 0, the only device at the end of
>a 2 meter cable and the device is properly terminated. After about a
>month of usage without any problems rebooting, we began getting the
>following sequence of errors each time upon a normal system startup:
>cam_logger: CAM_ERROR packet
>cam_logger: bus 1 target 0 lun 0
>dme_tcds_resume()
>Invalid DME DAT element.
>cam_logger: CAM_ERROR packet
>cam_logger: bus 1 target 0 lun 0
>sim_error_sm
>Target went to data in phase
>at which point the machine hangs. If one simply halts and hits "b <cr>"
>at the ensuing console prompt, the machine boots up fine. I maintain
>that this should not happen.
>After calling DEC, their response was, "Firmware problem on the drive.
>Contact Seagate and get a firmware upgrade." After talking to
>Seagate, their response was, "The O/S is not allowing enough time (60
>seconds by SCSI-2 spec) for the device to come up. It is an O/S
>problem." I am by no stretch of the imagination a SCSI expert.
>So, we're getting the good old bi-directional finger pointing. I thought
>that this had vanished at DEC; I guess not. My question: has anyone
>else seen this problem? If so, what is the fix? There are a couple of
>ST11200Ns on bus 0 which work beautifully.
First off, I'd like to thank Mr. Steven Choy of Digital Unix support for his
response. He managed to escalate this problem to Digital Engineering
and get an answer, which is as follows:
I got a response from the engineering, and would like to pass it to you.
Hope this resolve the problem. After you made the change to
'cam_data.c', you need to run 'doconfig -c SYSTEMNAME' to create a
new vmunix, copy the new vmunix to root filesystem, then reboot
system. Please let me know the result.
Stephen Choy
UNIX Support
Digital Equipment Corp.
Phone: 800-354-9000 X75410
==========================================================The powerup/spinup time for any particular disk can be specified in
"/usr/sys/data/cam_data.c" on a V3.X system. There is a good
description on how to do this in the file itself. Search for the section of
the file which begins with:
/* * How to add "your own" SCSI (disk/tape/cdrom) device:
...
* The twelfth field is maximun ready time is seconds. For disks this
* field represents powerup/spinup time combined. This is the maximun
* amount of time in seconds the disk driver will wait for a unit to
* become ready.
...
* An example disk entry might look like the following:
*
* DEV_DESC cam_devdesc_tab[] = {
*
* {"DEC RZ55", 12, DEV_RZ55,
* (ALL_DTYPE_DIRECT << DTYPE_SHFT) | SZ_HARD_DISK,
* (struct pt_info *)ccmn_rz55_sizes, 512, DEC_MAX_REC,
NO_DENS_TAB,
* NO_MODE_TAB, SZ_BBR, NO_OPT_CMDS, SZ_READY_DEF,
SZ_NO_QUE,
* DD_REQSNS_VAL| DD_INQ_VAL , 36, 64
* },
In this example, the disk is using the default time of SZ_READY_DEF,
which is defined to be 45 seconds. To increase this time to 60
seconds, simply replace SZ_READY_DEF with 60.
Although this QAR was directed toward V3.2C, it should be mentioned
here that the funcionality of the cam_data.c file has been largely
replaced in V4.0 with /etc/ddr.dbase. In this file the keyword is
"ReadyTimeSeconds", and the values are also in seconds. Again the
default is 45 seconds. If a device needs 60 seconds to spin up, then
the following line is added to the entry for that device:
ReadyTimeSeconds = 60
==========================================================
I think the answer is that you need to define a new disk in cam_data.c
with the SZ_READY_DEF keyword replaced with 60. I am not going to
make this change, as this device is scheduled to be replaced with a DEC
Storageworks RADI unit shortly. I *think* that this is the final word on
how to fix this strange problem, but will not have a way to verify this.
Bob
haskins_at_myapc.com
Received on Wed Apr 17 1996 - 22:39:38 NZST