CMOS updates

I had set the Beagleboard the task of copying several gigabytes of data to an SD card overnight. The SD card is in the on-board card slot. I had taken out the boot card which the Beagleboard had loaded its ROM and CMOS from when it started up. After loading the ROM and CMOS, RISC OS itself boots from a SCSIFS drive plugged in via USB. The boot SD card only has a FAT partition.

I was surprised this morning that the machine had not completed the job. Instead SDFS had stalled the machine, asking me to insert the disc “RISC”. This turned out to be the boot SD card. As soon as I had swapped the cards, I was asked for the other card again so that the filer could resume the copying job. Maybe about ten or twenty minutes later the same happened again, but now the machine has been going for over an hour without further occurrences so far.

I can only assume that the OS was needing to write to the CMOS file. Why would this be happening? Is it something to do with the date/time perhaps? If so, how often can I expect it, and how could I disable it (without resetting the machine) so that the file copying can conclude without further interruptions?

I can only assume that the OS was needing to write to the CMOS file.

Or needing to read something from the SD card. If it was writing to anything, surely we would see the datestamps change on the files, which does not appear to be the case on this system. Do your datestamps tell you anything?

I have removed the SD card from this Raspberry Pi (which is configured like yours). I will report back if RO notices that the SD card is not there.

I have just come back to this to report that the SD card has not ben missed.

However, I have just noted that you are using a Beagleboard and not a Pi. Perhaps the difference lies there.

Or maybe the OS version? I am using 5.24

The CMOS file timestamp was definitely updated. I was wondering whether it was writing something to do with the clock?

I was wondering whether it was writing something to do with the clock?

Sounds very plausable. I have just cliked on the ‘Set clock’ option in !Alarm and immediately got a request to insert disk PiBoot. Re-inserting the SD card cleared that message.

I normally have this system updating the time from my ISP timeserver every 30 minutes and that does not access the SD card. Maybe a less frequent update sometimes accesses the SD card.

We may need input from somebody with knowledge of the code.

I normally have this system updating the time from my ISP timeserver every 30 minutes and that does not access the SD card. Maybe a less frequent update sometimes accesses the SD card.

We may need input from somebody with knowledge of the code

If memory serves it was Jeffrey that did some changes to the date/time code a few months back.

Matthew hasn’t said whether he’s running a beta release (5.27) or a full release (5.26 or 5.24) which may have a bearing on the observed effects. Is this an older release issue or current release?

I believe the save back of last used time only occurs when a step change is made (as with the Set Clock option) but not with the delta adjustment done by the NTP associated code, otherwise every minute adjustment carried out by NTP would produce a save to disc.

I’m using 5.27 of 19-Jun-19 for the ROM. I’m not sure how up to date the !Boot is.

I partly posted because I was worried that I’ve be asked to swap discs several more times during the copy job, but the prompt didn’t recur.