[comp.sys.ibm.pc] watch out for install program in LIm EMM 4.0

evan@ndcheg.UUCP (Evan Bauman) (11/08/87)

Today I received a disk from Intel with the newest EMS drivers, version
4.0 .  The package contained mostly sales literature, a disk, and a 
short manual for the upgrade/installation.

Page 1 of the manual indicates that although I can do the installation
myself, I can also use the supplied INSTALL program.  Now I'm
perfectly capable of doing at, but since I saw no reason to re-invent
the wheel, I fired up the INSTALL program.

It asked me a few questions about the type of PC I was using (an XT-clone),
whether I wanted to configure a RAM disk (yes), and a print spooler (no).
It then asked me the letter for the drive that contained the system (C).

It then went about configuring the new software.  After a few seconds, I
got an error message indicating that it was unable to proceed.  It then
gave the option of continuing or halting.  I halted the program and tried
it again, this time at the standard 4.77MHz clock speed.  This didn't
work either.

Then I tried to quit the program but the PC crashed.  Then it wouldn't re-
boot.  I booted from a floppy and then tried to run some software from
the hard disk but kept getting 'bad file allocation table' messages.
Low-level panic set in.  I tried running chkdsk, but was unable to
fix the problem.  In the end, I had to re-format the disk and
re-install all my software and documents from a 2 month-old backup.

So beware of this INSTALL program.  When you get the upgrade disk,
do the installation manually; it doesn't look that difficult.

	Evan Bauman
	Univ. of Notre Dame
	..!iuvax!ndcheg!evan

schwalbe@encore.UUCP (11/10/87)

Be forewarned, DO NOT do anything which writes to the hard drive when you
are in turbo mode on your PC clone.  Most of the time it will work with no
trouble. Twice in the last year I had the same problem you did. After
doing something which wrote to the hard disk when I was in turbo mode, I
got an error message, BAD FAT!  The first time it happened, I did what you
did, I reformatted the disk since I didn't have much on it and just
shrugged my shoulders.  The second time it happened, I went in and
explored the FAT with Norton Advanced Utilities (has a nice FAT editor).
My first thought was that I had fallen victim to a "Trojan" but more
careful thought revealed the real problem.  About half a sector of the FAT
had all its data shifted one up?  I looked at what the extra inserted byte
was and sure enough it was the same as the first shifted byte.  Aparently
one of the bytes written to the disk had been double clocked.  Anyway,
after about an hour I fixed the problem by shifting everything back.  The
lesson I learned is not to write to the hard disk in turbo mode.
Curiously, I went back and looked in the manual that came with my clone
and sure enough, they state that programs like diskcopy, copyiipc, and a
few others won't work properly in turbo mode.  My bet is that the timing
to the disk controller doesn't make worst case at 8 MHz so spurious errors
can occur.  Have any other clone users seen this problem in turbo mode?
I'll bet it's a generic problem although it could be the type of hard disk
controller we're using (mine is a Microtek).

.---------------------------------------------------------------------------.
: Jim Schwalbe               .----------------. Mail: {linus,allegra,ihnp4} :
: Hardware Research Group .--+-------------.  |       !encore!schwalbe      :
: Encore Computer Corp.   |  | E N C O R E |  |                             :
: 257 Cedar Hill Street   |  `-------------+--' Phone: [617] 460-0500       :
: Marlborough, MA  01752  `----------------'                                :
`---------------------------------------------------------------------------'

acm@bu-cs.BU.EDU (ACM) (11/18/87)

In article <2174@encore.UUCP> schwalbe@encore.UUCP (Jim Schwalbe) writes:
>Be forewarned, DO NOT do anything which writes to the hard drive when you
>are in turbo mode on your PC clone.

Woah!  This is *not* the case for most clones!  While this may be the
case for many clones, I wouldn't go tell all clone owners "don't use
your hard drive while in turbo mode."  Of all of them I've used, none
had trouble with the hard drive.

Many clones *do* have problems with the floppy drive while in turbo
mode, however.  There are some subtle timing problems that
occasionally cause the PC to lock up and you have to do a physical
on/off to reset it.  The clone that used to be put out by PC Network
is a prime example of a clone that exhibits this trait.

[description of his problem follows -- apparently a doubly written
byte]

>Curiously, I went back and looked in the manual that came with my clone
>and sure enough, they state that programs like diskcopy, copyiipc, and a
>few others won't work properly in turbo mode.  My bet is that the timing
>to the disk controller doesn't make worst case at 8 MHz so spurious errors
>can occur.  Have any other clone users seen this problem in turbo mode?
>I'll bet it's a generic problem although it could be the type of hard disk
>controller we're using (mine is a Microtek).

Wow.  Which clone do you have?  I've never seen one that actually
documents problems with the hard drive in turbo mode and I would like
to know more about it; what type of controller, PC, drive (you say
Microtek but which?) etc.

Thanx for any info.

jim frost
madd@bucsb.bu.edu

wtm@neoucom.UUCP (11/21/87)

<<Stuff about hard disk, maybe EMS 4.0 install bug>>


I just got my copy of EMS 4.0 and the developer docs this
Wednesday.  Gritting my teeth after seeing the Usenet articles, I
let it do its thing.  I had no problems with an AT&T 6300 outfitted
with a NEC V30 running at 8 MHz.  The drive is an ST-238 and OMTI
5527 RLL controller.  It seems like if anything is going to go
wrong this collection of hardware out to make the problem show up.

I set up the option of bypassing the extended memory test procedure
after warmboots.  Works well.  I really appreciate that, because 2
megs of RAM takes a while to check, even at 8 MHz.

I don't think I'd be too worried, if your hardware operates
resonalby stably with the normal DOS envrionment.


Bill
(wtm@neoucom.UUCP)