Misc uport bugs and observations

[James Van Artsdalen]

IN article <946 at ddsw1.UUCP>, karl at 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 <fdisk.data
3. mkpart -P rootus -P swap -P reserved -P alts disk0
4. mkpart -P usr -P usr2 -P dos				(whichever apply)

Order isn't important here:

5. mkfs  & labelit on rootus, usr and usr2		(whichever apply)
   The mkfs.data file has the constants to use.
6. Create & enlarge the lost+found directories.

At this point I always restore from tape, but you probably can:

7.  mount /dev/dsk/0s0 /mnt
8.  find /dev /bin /etc /shlib /unix /tmp -print | cpio -pdmau /mnt
9.  >/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