Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cc.utah.edu!cc.usu.edu!jrd Newsgroups: comp.unix.sysv386 Subject: Re: SVR4.0 Message-ID: <1991Apr22.175643.47521@cc.usu.edu> From: jrd@cc.usu.edu Date: 22 Apr 91 17:56:43 MDT References: <9104051959.AA23768@ucbvax.Berkeley.EDU> <1991Apr6.184400.47303@cc.usu.edu> <9104182047.25@rmkhome.UUCP> Organization: Utah State University Lines: 51 In article <9104182047.25@rmkhome.UUCP>, rmk@rmkhome.UUCP (Rick Kelly) writes: > In article <1183@applix.com> scotte@applix.UUCP (Scott Evernden) writes: >>In article <9104152217.20@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes: >>>I think jrd has it bass ackwards. SVr4 doesn't like shadowed BIOS. Phoenix >>>doesn't allow you to turn off BIOS shadowing in the set-up program, while >>>AMI does. >> >>No problems here with my AMI Voyager 486/33 and its shadowed BIOS and >>SVR4. Never needed to turn shadowing off... > > There are two possibilities here: > > 1. It was hardware specific to Micronics 386/33 motherboards. > > 2. I saw this in early SVR2 sources. > > Rick Kelly rmk@rmkhome.UUCP frog!rmkhome!rmk rmk@frog.UUCP ----------------- Hmmm. Ok fellas. First I'll be happy to be all wet now and then if some progress is made simultaneously. But my observations have been many AMI machines won't survive creation of the initial Unix RAM disk from the boot floppy. But many Phoenix ROM systems will. Nothing to do with shadowing, at least not in the obvious ways because I've tried the variations. Playing with the A20 line adjustments of AMI Bios's did not help either. So, I presume there are some pretty vast differences concerning the fast ways of getting into protected mode (setting up the system as a RAM disk one) that the Intel written RAM disk software can't cope with. That's a Beware item for new buyers. Another item I mentioned was to be very cautious about the promised support for peripherals, such as disk drives, tape drives, Ethernet boards, and the like. I am tearing my hair out now over a SCSI disk problem where the same brand controller (WD 7000 FASST2) as AT&T uses is rejected by AT&T SVR4.02.1. Stealing AT&T's rendition of the board next shows Unix to reject my CDC drive (Seagate's ident of ST4766N, CDC's 94191-766). Naturally none of this is mentioned in the AT&T docs. I have some hints on all this but nothing I can mention in public. And I feel that AT&T is not necessarily unique in this regard (just what SCSI system does DELL use? Not a word in print that I've seen). My feeling is the Unix vendors are destroying their own market by hiding the true systems components requirments. The "buy Unix, now" hyperbole is a little out of hand, particularly if one wants to assemble "equivalent" pieces rather than purchasing a turnkey system at triple the real price. It's expensive and not much fun writing drivers for all and sundry peripherals so I appreciate their inability to support everything on the market. But candidness is needed somewhere in the purchasing chain. Ok, interesting comments on this might shed light on the situation. Please let off steam by direct mail to jrd@cc.usu.edu and in turn I'll not consume network bandwidth pouring out my troubles. Btw, I do appreciate the couple of people who are helping me sort out the above by offline msgs. Joe D.