"file is not executable" with Fast mem added?

[E-Penguin]

Here's a strange one... In my A500plus I have an on-socket 8mb fast ram and an A590. The firmware on the expansion has been set so as to not do autoconfig if the A590 is plugged in (because I need that to be seen first in order to load the scsi.device, etc).

I start workbench (2.0) and addmem the 8mb - everything looks fine, I can see it in "avail" and on the workbench title bar.

If I try to start any programs though (apart from avail and cli), I get an error "file is not executable".

It gets weirder. I can do lots of 'newcli' followed by 'avail' and see the fast mem is being used for these processes. So the memory is there and is usable.

I tried putting the addmem statement in startup-sequence but then workbench doesn't start, with the same "not executable" error.

I understand this is fundamentally an incompatibility between the A590 and the memory, but it seems so close!

Any ideas?

[Toni Wilen]

Most likely reason is non-DMA capable RAM board. You can try setting mask in hdtoolbox to force all transfers to/from chip ram (0xfffff) but it will make transfers 3x+ slower..

[E-Penguin]

PFS does not like that, errors about mask not matching ram type. Do I need to delete and recreate / format the partition?

You might have hit the nail on the head though - booting from floppy and running addmem, etc, from there works fine. I assume the floppy is read into chip memory by Paula.

[thomas]

The mask does not select the memory, it only allows to check it. BufMemType in the environment vector selects the memory if the mask does not match. Unfortunately you cannot set this with HDToolbox.

This is how ThoR somewhere explained how FFS does it, and PFS probably, too: the buffer address given for read or write is checked against the mask. If it fits (i.e. no bits set in the address which are not set in the mask), then the buffer is used as is. If the mask does not fit, it allocates a new buffer using BufMemType and copies the data to that for DMA.

Apparently PFS checks the newly allocated buffer against the mask again and complains if it still does not fit. FFS probably does not do this additional check and thus might run into DMA errors without notice.

[E-Penguin]

Ah, thanks. I'll throw some env at it and see if that works

[thomas]

Originally Posted by E-Penguin

I'll throw some env at it

What???

[E-Penguin]

Setenv BufMemType 2

Is what I'm currently trying. No luck so far. Might I need a mount list, bearing in mind this is the boot device?

[thomas]

What you need is a program which can poke the value into the partition table.

Everything which is stored on the partition (like env variables or mount lists) can only be read when the partition is already mounted. But when the partition is already mounted it is too late to change mount parameters.

But don't worry, there is a solution: I added this feature to my ChangeBootPri program.
http://thomas-rapp.homepage.t-online...ngebootpri.lha

[E-Penguin]

Thanks, I'll have a look at that.

My plan b is to copy the mount list to ram:, dismount dh0: then remount it with the mount list, before calling addmem then continuing with the boot. It's a bit sideways though.

[E-Penguin]

You guys are brilliant! Thanks

The magic sauce was:

changebootpri BufMemType 2

And mask set to 0x1FFFFC

[E-Penguin]

Slight weirdness remains; copying files which are larger than available chip mem gives this out-of-memory error (see attached; from a winuae setup but same hardware/software setup).

If I do "Copy BUF=200 somefile dh0:test/", or otherwise specify "BUF" to something, it works. It's only dragging & dropping that the copy fails.

The error shown only when using PFS3aio (latest) but FFS 45.16 doesn't successfully copy either.

It's as if the Copy function is attempting to allocate the temporary copy buffers in Chip but is over-allocating. The AmigaOS user manual tells me that BUF=200 is the default, so it's not clear why this is happening.

It only occurs when using the non-DMA fast mem, with bufmemtype=2 (chip).

I fear I'm flogging a dead horse of a memory expansion.

[hooverphonique]

The size of the filesystem buffers have nothing to do with the memory used when copying a file. During copy it is entirely up to the application performing the copy how much memory it uses. In your case it seems that drag n'drop tries to allocate as much memory as the filesize, which then fails - it's been too long since I tried that to remember if that's always how Workbench does it.

[E-Penguin]

The command line "copy" does use buffers. I imagine the workbench copy routine is similar, but I can't find any info on that.

https://wiki.amigaos.net/wiki/AmigaO...Reference#COPY

It's all very strange

[hooverphonique]

I misread your post, you didn't really mention filesystem buffers..

Does it work when using the CLI copy command without explicitly specifying buffer size?

Workbench doesn't use the CLI copy command afaik (nor is there a common/shared copy function in the OS), so you can't expect drag n'drop to perform the same...

For performance reasons it makes sense to use the same type of memory for copy than is specified for bufmemtype (to support dma), maybe that's why it uses a chipmem buffer when bufmemtype is set to chip.

[daxb]

Which OS and Copy version do you use? If I remember right there was a bug on an old Copy version that tries to allocate memory in the amount of file size and fails when not enough memory is available. But normally fast memory is used first.

[E-Penguin]

Wb2.1 - it does look like a problem with trying to allocate the whole file in memory. Smaller files are OK.