Pi 3 bugs

Thanks for the pointers and the hard work Chris. I did try looking in the forums for help but didn’t go back far enough. The good news is that the latest version does allow the nano router we supply with the pi-topRO top be configured under RISC OS:-)

One of the bugs I mentioned at the start of this thread which I thought was solved has come back to bite me, or at least my Pi-top with Raspberry-Pi 3 inside.
Can folk try the following on a Raspberry-Pi 3.
In a task window and on the command line, ping a non-existent IP address or do a broadcast by pinging X.Y.255.255 or X.Y.Z.255. My Raspberry-Pi 3 is seriously crashing with error messages like “Internal error”, “no stack for trap handler” and “abort on data transfer”

My Pandaboard doesn’t do this.

Works here on RPi3.
Pinging my router works as expected. Using x.y.255.255 produces ‘Unknown Host’, and something like 123.234.4.5 sends 56 data bytes and does nothing until I hit the Escape key. No lockups or errors.

It isn’t crashing any more, but then I changed various IP addresses on the R-Pi3 and on the router. There could have been clashes of DHCP ranges with subnet masks and addresses before. Is it too much to hope that a ping should never result in a crash even if IP addresses, subnet masks etc. are set to conflict?

Pinging my router works as expected.

Short of setting an ACL or putting firewall in the way your gateway should always respond.

Using x.y.255.255 produces ‘Unknown Host’

If you have a /24 mask unless x.y.255 matches the first three octets of your IP then the ICMP packet goes to your gateway address. Since that appears to be your router and the router can’t route private addresses onto the internet it wouldn’t go to the host.

If you have a /16 mask then all 64k of available IP’s from x.y.0.1 to x.y.255.254 would respond to the ICMP packet generated.

and something like 123.234.4.5 sends 56 data bytes and does nothing until I hit the Escape key.

123.234.4.5 responding would mean that the specific host device in China with that IP address was turned on and there was no firewall in the way. Given the location the latter is probably unlikely.

No lockups or errors.

Crashes shouldn’t occur, but the ping build we have continues until stopped and only displays the reply. In effect until the process is interrupted the task window does not respond in any way

Perhaps the crashes happen only on an R-Pi3?

Hi just thought i’d wade in here, saving starting a new thread….

I have been attempting to do an update of my build (March 2016 … i think) which did implement some ZeroPain features however after updating the SD card with new firmware and yesterdays (08/02/17) nightly build ROM…. there dose appear to be some issues!

I know people are working on this and putting in the hours so i dont want to just rant … part of the issues could well be at my end but….

Monitor , Keyboard and Themes configuration panels are not functioning or not saving settings after reboot,

Monitor throws a dilog : “Failed to open <PreDesk$Configure> for writing”
leaving the auto setting which defaults to 640×480 256 colours… other modes can be set but cant be saved
same with keyboard settings caps lock num lock etc can be set but wont be saved after shutdown
Themes also will default to patterned windows when these options have been ticked off.

I also had issue with USB flash drives , I was not able to copy a jpg file to a drive, as although all looked fine once the drive had been removed the new file was not present on the drive????

Could all this be due to ZeroPain and if i understand correctly RISC OS builds can run without it if rebuilt from RC14?
I did like the improved monitor resolution switching, its just a shame about how unstable the OS is or at least was for me.

Did you also update the !Boot to the latest nightly build??
You also need to have the zero pain loaded to use the lastest rom.

Pi ROM 06-Feb-17 and firmware 08Feb17 are good here. However there has been a change to the CMOS arrangements.

Pi ROMs from the 16th October 2016 onwards save CMOS settings in a file called “CMOS” alongside the ROM image file, previously these were stored within the ROM image file.

The ROM does not automatically create the CMOS file.

For an RCxx partitioned SD card manually create the CMOS file, either at the command line by pressing the function key F12 or in a TaskWindow by pressing CTRL-F12, with the following command :-

*SaveCMOS SDFS:$.!Boot.Loader.CMOS

Two new lines are required in CONFIG/TXT :-

ramfsfile=CMOS
ramfsaddr=0x508000

Pi ROMs from the 16th October 2016 onwards save CMOS settings in a file called “CMOS” alongside the ROM image file, previously these were stored within the ROM image file.

But an obeyfile in, say, Tasks could, and be provided as part of the beta HardDisc4 image:

IfThere SDFS:$.CMOS Then Else SaveCMOS SDFS:$.CMOS

Two new lines are required in CONFIG/TXT:-

and is it beyond the wit of man² to parse the CONFIG/TXT file¹ on boot for the word CMOS and append those lines if not already present, or if the CMOS file was absent originally (discuss)!

Otherwise this problem is going to recur endlessly!

¹assuming there are obstacles to having it incorporated into the firmware at source.

²meaning humankind, and not intended to offend anyone!

Ok… to rule out anything I had done, I’ve installed a fresh RC14 build and updated with the nightly build ROM and Zeropain !boot folder from 2 nights ago, installing the zeropain before switching the ROM over

I’ve created a CMOS file and added the suggested lines to the CONFIG/TXT file.

The monitor issue has now gone away and is working correctly, so that looks to be something more to do with my previous build…

However….. *unplug commands are ineffective after a reboot and RICOS is still unable to remember any settings for things such as keyboards, or switching off pattens for windows / 3d iconbars etc… so I thinking its still not saving these changes?

As I type this i’ve not tried USB sticks and saving files to them as yet…

Should this CMOS file be at: SDFS:$.CMOS

or should it be in the ‘Loader’ folder next to the ROM (FAT partition) ?

The CMOS file should be in the Loader folder.

Ah…. Ok that was me being an idiot…. We have working CMOS!

Ok that was me being an idiot….

Perhaps not, my post above was not correct for an RCxx partitioned SD. I will correct it.

Ah…. Ok that was me being an idiot…. We have working CMOS!

Well, both David and John gave the wrong location :-)

Glad you’ve got everything working now!

Well, both David and John gave the wrong location :-)

Cut’n’paste – mea culpa.

But what about the idea?

Well, both David and John gave the wrong location :-)

It was a correct location, just not in this case. :-)

I use an unpartioned SD card with all the RISC OS stuff on an SSD.

Cut’n’paste – mea culpa.

Me too! Closer inspection shows that I copied from a Pico discussion.

There still seems to be an issue with the Screen Configuration tool which was working but after a few reboots is now giving me the

Failed to open <PreDesk&Configure> for writing

error dillog once again so is so is something corrupting because nothing has changed as far as i can see from a user perspective ???

Failed to open <PreDesk&Configure> for writing

There may be an error in PreDesk.

What does *show PreDesk* have to say for itself.

In !Boot.Choices.Boot.PreDesk.Configure.!Run is there an X before VIDCBandwidthLimit.

We do indeed have an X before VIDCBandwidthLimit

Zip me the PreDesk folder, to see if there is an error. The problem does sound like Boot failure/

pittdj at pittdj dot co dot uk.

Failed to open <PreDesk&Configure> for writing

Shouldn’t that normally be <PreDesk$Configure> ?

I have now had a look at the zip of PreDesk which arrived without any RISC OS filetypes.

InetSetup is the problem.

|
| Internet
|
IF "<BootResources$Path>" = "" THEN Set BootResources$Path <Boot$Dir>.Resources.
IF "<System$Path>" = "" THEN Run BootResources:!System
RMEnsure  0.00 RMLoad System:Modules.Network.
Run BootResources:!Internet.utils.TriggerCBs

The RMEnsure has no filename!

Deleting the file will allow the boot to complete and allow the screen setup to work properly.

Yes well sorry about the zip was unable to zip on RISC OS build as the FAT usb driver is / was not working…

Which file are you suggesting is deleted?

As i found that source under

SDFS::RISCOSpi.$.!boot.Chouces.Boot.PreDesk.SetupNet

I removed that file to no effect on screen configuration tool, which is still generating the error.

If im looking for a modules to remove under !System then could you direct me to which one? As i’ve been though all in the directory and under network but dont know which file im looking for none appear to be labeled RMxxxx etc