386/ix Installation Woes

[Karl Denninger]

In article <12463784207006 at osu-20.ircc.ohio-state.edu> DEBULA-R at osu-20.ircc.ohio-state.edu (debula) writes:
>I recently had the time to begin installing Interactive Systems 386/ix
>package (I was already running Microport 386 3.0e) on my AT&T 6386 WGS.
>I have been through the manuals notes, etc. several times & I still have
>a problem.  My hardware configuration is:
>
>AT&T 6386 WGS (16Mhz -- they were on sale cheap)
>WD1007-WA2 ESDI Controller
>Fujitsu 2245E (103Mb ESDI drive with 25ms access)
>Logitech EGA/bus mouse card
>NEC Multisync II monitor (soon to become Princeton Ultrasysnc)
>4Mb of memory
>
>I seem to get as far as the "Surface Scan" just fine, but it never seems
>to return from the scan.  The drive is set up with 7 heads, 823 cylinders,
>35 sectors/track (hard sector with jumpers per hardware instructions &
>vendor support tech person).  As I said before, the real puzzler is that
>Microport 386 3.0e works just fine (perhaps I should mention that 
>Interactives 386/ix is also 3.0 *not* 3.2).  It also seems that Microport
>386 gives me quite a bit more info on just what is going on during 
>install.  Any ideas? Anybody from Interactive out there?  I realize my
>drive configuration is not quite the "norm" (I've only ever found one place
>that sells Fujitsu hard drives & they sell 'em cheap).
>Any help would be deeply appreciated.

You're in deep. 

The problem may be related to the fun I went through with Interactive 2.0
the other day.  What makes the entire episode interesting is that the
problem lies within their installation procedure....

Here's a transcript of a report I sent to the customer involved with
this mess; the problem is certainly solvable, but not easily.  They've also
got a few limitations I can't deal with (like 240 bad _sectors_, better than
the old 63 limit in 1.0.6 (yikes!) but still not enough).  Doesn't anyone
try to use these systems (other than SCO) with really BIG disk drives (read:
anything over 100MB)?  Big disks (300MB anyone?) have lots of defects!

I guess we'll have to hand-calculate the alternates table and rip apart
their installation procedure to determine how to run it by hand; that may be
the only method that works properly in the end (YUCK).  What's the point of 
a nice installation system if it doesn't work right?

[Begin]

Interactive:

I had the following problems with the software and support while onsite
  (386/ix, V2.0):

o The bad block table is incorrectly computed for drives with other than
  a "3:1" interleave by the 386/ix installation software.  This was confirmed 
  by Brian @ Interactive on the telephone after several hours of questions
  and irrefutable evidence in the form of a miscomputed /etc/partitions
  alternates table (along side the manufacturer's defect list which I had
  just entered, and a calculator).  My first call to Brian was placed at about 
  11 AM, I did not have confirmation of the problem (and a recommendation to 
  reformat at 3:1) until about 2:30 PM.  It appears that this problem is (and 
  was) present in the original 386/ix 1.0.6 version shipped to Gerry as well;
  the original failure may have been caused by just such a miscalculation 
  during the initial loading of 1.0.6 386/ix.  This is not documented anywhere 
  in your installation procedure or release notes (in fact it states that
  you can choose an interleave), and furthermore, appears to have been 
  unknown to Brian and Interactive's offices (Both coasts) until I brought 
  it to their attention.  They have now acknowledged the bug, but given no
  date or schedule for a fix.

  Note that this should affect all customers who attempt to use a 1:1
  interleave controller at it's full rated performance level.  This would 
  include the WD1007 crowd (a sizable number of ESDI users!) as well as 
  anyone who uses a high-performance MFM or RLL controller (Adaptec ACB2372 
  or Western Digital WD1006-VSR2 or WD1006-WAH).

  Low performance controller subsystems would have shown us this problem
  immediately through disk I/O errors.  With a high-performance controller 
  this kind of difficulty is insidious; since the controller's ECC circuitry 
  (and superior data separation capability) will allow it to read the data 
  that was written on a "flawed" area 95% of the time you may not notice 
  the miscalculations for weeks (or months) -- everything appears to work 
  properly!
  
  The installation software did indeed query me for the interleave, and it
  also reported the interleave correctly during installation; this information 
  appears to have be disregarded.

o The bad block table still may be incorrect.  We have not yet had time to
  analyze the current list and compare it with the physical defect map (it's
  more work when you're at 3:1 as compared to 1:1 where sectors are linearly
  numbered).

o The bad block request in the installation procedure will not accept a BFI 
  (byte from index) in RLL format.  Given that 386/ix supports RLL drives this
  is rather ludicrous; how else would you expect the manufacturers to list
  this information?  Brian stated that it is "calibrated" for MFM BFI indices;
  this is _possible_ but the evidence at this point indicates that a problem 
  still exists on the customer system in the form of incorrect alternates 
  table entries (even at the "recommended" 3:1 interleave).

o Brian stated "ignore the manufacturer defect list and just let the surface 
  scan find the bad blocks".  I think it's unnecessary to elaborate further;
  the controllers we sell are good, but not good enough to work reliably on 
  known bad areas of a disk drive! 

o Brian also stated that "there is no change in the sector layout when the
  interleave is changed".  Need I explain further?

o Many manufacturers ship drives with only bad cylinder and head
  information; no BFI is supplied.  Your system is _unusable_ with these
  drives due to the 240 bad block limitation.  (Fortunately we are not in 
  this situation).  SCO Xenix supplies a choice; you can remap individual 
  sectors or _entire head/cyl sets_ if necessary.  

The 3.2 software (your version 2.0) appears to be really nice; it's very fast 
and capable (the Xenix compatibility works 100% as far as I can tell).  
Unfortunately the installation package is not up to the quality of the kernel 
and other parts of the system.  Omissions and inaccuracies in the installation 
software, as well as a lack of knowledge (and workarounds) on the part of 
Interactive's technical staff is not reassuring.

Note also that the "freezes" which the system used to experience appear to
be gone; the same serial driver which was thought to be the cause of the
crashes under 1.0.6 is being used now with only a recompile. 

-- End included text --

Microport learned this lesson with buggy installation software a while back;
I understand their current offerings don't have these problems.  SCO never
did have this kind of trouble.

[The original mess was caused by the customer doing a "mkpart -A" to add a 
 bad sector per Interactive's recommendation.  Unfortunately, mkpart -A has 
 a bug (which they knew about but didn't warn the customer of!) and if it
 doesn't like what it finds it destroys the VTOC!  The "high performance 
 disk driver" in the V2.0 software was supposed to fix the problem; I was 
 skeptical then and it appears that skepticism was healthy :-)]

(People who need serial support for Digicom/8 and similar boards and/or 
 16550 FIFO UARTS should contact us for information on our installable 
 driver support kit handling up to 24 ports on 3 IRQ lines).

-- 
Karl Denninger (karl at ddsw1.MCS.COM, ddsw1!karl)
Data: [+1 312 566-8912], Voice: [+1 312 566-8910]
Macro Computer Solutions, Inc.    	"Quality solutions at a fair price"