Conference hydra::amiga_v1

>	mountlist defined 4 surfaces, cyls 0 - 611, reserved 2, etc
						^
	i used 0-614

>	Disk was partitioned as:
>			RES0:	2 cyls
>			DH0:	5meg, old filesystem (as if I had a choice)
>			DH0B:	10meg, ffs
>			DH0C:	5meg ffs

	why so much for the OFS? i boot from the ST-225, so i gave it
	3 cylinders (2-4) to hold enough to transfer control to a FFS
	i have another (RD53) and only gave it 1 cyl and don't use it
	for anything
	since this is a 2090, 1 cyl should be plenty, since you will
	boot from the floppy & transfer control (maybe)

	i had problems with the resistor on the motherboard, but this
	was always read/write problems, disk validator stuff, i don't
	recall ever hanging (maybe lucky)

	here is my mountlist for the ST225 (PREPed to cyl 4)
================================================================================
/* Sample Mountlist Entry to add another partition to a ST-506 drive */

/* FASTfilesystem; 2nd partition on ST225 , named HD0 */
HD0:     Device = hddisk.device
           FileSystem = l:FastFileSystem
           Unit   = 1
           Flags  = 0
           Surfaces  = 4
           BlocksPerTrack = 17
           Reserved = 2
           Interleave = 0
           LowCyl = 5 ; HighCyl = 614
           Buffers = 30
           GlobVec = 1
           Stacksize = 4000
           BufMemType = 4
           DosType = 0x444F5301
           MaxTransfer = 0x77abcdef
           Mount = 1
#

RES0:      Device = hddisk.device
           Unit   = 1
           Flags  = 0
           Surfaces  = 4
           BlocksPerTrack = 17
           Reserved = 2
           Interleave = 0
           LowCyl = 0  ;  HighCyl = 1
           Buffers = 20
           BufMemType = 0
#

	mark

    Hmmm ... didn't know you could mix filesystems like that. Why isn't
    RES0: your OFS for booting? 
    
    And, are those device names legal? I ask because GVP (for example)
    requires that DH0:, DH10:, and DH11: be used for the hard drive
    partitions.

   <<< Note 4005.2 by DICKNS::MACDONALD "VAXELN - Realtime Software Pubs" >>>

>    Hmmm ... didn't know you could mix filesystems like that. Why isn't
>    RES0: your OFS for booting? 
    
    YES, RES0 is used to boot, RES1 that i didn't show is just a 1 cyl
    (PREPed to cyl 2), well OK 3 altogether is you count the 2 reserved
    ones. RES0 only contains enough stuff to transfer control to my FFS
    partition (the rest of the disk). I don't see any need to have more
    than 1 partition (not counting the OFS one), cus i just use drawers 
    to divide it all up.

	results from INFO
	DH0:	96K (OFS)
	DH1:	63K (OFS)
	HD0:	20M (FFS)
	HD1:	69M (FFS)

>    And, are those device names legal? I ask because GVP (for example)
>    requires that DH0:, DH10:, and DH11: be used for the hard drive
>    partitions.

	Well, they seem to be legal for a 2090A, no problems so far.

	mark

    re .2
    
    	GVP doesn't require DH0: ... ect. for disk names. Their
    configuration program sets them up this way but if you SCSI format,
    and prep the GVP drive by hand you can rename the devices.
    
    
    		Steve
    

    Re: why I had cyls 0 - 611
    
    That was the example given in the 2090 manual (20 st506). I had
    heard that the RD31 actually went to 614, but I thought better safe
    than sorry since I had no documentation myself. Since I assume you
    have been running for a long time (or have filled up the drive at
    some point), I'll change it.
    
    Re: Why a large OFS
    
    Well - if you look you'll see that my problem is "hanging" when
    using the FFS partitions. If I can't change this the whole drive
    is going to become old file system - I can't live with the hanging.
    
    
    
    In the sample mountlist given in previous replies I saw a line
    referencing MaxTransfer -- I have never seen this before. Should
    I be specifying it and can it possible solve my problem?
	    
    Does anyone have info addressing my actual problem? Has anyone else
    seen it? Could it be due to FFS and old kickstart? Could it be a
    bad drive? Could it have something to due with using the non-DH0
    partition? Is the hddisk only used for DH0:?
    
    
    			Still stumbling -

    Update:
    
    I increased the last cyl # to 614, added a mountlist line for
    MaxTransfer, and change the GlobalVec from -1 to 1. I also made
    Dh0: 2 cyls long and created a DH0A in the FFS format.
    
    The result was that the disk was able to format completely; but
    the system still would hang occasionally. BUT - it would hang at
    reproducible situations. After investigating; it seems that the
    hangs would occur when available FastRAM went real low (this is
    a 1 meg 2000, so it was easy to cause). BTW - the mountlist entries
    use BufMemType of 4 (FastRAM).
        
    So it appears to be a memory resource problem.
    
    Question: If the BufMemTypes were changed to 0, how does AmigaDOS
    determine which to use? Does this memory "allocation" change during
    system use, or is it "fixed" once chosen?
    
    Also -- is that initial whapping noise in the RD31 normal?
    
    
    Thanks - Keith
    

Re: .6

>    Question: If the BufMemTypes were changed to 0, how does AmigaDOS
>    determine which to use? Does this memory "allocation" change during
>    system use, or is it "fixed" once chosen?

The BufMemType value is just the second argument to AllocMem (or whatever
the Exec memory allocation routine is named: my mind is going).  Thus, if
the argument is zero, non-public fast memory will try to be allocated.  If
that fails, non-public chip memory will be allocated.

However, for whatever its bearing on your problem, I believe that the
memory allocation for a device happens when the device or partition
is accessed the first time.  It then remains constant until you do an
AddBuffers CLI command, which causes more buffers to be allocated.

If your problem looks like an out-of-memory problem, then could the
real problem be something else?  Are you running any background tasks?

Sorry, been on vacation for a couple of days...

MaxTransfer was a value for a patch pgm that tried to correct the race
condition in the 2090 when displaying a hi-res overscanned picture and
accessing the drive.

Glad you finally got a handle on it, these things can be frustrating
as hell.

 mark

RE:   <<< Note 4005.6 by MSVAX::BARRETT "This is your brain on Unix; any ??" >>>
    
A late comment...

>    The result was that the disk was able to format completely; but
>    the system still would hang occasionally. BUT - it would hang at
>    reproducible situations. After investigating; it seems that the
>    hangs would occur when available FastRAM went real low (this is
>    a 1 meg 2000, so it was easy to cause). BTW - the mountlist entries
>    use BufMemType of 4 (FastRAM).
        
>    So it appears to be a memory resource problem.
    
If you have a 1MB A2000, then you have no Fast RAM. It is all Chip RAM, so your
BufMemType = 4 could be causing you problems. I found I was losing a lot of
memory by having 30 buffers on each partition (I have a 2090A, RD52), so I
reduced the number of buffers to 17 on my 10MB partition, and 20 on my 24MB
partition, and haven't noticed a performance hit. But I still have over 600K
free when I boot up with SNAP, DMOUSE and VIRUSX running.

More memory is definitely required though, as I've still had the system complain
(falsely) of disk corruption, and then GURU when running GIF2IFF on a big GIF
file. My assumption is that the controller couldn't find enough memory to do a
DMA transfer, and interpreted that as corruption.

Lindsay

    It was a .5 meg system, but I figured it was having this problem
    anyway.
    
    The system hangs still occur; but usually when doing something pretty
    heavy or large in memory size. Did anyone use a 2090 w/ ST506 on
    a 1meg old agnus setup?

I have GIF2IFF guru on my A500, normally on the 2nd or 3rd gif file.

Mike

    Well, I discovered the cause behind the disk hangs -- one of the
    disk partitions was configured as 6 heads instead of 4. The drive
    would "crash" when a conflict in disk access was reached.

    
    End of mystery.