root@libove.UUCP (The Super User) (06/24/88)
I have SCO Xenix 2.2.1 running on an IBM PC/AT clone (made by PCs Limited) and it has a Seagate Technologies ST4096 (80 megabyte) hard drive as the root device, with a ST4026 (20 megabyte) mounted secondary filesystem. The 20 meg drive has no flaws, but the 80 meg drive has a few bad tracks. The Xenix bad track (badtrk) utility does not mark them all; it, like all Xenix programs that use disk devices lets the kernel absorb a great deal of bad returns before accepting something as bad - something that causes a great deal of trouble with floppies - the Xenix utilities will often write to a bad spot on a floppy (assuming that it *will* hold out, instead of the more likely case that it will *not*) ... but anyway... So, often I am running something disk intensive and the system starts thrashing; that is, I hear the hard drive making its characteristic "seek to root, attempt to seek to target sector again" noise. My solution is to back up everything and reformat the drive with a utility that really checks out for bad blocks, and marks them as unusable. Who cares about the extra megabyte I lose if it keeps potential explosions from happenning (and keeps that awful wait during recalibration from occurring). The point of this post, anyhow, is to ask if anyone else has experienced this type of behaviour, or has any opinions on SCO's disk drive device drivers. Perhaps we could convince SCO to go a little more conservative on the drivers' retry attempts... -- Jay Libove Internet: libove@cs.cmu.edu libove@andrew.cmu.edu 5313 Ellsworth Avenue formtek!ditka!libove!libove@pt.cs.cmu.edu Pittsburgh, PA 15232 UUCP: cmucspt!formtek!ditka!libove!libove (412) 621-9649 cadre!pitt!darth!libove!libove
wrm@pnet02.cts.com (William Mattil) (06/28/88)
root@libove.UUCP (The Super User) writes: > >I have SCO Xenix 2.2.1 running on an IBM PC/AT clone (made by PCs Limited) >and it has a Seagate Technologies ST4096 (80 megabyte) hard drive as the >root device, with a ST4026 (20 megabyte) mounted secondary filesystem. > >The 20 meg drive has no flaws, but the 80 meg drive has a few bad tracks. >The Xenix bad track (badtrk) utility does not mark them all; it, like all >Xenix programs that use disk devices lets the kernel absorb a great deal >of bad returns before accepting something as bad - something that causes >a great deal of trouble with floppies - the Xenix utilities will often >write to a bad spot on a floppy (assuming that it *will* hold out, instead >of the more likely case that it will *not*) ... but anyway... > >So, often I am running something disk intensive and the system starts >thrashing; that is, I hear the hard drive making its characteristic "seek >to root, attempt to seek to target sector again" noise. > >My solution is to back up everything and reformat the drive with a utility >that really checks out for bad blocks, and marks them as unusable. Who >cares about the extra megabyte I lose if it keeps potential explosions from >happenning (and keeps that awful wait during recalibration from occurring). > >The point of this post, anyhow, is to ask if anyone else has experienced >this type of behaviour, or has any opinions on SCO's disk drive device >drivers. Perhaps we could convince SCO to go a little more conservative >on the drivers' retry attempts... > This can always be a problem. I strongly suggest that once bad tracks have been determined, you enter them manually. Always include the bad tracks that are marked on the drive itself. When I low-level format the drive(s) I include the bad track data there too. When installing Xenix, it asks if you would like to enter bad tracks. Thats the time to do so. If you doubt the reliability of the drive you can have it check by any competent disk repair house. When they return the drive they will include a hard/soft error map. I enter all of these tracks as bad. This seems to work for me. UUCP: {ihnp4!scgvaxd!cadovax rutgers!marque}!gryphon!pnet02!wrm UUCP: {hplabs!felix, crash}!telcomm!wrm INET: wrm@pnet02.cts.com
ericg@sco.COM (Mwa ha ha) (06/28/88)
root@libove.UUCP (The Super User) wrote in article <51@libove.UUCP>: > >The 20 meg drive has no flaws, but the 80 meg drive has a few bad tracks. >The Xenix bad track (badtrk) utility does not mark them all; it, like all If you know that there were not some included after the scan, the correct action to take is to enter them manually from the flaw map. In fact, if you have a flaw map, don't even bother with the scan -- just enter the flaws manually. >a great deal of trouble with floppies - the Xenix utilities will often >write to a bad spot on a floppy (assuming that it *will* hold out, instead >of the more likely case that it will *not*) ... but anyway... The floppy driver assumes error-free floppies -- so bad writes/reads will retry quite a bit. > >So, often I am running something disk intensive and the system starts >thrashing; that is, I hear the hard drive making its characteristic "seek >to root, attempt to seek to target sector again" noise. Do you get any console error messages at this point? If so, you can just take the cyl/track numbers and add them into the badtrack table. >Jay Libove Internet: libove@cs.cmu.edu libove@andrew.cmu.edu >5313 Ellsworth Avenue formtek!ditka!libove!libove@pt.cs.cmu.edu >Pittsburgh, PA 15232 UUCP: cmucspt!formtek!ditka!libove!libove >(412) 621-9649 cadre!pitt!darth!libove!libove -- Eric Griswold |\*/ \*/ \*/ \*/ \*/ \*/ \*/ \*/ \*/ \*| "When Zen is outlawed | ericg@sco.COM | I do not speak for SCO. I barely | only outlaws will | uunet!sco!ericg| have enough room for my own opinions.| practice Zen" - Zippy | --------------/ \------------------------------------/ \---------------------/
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (06/28/88)
Let me see if I can share some of my experiences here, even if it doesn't supply "the" answer. In article <51@libove.UUCP> root@libove.UUCP (The Super User) writes: [ brief desription of badtrack not finding all bad tracks ] | My solution is to back up everything and reformat the drive with a utility | that really checks out for bad blocks, and marks them as unusable. Who | cares about the extra megabyte I lose if it keeps potential explosions from | happenning (and keeps that awful wait during recalibration from occurring). badtrack allows you to enter bad track info manually, and this can include the manufacturer's defect list. The manufacturer uses better equipment to find problems than a disk controller, and therefore will find some tracks which are not found by a scan. You will have a better chance of finding bad tracks using a low level format than a standard format. In addition, bad tracks can change during shipping. I have had badtrack identify tracks not on the original list, and not mark some which were. If you have a reliable program to identify bad tracks, use it, for sure. | The point of this post, anyhow, is to ask if anyone else has experienced | this type of behaviour, or has any opinions on SCO's disk drive device | drivers. Perhaps we could convince SCO to go a little more conservative | on the drivers' retry attempts... Early versions of SCO (2.1.3) really didn't handle bad trqacks well. Everytime I've gotten one I've had to recover more or less manually. I see no evidence that I have had any errors on my 2.2.1 system, so I can't comment. I would hope that there would be a way to remap stuff, but the separation of the drivers and the kernel may be a problem here. Others please comment, my experience has been good after entering all manufacturer's listed tracks. | -- | Jay Libove Internet: libove@cs.cmu.edu libove@andrew.cmu.edu | 5313 Ellsworth Avenue formtek!ditka!libove!libove@pt.cs.cmu.edu | Pittsburgh, PA 15232 UUCP: cmucspt!formtek!ditka!libove!libove | (412) 621-9649 cadre!pitt!darth!libove!libove -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
kinmonthprep@deneb.ucdavis.edu (0000;0000005488;410;465;401;) (06/28/88)
What about the MSDOS partition. The badtrk utility refuses to accept bad track information for the MSDOS partition but the dos* functions seem to have a remarkable ability to address bad tracks in the MSDOS partition. Then the disk drive starts making noises like an old Maytag with rocks in it....
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (06/29/88)
In article <2354@ucdavis.ucdavis.edu> kinmonthprep@deneb.ucdavis.edu.UUCP (Earl H. Kinmonth) writes: | What about the MSDOS partition. The badtrk utility refuses to | accept bad track information for the MSDOS partition but the dos* | functions seem to have a remarkable ability to address bad tracks | in the MSDOS partition. Then the disk drive starts making noises | like an old Maytag with rocks in it.... I have never seen any problem with the utilities failing to honor the bad track info created by the DOS "format" program. Has anyone else seem this? -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
karl@ddsw1.UUCP (Karl Denninger) (06/30/88)
In article <2354@ucdavis.ucdavis.edu> kinmonthprep@deneb.ucdavis.edu.UUCP (Earl H. Kinmonth) writes: >What about the MSDOS partition. The badtrk utility refuses to >accept bad track information for the MSDOS partition but the dos* >functions seem to have a remarkable ability to address bad tracks >in the MSDOS partition. Then the disk drive starts making noises >like an old Maytag with rocks in it.... If you use a product such as Speedstor (tm) to do the low-level format, you'll get the bad tracks flagged in the DOS FAT table when you perform the high-level format. The 'dosxxx' commands will not use them, since they're marked as being unusable..... Remember, on the MSDOS partition, you need to do things the DOS way (at least at the format/generation level). Our version of Xenix, SV/386 2.2.1, correctly marks and interprets bad track tables, and you can add to it without reformatting or reloading your disk if a track goes bad after installation. The system will even attempt to salvage the data in the now-bad area, although it's not always successful. (BTW: Speedstor can also 're-initialize' (ie: change interleave) on a Xenix disk and not blow everything up. I was *amazed* that this worked; our system still booted after messing with the interleave in this exact fashion). Speedstor is a product of Storage Dimensions, Inc. We're a very satisfied customer..... -- Karl Denninger (ddsw1!karl) Data: (312) 566-8912, Voice: (312) 566-8910 Macro Computer Solutions, Inc. "Quality solutions at a fair price"
neese@cpe.UUCP (06/30/88)
Another solution is to use SCSI Hard Drives. Tandy is now selling a version of SCO (called 2.2.4) which has support for the Tandy 16 Bit Intelligent SCSI Host Adapter. Flaw management is completely transparent to the user and is much more elegant than any other solution I have ever seen. The speed is also remarkable. With two of the SCSI drives, disk throughput is 83% faster than the Compaq's 130MB ESDI drive. Not to mention that CPU overhead is about 1/2 that of associated ST506/ESDI controllers due to the First Party DMA approach Tandy uses. As I also understand it, Tandy will be the only vendor who will have 2.2.4. There are also numerous fixes to the kernel over 2.2.[12]. Roy Neese UUCP @ ihnp4!sys1!cpe!neese
stacy@mcl.UUCP (Stacy L. Millions) (06/30/88)
In article <2354@ucdavis.ucdavis.edu>, kinmonthprep@deneb.ucdavis.edu (0000;0000005488;410;465;401;) writes: > What about the MSDOS partition. The badtrk utility refuses to > accept bad track information for the MSDOS partition ... It is not the function of Xenix to look after the DOS partition, that job should be done by the DOS format utility, after that the Xenix "dos functions" should not access any tracks that DOS wouldn't. -- "IBM Personal System/2. It's like having 256,000 crayons in one box." For those of you who are still doing your business reports with crayons! S. L. Millions ..!uunet!mcl!stacy
rac@jc3b21.UUCP (Roger A. Cornelius) (07/02/88)
From article <11419@steinmetz.ge.com>, by davidsen@steinmetz.ge.com (William E. Davidsen Jr): < In article <2354@ucdavis.ucdavis.edu> kinmonthprep@deneb.ucdavis.edu.UUCP (Earl H. Kinmonth) writes: < | What about the MSDOS partition. The badtrk utility refuses to < | accept bad track information for the MSDOS partition but the dos* < | functions seem to have a remarkable ability to address bad tracks < | in the MSDOS partition. Then the disk drive starts making noises < | like an old Maytag with rocks in it.... < < I have never seen any problem with the utilities failing to honor the < bad track info created by the DOS "format" program. Has anyone else seem < this? < < -- < bill davidsen (wedu@ge-crd.arpa) < {uunet | philabs | seismo}!steinmetz!crdos1!davidsen < "Stupidity, like virtue, is its own reward" -me Yes, I have Sperry Xenix (really SCO) sysVr2.0 and although I haven't tried badtrk, or even know if I have it, the utilities that access the dos partition sometimes fail when trying to read a bad area of the dos partition. It's been a while since I checked into it, but cylinder-head info returned by the error matched the bad areas on the dos partition. Roger -- +---------- Roger Cornelius -----------+ | (813)347-4399 | | ...gatech!codas!usfvax2!jc3b21!rac | +- ...gatech!usfvax2!jc3b21!rac -+
karl@ddsw1.UUCP (Karl Denninger) (07/05/88)
In article <6800003@cpe> neese@cpe.UUCP writes: > >Another solution is to use SCSI Hard Drives. Tandy is now selling a version >of SCO (called 2.2.4) which has support for the Tandy 16 Bit Intelligent SCSI >Host Adapter. Flaw management is completely transparent to the user and is >much more elegant than any other solution I have ever seen. The speed is >also remarkable. With two of the SCSI drives, disk throughput is 83% faster >than the Compaq's 130MB ESDI drive. Not to mention that CPU overhead is >about 1/2 that of associated ST506/ESDI controllers due to the First Party >DMA approach Tandy uses. As I also understand it, Tandy will be the only >vendor who will have 2.2.4. There are also numerous fixes to the kernel >over 2.2.[12]. A few comments: First, ALL SCSI drives have transparent flaw managemenet. Tandy is not unique in that regard. Thus, any company which can provide an SCSI driver and controller has this "unique" benefit of the "more elegant" solution.... I'm also interested in some numbers on the "50% overhead reduction" claim. First-party DMA... hmm... this is the MC5000 you're touting, right? Finally, and most disturbingly, you mention "fixes to the kernel". Would you care to list some of the flaws you've found? We've been running 2.2.1 here for many months, and have never had a *kernel* problem. I'd be quite surprised if SCO was not intending to supply these "kernel" fixes to all their customers; that would be very much out of character for that fine organization. Are you implying or stating that Tandy will have the *only* version with these fixes in place? It should also be noted that your comments have a slight inherent bias, as your site is *Tandy's Computer Product Engineering* department (not obvious either -- no organization was listed in the posting.... until I looked in the maps....). I've no problem with postings from such sources, of course -- but I do think you should identify the organization you represent! -- Karl Denninger (ddsw1!karl) Data: (312) 566-8912, Voice: (312) 566-8910 Macro Computer Solutions, Inc. "Quality solutions at a fair price"