ROD's new TCP/IP stack.

I think we’ve tracked it down

Brilliant! Can you add your findings to the bug report please?

I added them to my own with a reference to yours. I’m not home tonight and don’t have the password available so can’t update your ticket at present, so it might be easier for you to reference my ticket from yours.

reference my ticket from yours.

Done. Interesting both start with various strange problems but end up with the same conclusion!

Just confirming that IPv6 SLAAC address assignment is unnecessarily slow in the 7.00 build. We have tracked the problem and have a fix going through QA now.

I suspect that may well be the case, and I am soon going to update problem 2600119 with my reasoning. [Edit]Now done.

Good work. I hadn’t caught that it was doing OS_Reset and I just assumed that it was going through the full shutdown process.

I think we’ve tracked it down: I made a little BASIC program that copies a file with *Copy then immediately does a SYS “OS_Reset”. The resulting file was corrupt.

OK.. for the record, as of now the installer does OS_Reset once the copies etc have finished.

BUT… if you are running a disk connected by usb it will take a while after the write transaction has apparently completed before it is safe to remove the power, which is what happens on OS_Reset.

In consequence we’ll provide a short delay following the point when it thinks it is done before actually resetting. FWIW it pretty much does a full shutdown before it starts…

I think I have a stable system, so long as I avoid Zap and LanMan98.

(Which reminds me, where do I get a complete and up to date Zap from now? Not where I thought, it seems. My searches have not proved fruitful.)

I’ve got another free DDNS domain and pointed an AAAA record at my RasPi, and been able to ping it by name.

Presumably we will need an updated TCPIPLibs to be able to write any IPv6-compatible apps?

There should be Rick07 version of Zap (latest AFAIK) on !Store. I think it is on his website too.

Dave – I sent you an email you about that a couple of days back, and with updated SLAAC, but didn’t get a reply. You were probably busy, but just wanted to check my emails did arrive and hadn’t been lost to some anti-spam deity out there in the interwebs…

Yes, I’m sorry, I received two that I haven’t responded to. Utterly remiss of me.

The updated SLAAC probably works faster, but the timing of the earlier version was not consistent, so it will require numerous tests until I’m sure. I suppose each test will require a power cycle, or at least a reboot.

The version of Zap (which I have now totally removed from the RasPi) must have been updated over the years, and so probably doesn’t match any distribution.

The new TCP/IP stack doesn’t seem to work with Harinezumi.

The new TCP/IP stack doesn’t seem to work with Harinezumi.

That’s because it insists on updating !Boot.Utils.BootRun, which is a pain in the backside if one happens to have modified it and has a program actually running that such modifications then mess up.

So, open that file, and about twenty lines down you will see:

If Boot$OSVersion >= 350 Then WimpSlot -next 512K
|256K
If Boot$OSVersion >= 350 Then FreePool
AddToRMA 768K

It’s the FreePool command that trashes a running application, in this case Harinezumi.

Comment all of those out (the harikick Obey file did those things already). Save the BootRun file.

Then open the HariKick file and ensure the WimpSlot is setting enough memory. Mine is 4MB, but I think the default is 256K. Edit that as appropriate, and then save the file.

Then, all should be good…

…at least, until you update the stack and need to remember to ‘fix’ the file again. :-/

As far as I can tell, the change that they have made is to change the default from saying:

If Boot$OSVersion >= 350 Then WimpSlot -next 256K

to saying:

If Boot$OSVersion >= 350 Then WimpSlot -next 512K

(comparing StackBeta8 which is the first one I laid my hands on, with a recent Harddisc4 distribution)

It’s rather annoying, since as a developer with a need to be able to run the compiler in a TaskWindow, I had modified mine to say:

If Boot$OSVersion >= 350 Then WimpSlot -next 4096K

so not only did Harinezumi fail, but so did trying to build stuff directly from a TaskWindow.

Not sure it’s good form to update a core system setup file by dumping a new one over top. How hard can it be to throw together some BASIC to look for the specific thing that needs changing, and alter that, leaving everything else intact?

In consequence we’ll provide a short delay following the point when it thinks it is done before actually resetting.

:-)

Anybody (if anybody…) who used my little utility to trap ShCtrlF12 and offer to power off or reboot with a CJE power controller, might have noticed that it delays for about three seconds between the end of the shutdown and when it actually does the power off/reboot.

It’s for this exact reason, to give flash media a couple of seconds to commit writes and do their housework prior to scrambling their brains.

Ideally, one should treat spinning rust in exactly the same way, as various forms of caching mean that data isn’t written to the disc as it is written to the device. It hasn’t been for a while. Some drives have a pretty big cache to allow them to block-write entire tracks if need be.

Thanks for the info on Harinezumi, Rick. We are planning a more context-sensitive bit of BASIC (as you describe) for the next version, all being well. Will see what we can do.

However, is that the place to be setting 4MB for compilers? I thought there was a later place that set next to 640K by default. Certainly on my own machine, the 256KB (surely too low) specified during BootRun is lower than what ends up allocated at the end of !Boot.

Question/Challenge…

Is there a version or changes of !BootRun that you could propose that make the freepool conditional for Harinezumi so we can make changes in a manner that retain compatibility with Hainezumi’s modifications?

That’s because it insists on updating !Boot.Utils.BootRun, which is a pain in the backside if one happens to have modified it and has a program actually running that such modifications then mess up.

Granted I don’t know the actual reasons for the WimpSlot being changed by TCP/IP, but I wonder whether it’d be better to put that line in the PreDesktop file instead. The file is documented in the PRM and developers are ‘allowed’ to add to it (as opposed to BootRun which isn’t documented; I feel like we shouldn’t be fiddling with undocumented system files).

I thought there was a later place that set next to 640K by default.

RO520Hook.Boot.Desktop does that (I can’t remember whether that gets copied out of Hook; I’m just looking at the HardDisc4 zip file on my work PC at the moment).

AFAIK the problem is that once BootRun has set the slot size, that is fixed (the rest of ram is set as freepool) for the duration of PreDesk. 256K isn’t a great deal of RAM these days for command line tools, and some of the binaries called by (pre-existing) network Startup files now exceed that (slightly). Increasing it is therefore desirable to allow existing configurations to run cleanly.

Suffice to say this is a topic that has received a fair bit of thought and discussion, and will likely continue to evolve/improve.

256K isn’t a great deal of RAM these days for command line tools

I completely agree. There’s no point in getting het up over saving every byte on a machine with at least 256MB onboard, and these days more likely 1GB.

network Startup files now exceed that (slightly).

Applications? Isn’t the OS supposed to fiddle the slot size if it’s too small?

that has received a fair bit of thought and discussion

The primary problem with Harinezumi is that it’s a running application and FreePool wrecks that.

I suppose a logical approach would be to modify Hari to detect WimpSlot and FreePool and ignore those lines?

My setting for the Next slot is 16 MiB.

My setting for the Next slot is 16 MiB.

“Andre has a red flag, Chiang Ching’s is blue
They all have hills to fly them on except for Lin Tai Yu …”

My setting for the Next slot is 16 MiB.

Tell me you are running gcc without saying you are running gcc… ;-)

“Andre has a red flag, Chiang Ching’s is blue
They all have hills to fly them on except for Lin Tai Yu …”

“Dressing up in costumes, playing silly games.
Hiding out in treetops, shouting out rude names.”

Tell me you are running gcc without saying you are running gcc…

Rumbled already.

It gives me something that works in all cases that I’ve yet found. When there’s so much RAM, using it makes things easy.

I have realised that my RasPi is not perfectly stable even without the new stack. The new stack makes a big difference to the symptoms, though: without it, something odd will happen with days between occurrences; with it, I get 100% repeatable crashes or lockups.

But I have to get to a 100% stable starting point before I report anything else.

I’m sure someone somewhere mentioned checking power supply, though I can’t for the life of me find it now. The system is running from a wall wart rated at 4 amps, which is way more than the system consumes. I’ve ordered some bits from eBay: some resistors to test whether the PSU actually delivers 4 amps; some capacitors to provide surge stabilisation; and a barrel connector that will enable me to shorten the PSU’s output cable a bit.

I’m sure someone somewhere mentioned checking power supply

A good starting point would be to use a multimeter on the GPIO 5 volt pin. Even better would be an oscilloscope, in case the voltage is momentarily dipping with peak loads.