kunkee@ficc.uu.net (randy kunkee XNX MGR #) (11/23/88)
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