Can I backup current emulator state - corrupted memory stick

CaptRobovski

@sugarfree thanks, I wondered about that. However, does the emulator need to be reloaded before the config change takes effect?

sugarfree

@CaptRobovski I believe so. By the way, save files are created when you choose to exit the emulator. Before that, they are stored in the
memory.

CaptRobovski

@sugarfree sounds like I'm going to be out of luck then :(

Can't back up the current memory, as I don't think you can really do that unless you're a dab hand with forensic style tools (I'm certainly not!)

Would hot swapping the flash drive possibly work? As in, if I remove the drive and plug in a different one, would RetroArch write to it on exiting the emulator? Or is the mount restricted to a specific disk identifier?

CaptRobovski

Kingston have supplied a new memory stick under warranty and I'm wondering if I'm able to hot swap it for the old one?

If I run df at the terminal, the original stick doesn't show up at all.

Do I need to configure the new stick with the correct UUID or anything for it to pick it up?

CaptRobovski

I've just checked again - the first line of output from df was:

pistation@pistation:~ $ df -h
df: /media/usb0: Input/output error

sugarfree

@CaptRobovski
Your issue is very strange. How is it possible for the system to run the ROMs but not have them be visible? Did you try accessing the files from Midnight Commander or Samba share? https://retropie.org.uk/docs/Transferring-Roms/"

CaptRobovski

@sugarfree aha! That's a great shout!

Sorry for the delay in replying - been a busy week and just had time to try.

In this time, the Pi has crashed once or twice, so the original desire to save progress is now a lost cause. However, I'm hoping I can copy the contents of the USB off onto another, so I can keep srm and roms at least.

I have a feeling that this may be a combo of:

A failing USB drive.
A permissions problem.

With the second one, I did all setup via ssh, including downloading roms. It worked without issues for ages, but I'm wondering if somehow there's ended up being a conflict where the ssh user can't see the contents of the drive, but the user for retropie can.

It may be in reality the same user...! 🙈 I use Linux a bit for web work, but I'm not great at all the stuff for using it as an actual computer.

The other thing that makes me think it could be permissions/access is I have been trying to get a Dualshock 4 controller to connect via Bluetooth. If I ssh into the Pi and run the retropie_setup script as per the guidance, it can connect to the controller, but not do anything in Emulation Station. Running it with ds4drv doesn't work either.

Then I tried to do the same from the Emulation Station front end (Retropie > Retropie Setup) and it worked flawlessly. I can control everything with the Dualshock 4 without any further setup.

So I've tried to access the USB stick via Emulation Station frontend too. Retropie > File Manager. They're all there!

Then on to point 1 above - after around 5 minutes in the file manager I started getting error messages. Have taken a couple of photos of them, as I wasn't able to copy any output. Lots of blocks failed. Lots of references to error - 71.

photos of error messages

I'm using an official Raspberry Pi 5 power supply and only have the USB stick and Bluetooth running, so I don't think there's any power issues going on.

Thank you again for your help and advice here!

sugarfree

I believe that the flash drive is failing and should be replaced. Some of the data may be corrupted. You can try to repair it with controversial results, but you have to unplug/unmount it first.

Lolonois

You noted you have a official Rpi power supply. Is it rated 3A or 5A?
--> https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#maximum-power-output

If it is a 5A power supply, underpowering is out of the mix.

Then, run lsusb and note the USB ids of the Kingston USB device. The USB ID looks like this format 174c:1153, which is VendorId:ProductId.

It is a wild guess from the distance, but I assume it might be a faulty implementation of the USB power suspend (of the device).

To work around this inhibit power suspend for the Kingston device (power/control=on) [1]

To testdrive if it solves your issue:

sudo su
echo -1 > /sys/module/usbcore/parameters/autosuspend

However, this will not survive a reboot.

To persist it:
Put a udev rule below /etc/udev/rules.d/, e.g. 99-kingston-power-control with the content (unverified):

ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="1153", TEST=="power/control", ATTR{power/control}="on"

Read: Whenever a usb device is added which has the vendor and product id and has the attribute of power/control to set it to on.
Replace the values for idVendor and idProduct with the values from the Kingston.
You can find a little context for example here [2] and the udev spec here [3].

Restart the udev system sudo udevadm control --reload

HTH

[1] https://www.kernel.org/doc/html/v6.14-rc7/driver-api/usb/power-management.html#the-user-interface-for-dynamic-pm
[2] https://hackology.co.uk/2015/selective-usb-power-saving-linux-laptop/
[3] https://wiki.archlinux.org/title/Udev

CaptRobovski

@Lolonois hi there,

Thank you so much for your advice here, and apologies for the delay in me replying. Life has been pretty busy and I haven't had a chance to try this out until now.

If I'm reading your post correctly, I think you're suggesting that the system will suspend power to the USB when it's idle or not needed for a while? I'm guessing this is a bit like when I use an external HDD on my laptop - if it's idle for a while I hear it spin up again when I try to open a file.

I've added those lines to the config and will try it for a few days to see if it fixes anything. A quick question - should the filename under etc/udev/rules.d end in the suffix '.rules' ? I have other files in there, such as 99-input.rules, 99-bluetooth.rules.

I did add the suffix to match the convention, but I noted it wasn't on your example above so thought I should check!

If this doesn't work, then I guess it must have just been a faulty memory stick. I'll swap for the new one in due course. Would you recommend me still adding the power suspend rule for the new stick?

Thanks again

Lolonois

@CaptRobovski said in Can I backup current emulator state - corrupted memory stick:

A quick question - should the filename under etc/udev/rules.d end in the suffix '.rules' ? I have other files in there, such as 99-input.rules, 99-bluetooth.rules.

No, the extension is not needed. Only the lexically order may be relevant of all rule files (cf. man udev -> RULES FILES).

The memory stick has left the factory mostly fine I would assume. It is the firmware that make things worse in use cases like this (as likely the USB spec has not been implemented by the letter by the vendor).

If you change make and model of the memory stick you may leave the power control rule enabled (adapt to the VID/PID). Does not have an impact unless you run on battery.

Or you can make a backup of you new memory stick and run it without the power control rule. If things repeat restore the memory stick and enable the rule.
However, if it repeats on a different make/model the issue could also be caused by the RaspBerry Pi Kernel USB implementation.