Aborts and machine lockups when SparkFS load

Hi All,

I am in need of some assistance in that my ARMX6 has been offline now for a few days and no matter what i do I can’t get it stable.

I have gone back to a back up have of the Boot sequence and also done a clean install from Recovery and even put a clean ROOL disc image on it but still get lock ups and aborts.

I can trigger a lock up if I have say MessengerPro , Netsurf and Printers loaded if it has a Postscript printer definition or networked printer.

If I delete SparkFS 1.46 then the machine is stable.

I have even tried a new download of SparkFS with the same issues.

I ahve tried going back to SparkFS 1.44 and still get lock ups.

This all started after I had been trying to resolve issues with Manga and PartMgr as up until then the machine ran fine.

I have tried also re-installing the OS and going back to an earlier version but no differnet.

The SSD seems to check out Ok with Disknight.

Whilst I am typing this I am downloading 2007 emails so I am sure the hardware is OK it is just that SparkFS if seen locks up and aborts every program but why did it work OK previously?

Any way hoping someone can help point me in the right direction.

Symptoms occur when SparkFS has been seen (!SparkFS.!Boot) or when it is run (!SparkFS.!Run)?

Oh, and what ROM revision?

SparkFS if seen locks up and aborts every program

Are you saying that SparkFS only has to be booted, or is it on the iconbar (with various modules loaded)?

Does Draw abort (what exactly does abort mean?) and what is the error message?

I am pretty sure there is nothing intrinsically wrong with SparkFS – I am runninmg it on an ARMX6, as well as a Titanium and IGEPv5.

I assume you are not being hit by the 148 module limit bug are you?

Verma say 151 in RMA when SparkFS is loaded!

Seems like this is indeed the issue and may be why Manga is aborting as well.

So I guess the fix is to have a ROM later than 16th Dec 2020 which rules out a RComp one for the moment?

Right just burnt ROOL Wandaboad ROM and booted up and normality is restored.

So moral of the story is don’t get stuck in to a loop when diagnosing issues and above all keep calm and just ask here as help is always as ever available.

You would of thought I would have known that but heh the brain gets fuzzy when you aint been out for over three weeks when shielding.

Only one down side Manga still aborts..sorry Rick.

I assume you are not being hit by the 148 module limit bug are you?

If this is a thing, the OS should error with appropriate text when Module 148 attempts to init.

If this is a thing, the OS should error with appropriate text when Module 148 attempts to init.

It was a memory corruption bug, not an intentional limit on the module count.

https://www.riscosopen.org/forum/forums/11/topics/15973

Only one down side Manga still aborts..sorry Rick.

Oh well, it would have been nice if that fixed it. ;-)

Alas, I don’t know what is happening in this instance. It’s handing off stuff to the URL fetcher (as works on other machines) and somewhere along the way that is blowing up.

Say… Could you get it to abort with another Debugger dump:

*Set Debugger$DumpOptions -file annotated
*Set Debugger$AnnotatedFile $.MangaCrash

but also do the following after:

*Spool $.MangaInfo
*FX 0
*Where
*ShowRegs
*MemoryI PC-32 +64
*MemoryI R14-20 +40
*URLProtoShow
*Modules
*Spool

(it would be useful if Debugger included disassembly around the crash point in the annotated dump)

That way, we can see what is actually faulting. Might give some clues?

Say… Could you get it to abort with another Debugger dump:

I will when i have sorted out another issue.

On boot up I get an error window say saying Director BASIC not found.

Thanks to Harinezumi I ruled out the main boot sequence and Reporter came to the rescue to identify the !SerialDev application being booted in Resources.

The Boot file is as below:

“IconSprites <Obey$Dir>.!Sprites
if “<SerialDev$Path>” = "" then Set SerialDev$Dir <Obey$Dir>
if “<SerialDev$Path>” = "" then Set SerialDev$Path <Obey$Dir>.

RMEnsure BlockDriver 0.00 RMLoad <Obey$Dir>.BlkDrv
SerialDev:Utils.RepeatBoot SerialDev:Modules"

In the Library directory in !SerialDev there is a “BASIC” directory with a Basic application called BlkDrvVars.

So any clues as to why it can’t see it as it used to run OK before the latest issues.

I have downloaded a new version and it gives the same error.

In the Library directory in !SerialDev there is a “BASIC” directory with a Basic application called BlkDrvVars.

Hmm, I don’t have that in my !SerialDev, but then again mine is quite old. That’s probably something XAT added.

So any clues as to why it can’t see it as it used to run OK before the latest issues.

Yeah… about that.

A recent change to the way the BASIC RunType is defined has had the side effect of breaking loads of BASIC programs that expect the command line to be formatted in the specific way that it has been for over thirty years.
I trust it will be reverted real soon.

BTW, it was an attempt to get If "<Alias$@RunType_FFB>" = "" Then ... to work, because with the quotes in the string the expansion gets seen by the command line as something with too many quotes in it, which means that one can’t easily tell if the variable is set.

One change that was made to the fetcher (not in the code, but elsewhere) was to revert to plain HTTP.
This is because when I was first playing around with MangaHere, going to HTTPS was a redirect to HTTP.
It appears that it now works, so… http://heyrick.ddns.net/manga/manga_0-54b.zip is a build that forces HTTPS to be used (so it should fetch like it used to do). I’d be interested to know if this works?

For others – that’s all it does different. I’ll roll HTTPS support (or maybe just make it a tickable option at long last!?) for the next proper release.

because with the quotes in the string the expansion gets seen by the command line as something with too many quotes in it

Example:

*If LEN "<Alias$@RunType_FFF>" > 0 Then Echo Textfiles defined!
Textfiles defined!
*If LEN "<Alias$@RunType_FFB>" > 0 Then Echo BASIC defined!
Unknown operand
*Echo <Alias$@RunType_FFB>
Basic -quit "%0" %*1
*

So the command would end up appearing to the system as:

*If LEN "Basic -quit "%0" %*1" > 0 Then Echo BASIC defined!

Which is gibberish.

A recent change to the way the BASIC RunType is defined

I remember seeing that and thought as I had installed a bang up to ROM that it could be something to do with recent chnages since the 3rd Nov 20 RComp one.

So thats most likely why Private Eye is broken as well then…

So in Dr Who speak I can have a Crashy washy ROM or a slightly less Crashy washy one :-)

Thats what you get for Alpha/Beta testing.

I’d be interested to know if this works?

See above comments..Crashy washy still :-)

I’ll have a look at doing some debug outp[ut but not until Tuesday earliest now.

Thanks for trying to help.

Yeah, it’s not the BlkDrvVars library, it’s probably going to be the RepeatBoot program in !SerialDev.Utils.

SYS "OS_GetEnv" TO env$
pos% = INSTR(env$,CHR$34)
IF pos% THEN pos% = INSTR(env$,CHR$34,pos%+1)
IF pos% THEN env$ = MID$(env$,pos%+1)
WHILE LEFT$(env$,1) = " " : env$ = MID$(env$,2) : ENDWHILE

Try this:

Open $.!Boot.Choices.Boot.PreDesk and create an Obey file called !!!FixFFB and put this into that file:

Set Alias$@LoadType_FFB Basic -load |"%0|" %*1
Set Alias$@RunType_FFB Basic -quit |"%0|" %*1

That should restore normal behaviour.

Crashy washy still :-)

The 0.54b one? That does HTTPS? Same crashy-washy?

Thats what you get for Alpha/Beta testing.

I like to think of it as “two steps forward, one step back”. ;-)

I mean – I can copy and drag stuff from writable icons now, which is sort of nice. But, on the other hand, I’ve had to rewrite bits of my weather station logger because the USB subsystem (with SerialUSB 0.12) sometimes responds to opening the endpoints with spurious “Bad request” errors. Annoyingly, it seems completely random, it might work for a day or it might work for an hour.
Started happening, IIRC, with RISC OS 5.25, which is why I stayed with 5.23 for so long. Because I had the thing running for uptimes measured in weeks with no problems.

Basically, I open SerialUSB#baud=2400;data=8;stop=1;noparity;nohandshake;noblock: for output, and then open it for input (to get the out/in endpoints set up). This happens every five minutes, to turn DTR and RTS on (wake up the device), then DTR off and RTS on (provide the high/low values), and finally start transferring data in both directions. Takes about ten seconds, at which point DTR and RTS are set off. Then the handles are closed, until the next time (it’s a weird protocol).

Yet, nowadays, for no reason I can understand, sometimes opening the input file fails with “Bad request”. I’ve not yet added logging to see how often this happens, just wanted to make it not crash. Which meant no more OPENIN/OPENOUT, easier to call XOS_Find and handle errors directly as they may happen.

So I guess the fix is to have a ROM later than 16th Dec 2020 which rules out a RComp one for the moment?

You might find that you can use a ROM from before by twiddling your monitor configuration, Chris had success by changing it from Auto to EDID and mode 32 in configure.

If it is the 5.28 148 module bug, then load the supplied CMOS from Utilties.caution.

Or, *configure monitortype 4, *configure mode 32, *configure wimpmode 32

Basically it was EDID that was knackering things, so don’t use it. The supplied i.MX6 MDF is more than capable of handling things video-wise, and if you need HDMI audio, just run the HDMI_aud_on file to enale it.

So thats most likely why Private Eye is broken as well then…

This little issue is not to with the 148 module thing but is possibly to do with the 24Jan21 ROM.

I’ve put a response here

Andrew said

Or, *configure monitortype 4, *configure mode 32, *configure wimpmode 32

I have gone back to the RComp ROM and done the above and normality is restored.

Why the issue only just popped up I do not know though perhaps a rogue program caused.

Rick said

The 0.54b one? That does HTTPS? Same crashy-washy?

Yes on the RComp ROM as well as the up to date ROOL one.

Thanks to everyone for your help and Rick I will do some more bug testing and thanks for all your help trying to resolve it.