[iyonix-support] Re: Lazy Task Swapping on Iyonix/RISC OS 5.11

On Sun, 25 Jun 2006 you wrote:

> In article <449E72D6.8000902@xxxxxx>,
>    David O'Shea <djkoshea@xxxxxx> wrote:
> > Maybe a daft question, but have you tried turning on LTS again
> > afterwards to see if the corruption re-appears?
> 
> No it doesn't reappear. I have turned it back on again, sometimes straight
> away. Nothing visible happens and the backdrop is still restored.

Okay, that's worth knowing; and one thing I regret not thinking of on
the single occasion that I've seen the problem.

Re comparing the corrupted pixels with the other applications'
WimpSlots, I suspect that what's happening is the incorrectly mapped
page(s) remain mapped in for all running applications, so it will
appear in the saved application memory of all tasks that have been
allocated a large enough wimpslot.

Note also that by increasing the WimpSlot of OvationPro to 3000KB
it's possible that you've just moved the problem to a higher address,
such that it..

     (i) it appears lower down on the screen
    (ii) it doesn't affect the Pinboard application because it's now
         beyond the size of the Pinboard's sprite (held in application
         memory)
or (iii) it no longer occurs, because it requires an interaction with
         Pinboard and only the Pinboard.

To emphasise, since I can't find my previous posting from the one time
it happened on my machine, it's nothing to do with the video memory/
NVidia driver module. It's only the Pinboard's application memory
(source sprite data passed to OS_SpriteOp) that's known to be affected,
leading to consistent, reproducible corruption on the background until
lazy task swapping is disabled. It's not a mysterious bug in
SpriteExtend either because it also showed with Geminus doing the
plotting using its own, unrelated code.

As for how to reproduce it more rapidly, to assist investigating the
fault, I'd be inclined to try running a number of parallel Wimp tasks
that randomly resize their application slots and read/write within
(or perhaps even just beyond) their allocated memory. Do it in
assembler with a minimal amount of code so that you can be confident
of the test application itself, and hopefully this will induce the
fault more rapidly and without requiring user input.

As for fixing it, as far as I can see there's no way any application
behaviour, even if buggy, should be able to cause such a fault. I'll
throw a couple of ideas into the melting pot because I'm not sure
that I'll find the time to investigate further:

 This problem has never been reported on pre-Iyonix/RO5 machines,
 what's changed (if anything)?
 - use of XScale core (MMU is slightly different, but not much)

 - use of DMA from hard disc (does the fault still occur if all
   transfers - applications, sprite backdrop and loaded JPEGs -
    come from RAM disc, not hard disc?

 - other background driver level software (audio DMA/IRQs, USB
   drivers etc)

 Note that the fault may still exist on the pre-Iyonix OS versions
 but just not show up for some reason. The corruption was about
 1.5M into the background sprite when it occurred here, so I doubt
 think it's a case of there never being enough screen memory/large
 enough sprite to exhibit a visible corruption on the RiscPC.

Adrian

---
To alter your preferences or leave the group, 
visit http://www.freelists.org/list/iyonix-support
Other info via http://www.freelists.org/webpage/iyonix-support

Other related posts: