ST506 HDD woes

Arc/RPCs, peripherals, RISCOS operating system & ARM kit eg GP2x, BeagleBoard
ajw99uk
Posts: 108
Joined: Fri Sep 29, 2017 3:00 pm
Location: W Yorks, UK

Re: ST506 HDD woes

Postby ajw99uk » Fri Oct 20, 2017 2:16 pm

Boydie wrote:... the first thing you should do with a new machine was make a complete set if backup floppies ... If you're very lucky, this will be what your backup floppies are and there won't be any personal data.

'Fraid not - the dump is dated and it's too late to be a factory-fresh R140 and also too late to be a "just done the upgrade to 1.15" dump.
What a fun morning it's been: Syquest died, dug out the spare* and set that up (less convenient as it's ID needs to be jumper-set rather than using a button on the back of the box), started with a fresh cartridge (if you can call something stamped "OCT 1996" fresh), sectioned/partitioned, booted 1.21, updated the disktab file** and ran newfs, ran my bodged mknewfs2 script, hand-copied vmunix, dsplit and libC rather than rely on cpsys, trimmed cpsys so as just to do the archive extraction.
Time to reboot, now into 1.15 - but it gave a kernel panic first time and now freezes, with the Syquest activity light on constant orange, on subsequent tries with 1.15 (device sd2) or 1.21 (device sd0). Ctrl-reset to get out of that. I can run the filesystem check on sd2a from the !RISCiX desktop app, for what that's worth, and it comes out clean.
Last try will be with the internal drives unpowered and the SCSI card terminated, for which I'll have to re-jumper the Syquest to ID0.
I don't understand why everything seems fine while setting up the installation, yet both it and then 1.21 refuse to boot.
UPDATE: Most probably a cable / termination / other SCSI voodoo issue - with Syquest as the only device on the chain, and a terminator block instead of a drive's "internal" termination, 1.15 has just booted fine - and I did not get the "cannot reboot with this rom" error I saw yesterday.
Not a "pure" 1.15 set-up, as I'm using RISCiXFS 1.24 and RO3.11. Aiming to try the restore stage this evening.

UPDATE2: restore from 19 floppies worked, so I now have the system as it stood in August 1993! The manual says a full backup can take 45 floppies and 5 hours; restoring 19 took 35-40 minutes, which I guess reflects ARM3/SCSI vs ARM2/ST506. Unfortunately no packages installed under packageadmin, and the first one I tried (X11R2) failed with a CRC error. And various hard-coded references to st0a don't help now it's running on sd0a. BUT this setup looks small enough (15.8MB per df) to fit on a 20MB ST506 ....

* There is a difference between the dead Syquest and the spare is a firmware revision - spare is 3.05 rather than 2.04.
** newfs returns an EOF error using a disktab that defines pa (partition 0's size), but the dynamic approach (as used for RO3065) works, and gives a clean fsck. I therefore suppose any drive can be added using only C/H/S, sector size and block/file parameters - meaning you don't need to update disktab if you alter the partition sizes on that drive, or want to add another drive with same geometry but different partitioning.
Running RISCOS: A5000, A540, R140, RiscPC, RPi B
Running *nix: SGI Fuel & Indigo2, RPi2, x86, amd64, RiscPC, A540, R140

philb
Posts: 118
Joined: Sat Aug 05, 2017 6:05 pm

Re: ST506 HDD woes

Postby philb » Sat Oct 21, 2017 8:07 pm

Boydie wrote:It's odd that your drive's giving a "no index" error code, given that it's not even managing to spin the platter. You'd have thought it would give one of the motor errors in preference, as this is the more fundamental problem.


I think that's exactly what "no index" means. The INDEX signal comes from a tachometer attached to the spindle and "no index" presumably means there is no activity at all on that pin after the controller has tried to start the drive. Obviously this might mean that the disk isn't spinning or it might mean that the sensor is faulty, and the controller doesn't have any way of knowing which of those is the case.

The other motor errors are all basically speed control problems (failed to reach nominal speed quickly enough / at all) and you would need a working tachometer to diagnose them.

Kazzie
Posts: 21
Joined: Sun Oct 15, 2017 7:10 pm
Location: North Wales

Re: ST506 HDD woes

Postby Kazzie » Sat Oct 28, 2017 10:05 am

ajw99uk wrote:(was it Zip drives where a dodgy drive could damage a cartridge in such a way that the cartridge would damage other drives?)


Yes, with the infamous Click of Death as the heads were swung back and forth to try and read a corrupted disk. If one faulty drive corrupted a disk, it would start clicking when trying to read it, as would any other working drive that tried to read that disk. (Actually damaging the other drives was unlikely, but the "click" showed up in whichever drive you tried to read the disk with.) Couple that with the sudden loss of all the data you had stored on the disk, and Iomega's reluctance to say anything about the issue, and you have a good recipe for rumour and hysteria!
Pudsey - BBC Model B 32k issue 7, Sidewise ROM board with 16K RAM

User avatar
davidb
Posts: 1901
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: ST506 HDD woes

Postby davidb » Sat Oct 28, 2017 11:51 am

I had (still have) a SyQuest SparQ drive that failed at an inconvenient time. Fortunately, Cannon/Cumana (who supplied it for Acorn machines) were able to recover the contents and put them on CD-ROMs for me.

I seem to remember that SyQuest were being sued by Iomega at one point, so maybe the mechanisms used were similar enough that they shared the problematic features of the Zip drive. I was a bit worried that the cartridge would be unreadable and go on to break Cumana's own drives, but I think the problem was probably with the drive itself.

User avatar
Seldon2k
Posts: 104
Joined: Sun Dec 08, 2013 3:19 am
Location: Redditch, UK
Contact:

Re: ST506 HDD woes

Postby Seldon2k » Sun Oct 29, 2017 6:34 pm

Hi,

I have only skimmed this so apologies if I have the wrong end of the stick.
In relation to the ST506 drive that didn't spin up mentioned early on in the post.

I remember Miniscribes were notorious for this although it did happen to other makes.

http://www.newworldencyclopedia.org/ent ... disk_drive
"Very high humidity for extended periods can corrode the heads and platters. If the disk uses "Contact Start/Stop" (CSS) technology to park its heads on specified sections on the platters when not operating, increased humidity can also lead to increased stiction (the tendency for the heads to stick to the platter surface). This can cause physical damage to the platter and spindle motor and cause a head crash."

The solution to this was to remove the drive and while holding it from above, rotate the
drive about the axis of the plater motor by giving a quick snap of the wrist!

This violent and last-ditch attempt usually freed up the platter to allow them to rotate.
It would usually be followed by a full backup as quickly as possible.
I have done this a few times back in the early 1990's on PCs usually Compaqs.

Hope this helps,
Terry (Seldon2k)

ajw99uk
Posts: 108
Joined: Fri Sep 29, 2017 3:00 pm
Location: W Yorks, UK

Re: ST506 HDD woes

Postby ajw99uk » Sun Oct 29, 2017 6:45 pm

Terry,
Thanks for your post. I did try the anti-stiction manoeuvre, having had success with it a couple of times in the past.
I have not yet resorted to the freezer trick!
Running RISCOS: A5000, A540, R140, RiscPC, RPi B
Running *nix: SGI Fuel & Indigo2, RPi2, x86, amd64, RiscPC, A540, R140

ajw99uk
Posts: 108
Joined: Fri Sep 29, 2017 3:00 pm
Location: W Yorks, UK

Re: ST506 HDD woes

Postby ajw99uk » Sun Nov 19, 2017 9:22 pm

It lives! Spent too long this afternoon looking at youtube videos of vintage/dying hard drives, then disassembled mine to take photos (so I could ask people here if they can see any PCB faults I had missed).
Then decided to take another crack at the wrist-spin technique, which seems to have done the trick. It sounds a bit rough starting up - one loud click before spin-up begins.

The disc returned 2 defects when verified, but the RISC iX 1.15 boot partition dd'ed without error. The two defects are right at the end of the verify process, which I think covers the entire disc not just the ADFS section, so given the order of partitions I wonder if these defects sit in the swap partition?

Layout is roughly 2.5MB ADFS, 34MB RISC iX root, 10MB swap.

From a brief look at the contents, I think it may be a reconstitution from the floppy installation of base files, restored dump and various packages, rather than an as-it-was-when-last-switched-off-in-1993 archive.

On the downside, my CRT no longer works. It hiccuped when I tried 768x576 on the A5000's ColourCard last night, and today would show only a 2mm wide vertical strip down the middle, compressing the mode 22 screen into that. Time for a new thread ....
Running RISCOS: A5000, A540, R140, RiscPC, RPi B
Running *nix: SGI Fuel & Indigo2, RPi2, x86, amd64, RiscPC, A540, R140

ajw99uk
Posts: 108
Joined: Fri Sep 29, 2017 3:00 pm
Location: W Yorks, UK

Re: ST506 HDD woes

Postby ajw99uk » Mon Nov 20, 2017 12:02 pm

HD noise getting louder and more variable - and other symptoms are emerging, though perhaps not all the drive's fault.

As an interim stage in its decline, while desktop was still working, the drive would not respond to a *Filer_OpenDir command and left-click on the drive icon had no effect. ADFSFiler 0.62 is active.

Then, though CLI commands (cat, list, copy, cdir) seem to be OK subject to a couple of "bad drive" errors, I could not get to desktop, even after configuring Drive 0 and Harddiscs 0 and doing a delete-power-on; it sticks at the RISC OS banner.

So I have taken out the AKA31 SCSI and AKA25 ethernet podules; can now get to desktop, reinstate drive 4, edit !boot and !deskboot to remove extraneous SCSIFiler/CDFS references and reboot to an RISC iX-ready desktop. And the HD's noise level seems to have gone back to normal.

Then booting RISC iX single-user is fine, which reminds me that the troubles started after a kernel panic and control-reset. Odd that that should have had persistent effect across several resets and a power-on delete, until I took out the podules. Last night I was unable to get past single-user, stuck at a repeated login prompt. This morning I discovered that /etc/fstab is referencing /dev/sd0a; but having fixed that, "file system full" : /dev/st0a is 111% full according to df (actually 33,492 out of 33,583KB used - "capacity" must allow for headroom beyond 100%; reducing swap from 10MB to 4MB would give some useful breathing space, though not sure I want to start that process now!) and it's again stuck at a repeating login prompt.

The 1.21 installations I have will allow X use from single-user, but 1.15 baulks at that - maybe just a matter of not having right path variable(s) set up, as /usr/bin/X11 seems well populated.

Having had to control-reset to get out of the login-loop in RISC iX, the ADFS drives no longer responds to an icon-click and Filer_OpenDir again has no effect. Weird.
Running RISCOS: A5000, A540, R140, RiscPC, RPi B
Running *nix: SGI Fuel & Indigo2, RPi2, x86, amd64, RiscPC, A540, R140


Return to “hardware”

Who is online

Users browsing this forum: No registered users and 8 guests