5

for a few weeks now, I have been suffering with the following problem:

I wanted to set up a NAS with a Raspberry Pi 4 and two WD Red, running ubuntu server, since the RPi 4 finally supports USB 3.0. Because the HDDs need more power, I have worked from the beginning with active SATA-USB adapters. However, a disk was always ejected and then remounted. This process was a matter of just one or two seconds and each time, the drive letter changed (sda > sdc ...). Also, each time my software raid was destroyed and the disks had to resynchronize.

While troubleshooting I stumbled across two error messages

  • over-current change #34

  • uas_eh_abort_handler 0 uas-tag 13 inflight: CMD OUT

The second was UAS causing problems, so I immediately blocked it as follows:

  • Create /boot/firmware/cmdline.txt

  • Add this line: usb-storage.quirks=174c:55aa:u

  • Update initramfs

    Now, the UAS related errors were gone.

For the first error, I needed some time to find out what was wrong. Afterwards it turned out that I needed an active USB hub in addition to my active SATA USB adapters to make this error message go away.

But now I still get a hard drive ejected regularly. I can't reliably reproduce the error though. What I know for sure is this: The error messages are:

usb 2-1.2: reset SuperSpeed Gen 1 USB device number 4 using xhci_hcd
usb 2-1.2: device firmware changed
usb 2-1.2: USB disconnect, device number 4
sd 1:0:0:0: [sdb] Synchronizing SCSI cache
blk_update_request: I/O error, dev sdb, sector 114344960 op 0x0:(READ) flags 0x0 phys_seg 4 prio class 0
blk_update_request: I/O error, dev sdb, sector 114345472 op 0x0:(READ) flags 0x0 phys_seg 5 prio class 0
blk_update_request: I/O error, dev sdb, sector 114352128 op 0x0:(READ) flags 0x0 phys_seg 22 prio class 0
sd 1:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
usb 2-1.2: new SuperSpeed Gen 1 USB device number 5 using xhci_hcd
usb 2-1.2: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
New USB device strings: Mfr=2, Product=3, SerialNumber=1
usb 2-1.2: Product: ASM105x
usb 2-1.2: Manufacturer: ASMedia
usb 2-1.2: SerialNumber:      WD-WCC7K0ZET7JE
usb 2-1.2: UAS is blacklisted for this device, using usb-storage instead
usb-storage 2-1.2:1.0: USB Mass Storage device detected
usb-storage 2-1.2:1.0: Quirks match for vid 174c pid 55aa: c00000
scsi host2: usb-storage 2-1.2:1.0
scsi 2:0:0:0: Direct-Access     ASMedia  ASM105x          0    PQ: 0 ANSI: 6
sd 2:0:0:0: Attached scsi generic sg1 type 0
sd 2:0:0:0: [sdc] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB)
sd 2:0:0:0: [sdc] 4096-byte physical blocks
sd 2:0:0:0: [sdc] Write Protect is off
sd 2:0:0:0: [sdc] Mode Sense: 43 00 00 00
sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, does not support DPO or FUA
sdc: sdc1
sd 2:0:0:0: [sdc] Attached SCSI disk
md: super_written gets error=10
md: super_written gets error=10
md: super_written gets error=10
[...more lines with the same message...]
Aborting journal on device md0-8.
Buffer I/O error on dev md0, logical block 488144896, lost sync page write
JBD2: Error -5 detected when updating journal superblock for md0-8.

Those errors do not occur when I

  • plug the active USB 3.0 Hub directly into the USB 2 ports.
  • use an active USB2 hub.

From this I conclude that this problem is related to usb 3.0 on the raspberry Pi.

Currently the NAS is running on the USB 2 ports without any other errors. (Already for several days.) But i would rather not run the NAS using USB 2, as I could use USB 3 to take advantage of my gigabit connection.

Does anyone have any idea where those errors are coming from?

EDIT: That's the output of lsblk --fs

$ sudo lsblk --fs
    NAME        FSTYPE            LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINT
    loop2       squashfs                                                                 0   100% /snap/snapd/11115
    sda                                                                                           
    └─sda1      linux_raid_member rpi-nas:0   7904b5e5-9f92-9402-2619-eeb41b0c0645                
      └─md0     ext4                          e5c91dcc-661e-4fb5-a431-74eaf4ae80d4    2.9T    16% /mnt/nas
    sdb         linux_raid_member rpi-nas:0   7904b5e5-9f92-9402-2619-eeb41b0c0645                
    └─md0       ext4                          e5c91dcc-661e-4fb5-a431-74eaf4ae80d4    2.9T    16% /mnt/nas
    mmcblk0                                                                                       
    ├─mmcblk0p1 vfat              system-boot 4D3B-86C0                             133.7M    47% /boot/firmware
    └─mmcblk0p2 ext4              writable    79af43d1-801b-4c28-81d5-724c930bcc83   22.5G    18% /
10
  • Just outta' curiosity, do you see this error when you connect only a single disk? And FWIW, I wonder if hardware RAID might be much easier?
    – Seamus
    Commented Mar 16, 2021 at 21:06
  • Using only one hard drive, it runs fine as far as I have been able to observe.
    – JJandke
    Commented Mar 19, 2021 at 16:32
  • I enjoy fooling around with my RPis, so this is not intended to be pessimistic, BUT: I have also seen a few, uh, "shortcomings", that wouldn't be tolerated in some systems. It seems at times that RPi is a system "by hobbyists, for hobbyists", if you get my meaning.
    – Seamus
    Commented Mar 19, 2021 at 20:05
  • Yes, but that doesn't solve my problem. Could it possibly be because both hard disks (or adapters) have the same ID (174c:55aa)?
    – JJandke
    Commented Mar 22, 2021 at 16:09
  • I don't know honestly - it's something I've never encountered. That might be something to investigate - assuming it's not difficult. Have you used the command lsblk --fs to list all block storage devices on your system? It may provide something useful - the drives need not be mounted - only "plugged-in" & powered.
    – Seamus
    Commented Mar 22, 2021 at 16:38

1 Answer 1

0

I am experiencing similar problems from time to time. I have a NasPI Gemini for my pi, and I have recently added a secondary SSD to run my own Nextcloud. I see this problem as a power source problem, because it either happens when pi has to write a lot of things to the SSD no.2. due to Nextcloud sync, or when there is a concurrent read/write from the primary SSD too. I already replaced the power source of a 5V/2A to an 5V/3A one and now at least i don't see the "Undervoltage detected" error messages. But I still believe that with a better power source, i might not have these issues.

Now, I have a 12V/5A charger (something like this) and currently waiting for my step-down module (to 5V/5A) to arrive and I will connect the whole system in that way. If it helps, I will let you know guys.

1
  • Nothing changed, I don't think it's a power issue. The stepdown module works great, the charger is like 5A, no Undervoltage is detected. The issue is just simply there and that's it. And even if one SSD is active, the issue can happen. Active in a sense that read/write might occur simultaneously. Like when I sync my nextcloud from my laptop, while my phone downloads the updates. I think i should limit things, and schedule properly to avoid concurrent heavy accesses.
    – cs.lev
    Commented May 20 at 1:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.