Pi 3 bugs

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

The boot process is stalled by an error so the FAT32 module does not get loaded. The loss of filetypes was not a huge problem except that I took the opportunity to set DALimit to Obey when it should have been BASIC thereby introducing a further error.

I installed your PreDesk on my RPi3 and reproduced the fault as described.

SDFS::RISCOSpi.$.!Boot.Choices.Boot.PreDesk.SetupNet is definitely broken as it stands and definitely needs to be got rid of. I have no idea what the file thought it was doing! Once the boot stoppage is resolved then networking can be reconfigured as required. Just get rid of it, fix it later. If the file is not there it can’t be messing anything up.

Having done that here my Pi fully booted to the configured monitor, and PreDesk$Configure was set.

As the problem persists then there is a further error.

One further possibility relates to CPUSetup. Is there a !CPUSetup in !Boot.RO500Hook.Res.Configure, if there is not then delete CPUSetup.

RMEnsure 0.00 RMLoad System:Modules.Network.

That’s bizarre. I can only imagine the setup tool failed to find a valid network driver (EtherUSB, for instance) and just blindly wrote the file with no name present. Duh.

What’s your path to this file? You said “InetSetup”. On my Pi, that information is $.!Boot.Choices.Internet.Startup and it’s much bigger.

Not seen that TriggerCBs before.
Hang on… WTF does that do? It appears to call XOS_Byte 0,1 (return machine info) ten times disregarding the result and… oh… my god… it’s basically wasting time to get callbacks to happen on return from the SWI, right? …

I had what seems to be the same issue as Tom’s experienced. I only noticed something had gone wrong when I started to look at the SD14 image and discovered that my install wasn’t loading FAT32.

Im going to go out on a limb here …. It seems to me that none of the Preboot Tasks or modules are being looked at and loaded. I was using KeyMapper which had an obey file setting up a key swap. Under the pre Pi 3 builds I set my Obey file to be looked at on boot, it in turn found the module and all was well.

On the first attempt with the latest beta build for pi 3 RISC OS couldn’t find or load any modules. Also note the location is used for monitor video and other preferences including the FAT32 system.. which all of a sudden don’t work anymore???

However if these modules or there obey run commands are manually opened or set to run on boot up then all is ok (ish)
Im not really of knowledge be able to look at source but hoping my user observations are useful feedback at this time.

I do have a sort of working 5.23 build for Pi3 as of tonight but its really fudged with as listed vital system functions being manually loaded, thats before we even get to software!

RMEnsure 0.00 RMLoad System:Modules.Network.

A peek inside !InetSetup.!RunImage would indicate that the full line might be :-

RMEnsure 0.00 RMLoad System:Modules.Network.Internet

The module is in ROM in OS5 and is not present in OS5.23 !System.

This is probably old stuff left in to allow the Boot to be used with older, ROL, ROMs.

That’s still incomplete; the first parameter to RMEnsure is still missing.

I managed not to notice that, but, oddly, that does not error.

*RMEnsure  0.00 RMLoad System:Modules.Network.
File name 'System:Modules.Network.' not recognised

Try again with a Module file that does exist but is not in RMA.

*Help NetI
No help found.
*RMEnsure  0.00 RMLoad System:Modules.Network.NetI
*Help NetI
==> Help on keyword NetI
Module is: NetI            6.26 (26 Jun 2016)

!InetSetup would have generated a correct command line. See :-

DiscDev.castle.RiscOS.Sources.SystemRes.InetSetup.Source.c.Save

   if (!got_d)
   {
       /* Not got the driver, load primary */
       fprintf(BootFile,
               "RMEnsure %s %s RMLoad System:Modules.Network.%s\n",
               interface_module[0],
               VersionToString(interface_version[0]),
               interface_filename[0]);
   }
   if (!got_a || !got_m || !got_i || !got_d)
   {
       fprintf(BootFile,
               "Run Inet:utils.TriggerCBs\n");
   }

Note, that is BootFile, not InetSetup.

Not that any of that matters much, the file is garbage and needs to be dumped.

@Tom. Try removing !!ZeroPain. This is just a diagnostic, it is not a solution.

I’m not sure if the following observation is best placed here to get picked up as a possible bug or what information is needed to help.

Whilst giving the latest February ROM (22nd) a test I noticed 3 things.

1. When using my USB pen drive to unpack the HardDisc4.util or when saving from my SD card to the USB pen drive, the following occurs. All files have their case changed to initial caps – ACORN to Acorn or ACorn to Acorn… The observed issue causes problems when you unpack a !Boot structure on the USB pen drive as it appears to work, but then you find it doesn’t because all the filenames have had their case changed.

2. When right clicking my USB pen drive to open it, this action inhibits SDFS from loading.

3. Opening and saving a !Writer document from the USB pen drive with Adjust click exhibits an unexpected behaviour – an overwrite dialogue box pops up. If you repeat the action with the file on the SD card it works as expected, no extra dialogue boxes.

The USB pen drive is formatted to FAT32.

The USB pen drive is formatted to FAT32.

Fat32fs 1.50 (28 Aug 2015) looks to be OK on my RPi3 with ROM 22-Feb-17.

(Fat32fs 1.50 (28 Aug 2015) looks to be OK on my RPi3 with ROM 22-Feb-17.)

That interesting, I have Fat32fs 1.40 loaded.

The route I took was by upgrading from SD14, by upgrading the PC Loader files, !Netsurf, !Packman, Disabling !Access and then merging the various !System and !Boot files.

How did you end up with Fat32fs 1.50?

How did you end up with Fat32fs 1.50?

By not paying sufficient attention, the latest version is 1.51 (23 Feb 2016)!

Another bug: copy thousand of files to an external USB disk (Acorn format, not FAT). Here, more than 80 GB of data. When you’ll connect the drive later, you’ll get a broken directory after clicking on the icon. Just click ‘dismount’, and this time it will mount without error. Bug only seen on some of my USB drives (SSD).

This bug (broken directory in RAM but directory on disc intact [after reporting an error terminating the large no. of files copy operation] or actual broken directory on disc [after exceeding number of files in a directory limit]) during copying of thousands of files into a filecore-based filing system has already been reported here. It is not specific to a model 3 Pi it is (AFAICT) platform agnostic.

Nota: there is no broken things on the disc. It’s just a message seen at first mount, that is not present on second mount.

Connect and click: error.
Dismount and click again: no error.
Connect, dismount and click: no error.

there is no broken things on the disc. It’s just a message seen at first mount, that is not present on second mount.

Yes. The message says the RAM copy of the directory is broken. Dismounting and remounting refreshes the RAM copy from the disc copy (which was OK) and hence is OK.

The message says the RAM copy of the directory is broken.

Am I the only one who thinks it worrying that such a message shows up at all?

Am I the only one who thinks it worrying that such a message shows up at all?

No.

The message says the RAM copy of the directory is broken.

Even if it was not mounted before (and so never seen or used before by the current session of RISC OS)? And even if there is no error at all on a second disk containing EXACTLY the same data? Strange. Especially when you know that the Root directory of these discs contains only 20 files. A very inconsistent bug.

Total on disc is 51k files and 83 GB of data.
Not so much for RISC OS.

The message says the RAM copy of the directory is broken.

What is the exact message? As far as I can see, the “Broken directory” message is created by FileCore if the directory is…broken; however the only evident reference to it being a RAM copy is that you connect the device again and the problem has (apparently?) gone away.

Can you do a *CheckMap – does it say “Map Good”? Anything else is bad…

And even if there is no error at all on a second disk containing EXACTLY the same data?

Off the top of my head and with no clue what I’m talking about ☺ I would wonder if the filing system has a cache somewhere?
Ah – yes. You’re using a USB key, so surely SCSIFSDirCache would apply?

Jeffrey – do you know, would there be any unwanted side effects (other than slowness) from setting the SCSIFSDirCache to zero?

Looking at the FileCore code, in BigDirCode:

• If failed to read “SBPr” identity (directory marker?)
• If BigDirVersion is within range
• If bottom 11 bits of DirSize are not clear
• If BigDirEndName is not correct ¹
• If the check byte is incorrect

It is worth noting that there is code here with the comment that if a directory in the cache is broken, to scrap the whole cache. This implies there is directory caching within FileCore. It also applies that simply trying again (without dismount/remount) ought to refresh from disc copy and work (question: so why can’t FileCore do that for itself?).

There are also checks in FileCore40 for non-big discs that generate “Broken directory”.

From my own personal observation, running my Pi with inadequate power (as it was at the beginning) would cause FS corruption. I am not aware of the cause, whether memory gets corrupted or if the SD card can’t write properly. I got a few Broken directories (and yay RISC OS can’t fix itself). When I message that the Free Space Map was corrupted (and RISC OS didn’t want to mount the device, I decided enough was enough and got a better power supply. This isn’t to say that your problem is due to power, I’m just pointing out that it seems rather…fragile. The system appears to be fine, but something somewhere has messed up.

Filesystems are HARD.

…

It is worth pointing out that Windows 95 was quite well known for trashing files if it got hammered. Copying thousands of files with lots of directories from, say, a CD-ROM would often result in a lot of crosslinked files. This was repairable with SCANDISK, but unfortunately SCANDISK would go ahead and fix the problem by replacing all the broken bits with zeros, and then not bother telling you want files it just messed up. Maybe recoverable if it was a text file or something parsable, not so much if it was an EXE file!

Filesystems are HARD.

Can you do a *CheckMap – does it say “Map Good”? Anything else is bad…

Free space map error :)

The disc is in perfect state, and data too. I can reproduce the problem when I want. Format the disc, copy all my data, reboot.
- Connect the disc, click on the disc icon: broken directory.
- Dismount, click on the icon again: no error.
- Disconnect the disc. Connect the disc, click on dismount, click on the icon: no error.
- Disconnect, connect, click on the icon: broken directory,
Etc.

I can do this several times, with always the same result. A perfectly stable bug with my SSD :)
A less common one with my HDD.

There is no broken directory and no free space map problem. It’s just wrong errors messages. While I get the broken directory error, DiscKnight find that the disc is OK. At the same time! DiscKnight show all the directories that the filer do not see.

I think Chris is right: it’s just the image of the map in memory that is wrong. But it seems to be a bit different from the bug cited, as I do not try to write ‘bunch of file’ before having an error.

IMHO, there is no failure with the disc. It’s just a first mount failure. Disc not ready? Cache corrupted?

From my own personal observation, running my Pi with inadequate power (as it was at the beginning) would cause FS corruption.

I agree. But once more, there is no FS corruption.
Nota: I use October low vector ROM

But once more, there is no FS corruption.

Actually, there is. Free space map error, remember? ;-)

But reading your report – are you saying that you plug the device in and there’s a problem. Dismount and remount and it works?
That’s a bit odd. I wonder what isn’t happening initially? It’s not like a flash device needs to spin up or anything.

Didn’t the first version of the ADFS/SATA drivers for Titanium suffer from the same pseudo “broken directories” problem? It might be worth knowing what this problem was and how they solved it, it could be a clue to the USB problem.

I’ve just seen the same “broken directory” issue with a floppy image on a build dated 5th Dec 2016. DISMOUNT didn’t resolve it, neither did remounting the floppy image, so the issue is likely to be related to memory allocation within FileCore.

Actually, there is. Free space map error, remember? ;-)

No, it’s also a mistake. After dismount/remount, there is no error detected any more.

But reading your report – are you saying that you plug the device in and there’s a problem. Dismount and remount and it works?

Voilà !

That’s a bit odd. I wonder what isn’t happening initially? It’s not like a flash device needs to spin up or anything.

Not sure. A SSD is like a whole computer. Ah, and it’s USB 3.0 too.