Xref:	news-dnh.mv.net comp.os.msdos.djgpp:1089
Path:	news-dnh.mv.net!mv!news.sprintlink.net!bga.com!news
From:	gauthier AT bga DOT com (Mike Gauthier)
Newsgroups:	comp.os.msdos.djgpp
Subject:	MEMMAKER PROBLEMS!
Date:	23 Jul 1995 06:35:18 GMT
Organization:	Real/Time Communications - Bob Gustwick and Associates
Lines:	66
Nntp-Posting-Host:	edwin-b5.ip.realtime.net
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway:	from newsgroup comp.os.msdos.djgpp

There is a serious problem with MEMMAKER on my system. The
system was just upgraded to a Microid Research BIOS that
supports LBA mode. Now the MEMMAKER.STS file keeps getting
corrupted when MEMMAKER is run (orphaned clusters). To
retry, I delete the .UMB files and the MEMMAKER.STS file. I
then use chkdsk with the /f option to clean up the disk and
re-run MEMMAKER. It corrupts the newly created MEMMAKER.STS
file every time.

My workaround is to turn off the write behind cache option
for drive C: in SMARTDRV. With that off, MEMMAKER works fine.
When MEMMAKER finishes, I turn the write-behind cache back
on again. This looks to me like a conflict between MEMMAKER,
SMARTDRV (with the write_behind cache turned on) and the new
BIOS.

I did not have this problem with the 1992 AMI BIOS that came
with the system originally. It seems like the new MR BIOS is
causing this problem, but I don't know that for sure. It
certainly could be a problem with MEMMAKER or SMARTDRV that
MR BIOS just highlights.

The system configuration is:
        -    Intel 486DX2/66 CPU
        -    16MB Memory
        -    DOS 6.22
        -    SMARTDRV 5.01
        -    MR BIOS V1.66 Copyright 1994
        -    BIOS ID SIS_400 9/13/94
        -    Chipset SiS 85C461C

Below is an excerpt from Microsoft describing when the cache
gets flushed to disk:

---------------------------------------------------------------------
Write-behind data stays in the cache until one of the following
occurs:

1.   The cache fills up. The oldest block in the cache is
     freed up, and if it is write-behind data, physically written
     to the disk.
  
2.   The system goes idle. SMARTDrive writes the oldest
     write behind data block to the physical disk. As long as the
     system is idle, SMARTDrive continues to write to the disk
     until all the write-behind data is written. This writebehind
     data also comes from Windows-based and MS-DOS-based
     applications that are idle.

3.   SMARTDrive detects that you have pressed CTRL+ALT+DEL.
     When you restart by pressing CTRL+ALT+DEL, SMARTDrive writes
     all write-behind data to the physical disk. This is a
     synchronous operation-- SMARTDrive does not give up control
     until all data is written.

4.   A block is older than five seconds. If a block is older
     than five seconds, it is written to the physical disk."
---------------------------------------------------------------------

Has anyone else seen this problem? Is it the MR BIOS? Is
there a solution short of giving back the MR BIOS an looking
for another BIOS upgrade or living with this problem? Does anyone
know about the general quality of MR BIOS?

Thanks in advance for any insight someone may provide.

- Raw text -