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
10

Still worth testing hdparm problems as suggested above, but looks like my assumption about how the SSD is powered was wrong: Persistent Undervoltage with Argon One M.2 Case - #15 by RjPi4m2 - ARGON ONE (V2 and M.2) DISCUSSION - Argon 40 Forum & Community

Looks like the whole case is basically a misconception which is doomed to not function for a notable share of users. Wasn’t Argon this overpriced design brand? I am kinda shocked they sell something like that …

They already limit official support to SATA drives only, which in average draw lower power. But of course there is no guarantee. They sell their own 5.1V 3.5A PSU, but problem is most likely or at least not always undervolted RPi, but undervolted SSD in a short peak period, which breaks detection or causes failures, potentially even randomly during operation.

Well, if it is a new case, I would ask for a refund. Instead buy a proper external drive case which allows to attach a dedicated PSU for the drive. It is not great to have 2 PSUs, but until including RPi 4, there is no other stable solution.

But maybe check how things are really attached in the case. There were some revisions.

11

Here’s what it returned just after the disappearance. This time it was after more than 12 days

[    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'
[1366752.784713] device offline error, dev sda, sector 818798927 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
[1366752.794997] Buffer I/O error on device sda1, logical block 102341674
[1366752.801682] device offline error, dev sda, sector 347815 op 0x1:(WRITE) flags 0x0 phys_seg 9 prio class 0
[1366752.811619] Buffer I/O error on device sda1, logical block 35285
[1366752.817941] Buffer I/O error on device sda1, logical block 35286
[1366752.824224] Buffer I/O error on device sda1, logical block 35287
[1366752.830505] Buffer I/O error on device sda1, logical block 35288
[1366752.836796] Buffer I/O error on device sda1, logical block 35289
[1366752.843102] Buffer I/O error on device sda1, logical block 35290
[1366752.849387] Buffer I/O error on device sda1, logical block 35291
[1366752.855667] Buffer I/O error on device sda1, logical block 35292
[1366752.861947] Buffer I/O error on device sda1, logical block 35293
[1366752.868262] device offline error, dev sda, sector 818798959 op 0x1:(WRITE) flags 0x0 phys_seg 4 prio class 0
[1366752.878577] device offline error, dev sda, sector 65535 op 0x1:(WRITE) flags 0x3000 phys_seg 1 prio class 0
[1366752.888664] Buffer I/O error on dev sda1, logical block 0, lost async page write
[1366752.896371] device offline error, dev sda, sector 65927 op 0x1:(WRITE) flags 0x3000 phys_seg 1 prio class 0
[1366752.906460] Buffer I/O error on dev sda1, logical block 49, lost async page write
[1366752.914294] device offline error, dev sda, sector 142672127 op 0x1:(WRITE) flags 0x3000 phys_seg 1 prio class 0
[1366752.924734] Buffer I/O error on dev sda1, logical block 17825824, lost async page write
[1366752.933062] device offline error, dev sda, sector 817954839 op 0x1:(WRITE) flags 0x3000 phys_seg 1 prio class 0
[1366752.943493] Buffer I/O error on dev sda1, logical block 102236163, lost async page write
[1366752.951941] device offline error, dev sda, sector 817955111 op 0x1:(WRITE) flags 0x3000 phys_seg 1 prio class 0
[1366752.962425] Buffer I/O error on dev sda1, logical block 102236197, lost async page write
[1366752.970843] device offline error, dev sda, sector 817955295 op 0x1:(WRITE) flags 0x3000 phys_seg 1 prio class 0
[1366752.981277] Buffer I/O error on dev sda1, logical block 102236220, lost async page write
[1366752.989768] Aborting journal on device sda1-8.
[1366752.994504] device offline error, dev sda, sector 499449855 op 0x1:(WRITE) flags 0x9800 phys_seg 1 prio class 0
[1366753.004942] Buffer I/O error on dev sda1, logical block 62423040, lost sync page write
[1366753.013170] JBD2: I/O error when updating journal superblock for sda1-8.
[1366753.020172] EXT4-fs error (device sda1) in ext4_reserve_inode_write:5829: IO failure
[1366753.028245] EXT4-fs (sda1): previous I/O error to superblock detected
[1366753.035001] Buffer I/O error on dev sda1, logical block 0, lost sync page write
[1366753.042617] EXT4-fs (sda1): I/O error while writing superblock
[1366753.048742] EXT4-fs (sda1): Remounting filesystem read-only
12

To me, it still somehow looks like it’s a problem with the case or the power supply. These would be the typical reasons why external disks go offline and then have I/O errors.