bill@cdin-1.UUCP (G. William Perrin) (10/11/88)
Has anyone managed to get Xenix up on a 338MB drive without lossing 60MB of
the drive because SCO Xenix can't handle that large a drive?
We are currently attempting to get SCO Xenix 386 2.3.1 up and running with the
Western Digital 1007 controller and the MiniScribe 9380E ESDI drive. These
configurations will be on 20 and 25Mhz 386 boxes.
So far:
We have confirmed that both the Adaptec 2322 and the WD1007 work with 150MB
ESDI drives and SCO Xenix 2.3.1 on 20 and 25 Mhz. units.
We have found that the Adaptec 2322 will NOT work with the MiniScribe 9380E on
either the 20 or 25 Mhz units. We did not try it on any slower units. The
one engineer we finally reached at Adaptec acknowledged the problem and had
promised us some type of "norton 3.1" fix over two weeks ago. Since that fix
hasn't shown up, cards have gone back and the 2322 is on our list as "doesn't
work as advertised". Incidently, we already went through the micro-code
problems with MiniScribe and the drives with the proper stuff still don't work
with the Adaptec 2322.
That takes us to the 1007. Surprisingly, these worked rather nicely right out
of the box (but their on-board stuff is very primative and un-friendly when
compared to Adaptec). Low-level formated nicely, etc.
Now the "fun" - loading SCO Xenix. Seems that SCO Xenix can't handle drives
with more than 1024 cylinders, and these drives have 1224. We used 1024 and
the drive came up great and runs fine - BUT, the customer wants to use all the
drive that they are paying for (can't really blame them for being concerned
about that missing 60MB). SIDEBAR: the tower we are building has a 25Mhz 386
with 8MB of memory, 64k of memory cache and a 32 bit slot. It is a SCREAMER.
So, we have tried using the tricks of WD - mapping the physical drive of 1224
and 14 heads with 35 sectors to the logical of 636 16 heads and 63 sectors.
That seemed to work just fine, Xenix only died once during loading but after
that worked okay. It runs great, until you try something like df -v. When
you do that you discover this nifty feature - it locks the system up.
We have also tried 14 other possible combinations of mapping, all failed.
Over the last month of trying to get this stuff all working, the only people
that have been helpful to any degree has been the MiniScribe folks. This
problem appears to be beyond the ability of SCO's support people and are at a
loss at who to direct it to for some real answers/help. Their last tech
simply said SCO treats it as a ST506 and all they want is the logical address
so we have to lie to it to get it to work - but won't/couldn't provide any
help regarding that card and drive, and tried to blow it off as a controller
problem. (don't know if that was an attempt to "close" the open problem
report on their part, but we have kept it open). Even asked who would know or
could help and how we could get the help we need, was told that he was it.
Western Digital has been even less helpful - and just about impossible to
reach. However, 14 phone calls have finally seemed to have located a real
person that might actually know who to reach. Adaptec was too busy blaming
MiniScribe so that the real problems could be handled.
What it appears to be is that the hardware companies are rushing their
products to market - but don't really know what their market is. MiniScribe,
Adaptec and Western Digital have all said that they never tested their
products with SCO Xenix - or any other "flavor". All their testing was
strictly with MS/DOS and PC/DOS. Each of them would beg off as not having any
knowledge or understand of Xenix/unix - and several admitted that they didn't
even know if the product would actually work (or how reliably). I asked on
them just "who" was going to be purchasing this stuff - the DOS user who's
whole system cost far less than the card/drive combination, or Xenix/unix
sites. The answer was "Gee, that's a good question. We never thought of
that. I think we better start learning about this Xenix stuff." My only
thought was "these are the guys we are supposed to turn to for support"??
Scary thought.
Sorry if this turned into a rather long posting, but I ended up actually
covering many issues and problems all of us are facing. We all need to remind
the hardware people WHERE their stuff is going to be used - so that we don't
have these types of headaches in the future. I really hope that SOMEBODY out
that has the solution we so badly need. Once a workable solution is found, I
will post the happy news here. Thanks for your help!
--
cdin-1!bill || UUCP: {gatech,rutgers,cbmvax,bellcore}!bpa!cdin-1!bill
Bill Perrin ||_______________________________________________________
CompuData, Inc. ||-------------------------------------------------------
Philadelphia, Pa. || Are we having fun yet?? richard@neabbs.UUCP (RICHARD RONTELTAP) (10/16/88)
> From: bill@cdin-1.UUCP (G. William Perrin) > Has anyone managed to get Xenix up on a 338MB drive without lossing 60MB of > the drive because SCO Xenix can't handle that large a drive? Well, we didn't have any problem using the extra tracks on our NBD (Newbury Data) 14380. That is a 380 MB (unformatted) drive, used with a WD1005 ESDI controller. We just put drive type 32 in the CMOS ram (a drive with 15 heads, but less cylinders and secs/track) and installed Xenix/386 2.2.1 on the disk. During the install you get to the dkinit program. There you can specify the exact parameters of your drive. Ours looks like this: Disk Parameters Values --------------- ------ 1. Cylinders 1224 2. Heads 15 3. Write Reduce 0 4. Write Precomp 65535 5. Ecc 0 6. Control 8 7. Landing Zone 1224 8. Sectors/track 34 The drive itself can handle 36 secs/track, but I believe the controller can't. Success with your screamer box. If you can't figure it out, send me one of your 25 Mhz cached 386 computers, I will galantly try it for you... (double -:) Richard (...!mcvax!neabbs!richard)