Path: utzoo!mnetor!uunet!ncc!alberta!att-ih!chinet!bigtex!james From: james@bigtex.uucp (James Van Artsdalen) Newsgroups: comp.unix.microport Subject: Re: Misc uport bugs and observations Message-ID: <1517@bigtex.uucp> Date: 12 Apr 88 18:10:24 GMT References: <4387@b-tech.UUCP> <1446@bigtex.uucp> <924@ddsw1.UUCP> <1469@bigtex.uucp> <946@ddsw1.UUCP> Reply-To: james@bigtex.UUCP (James Van Artsdalen) Organization: F.B.N. Software, Austin TX Lines: 93 Keywords: 386 setup Summary: Long, but has details on setting up a disk manually IN article <946@ddsw1.UUCP>, karl@ddsw1.UUCP (Karl Denninger) wrote: > >Karl, are you sure it formatted at 2:1 interleave? The INSTALL script on my > >disks assumes 1:1 for Televideo and 3:1 for all others. I don't know of any > >way to determine the actual interleave after formatting. > Actually it's quite trivial; run CORETEST, which measures the transfer rate, > and compute from there. [...] Hmmm. I had hoped that the various buffering controllers always read the track in one rotation by simply reading whatever came under the head, instead of reading the sectors in order. That would have cut the rotational latency in half, and made the interleave irrelevant. Oh well, maybe the next generation of controllers... > When I tried to > install on a HD prepped from Speedstor (my favorite) at 1:1, installation > began ok, then blew up with what was an obvious R/W error on the drive. > Now, I DID specify where the bad spots were during installation; is it > possible that Uport has blown it w/regards to the mapping of bad regions > on the disk (ie: BFI <> sector number translation) and is using 2:1 > tables for the Televideo? If this is the case, then 1:1 using their > installation script is not achievable (although cheating might do it). Well, what I did that worked is as follows: 1) back up old disk to tape 2) make copy of build disk. 3) put stripped /unix with tape driver on the floppy along with ed, tar & ls. 4) edit /INSTALL on floppy so that "intlv" is always 1, and disable patches to kernel (because I stripped the kernel in #3 and it isn't going to work). 4) format disk under DOS. 5) boot the floppy & go like it says until it boots the hard disk. 6) boot the floppy again, mount hard disk partitions & restore from tape. > Does this ALSO take care of badtracking correctly? Technical support at > implied that it had something to do with the formatting process (which > doesn't seem right; I've looked at that partitions file). Setting intlv correctly appears to take care of badtracking. I've hedged my bets here as I'm not sure of the cause of Karl's problem. But in my case it worked. I was told by John Sully that the disksetup program does use the intlv value to calculate the mapping from defect BFI to sector number, so if intlv doesn't match the interleave, you will have trouble. I have found no reason so far to use their formatting process, and have not done so at any time with unix/386. > Can I then assume that if the file '/etc/partitions' is created on the > floppy I can use 'mkpart -i disk0' to init a low-level formatted HD with the > info in that file? This actually works? If you do this by hand, the order can be important. The correct order is: 1. mkpart -i disk0 2. fdisk /dev/rdsk/0s0 /mnt/etc/mnttab 10. mkdir /mnt/mnt /mnt/usr2 The permissions on files need inspection at this point, but it is entirely possible to set up a disk without using the INSTALL script, using steps 1-6. One thing though that can't be overemphasized: the /etc/partitions file on a disk MUST match exactly the partitions on both hard disks. If not, then next time mkpart is run it apparently tries to reset the VTOC (both internal and on disk) with predictable results (ie, have your backup handy). Never let a partitions file wander into /etc unless it's the same file that did the mkpart -i to your disk... > I take it you need to hand-code the defect locations for this as well... No, the disksetup program *appears* to work just fine so long as the intlv value matches reality. I let it calculate the values when I was using the WD1006. Fortunately, the WD1007 ESDI controller remaps things around and ESDI drives appear to have no defects to the software (there's a spare sector every 34 or so for this purpose I gather). -- James R. Van Artsdalen ...!ut-sally!uastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746