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
Christmas.
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
outset.
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 externally...so 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@jtsv16.jts.com Clive Beddall
hsieh@crayfish.UCSD.EDU I-Teh Hsieh
jay@Princeton.EDU Jay Plett
jwills@deltam.com jim wills
mark@deltam.com Mark Galbraith
mch@west.sq.com Mark C. Henderson
mdl@cypress.com J. Matt Landrum
parens@dazixco.ingr.com paul arens
paul@bmskc.ppg.com Paul Evan Matz
ron@drd.com Ron Madurski
walter@pins.com Walter F. Hartheimer
----------------------------------------------------------------------
Jon Stone jon@ingr.com
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