Mixing Disks on a 451 controller

Scott Musman musman at radar.nrl.navy.mil
Tue Dec 12 14:49:11 AEST 1989


A few months back I installed an after-market CDC Sabre 9720-850 disk onto
my sun 3/260. It already had a Fuji 280MB disk on it from the factory.
Both disks hang off a single XY 451 controller.  Ever since installation I
have been getting an intermittent error message on the console:

	vmunix: xy1b read restore (disk sequencer error) -- blk #1005, \
	abs blk #1005

The partition in the message refers to a second swap partition, but I have
also recieved the error for several different blocks on our file system
which resides on the rest of the disk. The error seems to be consistent to
the same blocks... But!! after re-formating the disk, a whole new set of
disk blocks cause the trouble, and the original set appear fine.

The error has only occured when the disk was being throughly thrashed. For
example: when multiple lisp processes are running, or when I do backups. I
have never seen the error occur when the disk load is small (but this
could just be coincidence). The frequency of the error is such that, in
the swap partition we may get the sequencer error on average of once a
week, and in the file system I will get the error message at least once
when I do a level 0 dump. Under normal circumstances the file system
partition is fine.  The only solution I've tried to date was to re-format
the disk.  When the system was down I ran some read tests using analyze on
a part of the swap partition which was giving me problems.. After running
through the cycle 10 times no error was detected or reported.  I've talked
to my local SUN service rep and he says that it is possible that the
controller may be having a problem supporting the two different disk types
at the same time. He says, that he thinks that he has heard of other
people who have had the same problem but he can't remember who. He also
thinks that some other machines with exactly the same configuration work
just fine..  The other very obvious cause for the error is that the new
disk is bad. Unfortunately, if this is the case, in order to get it
repaired under warranty I will have to crate up the disk and ship it off
to Seagate. This will mean down time for many users on the system.. Before
I do this I'd like to make sure that the problem is in the DISK and not in
the controller or configuration.  Any ideas?? Is there any way I can
further isolate the fault??  Appart from sending off the disk for repair,
the only obvious things I can think of would be to load the OS on the new
disk and only use it (without the older Fuji disk online). Is there
something I can try first? Or perhaps another approach to take.

	-- Scott
	   musman at radar.nrl.navy.mil



More information about the Comp.sys.sun mailing list