Raspberry PI 4 Argon One M.2 case, M.2 SSD inaccessible after a random amount of time

Troubleshooting
1

I have searched the existing open and closed issues

Required Information

  • DietPi version | 9.13.2
  • Distro version | bookworm 0
  • Kernel version | 6.12.25+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.25-1+rpt1 (2025-04-30) aarch64 GNU/Linux
  • Architecture | arm64
  • SBC model | RPi 4 Model B (aarch64)
  • Power supply used | (EG: 5V 1A RAVpower)
  • SD card used | Verbatim 64 GB
  • SSD used | Intenso M.2 512GB

Steps to reproduce the problem

  1. Start raspberry
  2. Check that the SSD is mounted and accessible.
  3. Wait for a random period
  4. Try to access the SSD
  5. Have an I/O error via an ls, cat, … command.

Expected behavior

The aim is to have an SSD that is constantly operational because it hosts docker services.

Actual behavior

The SSD becomes inaccessible after a random period, and a Raspberry reboot solves the problem until the next inaccessibility.

2

I guess the SSD doesn’t have an own PSU and is connect to RPi4 usb port only. Which basically is your problem. RPI4 USB ports are not designed to power thinks like SSD or HDD. It might work, but we have seen many issues on this. Best to use external PSU for external drives.

3

The argon one m.2 box was designed for this purpose and I can’t find a single person listing an identical problem, hence my question. Thank you for your answer.

4

at least we have a couple of post within our forum about RPi4 and issues with connected drives (without external power). If I’m not mistaken there was a statement from RPI about this in past. But I was not able to find it. Maybe @MichaIng is recalling this.

One thing in addition, if the issue happens, check for related kernel errors

dmesg -l 0,1,2,3
5

My guess is also a powering issue. These I/O errors for system command are a typical indication for this type of problem.

It’s poorly designed when it draws the power via USB ports IMO.
But maybe you have some power fluctuations inside your power grid?
So let’s check for errors, usually with power problems your get messages lik

Under-voltage detected!

6 
~# dmesg -l 0,1,2,3
[    0.680858] bcm2708_fb soc:fb: Unable to determine number of FBs. Disabling driver.
[    0.680905] bcm2708_fb soc:fb: probe with driver bcm2708_fb failed with error -2
[    7.016982] Bluetooth: hci0: BCM: firmware Patch file not found, tried:
[    7.023779] Bluetooth: hci0: BCM: 'brcm/BCM4345C0.raspberrypi,4-model-b.hcd'
[    7.031025] Bluetooth: hci0: BCM: 'brcm/BCM4345C0.hcd'
[    7.031034] Bluetooth: hci0: BCM: 'brcm/BCM.raspberrypi,4-model-b.hcd'
[    7.031037] Bluetooth: hci0: BCM: 'brcm/BCM.hcd'

Here is the result of the order, obviously nothing to do with my concern

7

Thanks for your help, but after checking No log file contains this type of message.

I’ve set up a cron job that checks the voltage and throttle every minute. See if it detects anything

8

I guess system has been rebooted after last occurred. Check as soon as the drive disappears again

9

Yes I found and linked it once, but will surely not find it anymore either in reasonable time. From their end, running USB drivers larger than a pen drive is not supported, which fits pretty well the various problems we received with this, which also are well explained with the limited USB power output of RPi up to 4. However, the Argon One M.2 case powers the RPi as well as the SSD, not the RPi powers everything. So unlikely voltage is the issue, unless the PSU itself is not powerful enough: 3A for the RPi 4, 2A for the SSD, and then there are some other features, a fan and such …

Aside of under-voltage, something else to test is hdparm spindown or APM, which sometimes causes issues.

When the drive is inaccessible, check the power state:

hdparm -C /dev/sda # just guessing device name here

APM (Advanced Power Management) is not set/changed anymore with the DietPi default config, due to low support and problems it caused with some drives, but to test whether it is supported by yours:

hdparm -B 255 /dev/sda

255 disables APM completely. As we do not change it, not sure whether it can be enabled by default by firmware, but worth a test, whether it is supported at all, and whether disabling it explicitly prevents the drive from going into some unrecoverable bad state.

Similarly, while not known to cause such issues, you could test whether putting the drive into idle mode triggers the issue immediately:

hdparm -S 120 /dev/sda

While it applies a 10 minutes idle timeout (default on DietPi images), running the command also puts the drive into idle mode immediately. If it indeed causes issues, and you have no other drive which shall go into idle mode after certain time, you could just purge hdparm altogether:

apt autopurge hdparm

If there are other drive, you’d need to set the value individually for them, which is possible as well via /etc/hdparm.conf.

If the device node is not present at all: not sure whether it is internally attached via USB?

lsmod

Should be, I am not aware of another way to attach a drive to an RPi 4, that would provide enough throughput for an SSD to make any sense.

But the kernel must then have reported an error as well.

1 Like