External SSD randomly fails with I/O and XHCI controller error

General Discussion
1

Hi team,
I am facing a weird issue. I have connected an external Crucial 240 GB SSD to USB 3.0 port. This drive randomly gets I/O error. I got it replaced but new one also gives same errors if I check the kernel logs using command “dmesg -l err,crit,alert,emerg”. This pi 4 has immich installed through Docker.

I am using DietPi v9.1.1.

I get below output on dmesg command:

[    0.565646] bcm2708_fb soc:fb: Unable to determine number of FBs. Disabling driver.
[  856.029264] xhci_hcd 0000:01:00.0: xHCI host controller not responding, assume dead
[  856.029354] xhci_hcd 0000:01:00.0: HC died; cleaning up
[  856.030280] I/O error, dev sda, sector 2160 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 2
[  856.030299] Buffer I/O error on dev sda1, logical block 14, lost async page write
[  856.030418] I/O error, dev sda, sector 2176 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 2
[  856.030429] Buffer I/O error on dev sda1, logical block 16, lost async page write
[  856.030490] I/O error, dev sda, sector 2208 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 2
[  856.030502] Buffer I/O error on dev sda1, logical block 20, lost async page write
[  856.030545] I/O error, dev sda, sector 16975712 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 2
[  856.030559] Buffer I/O error on dev sda1, logical block 2121708, lost async page write
[  856.030599] I/O error, dev sda, sector 16975728 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 2
[  856.030612] Buffer I/O error on dev sda1, logical block 2121710, lost async page write
[  856.030652] I/O error, dev sda, sector 25429920 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 2
[  856.030665] Buffer I/O error on dev sda1, logical block 3178484, lost async page write
[  856.030703] I/O error, dev sda, sector 25708400 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 2
[  856.030715] Buffer I/O error on dev sda1, logical block 3213294, lost async page write
[  856.030757] I/O error, dev sda, sector 26314152 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 2
[  856.030769] Buffer I/O error on dev sda1, logical block 3289013, lost async page write
[  856.030807] I/O error, dev sda, sector 26707408 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 2
[  856.030819] Buffer I/O error on dev sda1, logical block 3338170, lost async page write
[  856.030856] I/O error, dev sda, sector 26839032 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 2
[  856.030869] Buffer I/O error on dev sda1, logical block 3354623, lost async page write
[  856.081220] EXT4-fs error (device sda1): ext4_check_bdev_write_error:218: comm kworker/u8:4: Error while async write back metadata
[  856.081290] Aborting journal on device sda1-8.
[  856.081307] EXT4-fs error (device sda1) in ext4_reserve_inode_write:5839: Journal has aborted
[  856.081324] EXT4-fs error (device sda1): __ext4_ext_dirty:202: inode #3556560: comm kworker/u8:4: mark_inode_dirty error
[  856.081347] EXT4-fs error (device sda1): ext4_check_bdev_write_error:218: comm kworker/u8:4: Error while async write back metadata
[  856.081349] JBD2: I/O error when updating journal superblock for sda1-8.
[  856.081366] EXT4-fs error (device sda1) in ext4_mb_clear_bb:6077: Journal has aborted
[  856.081381] EXT4-fs (sda1): Delayed block allocation failed for inode 3556560 at logical offset 0 with max blocks 83 with error 30
[  856.081395] EXT4-fs (sda1): This should not happen!! Data will be lost

[  856.081422] EXT4-fs error (device sda1) in ext4_writepages:2854: Journal has aborted
[  856.082069] EXT4-fs error (device sda1): ext4_journal_check_start:83: comm kworker/u8:4: Detected aborted journal
[  856.082177] EXT4-fs (sda1): previous I/O error to superblock detected
[  856.082220] EXT4-fs (sda1): I/O error while writing superblock
[  856.082251] EXT4-fs (sda1): Remounting filesystem read-only
[  856.082262] EXT4-fs (sda1): ext4_writepages: jbd2_start: 9223372036854775807 pages, ino 3556561; err -30
[ 8972.824150] EXT4-fs error (device sda1): __ext4_find_entry:1664: inode #3538945: comm immich_server: reading directory lblock 0
[ 8973.075529] EXT4-fs error (device sda1): __ext4_find_entry:1664: inode #3540444: comm immich_server: reading directory lblock 0
[ 8973.102745] EXT4-fs error (device sda1): __ext4_find_entry:1664: inode #3540444: comm immich_server: reading directory lblock 0
[ 8973.723127] EXT4-fs error (device sda1): __ext4_find_entry:1664: inode #3538945: comm immich_server: reading directory lblock 0
[ 8973.823943] EXT4-fs error (device sda1): __ext4_find_entry:1664: inode #3538945: comm immich_server: reading directory lblock 0
[ 8973.871829] EXT4-fs error (device sda1): __ext4_find_entry:1664: inode #3538945: comm immich_server: reading directory lblock 0

Thank you.

2

How does the drive is powered? Does it have own PSU? Because RPI4 is know to not be able to power USB device larger than pen sticks. Means, things HDD or SSD would need an extra power supply.

3

I have powered it through raspberry pi only. I have one more raspberry pi with Dietpi 8 with a HDD attached to USB3.0. There I do not get the any issues. But this SSD one is giving problem.

4

As said, on RPI4 it’s highly recommended to use external PSU for attached HDD/SSD. By design, RPI4 usb port’s are not designed to power larger things (according RPI developer). You are not the first user having this behaviour.

5

Thanks for reply. So, shall I assume that if I use separate PSU to disk then this issue will be resolved?

6

A powered USB hub should be fine as well. However there could be files damaged already. Depends on what is stored on your SSD.

7

I have total 2 raspberry pi4 devices. Both have 4 GB RAM. I tried same SSD with other pi 4 by directly connecting with USB- port of pi. It did not fail at all. Only difference I see between working pi and non working is their DietPi version.
Working pi: DietPi 8
Non-Working: Dietpi 9

Both have same PSU.

What do you think would be the reason?

8

Probably a different Raspberry Pi kernel version having different power consumption, leading to power issues on the device having challenges. As already said, USB ports of RPi4 are physically not designated to power larger USB devices.

9

Where can I get image of Dietpi 8? I searched but couldn’t get that version.

10

https://dietpi.com/downloads/images/
But on first boot it will do an automatic update. You can interrupt that with ctrl+c.

11

Thank you, but I checked this page. It seems to have this year’s image and not Dietpi 8.x.x version. Do you have link to 8.x.x version please?

12

We don’t have DietPi V8 image. And you would need to compare Debian + kernel version of both systems. Theoretically a downgrade of RPi kernel would be possible but not recommended.

13

OK, thank you. I was thinking to pull raspbian and build on top of that from branch 8. How shall I go ahead?

14

Looks like the specific version of Kernel (6.1.21-v8+) has an issue as listed here. Pi 5 xHCI controller fails during disk-to-disk copy behind a hub · Issue #5753 · raspberrypi/linux · GitHub

15

This is related to RPi5 isn’t it? Or does it apply to RPi4 as well.

Once again, it’s related to kernel/ firmware version. It has nothing to do with DietPi version. There is no relation between DietPi and RPi kernel version.

16

It happened with my Rpi4.
Yes, sorry, I didn’t want to blame. But want to resolve this issue. What would be best possible way to build 8.25 from scratch.

Thank you.

17

We still misunderstood each other. DietPi version nas nothing to do with kernel version. Even on 8.x you can get kernel 6.1x.

That’s why you need to compare kernel version between both systems.

18

On 8 we have 5.10.103-v8+

19

looks like even a different Debian version. Can you check

echo $G_DISTRO_NAME $G_RASPBIAN
20

Upon execution of above command I get buster 0.