SmartReflex, 1Ghz and screensavers

Having had an odd crash after leaving a screensaver (flowerbox) running for about 3 days on a 1Ghz-enabled machine, I was wondering whether any provision was made in the current code to cope with the situation of a screensaver?

By that, I mean that screensavers tend to run as full-screen “single-tasking” apps, which could push power requirements right up, but by definition screensavers should only be kicking in when idle. I suggest that when screensavers are active, the CPU should drop to a lower power state (if it doesn’t already). This would prevent a potential scenario where a pretty screensaver could trigger lengthy 1Ghz operation when the computer is left unattended.

Clearly when a screen save kicks in, the speed/power selection should be forced to slow/low and back again when the OS is woken up. Presume this is a new requirement for a multi-speed processor?

Clearly when a screen save kicks in, the speed/power selection should be forced to slow/low and back again when the OS is woken up. Presume this is a new requirement for a multi-speed processor?

Not sure about that. What about the situation where the computer is doing some number crunching without any user input. You would want the processor doing its job flat out even if the screen saver kicked in.

I suspect the answer is that the power state needs to be preserved when enterring screensaver – ie. if CPU activity is high when the screensaver is triggered, then don’t change it, otherwise stay at a lower power state (ie. don’t increase power state to accommodate demanding screensavers!).

Andrew: We’re you using a ROM from before or after I fixed the unreliable resets? When I fixed the resets I also made a change that should reduce the chance of crashing when switching to 1GHz, based around a recommendation from the datasheet to start off at a slightly higher core voltage before re-enabling SmartReflex (1.38V instead of 1.35V). Now that I think about it, there’s also another bit I can tweak to make one of the errata workarounds more bullet-proof.

It’s a good idea to limit the CPU speed while a screensaver is running, but as Gwyn says it’ll need to be applied intelligently to avoid hindering the performance of any number-crunching software that’s been left running. I don’t really want to make it a configurable option the user has to toggle on and off, since that would be hassle for the user if they’re only running number-crunching software some of the time (compiling code would be a good example of that). So instead we’ll have to find a way of getting the Wimp to automatically detect when the speed should be limited. I think the best way of doing this would be to add the ability to flag tasks as being “low priority”, which would then cause the Wimp to ignore them when it collects the statistics it uses to decide whether to run at low/high speed. The screen saver module can flag the task as low priority after it’s been created, so there’s no requirement to update all the screensavers to cope with the system (Unless there are screensavers which don’t run as Wimp tasks?)

I suspect the answer is that the power state needs to be preserved when enterring screensaver – ie. if CPU activity is high when the screensaver is triggered, then don’t change it, otherwise stay at a lower power state (ie. don’t increase power state to accommodate demanding screensavers!).

I did think about that myself, but it could result in slightly inconsistent behaviour if you’ve got a task which periodically does some processing – backups, mail fetches, etc.

Yes, I thought about this, but non-critical things like that won’t mind running at a slower speed anyway, when unattended.

Regarding which ROM I was using, it was the one that you made available as a direct download (after reset fix, I think) because the autobuilder wasn’t autobuilding at the time.

I’ve certainly had mixed reports back from testers. Some are quite happy. Others (esp those using extra drives, FAT32 formatted, but this may be co-incidental) have reported odd crashes. Some reports were whilst typing in StrongEd or Messenger, whilst I had one after FAT32 complained when I tried to update a backup (didn’t like overwriting locked files). Usually the crashes seem to trigger a “Filecore in use” type error, although I was tending to see “Message Token inuse not found”, which suggests memory corruption to me? I’m still investigating this, but an using 5.18 on machines with extra drives for stability.

non-critical things like that won’t mind running at a slower speed anyway

Maybe, but I think users wouldn’t expect/want their builds/backups/whatever to not be finished after the usual amount of time if they leave the machine and a screensaver kicks in. The slower clock speed would be more appropriate IMHO after any demanding tasks have completed (assuming this is easily notifiable/detectable).

I’ve certainly had mixed reports back from testers. Some are quite happy. Others (esp those using extra drives, FAT32 formatted, but this may be co-incidental) have reported odd crashes.

OK, I’ll set up a soak test or two that I can use to give the code a proper workout.

Sorry to be a pain. If I can isolate things further, I’ll feedback as much as I can. I’ve just had a CD-only machine happily running for the last 4 hours or so.

That’s OK; I want it to be stable just as much as you do.

I think I may have already found one bug (*taskwindow produces an odd error along the lines of ‘Filename $ModuleName not recognised’), so it’s not a complete waste of my time. I’m still tracking down the cause, but hopefully this will explain some of the things people have been seeing.

(*taskwindow produces an odd error along the lines of ‘Filename $ModuleName not recognised’)

Now fixed. Looks like it had been around for a couple of months.

Early morning thought – could the quirks resulting in “filecore in use” type problems (possibly connected with FAT32FS) be related at all to the filing system/heap fixes done earlier this month? It just occurred to me that the smartreflex stuff could be a red-herring?

Early morning thought – could the quirks resulting in “filecore in use” type problems (possibly connected with FAT32FS) be related at all to the filing system/heap fixes done earlier this month?

Possibly!

Despite leaving some tests running for a few days I haven’t seen any SmartReflex-related problems here. To help narrow down the cause of the problems, I’ve uploaded a zip file here with three ROM images inside:

• nocda – OS_ChangeDynamicArea optimisations disabled, SmartReflex enabled
• nosr – SmartReflex disabled, OS_ChangeDynamicArea optimisations enabled
• tweaked – OS_ChangeDynamicArea + SmartReflex enabled. Extra tweaks to SmartReflex code that could/should improve stability.

So if anyone who’s been running into problems could give those ROMs a try then it would be much appreciated.

I guess the next thing I should do is grab the latest copy of FAT32FS and see if I run into any issues using that.

OK, I was the first person on the ARMini list to report crashes in 5.19. These were reproducibly due to using the arrow keys in StrongED (v4.69a6) and EmailEdit, and Fireworkz. I have had no such problems on 5.18 (now reverted to 5.18

At boot I load MessengerPro 6.05, NetSurf (r13571) and NetFetch 3.20. I’ve had the ARMini for a couple of months. It has a 32 GB USB drive and FAT32FS 1.39

“nocda” ROM: I was able to provoke a crash very easily:
“Application may have gone wrong. Internal error: abort on instructrion fetch at &A0000116”
This caused StrongEd to quit. On reloading it (no reboot) I then got this:
“Messenger Pro may have gone wrong. Internal error: abort on instruction fetch at &80000116”
The error box offered a post mortem. Ignoring the Arg values, it gave:
2621c in function event_pollidle
34aa0 in function main
fc13c4d0 in shared library function
8390 in anonymous function

“nosr” ROM. Initially this was stable for a substantial number of hours. I then did get a crash, while the input focus was in StrongED:
“MessengerPro may have gone wrong. Internal error: abort on instruction fetch at &80000116”
Post mortem results were:
2621c in function event_pollidle
34618 in funtion messenger_poll
34aa0 in function main
fc136610 in shared library function
8390 in anonymous function
I then had an error from StrongED: “Internal error: abort on instruction fetch at &80000116”. This was followed by a filecore error so I rebooted.

I then quickly provoked problems again, with a sligtly different address for the MPro instruction fetch: &600016

“tweaked” ROM: I rapidly had an application error from StrongEd, abort on instruction fetch at &80000116

I hope this helps

Thanks – that’s exactly the kind of information I need. It didn’t take long for me to reproduce the bug and find the cause; some minor optimisations I made to the kernel a couple of months ago introduced a bug where OS_Byte and OS_Word would enable IRQs on entry instead of disabling them. This could lead to R14_irq being corrupted if they were called from IRQ handlers, as was the case with the crashes you were seeing, where StrongED’s KeyExtend module was calling (or indirectly calling) one of them from an IRQ handler. I’ve checked in a fix now, so with any luck everything will be OK once the new ROM is available in the morning.

Jeffrey, is this your fix for it? https://www.riscosopen.org/viewer/revisions/logs?ident=1337117164-102825.html

Yep.

Nice one, should be in the autobuilt ROM image on the ROOL site tomorrow morning.

Brilliant stuff, thankyou Jeffrey!

I’ve been using this fix and it seems to have sorted the problems I was having. Thanks :-)