Hi Tobiasz, Tobiasz Karoń writes: > [Wed Nov 12 11:11:01 2025] sd 2:0:0:0: [sdc] tag#5 > uas_eh_abort_handler 0 uas-tag 1 inflight: CMD > [Wed Nov 12 11:11:01 2025] sd 2:0:0:0: [sdc] tag#5 CDB: ATA command > pass through(16) 85 06 0c 00 d4 00 00 00 82 00 4f 00 c2 00 b0 00 > [Wed Nov 12 11:11:01 2025] scsi host2: uas_eh_device_reset_handler start > [Wed Nov 12 11:11:01 2025] usb 4-1.2: reset SuperSpeed USB device > number 7 using xhci_hcd > [Wed Nov 12 11:11:01 2025] scsi host2: uas_eh_device_reset_handler success > > That happens after a minute wheenver I do: > smartctl -l long -C /dev/sdc > > So it seems I can't do a long, captive HDD test through this enclosure. > This is the self-test log for the drive: USB attached disks, even directly attached (like WD Passport*) without a SATA2USB bridge are unfortunately often...special...this way. The way to run a long SMART test on them (if the controller isn't uselessly buggy) is to use a "while true" loop to do something like dd a block from /dev/urandom to /mnt/point/delete_me, sleep for a period shorter than then the enclosure's sleep timeout (IIRC there are bad controllers that will always sleep even if you tell them not to), sync, allow to iterate, and interrupt the loop after you've allowed the long test to complete, plus an hour, plus checked the self-test log (checking the log will abort a running test!). I've also, 3× now, run into disks that marked blocks for reallocation, in firmware, during their first write -> read_verify-write cycle, wrote to the manufacturer (three different manufacturers), and was told that was normal--oh brave new world. > root@pve:/mnt# smartctl -l xselftest /dev/sdc > smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-16-pve] (local build) > Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org > > === START OF READ SMART DATA SECTION === > SMART Extended Self-test Log Version: 1 (1 sectors) > Num Test_Description Status Remaining > LifeTime(hours) LBA_of_first_error > # 1 Extended captive Interrupted (host reset) 90% 42 - > # 2 Extended captive Interrupted (host reset) 90% 42 - > # 3 Extended offline Aborted by host 90% 42 - > # 4 Extended offline Aborted by host 90% 1 - > > I have tested blacklisting the uas driver, but the enclosure would > just not show up (should I load an alternative driver for it?) > lsusb says this about the 2-bay disk enclosure: > Bus 004 Device 007: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA > 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, > ASM1153E SATA 6Gb/s bridge > > I wonder if there's something that can be done about this enclosure in > terms of patching the driver or something? > Should I contact a different mailing list? > This is by no means Btrfs-specific at this point. I don't have experience with this chipset, and someone[s] in the following thread maintain[s] that it works fine in UASP mode in 2022 (it is documented in various places that it was not fine in 2015). https://forums.raspberrypi.com/viewtopic.php?t=339591&start=25 > About write cache disabling, I was unable to do it persistently with > hdparm, but I found that there's a way to disable write caching > persistently with smartclt. It's also possible to disable write cache > reordering, which I suppose could be more dangerous fro Btrfs. I have > once used bcache with Btrfs in writeback mode and after a particular > system crash the FS has gone bad. (I've even written a song about > it..) > smartctl -s wcreorder=off,p /dev/sdc > > I have attempted to disable autosuspend for all xhci controlers using PowerTop: Have you tried adding "usbcore.autosuspend=-1" to your kernel arguments? (ie: /etc/default/grub, then run `update-grub`). > Good Enable SATA link power management for host0 > Good Enable Audio codec power management > Bad Autosuspend for USB device xHCI Host Controller [usb1] > Good Autosuspend for USB device USB2.0 Hub > [VIA Labs, Inc. ] > Good Autosuspend for USB device USB2.0 Hub [1-1] > Good Autosuspend for USB device USB2.1 Hub [Generic] > Bad Autosuspend for USB device xHCI Host Controller [usb3] > Good Autosuspend for USB device USB3.0 Hub > [VIA Labs, Inc. ] > Bad Autosuspend for USB device xHCI Host Controller [usb2] > Good Autosuspend for USB device USB3.2 Hub [Generic] > Bad Autosuspend for USB device xHCI Host Controller [usb4] How is VIA's xHCI support for UASP? Missing usb-host quirks could hypothetically be needed, and USB device manufacturers sometimes assume Intel to such an extent that there have been cases where the hardware (I'm thinking of a handful of audio interfaces) didn't work at all on AMD motherboards of that era. I assume this class of issue can be mitigated in-kernel. Cheers, Nicholas