SUMMARY: Wren IV Errors

From: Jon Stone (
Date: Thu Jan 16 1992 - 17:24:10 CST

My original query was:

> I have a CDC Wren IV 327MB drive. It was connected to a 386i and we
> had no problems. When I connected it to a SS with 4.1.1b as an
> external disk, we found this problem.
> Formatting the disk keeps saying:
> esp0 scsi transfer failed
> retry read error
> retry write error
> Newfs gives the same message, and we cannot read and write from the
> disk.
> Any hints?

Sorry for the long delay. I've been out of my office since before

The responses basically came in these categories:

1) Re-format the drive.

    You must re-format the drive before you can do anything else; When
    you run format, it will either automatically or interactively try
    to identify the disk type. The standard format.dat has the
    following entry for the Wren IV:
     <CDC Wren IV 94171-344 cyl 1545 alt 2 hd 9 sec 46>
    Once you've re-formated, you should be able to do what you want.
    The re-format is necessary because the 386i has a different byte
    order than the SPARC, and SunOS 386i 4.0.1 is probably different
    than SPARC 4.1.1;

2) Byte ordering is different in disk header blocks.

    I believe your problem is a "Byte-ordering" problem. The 386i, as
    with all Intel products, employ a LSB first technique for writing
    words of data. When this is attempted to be read by a SPARC or
    Motorola chip, things don't work quite right.
    Have you tried reformatting the disk with the machine that it is
    intended for? This may work, although I seem to remember
    something about a problem that format(8) had in even addressing a
    disk that had been formatted for a 386i. If this happens, all is
    not lost.
    Place the disk on a SPARCstation along with another Wren IV that
    works on the SPARCstation. Using the dd(1) command, copy the
    first 16 blocks from the good disk to the one you are trying to
    use. This should copy a good label onto the disk. Please note
    that doing this makes all data that was on the disk unaccessable.
    The next step is to use the format(8) command to reformat and
    partition the disk.

3) Change the jumpers. (from jay@Princeton.EDU)
    I dunno if this is your problem, but when I moved a Wren IV from a
    386i to an IPC, my Sun FE told me to remove jumpers J4:P, and
    J3:1-2,3-4. Since this was nowhere documented in the upgrade
    instructions, I was dubious. But, then, my FE is usually pretty
    reliable, so I followed his advice. The disk worked fine from the
    There is a row of 7 jumper pairs just left of the power connector
    on the back of the drive. J4:P is the leftmost jumper. J3:1-2
    and J3:3-4 are the rightmost two jumpers. Target ID selection is
    determined by the 3rd through 5th jumpers from the left. Except
    for ID selection, I now have no jumpers in that row.

4) And a warning or two

    It sounds like the disk was internal in the 386i(?) and the SS has
    it attached the setup you have created is flaky.

The guy who asked me to post this to you did the following:

1) Deleted entire defect list, and re-formatted the drive. While
    this appeared to work, the entire system was much slower. My
    guess is that having the old drive forced the two internal drives
    on the SS to go into asynchronous mode.

2) Then he loaded SunOS onto this external drive and booted with that
    drive as the system disk. This seems wierd to me, but he says
    that the system performance is back to normal. It seems that
    SunOS is treating the system disk somehow different.

    I don't know how good of a solution this is, or how long it will
    last, but it seems to work for now. If anyone has any information
    as to why this works, let me know and I will post a followup.

Many thanks to: Clive Beddall
hsieh@crayfish.UCSD.EDU I-Teh Hsieh
jay@Princeton.EDU Jay Plett jim wills Mark Galbraith Mark C. Henderson J. Matt Landrum paul arens Paul Evan Matz Ron Madurski Walter F. Hartheimer

Jon Stone
Dazix, an Intergraph Company; Huntsville, AL (205) 730-8594

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:34 CDT