RC2 - heading towards the finish line

So I’m running 5.29 22-Dec-2022

The potentially guilty code was introduced on 24-Dec-2022 so would only appear in ROMs dated Christmas day onwards.

The symptom is a hang during boot around the time the theme is loaded, and is dependent on the theme too. With Morris4 selected my Pi3B works, but with Raspberry theme it gets stuck with an error box that flickers disturbingly as an error happens while drawing the error box. My theory is the that the theme is a large file being loaded and causes some early issue to raise its head, for example: code loaded into RMA which didn’t have the cache flushed on it.

The problem goes away if you swap the SD controller back to the older code.

The symptom is a hang during boot around the time the theme is loaded, and is dependent on the theme too. With Morris4 selected my Pi3B works, but with Raspberry theme it gets stuck with an error box that flickers disturbingly as an error happens while drawing the error box.

That’s bad!!! Raspberry good, Morris bad here though.

Using the Morris4 Theme which fails to boot here.

Comment oit the Theme iconsprites line near the top of !Boot.Choices.Boot.Desktop :-

|Start RISCOS !ThemeDefs 0.05 Deferred
| Load any deferred theme resources now the WimpMode is set
| If "<ThemeDefs$ToBeIcons>"<>"" Then IconSprites <ThemeDefs$ToBeIcons>
If "<ThemeDefs$ToBeIcons>"<>"" Then /BootResources:Configure.IconChange
If "<ThemeDefs$ToBeTools>"<>"" Then ToolSprites <ThemeDefs$ToBeTools>
Unset ThemeDefs$ToBe*
|End

The Boot does then complete.

A manual iconsprites can cause the error :-

iconsprites SDFS::32grB.$.!Boot.Resources.!ThemeDefs.Themes.Morris4.Sprites22

It may be necessary to try also:-

iconsprites SDFS::32grB.$.!Boot.Resources.!ThemeDefs.Themes.Morris4.Sprites

The repeating Error is seen.

Obligingly WimpLog captured this :-

31 Mar 09:02:53 000 FDFDFDFD: Error from : ˝˝˝˝˝˝˝˝!!!!NULL.POINTER.DEREFERENCE!!!!
31 Mar 09:02:53 000 FDFDFDFD: Error from : ˝˝˝˝˝˝˝˝!!!!NULL.POINTER.DEREFERENCE!!!!

The ZeroPain 0.10 module does not show anything.

Does the offending sprite file on the 3B load into Paint on that system?

A manual iconsprites can cause the error

Almost as though the combined theme sprites are overflowing the assigned wimp sprite pool??

I was more thinking along the lines of files at/beyond some offset on the SD card giving that SD controller a headache.

Does the offending sprite file on the 3B load into Paint on that system?

Good thinking.

Error from Paint: Unrecognised sprite data

giving that SD controller a headache.

The iconsprites thing is only an example of the general SDIO fault, any filer operations are at risk. A little disc bashing prog that writes and reads files to measure disc performance stiffs on SDFS the afflicted RPi3B, it is OK everywhere else. It did a bit more than stiff itself, after Alt-Break the SD card was found to be corrupted. DiscKnight time!

The symptom is a hang during boot around the time the theme is loaded

Is that why the latest WindowManager from PlingSystem fails to get into the Desktop under RISC OS 3.11? The boot sequence completes the PreDesk tasks and then just sits at a flashing cursor.

That said, it could be related to this issue which I still need to look into – its the same machine, just different symptoms. Previously it would at least get into the Desktop, now it doesn’t even get that far.

EDIT: I failed to notice its an issue with the SDIO driver, so my issue is unrelated

The symptom is a hang during boot around the time the theme is loaded, and is dependent on the theme too

Having repro’d this issue this morning, its a looks like an issue with where the file is located on the SD and its file size. If you make multiple copies of the Theme Sprites / Sprites22 files in the Theme folder (ie copy them from the HD4 zip), you can get them to eventually read okay and then rename them for a successful boot.

Formatting FAT and Filecore volumes with Partition Manager works, so small read/writes across the full SD work as expected.

It can be easily repro’d by copying a large file to the root of an SD. The symptom is the tail of the file isn’t read from the disc correctly, so using the Pi theme Sprites22 as an example, bytes &102000 to &105FFF are corrupt when read back.

I’ve not tried disabling scatter lists, to rule them out though.

There is a fix in progress. Having built that into a Pi ROM the Themes now load.

The downside is that the disc corruptions I “alleged” earlier are still present on both the RPi3B and RPi3B+. My RPi3B is suspect in that its Bluetooth/WiFi is MIA for unknown reasons bur the RPi3B+ is fully compos mentis.

There is no such problem on an RPi2 or RPi400.

This disc performance testing proglet readily shows the problem.

| !Run for DiscBash
Wimpslot -min 2480k -max 2480k
Set DiscBash$Dir <Obey$Dir>
/<DiscBash$Dir>.DiscBash

REM >DiscBash
REM 01Apr07 - 13Dec14
ON ERROR  PRINT REPORT$;" at line ";STR$ ERL:END
file$="<DiscBash$Dir>.bash"
HIMEM=&10000
start%=HIMEM
PRINT "20 * 1MB files "
TIME=0
size%=1024*1024
FOR X%=1 TO 20
PRINT "w";
OSCLI  "SAVE "+file$+" "+STR$~start%+" +"+STR$~size%
PRINT "r";
OSCLI  "LOAD "+file$+" "+STR$~start%
NEXT
time%=TIME
PRINT '"Write/Read ";time%/100;"secs"
OSCLI "remove "+file$
END

This test is OK everywhere else.

Themes now load. The downside is that the disc corruptions I “alleged” earlier are still present on both the RPi3B and RPi3B+. My RPi3B is suspect in that its Bluetooth/WiFi is MIA for unknown reasons bur the RPi3B+ is fully compos mentis.

I can’t get that DiscBash to do anything exciting here. This is on a Cortex-A53 Pi 3B+ on a vanilla 2GB RISC OS Pi disc image (on a SanDisk 8GB card as it happens). I ran it 10 times and *CheckMap and rebooted afterwards. Is it worth trying a different power supply?

I also ran FSBash and it got past 40000 runs before I got bored watching.

I can’t get that DiscBash to do anything exciting here. This is on a Cortex-A53 Pi 3B+ on a vanilla 2GB RISC OS Pi disc image (on a SanDisk 8GB card as it happens).

DiscBash fails with a Disc error on two 32GB Silicon Power cards, with RISC OS occupying the whole space, in both the RPi3B and RPi3B+. However a 4GB card, of unknown parentage and incredibly slow, with RISC OS using all of it, is fault free.

The power supply is an official Pi4 one with a USBC to micro adaptor, an official Pi3 power supply fared no better.

A few more DiscBash tests on a RPi3B+.

A 4GB card with an LFAU of 2048 rather than the default 512 was OK. The 32GB cards that fail have a default LFAU of 2048. (A straw to clutch.)

ROOL’s 2GB Pi Image on a 32GB Silicon Power card failed.

A full 32GB RISC OS instance on a new 32GB SanDisk Extreme also failed.

All the 32GB cards, once repaired are fine in the RPi400.

I can’t get that DiscBash to do anything exciting here. This is on a Cortex-A53 Pi 3B+ on a vanilla 2GB RISC OS Pi disc image (on a SanDisk 8GB card as it happens).

Card size seems to be key, 4GB good, 32GB hazardous. I don’t have any intermediate sizes to hand, an 8GB test here would have been good.

Card size seems to be key, 4GB good, 32GB hazardous. I don’t have any intermediate sizes to hand, an 8GB test here would have been good.

It seems far fetched, but 32GB happens to be the crossover from SDHC to SDXC. Are any of the cards marked as such? I’ve got lots of 16’s and 8’s and 4’s here but no 32’s.

Also – does 32GB card on Pi 3B+ on RISC OS 5.28 (or any ROM prior to December 2022) behave differently. ie. can we eliminate the card if the older driver was in use?

It seems far fetched, but 32GB happens to be the crossover from SDHC to SDXC. Are any of the cards marked as such?

None of the 32GD cards are marked as SDXC.

Also – does 32GB card on Pi 3B+ on RISC OS 5.28 (or any ROM prior to December 2022) behave differently. ie. can we eliminate the card if the older driver was in use?

The 32GB cards are fine in the RPi3B+ with a ROM of 15-Dec-22.

I’m a bit out of ideas just now, we don’t have a confirmed repro for the developer as yet.

but 32GB happens to be the crossover from SDHC to SDXC.

Up and including 32GB appears to be SDHC, anything larger (which means 64GB and up) must be SDXC.

Are any of the cards marked as such?

I’ve a photo of a 32GB µSD clearly marked SDHC. I’ve not tried it with RISC OS, as it’s the card that normally lives in my phone. https://heyrick.eu/blog/images/20230402sdhc32.jpeg

Card size seems to be key, 4GB good, 32GB hazardous.

Thank goodness mine’s an 8GB card (and an older ROM)! ;)

So, what’s the difference with 32GB? Do we pass a signed integer boundary in addressing it, or something?

I’m a bit out of ideas just now

Have you checked the cards with the list of ones known to work/fail on the Pi? Not all SD cards are created equally.

https://elinux.org/RPi_SD_cards (huge table, probably best not to try this on RISC OS!)

probably best not to try this on RISC OS

No problem on Netsurf 3.11 on a Pi 4 running 5.28

It’s interesting seeing this thread turn to SD cards, as I, at one point, was having an issue with a new Samsung 32 GB SD Card that is listed as being compatible with the Pi4. Yet, I found I’d create a RISC OS image on Ubuntu using the built-in tools, and although it would install and be usable, it tended to work either once or twice.

During subsequent use on a Pi3B, it works fine. The only thing that’s changed is I now use the Rpi imager.

(the list works fine on RISC OS- thank you, Rick, for providing a link to it)

the list of ones known to work/fail on the Pi?

being careful not to buy fakes of course – there are fake Kingston cards around, and probably others too.

If it’s too cheap to be true, it probably is untrue.

Here’s a Repro. This fails on the 2nd loop every time on my 8GB test SD:, with a large chunk of corruption somewhere in the file.

size%=1540000
DIM tmp% size%+512

file$="$.tmp"
file2$="$.tmp2"
OSCLI "IfThere "+file$+" THEN DELETE "+file$
OSCLI "IfThere "+file2$+" THEN DELETE "+file2$

PRINT "Generating test file"
FOR L%=0 TO size%:tmp%?L%=L%:NEXT
OSCLI "SAVE "+file$+" "+STR$~tmp%+"+"+STR$~size%
SYS "OS_CRC",0,tmp%,tmp%+size%,1 TO crc%

C%=0
REPEAT
  FOR A%=0 TO size% STEP 4:tmp%!A%=0:NEXT
  PRINT "Test loop ";C%:C%+=1
  OSCLI "RENAME "+file$+" "+file2$
  OSCLI "COPY "+file2$+" "+file$+" ~V~C~Q"
  OSCLI "LOAD "+file$+" "+STR$~tmp%
  SYS "OS_CRC",0,tmp%,tmp%+size%,1 TO crc2%
  IF crc2%=crc% THEN OSCLI "DELETE "+file2$
UNTIL crc2%<>crc%
PRINT "Failed"

Does it still happen with the latest ROM?

I noticed this in the history: https://gitlab.riscosopen.org/RiscOS/Sources/HAL/HAL_BCM2835/commit/9c1db0ed6d825b58584891e125e95c07c25c550a

Does it still happen with the latest ROM?

My Repro no longer fails, so I guess the issue has been resolved.

Recap, crashes

Card size seems to be key, 4GB good, 32GB hazardous. I don’t have any intermediate sizes to hand, an 8GB test here would have been good.

Having now acquired some other size cards, the issue is a bit more complicated than size. Really small cards, 8GB and 16GB, are not so common now and are more expensive than 32GB cards. Avoiding Amazon silly names I bought Gigastone 8GB and 16GB cards which I had heard of and seen well reviewed. They are fine in the RPi400 with the current beta ROM and in two RPi3’s with ROMs from before last Christmas.

The problem was accidentally discovered on running one of my speed testing apps on the RPi3, with the new SDHost controller, as the horrendous crash on loading a Theme was being investigated. A simplified repro app was distilled down to DiscBash which readily provokes the issue. It is a real issue and not just an artefact of DiscBash as other activity also causes the fault, a ROM build or even moving a large file.

Run DiscBash, which is a repeating sequence of writes and reads of a 1MB file. With some cards the process can stall for a second or two and eventually complete but on other cards it stops with a disc error and the SD card is no longer reachable. Clicking on the SD icon gives “Device error – illegal command”, a reboot is required. Disc corruptions can also occur which DiscKnight will fix but with data retrieved in Lost and Found.

The really bizarre bit is that this effect is dependent on display bandwidth, reduce 1920×1080 16M colours to 256 colours and everything is back to normal. Resolutions below 1280×1024 are good at 16M colours.

Some cards never show the fault. The determinant is disc speed as indicated by DiscBash, a fast card with one pass taking 2 seconds will fail, slower cards 4 seconds or more are fine.

It is as if there is a potential bandwidth restriction somewhere, where the bandwidth is a function of card plus screen data rates.

This is with the beta Pi ROM of 09Apr23. This merge request looked like salvation but it wasn’t.

So far no one else has reported any such problem but for it to be a “just me” thing would require two duff PRi3B’s, three duff power supplies and an immense amount of bad luck with cards. And the whole thing absolutely goes away with a Pi ROM of 15Dec22.

Anyway this is one of the issues holding up OS5.30.

It would useful if someone else could confirm, or refute, this. On a spare card that is.

The really bizarre bit is that this effect is dependent on display bandwidth

That doesn’t surprise me as various clocks are linked in the Pi, not to mention the Pi’s lack of power regulation. Are your Pi3’s running at stock frequencies?

You could try explicitly setting the SDIO clock via CONFIG/TXT (ref. sdio_overclock in the Pi README )