CompuServe Thread

#Cart drive hangs boot

13 messages in this thread
#189169From: Richard RaeMar 15, 1995 9:06 PM
Actually, the scanner went both ways. When I first found out the thing wouldn't boot, I disconnected the scanner to see if it made a difference. That was my standard procedure through most of this, except when I started having checksum errors after pulling the terminators on the Maxtor. In _that_ case, reasoning that the line was unterminated on one end, I plugged in the scanners SCSI terminator pack (actually a DB25 pass-through, not SIP resistors). I _do_ have one of those 'newfangled 3.5" Syquests.' What did I (mistakenly) say to make you think otherwise? Haven't had a chance to open the machine yet to check things, but I write-protected the cart the other night and it hasn't gone south yet. Thanks for the version number, by the way. Rick
#189192From: Erik FlomMar 15, 1995 10:14 PM
I thought you had a 3.5" drive….the people telling you to check ROM numbers were probably thinking you had a 5.25" (If you'd squeezed a large Syquest into the 3000, I'd say you're getting the problems you deserve. :^) I never could really determine the exact configuration for terminators on my 3000. The set of terminators on the motherboard seems to act as one end, when there's no external SCSI device, but when I _did_ have something external, I would get read/write errors if I tried pulling the terminators from the motherboard. Glad it's working thus far…. Erik Flom
#189283From: Richard RaeMar 16, 1995 8:16 PM
Yeah, Bill is telling me the same thing over there <pointing to another message> as we speak. So that's probably not it, but I'll still check the ROM revision number when I go inside. Odd, your story about the terminators. If you had them on the external device I, too, would have thought they would come off the motherboard. (that is, now that I know they are ON the motherboard <grin>). These days the terminators I pulled from the Maxtor are less suspect. What with trashing the cart on write the other day, I'm thinking the same thing (whatever it is) caused the checksum errors. I think the reason "it's working thus far" is that I have it write-protected. Bet if I started trying to write something to it every so often I'd trash the cart again. Actually, maybe I should leave it like this; I got the thing for backups, so I want to resist the temptation to use it as another hard drive (what would I back it up to?) If it turns out I can format the cart, write to it once (the backup), and read from it forever, but would trash it if I wrote to it again later… well, that'd certainly remove the temptation to use it for anything else. <Laughing> Dumb question, I imagine: what are the odds of my having a bad cartridge, or of having damaged it? The first time I ever formatted it, it only took about five minutes. The last two times I've had to do it the process took _much_ longer. I'm just wondering if I damaged the surface in some way (maybe when I had to manually eject the cart when I couldn't get the thing to boot) and now it's marginal. Is this as far-fetched as it seems? Rick
#189380From: BILL LEACHMar 17, 1995 4:00 PM
Rick; Out of a few dozen SyQuest carts I have ended up with four that went bad. That is, the carts themselves were no good. Supposedly there is an outfit that can restore them if the surface itself is not physically damaged. SyQuest (at least mine) have a servo-track. -bill
#189389From: Richard RaeMar 17, 1995 5:58 PM
Bill, May I ask what symptoms you experienced? With the very little reading and writing I've done to this cart it's hard to believe it might have just "gone bad," but I did eject it manually a couple of times in the early stages of debugging this problem. I'm thinking that maybe I did so too soon, before the cart had spun down; or perhaps I rapped it a bit too hard while shuffling stuff around with the machine open. <Shrug> Just trying to keep an open mind as to what the problem(s) might be. Rick
#189614From: BILL LEACHMar 19, 1995 7:59 PM
Rick; I have not done more than 'spin up' a SyQuest and do a directory listing in over a year (in fact I just did it after installing OS3.1 on a A2000/GVP040) yesterday… thus specifics might be a bit tough to remember. The worst that I remember was trying to use a SyQuest in an A3000T/040. That drive would work fine for a couple of megabytes sometimes and then hang the bus (led on). Sometimes, it would hang the bus just transfering an Icon file. At other times, it would hang the bus when trying to boot the machine. The OS would often report the cart as NDOS but a reboot (if successful at all) would usually show the cart as good (and the internal in another A2000 would also show the cart as good). The older ROM problem that I first had usually prevented the machine from booting (though not always) if reselection was on. When used on an A3000, the 5F (I think) ROM was pretty reliable. If you have a bad cart, when you try to format the thing, the attempt will fail. Depending upon the formatting software, you will get messages to the effect or the format operation just will not complete). What is happening, is that the servo track is bad and the drive appears to 'get lost'. The carts that I had go bad, did so without appearent reason. I have also done a few of the 'stupid things' that you described without harm (and the bad carts never suffered my trying to remove them while still spinning). -bill
#189910From: Richard RaeMar 22, 1995 6:06 PM
Thanks for the information, Bill. I don't want to blame this on the cart yet, but your comments about not being able to format sure sound suspicious. Perhaps the cart is marginal and the drive is retrying a zillion times. Rick
#189407From: Erik FlomMar 17, 1995 8:41 PM
When you 'manually ejected' the cart, was it still spinning? Still, I doubt it's damaged – I've seen friend' force 88MB syquest's out before they've stopped spinning, with no ill effects. You mention the first time formatting was quick, but the last 2 were slower? Is this while formatting from the CLI, or using the Low Level Format in HDToolBox? Also, when formatting from the CLI, you can add the keyword 'QUICK' to do a simple reformat of the drive's directory structure (or something like that), which only takes a few seconds, compared to the long minutes required to format an entire drive. (Though I think you still need to do at least one full format the first time….) Have you tried the Find Bad Blocks option in HDToolBox? Oh well, the mystery continues…….. Erik Flom
#189909From: Richard RaeMar 22, 1995 6:06 PM
Erik, I don't know if the cart was still spinning or not. I note the manual says wait 30 seconds. I doubt I waited that long every time… but I also doubt it takes that long for the thing to spin down. All my references to formatting have been low level. AmigaDOS formatting seems to be pretty consistent. (Yes, I know about QUICK and you're right, you do have to do it "unquick" at least once after low level formatting.) I don't have a Find Bad Blocks option in my HDToolBox, at least not that I can find. I do have Verify Data on Drive. This is the one that was aborting halfway through before I reformatted the cart last time. Once I low-leveled it, the verify worked fine, as it has every time I formatted the drive. Interesting… I just pulled up HDToolBox to make sure there is no Find Bad Blocks, and for grins I ran Verify. Guess what: the verify is aborting in the middle again without explanation. Guess what else: I copied some new files to the cart last night (after running read-only for days without incident). Hmm… Looks like it's time to do some structured testing. _IF_ I've just stumbled across a way to detect when damage occurs, then I can cycle through some different configurations and perhaps find what's causing this. I'll keep you posted. Rick
#189942From: Erik FlomMar 22, 1995 11:21 PM
I just checked, and you're right, there is no 'Find Bad Blocks'. I think what you have to do is run a 'Verify Data', and then add those blocks to the list manually. This is, of course, a moot point with SCSI devices, as they will almost always do the bad block remapping 'on the fly'. (And, most new drives these days will have few, if any, bad block in their defect list anyway.) Just out of curiosity, when looking at the partition window for the cart, have you checked the 'Change…' Filesystem options? You might want to verify that you're using the right FileSystem, with appropriate masks, etc. (Yes, I _am_ grasping at straws here…) The saga continues….. Erik Flom
#190039From: Richard RaeMar 23, 1995 9:49 PM
No problem, I've been grasping at straws for days now. Yes, "Verify Data" is the option you run, but you don't have to add any bad blocks it finds. At least not according to the AmigaDOS manual… it says they get added to the list automatically when Verify Data finds them. (Since I've never found any, I dunno.) The cart is set for FFS, but it was a good suggestion. One thing I've wondered about in the past is the Max Transfer value. It's set to 0xffffff now and that should be okay, but I'm going to try cutting it down if things keep up this way. The mask is set to 0x7ffffffe; I don't remember enough about this one offhand to know if this is correct. It _is_ the same as for my two hard drives. I've an interesting tidbit on the terminators. You'll recall we both though I had three sets in. I tore the machine apart last night to finally set things up right. Pulled the drive bay out and guess what: no terminators on the motherboard! So there's only been two sets in all along (though in the wrong places), and when I pulled them out of the Maxtor, that left me with only _one_ set… no wonder I got errors that way! Anyway, it's now set up "correctly": a terminator pack on the external scanner, resistor packs on the SyQuest (which is the last drive on the internal chain), and the controller in the "middle." I've reformatted the cart from low level up (took three tries to get it to take, again) and am going to see how things work now. I posted an inquiry on the SyQuest support BBS last night. We'll see if they have any insight on the problem. Rick
#190087From: BILL LEACHMar 24, 1995 10:48 AM
Rick; I think that the 0xFFFFFF max transfer and the 0x7FFFFFFE max transfer are correct. These are the values for the drives on this machine. I remember something about having a "c" as the last value for one of those but if I am remembering correctly the "c" was a potential problem not a solution. -bill
#190120From: Erik FlomMar 24, 1995 7:18 PM
Yes, I remember reading the same thing about Verify Data, now that you mention it. As for the Mask & MaxTransfer values, as long as I'm using C= controllers, I just let it do a best guess – I've never seen a clear written description of what the flags _mean_ anyway…. re: terminators….. I hope that does it – I had similar problems the one time I reid running wihtout terminators on the motherboard!! Good Luck! Erik Flom