Problems with 380MB 5&1/4" disks as system drives
randy kunkee XNX MGR #
kunkee at ficc.uu.net
Wed Nov 23 05:53:59 AEST 1988
Has anybody else seen the following or have any comments?
We are using Intel provided equipment: 310 systems with/without 311
expansion chassis, and 320s. Some of our 310 systems have been
upgraded to 386 (however, our current version of Intel Xenix is R3.5
and runs the 386 in 286 mode; the only advantage is the higher clock
speed and some caching the 386 does). They all run Intel Xenix R3.5,
update 1 or 2.
About a year ago storage requirements pushed us into using 380MB
5&1/4" drives (we use Priam 638, Maxtor 4380E, and are going to start
using Miniscribe becase they are cheaper than the Maxtor and Priam
(any experience on the Miniscribe?)). (By the way, good ol' Maxtor
has two kinds of 4380Es floating around -- one will handle 19 1024
byte sectors while the other will only do 18 -- fun huh?) We went to
SMS 8009 controllers which are (almost) 214 look-alikes, so we didn't
have to change drivers -- just reconfigure the disk parameters and we
were off.
We have been having problems ever since we starting using 380MB drives
as system disks. In almost every case, we started getting "panic: IO
err in swap" after the system got busy. As near as I can put it
together, the problem only occurs with the higher speed Intel 386/2x
and 386/3x CPU boards where x=2 or 4 (ie. 2 or 4MB of on-board
memory).
However, since all of our 286 machines have a minimum of 5MB memory,
it seems that the problems really were brought about when we starting
putting in 386/24 CPU boards, with 1MB less of memory. When I started
configuring SMS 8009 controllers to control a 380MB drive as a system
disk drive, combined with a 386CPU, it's crash city.
We have reduced the problem by adding more memory to the systems, but
this is expensive and doesn't really solve the problem. Even 386/28
CPU-based systems eventually crash with the same panic message, in spite
of their 8MB of on-board memory.
Further investigation has revealed (by using SDM to break when the
panic routine is called) that the crash always occurs when trying to
read 512 bytes(!) from the swap area. Now, all of our disks are
jumperred/switched/formatted to 1024 bytes/sector. Why the heck is
Xenix doing a 512 byte read? In the 215g manuals (an old controller I
think Intel no longer makes) a partial sector read is documented. On
the 221 controller (Intel's ESDI controller that's compatable with the
215 and 214 drivers) there is no mention of partial reads or what they
do. If I take a 221-based system and do the following:
dd if=/dev/rw0 of=/dev/null bs=512
the system hangs in an instant, and the controller has apparently gone
into an error state (green led goes off, red led comes on -- who knows
what the red led means? -- I'll be calling Intel). Examination of the
CCB at this point indicates 'busy', and there is no completion status
in the CIB.
To summarize: the SMS 8009 causes the system to panic. The Intel 221
is more likely just to hang. Also, I have associated this with ESDI.
Using the ST506 interface of the SMS8009 seems to work a little
better, but we still get crashes.
A further tidbit is that the same dd command done on a 214 controller
based system will work, but the association of the dd is lost from
the terminal, requiring a ps -p to hunt it down and print it. When
ps prints it, the STIME has also been lost. Cute, huh? Something
tells me when they went to 1024 byte sectors, they (MicroSoft, Intel)
didn't do it right for swapping. Or maybe there are general swapping
problems that lurk in the system.
Clues? Knowledge? Fact? Fancy? Intel?
--
Randy Kunkee
Ferranti International Controls Corporation
12808 W. Airport Blvd. Sugar Land, TX 77478
UUCP: uunet!ficc!kunkee ph: (713) 274-5132
More information about the Comp.unix.xenix
mailing list