mike@atc.SP.Unisys.COM (Mike Grenier) (11/10/90)
From article <1990Nov7.051419.19612@karnak.cactus.org>, by john@karnak.cactus.org (John B. Meaders Jr.): > In article <1990Nov6.002853.582@medtron.medtronic.com> dt4100c@medtron.medtronic.com (Derek Terveer) writes: >> >>I have never been able to get rll controllers to work reliably with either rev c >>or rev d of esix. > > I have one running under Rev D (2 floppy, 2 disks Western Digital plain jane > 16 bit type). My AMI 386 BIOS does let me define my own drive type though > so I can set it to ST-251 with 26 sectors instead of 17 sectors. > -- Yes, but can you get it to work with the Fast File System? I also have the Western Digital plain jane (WD1003-SR2) with my AMI bios but ESIX consistantly panics in the routine echd_read_vtoc() when booting the box after the tenth distribution floppy. My disk is somewhat bigger than yours, .i.e 250 meg. The S51K file system works fine. Of course, my Adaptec 2372 disk controller wasn't supported at all with panics in the hdintr() routine. This forced me to buy the slower WD card only to find out that the fast file system didn't work. The WD1006-SR2 can also panic when accessing the raw drive : .i.e use 2 drives and do a mkpart -v on the second one while compiling something big on the first. Using /etc/crash, it appeared that the user space wwas not locked in memory causing a page fault in hdintr(). But that's not so bad. The Furture Domain scsi card just gave me errors something like "HA 1 has no TAs" when connecting to the Wren Drive under ESIX...more money down the drain The Adaptec driver does bad things when using multiple SCSI drives. In particular, if a bad block occurs on the second drive, ESIX will attempt to reread the block on the first drive...this can be really bad. (We ended up using a SCSI analyzer to track that one down :-) The Scsi Device Interface (SDI) also doesn't seem to work correctly with examples taken right out fo the AT&T manual failing the SDI_SEND ioctl. This only describes the problems I've had with the hard disk drivers. As you can tell, I wouldn't recommend ESIX to my cat let alone a UNIX user. So far, I've swapped in my printer driver and the FAS serial driver and am using the ST01 scsi controller for the Wren drives. One thing I can say for Microport, my old UNIX System V/386 Release 3.0e was rock solid on the same hardware. You can guess which vendor will be supplying our UNIX V.4 -Mike Grenier mike@cimcor.mn.org mike@sp.unisys.com
pcg@cs.aber.ac.uk (Piercarlo Grandi) (11/12/90)
On 9 Nov 90 21:38:27 GMT, mike@atc.SP.Unisys.COM (Mike Grenier) said: mike> I also have the Western Digital plain jane (WD1003-SR2) with my mike> AMI bios but ESIX consistantly panics in the routine mike> echd_read_vtoc() when booting the box after the tenth distribution mike> floppy. My disk is somewhat bigger than yours, .i.e 250 meg. The mike> S51K file system works fine. This does not make much sense really. the vtoc reading routine is in the driver, not in the filesystem. As far as things are supposed to be, the WD and Adaptec RLL controllers and the WD MFM controller are absolutely identical as far as the kernel is concerned. I think it would take some deliberation to actually write code that could discerne among them (except for the trivial issue of the # of sectors per track). Your problems seem to be hardware related. mike> Of course, my Adaptec 2372 disk controller wasn't supported at all mike> with panics in the hdintr() routine. This may well be hardware related as well. My own machine has to stay turned on for half an hour before booting to warm up the controller and the drive, otherwise horrible things will happen. mike> The WD1006-SR2 can also panic when accessing the raw drive : .i.e mike> use 2 drives and do a mkpart -v on the second one while compiling mike> something big on the first. This instead looks like an authentic bug, caused by not anticipating the idea that a user may want to format disks while in multiuser mode. mike> One thing I can say for Microport, my old UNIX System V/386 mike> Release 3.0e was rock solid on the same hardware. You can guess mike> which vendor will be supplying our UNIX V.4 But 3.0 (without the e) was quite buggy instead. Do not expect consistency in these matters. Also, have a look at Dell's (or Intel's) SVR4. If I understand correctly you can use your ESIX rev. D to get a substantial discount on SVR4. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
mschedlb@hawk.ulowell.edu (Martin J. Schedlbauer) (11/12/90)
In article <1990Nov9.213827.1059@atc.SP.Unisys.COM> mike@atc.SP.Unisys.COM (Mike Grenier) writes: >From article <1990Nov7.051419.19612@karnak.cactus.org>, by john@karnak.cactus.org (John B. Meaders Jr.): >> In article <1990Nov6.002853.582@medtron.medtronic.com> dt4100c@medtron.medtronic.com (Derek Terveer) writes: >>> >>>I have never been able to get rll controllers to work reliably with either rev c >>>or rev d of esix. >> >> I have one running under Rev D (2 floppy, 2 disks Western Digital plain jane >> 16 bit type). My AMI 386 BIOS does let me define my own drive type though >> so I can set it to ST-251 with 26 sectors instead of 17 sectors. >> -- > >Yes, but can you get it to work with the Fast File System? >I also have the Western Digital plain jane (WD1003-SR2) with my AMI >bios but ESIX consistantly panics in the routine echd_read_vtoc() when >booting the box after the tenth distribution floppy. My disk is somewhat >bigger than yours, .i.e 250 meg. The S51K file system works fine. > I have a similar problem with an UltraStore 12F (supported by Esix) and a ESDI drive. After booting the foundations set (first 20 disks) I get errors like: Missing BKI segment or NOT 80386 COFF FORMAT for /unix. This happens for the FFS, but I haven't tried it with the S51K file system as I didn;t think that would help. But now that you mention it. ...Martin Martin J. Schedlbauer Graphics Research Laboratory, Department of Computer Science, WL 118 University of Lowell Lowell, MA 01854 (USA) (508) 934-3612 Martin J. Schedlbauer Graphics Research Laboratory, Department of Computer Science, WL 118 University of Lowell Lowell, MA 01854 (USA) (508) 934-3612
conklin@frith.uucp (Terry Conklin) (11/13/90)
I have run my ESIX system on an RLL controller (DTK) with a 65-meg Micropolis drive (just big enough to hold the O.S. ;-)) It's in constant use with currently around 4-5 users. I have the entire drive formatted FFS. The performance I get out of this setup is outstanding. With just a stupid 386/20 and the 65M drive, all 5 users see instant response. Fgrepping /etc or /bin is that fast. I'm exceedingly pleased with it and the combined load of C development, nethackers and X-windows keeps it earning it's keep. I go on site every day to an Interactive machine, a 386/33 cached with an 18-mil 100Meg drive. While it's Norton SI (weak, granted) is DOUBLE my 20-mhz machine's, and it's drive twice as fast, and there's only 1 user, it's barely as fast, and in some cases much slower. As far as my use has seen, Interactive's fast file system is an oxymoron. ESIX rev D has really sped things up a LOT. I am not so excited about the opportunities that lay ahead when I switch to a Adaptec 1542B w/750M Micropolis drives (especially since I want them running sync mode) but who knows. I can hope. Terry Conklin conklin@egr.msu.edu uunet!frith!conklin The Club 517-372-3131 2400 Mnp5
mike@cimcor.mn.org (Michael Grenier) (11/13/90)
From article <PCG.90Nov11203147@odin.cs.aber.ac.uk>, by pcg@cs.aber.ac.uk (Piercarlo Grandi): > > On 9 Nov 90 21:38:27 GMT, mike@atc.SP.Unisys.COM (Mike Grenier) said: > > mike> I also have the Western Digital plain jane (WD1003-SR2) with my > mike> AMI bios but ESIX consistantly panics in the routine > mike> echd_read_vtoc() when booting the box after the tenth distribution > mike> floppy. My disk is somewhat bigger than yours, .i.e 250 meg. The > mike> S51K file system works fine. > > This does not make much sense really. the vtoc reading routine is in the (good argument why it should be a hardware/driver problem) > > Your problems seem to be hardware related. I agree with your logic but sometimes life isn't logical...at least when ESIX is concerned. I couldn't believe it either so I repeated the test multiple times. Why should the S51K file system work fine but the FFS one fail. Why should RLL work great under Microport V/386 and V/AT and of course DOS if there is a hardware error. ESIX with the S51K file system has been fine on this box. .... another note.... When installing ESIX and you have a big non-scsi drive, you must set partitions evenly if you are going to use FFS. It seems that the Fast File System will go right ahead and create a file system with more than 64K inodes. This is bad in System V which uses an unsigned short to hold the inode number in the kernel and will cause the kernel to panic when mounting the file system. Scsi installation checks for the above condition. ESIX technical support admits to the problem. > > mike> Of course, my Adaptec 2372 disk controller wasn't supported at all > mike> with panics in the hdintr() routine. > > This may well be hardware related as well. Bah...humbug. This controller worked great on 3 different operating systems. We also tried multiple motherboards and other hardware. ESIX has problems here but I guess we shouldn't complain since this card is not on the certified list..unlike the WD8003-SR2. > mike> One thing I can say for Microport, my old UNIX System V/386 > mike> Release 3.0e was rock solid on the same hardware. You can guess > mike> which vendor will be supplying our UNIX V.4 > > But 3.0 (without the e) was quite buggy instead. Do not expect > consistency in these matters. Also, have a look at Dell's (or Intel's) > SVR4. If I understand correctly you can use your ESIX rev. D to get a > substantial discount on SVR4. Yea but Intel won't support 1024x768 graphics at all. Microport gives me a 40% off on my old system. I don't know about Dell. -Mike Grenier mike@cimcor.mn.org mike@sp.unisys.com
larry@nstar.uucp (Larry Snyder) (11/14/90)
mike@cimcor.mn.org (Michael Grenier) writes: >Yea but Intel won't support 1024x768 graphics at all. Microport gives >me a 40% off on my old system. I don't know about Dell. Don't let the 40% off fool you - take a look at the bottom line with all the options available to you. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, {uunet|backbone}!nstar!larry, larry%nstar@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
jde@everex.uucp (-Jeff Ellis()) (11/20/90)
In article <1990Nov13.142439.155@cimcor.mn.org> mike@cimcor.mn.org (Michael Grenier) writes: >When installing ESIX and you have a big non-scsi drive, you must set >partitions evenly if you are going to use FFS. It seems that the >Fast File System will go right ahead and create a file system with more >than 64K inodes. This is bad in System V which uses an unsigned short >to hold the inode number in the kernel and will cause the kernel >to panic when mounting the file system. Scsi installation checks for the >above condition. ESIX technical support admits to the problem. I have talked with the Guy that did the work on the newfs commandand we looked at the source code. In ESIX Rev D beta we had a problem when using large SCSI drives, newfs (called by mkfs) could make FFS file systems that had more 64k inodes and panic the system. But it was fixed before it went into production and the newfs command checks for that condition and keeps it less than 64k. This works for all type of drives, not just SCSI. -- Jeff Ellis ESIX SYSTEM/V UUCP:uunet!zardoz!everex!jde US Mail: 1923 St. Andrew Place, Santa Ana, CA 92705