dvc@cbnewsb.cb.att.com (david.a.vancleef) (05/17/91)
In article <LIBOVE.91May1091948@libove.det.dec.com> libove@libove.det.dec.com (Jay Vassos-Libove) writes: >generic 386sx clone running SCO Unix v3.2v2.0 >Micropolis 1325 68(?)MB MFM hard drive >the Micropolis disk is actually repackaged as a DEC RD53 > >The questions become: >Is there something different about this drive because it was >resold by DEC as an RD53? >Does SCO Unix v3.2v2.0 have a problem with drives that are >not directly supported by the BIOS (though the BIOS in this >box does have this user configurable support mode)? >Is there something about a Micropolis 1325 disk that causes >problems, for SCO Unix or whatever else? I was using a similar hardware configuration, except running off of AT&T SVR3.2.2, and encountered no problem. The system was a 386-25, AMI bios, and the drive was also a cast-off RD53, aka 1325, running as the second drive in the system. My suspicions would lie towards the manufacturer/vintage of your BIOS or the SCO UNIX. ------- David A. Van Cleef AT&T Bell Laboratories internet: dvc@hrmso.att.com Red Hill Facility, Middletown, NJ uucp-land: ...!att!hrmso!dvc +1 908 615 4906
darrell@eeocdt.UUCP (Darrell Tschakert) (06/06/91)
> >generic 386sx clone running SCO Unix v3.2v2.0 >Micropolis 1325 68(?)MB MFM hard drive >the Micropolis disk is actually repackaged as a DEC RD53 > >The problem is that though the system can reference the >1325 disk from its AMI BIOS and from DOS, any attempt to >access the disk under SCO Unix v3.2v2.0 causes the >process doing the access to hang... The BIOS doesn't have >a drive type number for the disk (its parameters are 1024 >cylinders, 8 heads, 17 sectors/track, write precomp >cylinder 1024, write current reduce cylinder 1024, control 5, >ecc none) but that doesn't bother either the BIOS (which has >a user configurable drive type #47 where you enter those >parameters) or DOS (which blindly and happily follows >the BIOS, I guess). This failure mode under SCO Unix happens >either with the disk as drive number 2 (of 2) or as a drive >on a second hard disk controller card (Which requires >hardware and software finagling too major to go in to here). I have had a similar problem with the same drive. However I also have the same problem with a Maxtor 140 Meg, Hitachi 86 Meg, Hitach 46 meg, etc. My problem though is that the system goes to hell as soon as I try to access any second drive. If I do an fdisk, divvy, dkinit or anything that reads the second drive I immediately get errors indicating that my first drive has bad blocks. Next I can't access files on the primary disk. Sometimes I can't even run haltsys and must RESET the computer. However sometimes I can get dkinit, divvy, fdisk to work just for a short time and then things go bad. That is to say, its not really consistent. I can work with both drives in DOS or SCO 3.2.0 but not SCO 3.2.2. I called SCO and they said to try another controller. I tried another controller but then ran into a different problem. I am now looking for another controller to try. SCO 3.2.0 uses HZ=100 while 3.2.2 uses HZ=60. The system won't let me change HZ to 100 so I can't try that. I don't know what else to try. I guess I could try a different interleave. Again SCO UNIX 3.2.0 worked just fine. I would really appreciate some help on this one. Thanks in advance. >> Darrell Tschakert >> Phone: >> >> Equal Employment Opportunity Commision >> (202) 663-4436 >> >> 1801 L Street N.W. >> Email to >> >> Washington D.C. 20507 >> uunet!eeocdt!darrell >>