ShareFS 'Crashes' with RiscPCs

ShareFS on the RPi seems to crash after about 30-60 seconds of operation. , ShareFS works fine for the brief time it is working after an RPi reboot. When ShareFS crashes, the remote disc icon on the iconbar gets greyed-out and a red ‘STOP’ sign appears.

I’m using an RPi to copy files to a couple of RiscPCs. The RiscPCs are using RISCOS versions 3.70 and 4.02 (approx). ShareFS on the RPi is version 3.54 (14-Jul-12) on a recent distro (5.19 21-Sep-2012).

IP addresses for the RiscOS machines are all manually set on subnet 192.168.0.×.

There are other (non-RiscOS) devices on this subnet, so ShareFS might be taking exception to some other network packet. I plan to test out the RPi connected directly to a RiscPC – this would eliminate other network packets from the equation.

Ralph

Try the usual “fix” for ShareFS problems, which is to do:

*ShareFSWindow 1

…on both machines.

Thanks for the suggestion Bryan. I’ve just tried the command “*SharedFSWindow 1” on both machines (RiscPC and RPi). However I still get identical symptoms. The ShareFS icon shows an error state a 30-60 seconds after opening a shared drive on the RiscPC.

Ralph

I’ve just verified that the same symptoms occur on a small LAN where the RPi is just connected via a switch to a RiscPC (4.02). There are no other devices present. About 30-60 seconds after opening the filer window on the RiscPC on the RPI, the ShareFS connection is ‘lost’ and the icon on the RPi iconbar becomes greyed out. Only way to recover is to reboot the RPI.

RiscPC IP addres is 192.168.0.164
RPi IP address is 192.168.0.162

RiscPC is fitted with an I-cubed EtherLAN500ALk podule.

Is ShareFS working reliably to old Acorn machines from an RPi for anybody else ?

Ralph

I have had the same problem with a Pandaboard ES. Try loading some files from the network onto the panda and the ‘Drives’ icon greys out and the transfer fails.

Just tried ShareFS with Beagle -xM 5.19 2nd Sept 12 ROM to Kinetic RiscPC with UniPod and RISC OS 6.20 and pushing/pulling files from either machine is OK. I tried a 48M file as the test. The only thing was that pulling to the Kinetic from the Beagle was alittle slow and had the hourglass coming up every now and then.

Chris, does the Panda use the EtherUSB? If so does the EtherUSB module now assign different MAC ID’s as if not your router may be trying to assign the same IP address as the Pi if using DHCP.

as if not your router may be trying to assign the same IP address as the Pi

it cannot be this as they are not both connected at the same time.

It uses EtherUSB 0.21 (in ROM).

After some tweaking (I have the Pandaland support) and upgrading to the latest rom (27-Sep-2012) it seems to work with no problems.

I’ve just updated my SD Card with the ROM image (only) from 27-Sep-2012, and it the symptoms remain the same. Boot files are still from the 24-Sep-2012 Distro.

ShareFS (version 3.54 14_Jul_2012) seems to ‘stop working’ after 30-60 seconds when connected to a RiscPC.

This issue occurs with a direct ethernet connection between the RPi and the RiscPC. i.e. no DHCP server and no router are involved.

Ralph

I had a problem like this at the last SAUG meeting. The setup had not been a problem at home, but drives kept falling off at the meeting. No Risc PC involved; just an Iyonix, a BeagegleBoard xM and a Raspberry Pi.

One difference was that there was no gateway at the meeting. Maybe you could try with and without a gateway connected, and see if it makes any difference.

There doesn’t appear to be a gateway on the LAN that my RPi and RiscPCs are connected to. I’ll try and get a Gateway set-up, and then see if this makes any difference.

Ralph

SharFS still ‘stopped’ working in the same manner when connected on a small network with just a RiscPC 3.7 and a router.

Ralph

Posted from a RiscOS RPi on a Pendolino at 100mph, via the Edimax box and a MiFi. Lapdock works suprisingly well under RiscOS, although I wish I’d remembered to bring a mouse.

Just noticed by accident that this ShareFS issue only occurs with one of my RPis ! ShareFS works fine on my other RPi :-)

Both RPis are Farnell supplied Rev. 1 0002? versions (i.e. mainstream from July 2012).

So either due to a hardware fault on my RPi or perhaps there is a memory address that’s not initialised correcty (and just relying on a random ‘1’ or ‘0’ in the ShareFS code ?).

Interestingly, the RPi that works OK with ShareFS used to have an issue whereby it would only boot up into RiscOS about 50% of the time back around July 2012 (but Linux always booted fine). This RPi now always now boots up fine with the newer RiscOS builds. Again, I suspect that that there might have been some other bit of critical code where a register was being used without first being initialised ??

Ralph

Just noticed by accident that this ShareFS issue only occurs with one of my RPis ! ShareFS works fine on my other RPi :-)

in a task window: ifconfig -a for both machines and post the output here.

Do they both have exactly the same ethernet card running exactly the same firmware?

Both the RPis have identical setup and boot from the same flash SD card. I just removed one RPi and plugged all the cables into my ‘spare’ RPi.

I will capture the ‘ifconfig’ -a info on Monday when I’m back at work. I will also give the errant RPi a good test with Linux loaded, just to rule out the network hardware.

Ralph

As requested here are the before and after ifconfig -a screen captures (captures using *spool).

Before:

ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
ej0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.0.162 netmask 0xffffff00 broadcast 192.168.0.255
ether b8:27:eb:08:b7:91

After (with shared disc icon ‘greyed-out’):

ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
ej0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.0.162 netmask 0xffffff00 broadcast 192.168.0.255
ether b8:27:eb:08:b7:91

Ralph

Using the latest build of Raspian Linux the ‘faulty’ RPi appeared to copy a 1GB file from a remote file-share OK via the RPi ethernet port. Whereas using ShareFS on RiscOS the drive icons dissappear and the iconbar ShareFS icon ‘greys-out’(*) after about 30-60 seconds after a ShareFS file copy has commenced from a RiscPC.

Ralph

• icon changes to a different icon with a red ‘STOP’ sign.

icon changes to a different icon with a red ‘STOP’ sign.

This usually means the machine on which the icon ‘greys out’ can no longer see the remote share – which has either been turned off or crashed in some way. Have you tried rebooting the remote Risc PC, rather than the Pi, to see if the greyed out sharefs icon changes back to the normal icon? It’s odd that one Pi works and the other doesn’t, everything else being the same.

everything else being the same.

It would be interesting to see the ‘ifconfig -a’ on the Pi that does not grey out.

Humble Pi time.

I re-tried the 2nd RPi and it now displays the same symptoms as the first RPi. ShareFS on the 2nd RPi was working as previously reported on Friday, as I used it to successfully transfer several directories from a RiscPC.

So neither of my RPi’s work reliably with ShareFS.

Ralph

ShareFS works much much better with the 5.19 RiscOS RPi ‘official’ release and the ROM dated 28-Oct-12. ShareFS no longer loses its connection to the RiscPCs after 30-60 seconds :-) Tested on both my RPis.

ShareFS still loses its connection to the RiscPCs after minutes or hours (I will do some more investigation although ShareFS is ‘flaky’ even on the old RiscPCs etc.).

ShareFS now very useable for copying files back-and-forth reliably between my RPis and other old Acorn RiscOS machines:-) So thanks to whoever made whatever change in RiscOS or the RPi boot files (more likely I guess??).

Ralph