How to Fix USB 3.0 Drive Issues on Raspberry Pi 4

As a Linux enthusiast venturing into the world of Raspberry Pi, I recently encountered an intriguing issue while trying to utilize a 4TB HDD connected via USB 3.0. While the drive worked flawlessly when plugged into a USB 2.0 port, it remained invisible when connected to the faster USB 3.0 port.

This article delves into the troubleshooting process, outlining the potential causes and ultimately, the solution that successfully resolved the problem.

The Problem:

The Raspberry Pi 4, running NextCloudPi_11–27–20 with a Debian GNU/Linux 10 distribution, failed to detect the 4TB HDD when connected via a USB 3.0 enclosure (DELOCK 42613). The enclosure is advertised to support UASP (USB Attached SCSI Protocol), a technology designed to enhance USB 3.0 performance. However, the sudo fdisk -l command failed to list the drive, while it worked flawlessly with USB 2.0.

Investigating the Issue:

The first step in troubleshooting involved analyzing the dmesg output, providing insights into the kernel's interaction with the USB device. The dmesg log displayed consistent entries indicating successful detection and attachment of the USB drive:

      [ 1423.007653] usb 2-2: SerialNumber: 0123456789ABCDEF
[ 1423.020119] scsi host0: uas
[ 1423.026589] scsi 0:0:0:0: Direct-Access     JMicron  Generic          0508 PQ                                                                                                                                                             : 0 ANSI: 6
[ 1423.027759] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 1423.029003] sd 0:0:0:0: [sda] 7814035055 512-byte logical blocks: (4.00 TB/3.                                                                                                                                                             64 TiB)
[ 1423.029017] sd 0:0:0:0: [sda] 4096-byte physical blocks
[ 1423.029705] sd 0:0:0:0: [sda] Write Protect is off
[ 1423.029720] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08
[ 1423.030162] sd 0:0:0:0: [sda] Disabling FUA
[ 1423.030175] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, does                                                                                                                                                             n't support DPO or FUA
[ 1423.031003] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a mult                                                                                                                                                             iple of physical block size (4096 bytes)
[ 1423.060421]  sda: sda1
[ 1423.063607] sd 0:0:0:0: [sda] Attached SCSI disk
    

However, a series of error messages related to BTRFS (B-tree File System) indicated an issue with writing data to the disk, followed by the drive being mounted as read-only. This pattern was repeated every time the drive was connected via USB 3.0:

      [ 1429.434640] BTRFS: error (device sda1) in btrfs_commit_transaction:2280: errn                                                                                                                                                             o=-5 IO failure (Error while writing out transaction)
[ 1429.434694] BTRFS info (device sda1): forced readonly
    

Further research led me to discover a known problem with USB 3.0 drives and certain SATA-to-USB adapters, specifically related to UASP. These problems are often attributed to chipset compatibility issues and potential conflicts with the way the Raspberry Pi 4's USB 3.0 controllers interact with UASP.

The Solution:

Based on this information, I discovered a workaround involving a specific quirk in the usb-storage module. This quirk blacklists UASP for certain devices, preventing the USB 3.0 controller from attempting to use it and resorting to standard USB Mass Storage protocol:

1. Identifying Device ID: First, I disconnected the USB adapter, cleared the dmesg log with sudo dmesg -C, reconnected the adapter, and ran dmesg again to identify the idVendor and idProduct of the drive. The dmesg output displayed these values:

         [ 1429.955630] usb 2-2: New USB device found, idVendor=152d, idProduct=0578, bcd                                                                                                                                                             Device= 5.08
       

   
   

2. Adding the Quirk: Next, I edited the /boot/cmdline.txt file using sudo nano /boot/cmdline.txt and added the following line at the beginning:

         usb-storage.quirks=152d:0578:u
       

   
   

   This tells the system to apply the quirk for the specific vendor (152d) and product (0578).

3. Reboot: After saving the cmdline.txt file, I rebooted the Raspberry Pi.

4. Verification: Upon reboot, the dmesg log now contained lines indicating that UASP was blacklisted and the device was being handled by the standard usb-storage module:

         [    2.495725] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
   [    2.531823] usb-storage 2-1:1.0: USB Mass Storage device detected
   [    2.549642] usb-storage 2-1:1.0: Quirks match for vid 2109 pid 0715: 800000
   [    2.566177] scsi host0: usb-storage 2-1:1.0
       

   
   

Conclusion

By blacklisting UASP for my specific adapter, I managed to circumvent the compatibility issue and successfully utilize my 4TB HDD on the USB 3.0 port. This simple workaround effectively resolved the problem and restored full functionality.

This case study highlights the importance of understanding and utilizing system logs for effective troubleshooting. It also emphasizes the need for research and community support in navigating complex hardware compatibility issues.

Remember, while this solution worked for my specific situation, individual issues might require different approaches. Exploring the Raspberry Pi documentation, consulting community forums, and seeking help from online resources like Stack Overflow are invaluable tools for resolving Linux-related problems.

This troubleshooting journey served as a valuable learning experience, emphasizing the importance of meticulous analysis and a problem-solving mindset in the world of Linux and embedded systems.

Source: Stackoverflow