musman@radar.nrl.navy.mil (Scott Musman) (12/12/89)
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@radar.nrl.navy.mil