386/ix Applications Platform
Karl Denninger
karl at ddsw1.MCS.COM
Wed Mar 1 02:04:48 AEST 1989
In article <1136 at marlin.NOSC.MIL> grabhorn at marlin.NOSC.MIL (Steven W. Grabhorn) writes:
>..... (version 2.1 does not exist, 2.0.1 includes the bugfixes to 2.0).
Well, they THINK it includes the bugfixes. Unfortunately, it still may
not work right for you.
There is a SERIOUS problem in Interactive's installation software. We have
brought it up twice; the first time they shipped a "fix" (which is the 2.0.1
update), the second time (they didn't fix it right the first time!) we're
still waiting for results on.
The trouble manifests itself if you try to enter BFI indices when you are
installing the drive. If your drive is a RLL (and probably ESDI too) unit,
the BFI option is WORTHLESS; it doesn't map out sectors right and in some
cases won't even accept a valid BFI!
Interactive does NOT support "map out this entire track as defective", so
you have NO CHOICE in the matter most of the time. Manufacturers, as a
rule, supply defect information as "head/cylinder/BFI". Interactive gives
you three choices for entering bad track info (absolute sector, sector
within track and head, and head/cyl/bfi). Of course, the first TWO are
useless as no manufacturer I have EVER, EVER run across uses these formats
for defect mapping.....
The _ONLY_ way to end up with an installation that has a semi-correct defect
table is to let the system destructively test the disk. This, unfortunately,
is not a solution, as high-performance disk hardware will be able to
read/write in a defective spot on the disk some of the time, even with ECC
and retries turned off. The end result is that you'll end up with KNOWN
BAD AREAS in your filesystems, and slow corruption of your data!
This, coupled with "mkpart -A"'s desire to eat VTOC tables (a customer of
ours had his VTOC _DESTROYED_ by mkpart while attempting to add a bad
sector!) makes the entire system worthless to us at present..... we've not
yet figured out how to obtain flag-free disks at a reasonable cost, nor do
we see that as a reasonable solution.
This bug exists in 386/ix V1.0.6 AND V2.x. It has been confirmed by the
folks in California at Interactive. I wouldn't touch the product until
this is claimed and PROVEN to be fixed; the risk to our data is too great to
play around with this kind of foolishness.
If Interactive is listening, we'd be more than happy to be a guinea pig
in testing their "new and correct" installation software....
(Note that the software itself, once installed, appears ok -- I've noted
no operational problems; even Xenix compatibility appears to be ok. IF
AND WHEN they get the installation working properly they'll have a
reasonable product).
Users who need dumb-multiport card support for Interactive 386/ix V2.x can
also call us; we have an installable driver that will run up to 24 ports
spread across three IRQ lines; it even recognizes and uses 16550A UARTs!
---
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"
More information about the Comp.unix.microport
mailing list