Pandaboard "FileCore in use"

I was given a second hand Pandaboard almost a year ago. I’ve made occasional efforts to get it going and doing something useful, but always found it stiffed or crashed after a while.

Recently I’ve made some slightly more serious efforts.

I powered it from a lab power supply which allowed me to ensure that it was receiving exactly 5 volts within the board, and displayed the current consumption for me. No improvement, so I can’t blame inadequate power. (Consumption is only about 1 amp total max, including SSD, USB hub, keyboard and mouse.)

Yesterday I wrote a little app that used wget to get the BBC news home page repeatedly and save it in RAMFS; this allowed me to exercise the network and the filing system but not the hard drive (a 240 GB SSD, which HForm may or may not have formatted correctly). I was dismayed to see that it fell over within 2 hours with the dreaded “FileCore in use”.

RISC OS is 5.23 from mid December last year. When it boots up, there is a message saying that it’s supported by the R-Comp scheme: I’d like to make it clear that I am not entitled to such support, but I don’t know how to find, identify and remove anything that I’m not entitled to. The relevance here is that I suppose it’s possible (though unlikely) that there is something on there that isn’t compatible with a standard dev build of RISC OS.

Anyway: if anyone has any good ideas about what I can do next to narrow down the cause, I’d be grateful.

Just a thought – why not repeat the test with the official RISC OS to see if it is specific to the one you have currently installed or what?
https://www.riscosopen.org/content/downloads/pandaboard

Came across this, which is interesting: https://bugs.launchpad.net/ubuntu/source/linux-ti-omap4/bug/971091

Having dealt with the “FileCore in use” error more times than I care to imagine, it’s more than likely caused by stack corruption. There’s other ways to trigger it, such as re-entrancy, but assuming there’s no 3rd party involved that’s probably unlikely.

I’d start by looking at anything that hangs off the IRQ vector. When diagnosing the error under ADFFS, I put a shim on the IRQ vector that checks the IRQ handler exits in the correct CPU mode, with correct stack pointers and IRQsema is clear when the IRQ stack is empty.

It occurred to me yesterday that my test (repeatedly downloading the BBC News front page to RAMFS) still used the SSD as the source of one part of the app, which was called repeatedly, thus it didn’t eliminate the SSD from the test. I ran it again from RAMFS. I was initially encouraged, because it ran overnight, but it fell over later in the morning, stiffing completely (no mouse movement). That was still on 5.23 of last month.

Using the official build is a good idea. Clearly it will take some time to test; I’ll keep trying and reporting back here.

I installed the stable version of RISC OS. The first test I tried was copying files across into RAMFS from the BBxM via ShareFS (after setting ShareFSWindow to 1 – and it is 1 on the BBxM too). This completely stiffs it in seconds, every time.

Where can one get a ‘low vector’, i.e. non-zero-page, version of a recent ROM for the Pandaboard?