DEBULA-R@osu-20.ircc.ohio-state.edu (debula) (01/19/89)
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.
karl@ddsw1.MCS.COM (Karl Denninger) (01/23/89)
In article <12463784207006@osu-20.ircc.ohio-state.edu> DEBULA-R@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@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"