Long descriptor page table support

Setting a 2GB ram disc in Predesk looks to be the cause.

Yeah, that triggers it – thanks.

Doing that also revealed a SATA data corruption bug that’s been lurking for the past few years. Oops! https://gitlab.riscosopen.org/RiscOS/Sources/FileSys/ADFS/ADFS4/-/merge_requests/1 (However, the only reason it’s been hidden for so long is that it’s unlikely to be triggered on regular ROMs)

Now that that’s out the way, I can start looking at the ELF issue (which looks like an issue with the way ARMEABISupport identifies the active application slot – it’s using OS_Memory 0 to get the physical address of the start of application space, so will fail if the physical address is larger than 32 bits)

Another consequence of setting a 2GB ram disc is sequential disc access is much slower. At least according to RISCOSMark5.

HD Read - Block load 8MB file                             206788    6934%
HD Write - Block save 8MB file                            182928    6015%

HD Read - Block load 8MB file                              19200     643%
HD Write - Block save 8MB file                             21748     715%

Yeah, the problem with the IGEPv5 is that only the CPU can access the RAM which is above the 4GB physical barrier. DMA transfers to the high RAM are forced through a (4KB) bounce buffer in SATADriver, making them a lot slower. So what’s happening is that the RAM disc is being allocated all of the spare low RAM, and apps/DAs which get created after that will be given the high RAM.

A bigger bounce buffer should improve things, but there’ll still be the general problem of trying to make sure that anything that wants to use DMA can be given DMA-able pages. An easy workaround for the RAM disc would be to make it avoid taking non- DMA-able pages, but that won’t help with other cases (e.g. other DAs which are given DMA-able pages, even though they’re never used for DMA). Potentially the OS could automatically swap pages around on demand whenever an attempt is made to DMA to non- DMA-able RAM – the first DMA request will be slow while all the pages get swapped over, but subsequent ones should be fast. But that might not be straightforward either (due to backwards-compatibility issues with swapping low pages with high pages)

ARMEABISupport identifies the active application slot – it’s using OS_Memory 0 to get the physical address of the start of application space, so will fail if the physical address is larger than 32 bits.

Or if physical address changes because it’s requested by Dynamic Area. Or if physical address is the same, which isn’t forbidden by documentation. Or on my Linux Port which doesn’t implement any API relating to physical addresses. (it also doesn’t implement PMP dynamic areas yet)

I don’t know what ARMEABISupport is for, but why can’t it use domainid?

why can’t it use domainid?

That probably would work, but domainid is technically an internal thing, so it’d be nice to find a “legal” way of doing the same thing.

The main place the code is using OS_Memory 0 is in a Wimp post filter, so I’m experimenting with changing it to just use Wimp task handles directly (or more correctly, the low 16 bits which the filter manager provides).

DMA transfers to the high RAM are forced through a (4KB) bounce buffer

Probably a daft question, if the machine has 4GB of RAM why is the bounce buffer so small?

domainid is technically an internal thing

I don’t see why we can’t consider DomainID public, a SysVar for it was added in 5.17. Aren’t the lower 16 bits of the Wimp task DomainID anyway?

If you’re looking at modifying Wimp filters, did we ever fix this fatal bug?

If you’re looking at modifying Wimp filters, did we ever fix this fatal bug?

If you mean this bug, it was fixed in Filter 0.29.

Apologies if that was not the bug you had in mind.