Portable SSD keeps giving errors (but works fine on Windows)

I keep getting errors like this:

set 18 13:06:09 helios kernel: usb 2-3: new SuperSpeed Gen 1 USB device number 9 using xhci_hcd
set 18 13:06:09 helios kernel: usb 2-3: New USB device found, idVendor=152d, idProduct=0562, bcdDevice= 6.06
set 18 13:06:09 helios kernel: usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
set 18 13:06:09 helios kernel: usb 2-3: Product: External
set 18 13:06:09 helios kernel: usb 2-3: Manufacturer: JMicron
set 18 13:06:09 helios kernel: usb 2-3: SerialNumber: DD56419884719
set 18 13:06:09 helios kernel: scsi host5: uas
set 18 13:06:09 helios mtp-probe[22516]: checking bus 2, device 9: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-3"
set 18 13:06:09 helios mtp-probe[22516]: bus: 2, device: 9 was not an MTP device
set 18 13:06:09 helios kernel: scsi 5:0:0:0: Direct-Access     JMicron  Tech             0606 PQ: 0 ANSI: 6
set 18 13:06:09 helios kernel: sd 5:0:0:0: Attached scsi generic sg1 type 0
set 18 13:06:09 helios kernel: sd 5:0:0:0: [sdb] 15624192 4096-byte logical blocks: (64.0 GB/59.6 GiB)
set 18 13:06:09 helios kernel: sd 5:0:0:0: tag#18 data cmplt err -75 uas-tag 1 inflight: CMD 
set 18 13:06:09 helios kernel: sd 5:0:0:0: tag#18 CDB: Mode Sense(6) 1a 00 3f 00 04 00
set 18 13:06:09 helios kernel: sd 5:0:0:0: [sdb] Write Protect is off
set 18 13:06:09 helios kernel: sd 5:0:0:0: [sdb] Mode Sense: 00 00 00 00
set 18 13:06:10 helios mtp-probe[22540]: checking bus 2, device 9: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-3"
set 18 13:06:10 helios mtp-probe[22540]: bus: 2, device: 9 was not an MTP device

set 18 13:06:40 helios kernel: sd 5:0:0:0: tag#19 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN 
set 18 13:06:40 helios kernel: sd 5:0:0:0: tag#19 CDB: Mode Sense(6) 1a 00 08 00 04 00
set 18 13:06:40 helios kernel: scsi host5: uas_eh_device_reset_handler start
set 18 13:06:40 helios kernel: usb 2-3: reset SuperSpeed Gen 1 USB device number 9 using xhci_hcd
set 18 13:06:40 helios kernel: scsi host5: uas_eh_device_reset_handler success
set 18 13:06:40 helios kernel: sd 5:0:0:0: tag#19 data cmplt err -75 uas-tag 1 inflight: CMD 
set 18 13:06:40 helios kernel: sd 5:0:0:0: tag#19 CDB: Mode Sense(6) 1a 00 08 00 04 00
set 18 13:06:40 helios kernel: sd 5:0:0:0: [sdb] Asking for cache data failed
set 18 13:06:40 helios kernel: sd 5:0:0:0: [sdb] Assuming drive cache: write through

set 18 13:06:49 helios kernel: pcieport 0000:00:1d.4: AER: Corrected error received: 0000:08:00.0
set 18 13:06:49 helios kernel: alx 0000:08:00.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID)
set 18 13:06:49 helios kernel: alx 0000:08:00.0: AER:   device [1969:e0b1] error status/mask=00000080/00002000
set 18 13:06:49 helios kernel: alx 0000:08:00.0: AER:    [ 7] BadDLLP               
set 18 13:06:50 helios kernel: pcieport 0000:00:1d.4: AER: Corrected error received: 0000:08:00.0
set 18 13:06:50 helios kernel: alx 0000:08:00.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID)
set 18 13:06:50 helios kernel: alx 0000:08:00.0: AER:   device [1969:e0b1] error status/mask=00000080/00002000
set 18 13:06:50 helios kernel: alx 0000:08:00.0: AER:    [ 7] BadDLLP

when I connect the FS200 Mini Portable SSD - USB3.1 on my notebook with Manjaro KDE 20.1.

Also, I got a lot of CPU usage during regular intervals while the FS200 is connected.

But it works fine on Windows 10 (dual boot).

https://www.dmlifeco.com/solid-state-drive-and-case/ssd/fs200-mini-portable-ssd-usb3-1.html

From what I could see over the interwebz, below parameter added to kernel command line in grub will help:

pcie_aspm=off

that would go to “/etc/default/grub” into this line [append before endquote - "]:

GRUB_CMDLINE_LINUX_DEFAULT=“quiet udev.log_priority=3 pcie_aspm=off”

then just:

update-grub

or:

grub-mkconfig -o /boot/grub/grub.cfg

and reboot the node, then check journalctl -xe or dmesg again after connecting the drive back to the computer.

Thanks for the help, I will test (cannot reboot now) and report if worked.

This parameter can cause any collateral effect?

Edit: I found in this link - Power management - ArchWiki - at the section USB autosuspend some examples of whitelist/blacklist; maybe I can use this method to blacklist only this device…

Tried to create /etc/udev/rules.d/50-usb_power_save.rules with the following content:

# blacklist for usb autosuspend
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="152d", ATTR{idProduct}=="0562", GOTO="power_usb_rules_end"

ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"
LABEL="power_usb_rules_end"

but it doesn work.

I tried the parameter on grub and it also doesn’t work.

You can see on the screenshots the CPU usage pattern when the FS200 is connected/disconnected.