SVR4.0

jrd at cc.usu.edu jrd at cc.usu.edu
Tue Apr 23 09:56:43 AEST 1991


In article <9104182047.25 at rmkhome.UUCP>, rmk at rmkhome.UUCP (Rick Kelly) writes:
> In article <1183 at applix.com> scotte at applix.UUCP (Scott Evernden) writes:
>>In article <9104152217.20 at rmkhome.UUCP> rmk at 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 at rmkhome.UUCP	frog!rmkhome!rmk	rmk at 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 at 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.



More information about the Comp.unix.sysv386 mailing list