Issues with DALimit

Why is it that boot-up sometimes goes wrong in DALimit?
 

I get the RiscOS… Cortex… Picolo… messages okay, but sometimes instead of the …DALimit message it stops with:

Error: Internal error: abort on data transfer
at &201D4044 (Error number &80000002)

and a star prompt.

Typing “desktop” brings up the Castle logo and then a partially working MODE 28 screen. If I then go into Boot.Choices.Boot.PreDesk and run DALimit myself, there’s no error message.

Looking at the single-line program shows DALimit merely sets the maximum size of a dynamic area to 128M, so what can sometimes go wrong?

On the rare (ish) occasions when this happens I just press the reset button and RISC OS 5.19 boots up nicely; what made me post today is that I’ve just had to reset twice.

Is there a little obey file I could concoct which would run everything from DALimit onwards to complete booting up, and then connect with the internet?

Could it be the PreDesk.Configure.!Run which runs just before this? I dimly recall some sort of problem with the configure plug-ins. Is your !Boot up to date?

It seems from (random, probably inaccurate testing!) that the Pi has problems with soft reset (as in OS_Reset) when DALimit has been run.
What does it actually do?

Sets the maximum size of a dynamic area to 128M (the deault is the installed RAM). Lord knows why. The PRMs are a bit behind…

The limit is set to avoid exhaustion of physical address room. If software asks for an “unlimited” DA, it gets the configured maximum size. If maximum size is unconfigured, it is the same as installed physical RAM. Now consider an IYONIX or a PandaBoard with 1 GiB of memory. You could only create one or two DAs with a max size of 1 GiB before you run out of allocatable pages. Therefore, a “sensible max” was defined, which happens to be 128 MiB.

Is there a little obey file I could concoct which would run everything from DALimit onwards to complete booting up, and then connect with the internet?

No, but there are a few commands you could put into an obey file and then run to help us track down the issue the next time it happens :-)

https://www.riscosopen.org/wiki/documentation/show/Reporting%20bugs

I’ll admit I’ve seen some crashes like this myself recently (not in DALimit AFAIK, but elsewhere when – IIRC – trying to run a BASIC file during startup), but haven’t yet seen it happen often enough to try and spend some time tracking down the cause (for all I know it could just be caused by whatever dodgy code I happened to be working on at the time, or something like this compiler bug – which I have seen cause booting to fail on at least one occasion).

The good news with problems like this is that they’re relatively easy to test for if you just set up a machine to automatically reboot after it reaches the desktop.

Could it be the PreDesk.Configure.!Run which runs just before this?

Dunno, that seems to set the VIDCBandwidthLimit to                 2000000000 2000000000 2000000000

I dimly recall some sort of problem with the configure plug-ins. Is your !Boot up to date?

It’s what came with the machine a few months ago – how can I tell what the version/date of my !Boot is?

Is there a little obey file I could concoct which would run everything from DALimit onwards to complete booting up, and then connect with the internet? No.

I’m a bit disappointed by that – okay, is there a huge obey file I could generate which would run everything in the bootup process, starting with the contents of PreDesk?

There are a few commands you could put into an obey file and then run to help us track down the issue the next time it happens.

I’ve downloaded Where/zip from which I’ve copied the Where utility into Boot.Library – what do I do with Makefile and the o & s directories, and where should I store the instructions to read them when needed?

I’ve downloaded Where/zip from which I’ve copied the Where utility into Boot.Library

Anywhere that will allow you to just run it when needed

what do I do with Makefile and the o & s directories,

Unless you were thinking of recompiling after an amendment of the code you might as well leave them in the zip.

and where should I store the instructions to read them when needed?

Printed on a small crib sheet near the machine?

I’m fully paperless here.

I’m fully paperless here.

Convert to a PDF and load onto a tablet for reading/crib when needed.

Sticking the commands in an obeyfile in the root of your hard disc should work fine.

Oh, that’s a good idea, I’ll try that later. Thanks.

Meanwhile, I’ve just had Edit crash the machine while tidying up an 11Mb text file, which has given me the chance to test this.

Typing ‘desktop’ at the star prompt gives me a working MODE 28 screen, with icons for the discs, Apps, Display, and Tasks on the icon bar.

So I go to !Boot.Library and run Where, which just says:

Address 201D3BE4 is not in any module

I let the filer see !System and !Scrap, then run !Netsurf which complains about no internet but otherwise starts working – in HUGE LETTERS.

I find the MDF file and drag it to Display, then start up a 1920×1080 screen mode which is much better!

Now I can read the instructions, but typing *Where fails to output any information about the last serious error, it just complains about Address 201D3BE4 again.

However, most of the machine is now working normally – if only I knew what to click to start the internet going. :(

But instead I save this typing, and PRESS RESET

Using Reporter.

*LoadModeFile BootResources:Configure.Monitors.Acorn.RedSq

This command produces this error with RedSq.

File ‘BootResources:Configure.Monitors.Acorn.!Sprites’ not found.

Adding a !Sprites file in Acorn dir – quietens the error.

Now that ‘VIDCBandwidthLimit’ has been removed with RO 5.21 – what now does the ‘Bandwidth’ command?

Isn’t there an ‘X’ now so that VIDCBandWidthLimit can fail gracefully?

Sticking the commands in an obeyfile in the root of your hard disc should work fine.

Okay, great, so that’s where I will put my huge obeyfile – which, (once it has been automatically generated for me), I shall name “!Shoe”.

However, this makes me wonder – when that error message leaves me at the star prompt, is the current directory the root of my hard disc?

So I type “Cat”, only to find that the current directory is instead the SD card… and oh, but look – there is !Boot itself, staring back at me.

Knowing that this would be where I’d type “!Shoe” at the star prompt, I wonder what would happen if I type “!Boot” instead – so I try it…
 

And guess what? Without making any fuss, RISC OS 5.19 dutifully completes its boot-up, and then connects to the internet!!!

Okay, the machine has finally crashed now I ‘wanted’ it to, and here is my capture file (I’ve skipped numbers 3 to 122 to keep this post short)…

No. Position Workspace Name
  1 FC01F094 00000000  UtilityModule
  2 FC0402F4 20000014  PCI

123 FC3EF68C 00000000  CDFSFiler
124 FC3F22DC 00000101  UnSqueezeAIF
Address 201D3BE4 is not in any module
Register dump (stored at &2000B0D0) is:
R0  = 80000110 R1  = EF000024 R2  = 00000000 R3  = 00008100
R4  = 00000000 R5  = 00000000 R6  = 00009D14 R7  = 00000000
R8  = 00008700 R9  = 40000000 R10 = 0000000D R11 = 0000903A
R12 = FB406E24 R13 = 1FFFFFD8 R14 = FC16D33C R15 = 201D3BE4
Mode USR32 flags set: NzcvqjggggeAift        PSR = 80000110 

..so what do I do with it now?

The instructions tell me to contact the application author directly, including the capture file, but who is the author of DALimit?

And guess what? Without making any fuss, RISC OS 5.19 dutifully completes its boot-up, and then connects to the internet!!!

Sorry, stupid question but I not see the answer in this thread… maybe the language barriere and I understand anything wrong. :-(
Have you only change the ROM or also the HDImage? The new ROM will not stable work with a old HDImage but a older ROM will do with a newer HDImage.
It is also possible that the entry after DALimit failed. I have it with a other error. The display output was to slow…

..so what do I do with it now?

The instructions tell me to contact the application author directly, including the capture file, but who is the author of DALimit?

DALimit is part of the standard hard disc image, so it falls under the category of “ROOL hosted software”. There’s a separate bit of the bug reporting doc which covers this, but the gist of it is to either (a) post on the bugs forum or (b) add a bug report to the bug tracker. But since we’re already talking about the bug here we might as well continue here.

Some extra information would be useful – if you could capture the output of the following commands then that would be great:

*FX 0
*memoryi fc16d31c + 40
*memoryi pc-20 + 40

The first two commands you should be able to run any time, the third one is only going to be useful if executed after the crash. But if you can provide the output of the first two right away then that would be a big help.

It seemed a good idea to copy those commands into my obey file, like this…

Spool $.capture
Modules
$.!Boot.Library.Where
ShowRegs
FX 0
memoryi fc16d31c + 40
memoryi pc-20 + 40
Spool
SetType $.capture FFF

..but the *FX 0 command stops the obey file running, so I’ve taken that out again. Anyway, *FX 0 produces the message:

RISC OS 5.19 (09 Feb 2013)

And the first memory dump is:

FC16D31C : ✘Ð.å : E518D084 : LDR     R13,[R8,#-132]
FC16D320 : .. ã : E3A00000 : MOV     R0,#0
FC16D324 : ÿ.-é : E92D03FF : STMDB   R13!,{R0-R9}
FC16D328 : ..Hå : E5480019 : STRB    R0,[R8,#-25]
FC16D32C : ..àã : E3E00000 : MVN     R0,#0
FC16D330 : ..Hå : E548001A : STRB    R0,[R8,#-26]
FC16D334 : xÐ.å : E508D078 : STR     R13,[R8,#-120]
FC16D338 : ð..ë : EB0002F0 : BL      &FC16DF00
FC16D33C : ..Xå : E5580014 : LDRB    R0,[R8,#-20]
FC16D340 : ..Pã : E3500000 : CMP     R0,#0
FC16D344 : .... : 0F000011 : SWIEQ   OS_Exit
FC16D348 : ,..ë : EB00022C : BL      &FC16DC00
FC16D34C : >..ï : EF00013E : SWI     OS_WriteI+">"
FC16D350 : Þ..ë : EB0002DE : BL      &FC16DED0
FC16D354 : &..ë : EB000226 : BL      &FC16DBF4
FC16D358 : F4.ë : EB003446 : BL      &FC17A478

And guess what? Without making any fuss, RISC OS 5.19 dutifully completes its boot-up, and then connects to the internet!!!

Sorry, stupid question but I not see the answer in this thread… maybe the language barriere and I understand anything wrong. :-(

Ihr Englisch ist besser als mein Deutsch, aber wenn es Ihnen helfen würde, versuchen diesen Post einfügen in eine Google Translate  Fenster. :-)

Have you only change the ROM or also the HDImage? The new ROM will not stable work with a old HDImage but a older ROM will do with a newer HDImage.

I haven’t changed anything.

My problem was that the machine sometimes fails to boot up due to this fault; however, all I had to do was press the reset button and it booted up.

Then one day I had to press the reset button twice (probably just due to chance), which worried me that if the fault ever got worse then I’d be stuck, and seeking help would become much more difficult.

So I raised the problem in this thread, where the discussion gave me a silly idea – instead of pressing the reset button, what would happen if I tried to run the boot-up sequence myself?

When the machine next crashed on booting-up, I tried typing “!boot” at the star prompt – and the machine simply continued its boot-up from where it had left off, and set up everything running perfectly! :D

That was “the answer in this thread”, but of course it’s merely a fix – DALimit shouldn’t be going wrong in the first place, and we’re trying to find out why.

Ihr Englisch ist besser als mein Deutsch, aber wenn es Ihnen helfen würde, versuchen diesen Post einfügen in eine Google Translate Fenster. :-)

Thats what I do but not often. GT is an aid but the translations are often not good. It hardly anyone writes like a three year old;-)

As I wrote in another post , I’m not sure that DALimit is the problem.
I have try many hardware in various combinations last years. The most (boot) problems are fixed by using a other SD card (if the power supply is the right one). The content of Predesk was the second most common cause. Not always the cause was the visible. The use of *spool helped sometimes.

..but the *FX 0 command stops the obey file running, so I’ve taken that out again

Hmm, good point. Can anyone think of any suitable replacements? (*Help UtilityModule isn’t very suitable as it’ll show the date of the kernel, not the ROM as a whole)

And the first memory dump is:

Thanks!

That memory dump is part of BASIC’s main loop, where it decides whether it should get another line of input (for immediate mode) or exit (if it’s just finished running a program with the -quit option). We can assume it’s the latter case which gets executed, so it will go on and call OS_Exit. The kernel’s code for OS_Exit is here, and one important thing that you’ll notice is that when it’s getting ready to call the exit handler it puts the PSR in R0 – which corresponds to what we’re seeing in the register dump. So it looks like it got as far as calling an exit handler (especially since it crashed in user mode, not SVC), and then that handler crashed. So the question becomes: What exit handler?

It’s unlikely to be BASIC’s one (all that really does is restore the previous handlers then call OS_Exit again, plus it’s located in ROM), so it’s presumably an exit handler which is being executed after that. But I can’t think of any that would be located outside a module. What’s also curious is that R12 (which is likely to be the exit handler workspace) is pointing to the system heap, which is generally only used by the kernel. So I think that in order to get to the bottom of this we’ll have to wait for it to crash again so we can get the memory dump for the area around the PC.

Hmm, good point. Can anyone think of any suitable replacements?

x fx 0

?

That just swallows the error, although I guess we could use this slightly more long-winded approach:

unset X$Error
X FX 0
show X$Error