WARNING: Bug (?) in TurboDOS

WARNING: Bug (?) in TurboDOS

Post by G.Onuf » Mon, 02 Apr 1990 06:59:00



Well, as much as I love the performance of TurboDOS, I will not use it
until one matter is straightened out.  I just added the original Tandem
drive from my SH204 to the Micropolis drive I had replaced it with.  Now
both are merrily storing all the data I give to them off of the SH204
controller board.  So I thought I would do some timings of TurboDOS/non-Turbo-
DOS.  I copied the TeX sources from SCSI-1/LUN0/PARTf to SCSI-1/LUN1/PARTc
(actually f: to g:) and timed em.  Took 2:34 sec with Beckemeyer's HD accel,
took 2:06 sec with TurboDOS.  Except fsck tells me it's okay the long way and
that there is a free clustor smack in the middle of a file the fast way.
(oh...those should be MINUTES times, not seconds :-)

So, is this a problem with having two drives on one controller?  Depending
on how much TurboDOS assumes about the hardware configuration, it may s*
the LUN number in its caching.  Time to actually go through the code and
start replacing addresses with labels and adding comments.......Ughhh.

Also, I would not recommend using any disk repair utilities that directly
access the drives while using Turbodos.  May really*things up if and when
Turbodos flushes its buffers.

Allen:  Any way to force a program such as TurboDOS to flush it's buffers?
Write a desk acc to do it?   (Add symbolic links to the next TOS!!)

G. Onufer

 
 
 

WARNING: Bug (?) in TurboDOS

Post by Ed Bee » Mon, 02 Apr 1990 06:56:00



>Well, as much as I love the performance of TurboDOS, I will not use it
>until one matter is straightened out.  I just added the original Tandem
>drive from my SH204 to the Micropolis drive I had replaced it with.  Now
>both are merrily storing all the data I give to them off of the SH204
>controller board.  So I thought I would do some timings of TurboDOS/non-Turbo-
>DOS.  I copied the TeX sources from SCSI-1/LUN0/PARTf to SCSI-1/LUN1/PARTc
>(actually f: to g:) and timed em.  Took 2:34 sec with Beckemeyer's HD accel,
>took 2:06 sec with TurboDOS.  Except fsck tells me it's okay the long way and
>that there is a free clustor smack in the middle of a file the fast way.
>(oh...those should be MINUTES times, not seconds :-)

>So, is this a problem with having two drives on one controller?  Depending
>on how much TurboDOS assumes about the hardware configuration, it may s*
>the LUN number in its caching.  Time to actually go through the code and
>start replacing addresses with labels and adding comments.......Ughhh.

>Also, I would not recommend using any disk repair utilities that directly
>access the drives while using Turbodos.  May really*things up if and when
>Turbodos flushes its buffers.

>Allen:  Any way to force a program such as TurboDOS to flush it's buffers?
>Write a desk acc to do it?   (Add symbolic links to the next TOS!!)

>G. Onufer

I am a little suspicious of fsck and its companion optimizer.  I had a hard
disk partion that fsck and chkdsk ( using pc-ditto ) both liked.   I used the
optimizer after which: fsck was still happy.  all my files were still
accessable from gem.  pc-ditto could no longer see several of my directories.
chkdsk attempted to repair the disk and appeared to be success full.  fsck was
no longer happy and i had about 2 meg of file which took up space but were
invisable from gem.  I zapped the partion, restored all the files and haven't
had any problems since.

UUCP: {cbosgd hplabs!hp-sdd sdcsvax nosc}!crash!pnet01!sreeb



 
 
 

WARNING: Bug (?) in TurboDOS

Post by G.Onuf » Mon, 02 Apr 1990 10:29:00




>>Well, as much as I love the performance of TurboDOS, I will not use it

> I am a little suspicious of fsck and its companion optimizer.  I had a hard
> disk partion that fsck and chkdsk ( using pc-ditto ) both liked.   I used the

I also used DLII to check the partition.  It didn't like what happened
too much either.....

DO NOT USE TurboDOS, Public Domain or not.  It may not work with
any strange hardware configurations (such as two drives on one
controller).

G. Onufer

 
 
 

WARNING: Bug (?) in TurboDOS

Post by Thomas Wo » Mon, 02 Apr 1990 19:38:00


Am I the exception or something?  I've been using TurboDos for over a
week now and never had any trouble.  Of course, my system isn't configured
in an "*" fashion; just a plain 1040ST with Supra 20Meg.  I don't
use any other caching program while TurboDos is loaded, because of the
warnings against that.  Also, whenever I power the system up, I
automatically enter GULAM (using GEMSTART in the AUTO folder), AND before
powering down, I exit GULAM -- this, I imagine will close all remaining
open files and flush buffers that TurboDos keeps.

Anyway, I just thought I'd proclaim that there ARE folks who've not yet
been disappointed by TurboDos.

Tom Wolf

Tom Wolf


 
 
 

1. TurboDos Bug

GASP! The most insidious bug in TurboDos just turned up :-(. It causes
ST Hack to bomb when changing levels. 2 bombs show immediately which
then turn into 4 bombs and then complete lockup of the system. Only
a reset clears up the problem. Removing TurboDos from the AUTO folder
and replacing it with ACACHE which I have been running for some time,
seems to give as much of a 'speed up' as TurboDos and doesn't "crash"
ST Hack ;-). Also doesn't eat up much memory either.
So, be warned, TurboDos may not work with some software. I am going
to stick with ACACHE.

2. Haitian Phone System

3. TurboDos suspected bug

4. Apple II Display Quality

5. atan2() in gawk - bug warning

6. Repairing Inbox

7. WARNING! Bug in Gulam v1.03

8. Dani drivers and CDROM digital transfer

9. Fix bugs to fix bugs, or to Fix Bugs?

10. Antic & Analog Type-Ins?

11. malloc bugs (s.b. Malloc bugs)

12. Fcreate bug...also Re: Bugs in MWC?

13. GEM bug? (was: Re: Tos 1.4 bug?)