Lacie Rugged USB3-FW does not work with UAS

Lacie Rugged USB3-FW does not work with UAS

[Julian Sikorski]

Dear list,

it appears that lacie rugged usb3-fw is not compatible with UAS.
I have just connected my few years old Lacie Rugged USB3-FW to my new
desktop PC to see if the backups I have been creating on the laptop can
actually be restored. I have then noticed that the drive does not work
in the default configuration and the following is written to dmesg
(tested with 5.2.9-200.fc30.x86_64):



[15737.797937] usb 6-3.4.2: new SuperSpeed Gen 1 USB device number 4
using xhci_hcd

[15737.810713] usb 6-3.4.2: New USB device found, idVendor=059f,
idProduct=1061, bcdDevice= 0.01

[15737.810716] usb 6-3.4.2: New USB device strings: Mfr=2, Product=3,
SerialNumber=1

[15737.810718] usb 6-3.4.2: Product: Rugged USB3-FW

[15737.810720] usb 6-3.4.2: Manufacturer: LaCie

[15737.810722] usb 6-3.4.2: SerialNumber: 00000000157f928920fa

[15737.814775] scsi host12: uas

[15737.815237] scsi 12:0:0:0: Direct-Access     LaCie    Rugged FW USB3
 051E PQ: 0 ANSI: 6

[15737.815879] sd 12:0:0:0: Attached scsi generic sg1 type 0

[15737.824985] sd 12:0:0:0: [sdb] 1953525168 512-byte logical blocks:
(1.00 TB/932 GiB)

[15737.825098] sd 12:0:0:0: [sdb] Write Protect is off

[15737.825101] sd 12:0:0:0: [sdb] Mode Sense: 43 00 00 00

[15737.825259] sd 12:0:0:0: [sdb] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA

[15767.920938] sd 12:0:0:0: tag#24 uas_eh_abort_handler 0 uas-tag 1
inflight: IN

[15767.920942] sd 12:0:0:0: tag#24 CDB: Report supported operation codes
a3 0c 01 12 00 00 00 00 02 00 00 00

[15767.926963] scsi host12: uas_eh_device_reset_handler start

[15767.991093] usb 6-3.4.2: reset SuperSpeed Gen 1 USB device number 4
using xhci_hcd

[15768.004434] scsi host12: uas_eh_device_reset_handler success

[15798.123965] scsi host12: uas_eh_device_reset_handler start

[15798.123996] sd 12:0:0:0: tag#4 uas_zap_pending 0 uas-tag 1 inflight:

[15798.124000] sd 12:0:0:0: tag#4 CDB: Report supported operation codes
a3 0c 01 12 00 00 00 00 02 00 00 00

[15798.188039] usb 6-3.4.2: reset SuperSpeed Gen 1 USB device number 4
using xhci_hcd

[15798.201126] scsi host12: uas_eh_device_reset_handler success

[15828.333035] scsi host12: uas_eh_device_reset_handler start

[15828.333081] sd 12:0:0:0: tag#5 uas_zap_pending 0 uas-tag 1 inflight:

[15828.333085] sd 12:0:0:0: tag#5 CDB: Report supported operation codes
a3 0c 01 12 00 00 00 00 02 00 00 00

[15828.397330] usb 6-3.4.2: reset SuperSpeed Gen 1 USB device number 4
using xhci_hcd

[15828.410190] scsi host12: uas_eh_device_reset_handler success

[15858.542068] scsi host12: uas_eh_device_reset_handler start

[15858.542145] sd 12:0:0:0: tag#6 uas_zap_pending 0 uas-tag 1 inflight:

[15858.542149] sd 12:0:0:0: tag#6 CDB: Report supported operation codes
a3 0c 01 12 00 00 00 00 02 00 00 00

[15858.606350] usb 6-3.4.2: reset SuperSpeed Gen 1 USB device number 4
using xhci_hcd

[15858.619513] scsi host12: uas_eh_device_reset_handler success

[15888.753114] sd 12:0:0:0: tag#7 uas_eh_abort_handler 0 uas-tag 1
inflight: IN

[15888.753120] sd 12:0:0:0: tag#7 CDB: Report supported operation codes
a3 0c 01 93 00 00 00 00 02 00 00 00

[15888.759101] scsi host12: uas_eh_device_reset_handler start

[15888.823237] usb 6-3.4.2: reset SuperSpeed Gen 1 USB device number 4
using xhci_hcd

[15888.836526] scsi host12: uas_eh_device_reset_handler success

[15918.956115] scsi host12: uas_eh_device_reset_handler start

[15918.956160] sd 12:0:0:0: tag#8 uas_zap_pending 0 uas-tag 1 inflight:

[15918.956164] sd 12:0:0:0: tag#8 CDB: Report supported operation codes
a3 0c 01 93 00 00 00 00 02 00 00 00

[15919.021247] usb 6-3.4.2: reset SuperSpeed Gen 1 USB device number 4
using xhci_hcd

[15919.038474] scsi host12: uas_eh_device_reset_handler success

[15949.170156] scsi host12: uas_eh_device_reset_handler start

[15949.170198] sd 12:0:0:0: tag#9 uas_zap_pending 0 uas-tag 1 inflight:

[15949.170203] sd 12:0:0:0: tag#9 CDB: Report supported operation codes
a3 0c 01 93 00 00 00 00 02 00 00 00

[15949.234229] usb 6-3.4.2: reset SuperSpeed Gen 1 USB device number 4
using xhci_hcd

[15949.247353] scsi host12: uas_eh_device_reset_handler success

[15979.371204] scsi host12: uas_eh_device_reset_handler start

[15979.371248] sd 12:0:0:0: tag#10 uas_zap_pending 0 uas-tag 1 inflight:

[15979.371252] sd 12:0:0:0: tag#10 CDB: Report supported operation codes
a3 0c 01 93 00 00 00 00 02 00 00 00

[15979.435356] usb 6-3.4.2: reset SuperSpeed Gen 1 USB device number 4
using xhci_hcd

[15979.448616] scsi host12: uas_eh_device_reset_handler success

[16009.585216] sd 12:0:0:0: tag#11 uas_eh_abort_handler 0 uas-tag 1
inflight: IN

[16009.585221] sd 12:0:0:0: tag#11 CDB: Report supported operation codes
a3 0c 01 41 00 00 00 00 02 00 00 00

[16009.591243] scsi host12: uas_eh_device_reset_handler start

[16009.655518] usb 6-3.4.2: reset SuperSpeed Gen 1 USB device number 4
using xhci_hcd

[16009.668915] scsi host12: uas_eh_device_reset_handler success

[16039.788257] scsi host12: uas_eh_device_reset_handler start

[16039.788310] sd 12:0:0:0: tag#18 uas_zap_pending 0 uas-tag 1 inflight:

[16039.788314] sd 12:0:0:0: tag#18 CDB: Report supported operation codes
a3 0c 01 41 00 00 00 00 02 00 00 00

[16039.852343] usb 6-3.4.2: reset SuperSpeed Gen 1 USB device number 4
using xhci_hcd

[16039.865416] scsi host12: uas_eh_device_reset_handler success

[16069.996177] scsi host12: uas_eh_device_reset_handler start

[16069.996377] sd 12:0:0:0: tag#19 uas_zap_pending 0 uas-tag 1 inflight:

[16069.996383] sd 12:0:0:0: tag#19 CDB: Report supported operation codes
a3 0c 01 41 00 00 00 00 02 00 00 00

[16070.060474] usb 6-3.4.2: reset SuperSpeed Gen 1 USB device number 4
using xhci_hcd

[16070.073580] scsi host12: uas_eh_device_reset_handler success

[16100.204124] scsi host12: uas_eh_device_reset_handler start

[16100.204194] sd 12:0:0:0: tag#0 uas_zap_pending 0 uas-tag 1 inflight:

[16100.204198] sd 12:0:0:0: tag#0 CDB: Report supported operation codes
a3 0c 01 41 00 00 00 00 02 00 00 00

[16100.268426] usb 6-3.4.2: reset SuperSpeed Gen 1 USB device number 4
using xhci_hcd

[16100.281565] scsi host12: uas_eh_device_reset_handler success

[16100.281680] sd 12:0:0:0: [sdb] Optimal transfer size 33553920 bytes

[16130.417121] sd 12:0:0:0: tag#4 uas_eh_abort_handler 0 uas-tag 1
inflight: IN

[16130.417126] sd 12:0:0:0: tag#4 CDB: Report supported operation codes
a3 0c 01 12 00 00 00 00 02 00 00 00

[16130.423122] scsi host12: uas_eh_device_reset_handler start

[16130.488247] usb 6-3.4.2: reset SuperSpeed Gen 1 USB device number 4
using xhci_hcd

[16130.501550] scsi host12: uas_eh_device_reset_handler success

[16160.624027] scsi host12: uas_eh_device_reset_handler start

[16160.624073] sd 12:0:0:0: tag#5 uas_zap_pending 0 uas-tag 1 inflight:

[16160.624077] sd 12:0:0:0: tag#5 CDB: Report supported operation codes
a3 0c 01 12 00 00 00 00 02 00 00 00

[16160.688329] usb 6-3.4.2: reset SuperSpeed Gen 1 USB device number 4
using xhci_hcd

[16160.701498] scsi host12: uas_eh_device_reset_handler success

[16190.827973] scsi host12: uas_eh_device_reset_handler start

[16190.828050] sd 12:0:0:0: tag#6 uas_zap_pending 0 uas-tag 1 inflight:

[16190.828054] sd 12:0:0:0: tag#6 CDB: Report supported operation codes
a3 0c 01 12 00 00 00 00 02 00 00 00

[16190.892234] usb 6-3.4.2: reset SuperSpeed Gen 1 USB device number 4
using xhci_hcd

[16190.905298] scsi host12: uas_eh_device_reset_handler success

[16216.299763] usb 6-3.4.2: USB disconnect, device number 4

[16216.350027] print_req_error: I/O error, dev sdb, sector 0 flags 0

[16216.350031] Buffer I/O error on dev sdb, logical block 0, async page read

[16216.350066] print_req_error: I/O error, dev sdb, sector 0 flags 0

[16216.350073] Buffer I/O error on dev sdb, logical block 0, async page read

[16216.350093] print_req_error: I/O error, dev sdb, sector 0 flags 0

[16216.350095] Buffer I/O error on dev sdb, logical block 0, async page read

[16216.350103] ldm_validate_partition_table(): Disk read failed.

[16216.350121] print_req_error: I/O error, dev sdb, sector 0 flags 0

[16216.350123] Buffer I/O error on dev sdb, logical block 0, async page read

[16216.350143] print_req_error: I/O error, dev sdb, sector 0 flags 0

[16216.350145] Buffer I/O error on dev sdb, logical block 0, async page read

[16216.350167] print_req_error: I/O error, dev sdb, sector 0 flags 0

[16216.350169] Buffer I/O error on dev sdb, logical block 0, async page read

[16216.350189] print_req_error: I/O error, dev sdb, sector 0 flags 0

[16216.350191] Buffer I/O error on dev sdb, logical block 0, async page read

[16216.350199] Dev sdb: unable to read RDB block 0

[16216.350215] print_req_error: I/O error, dev sdb, sector 0 flags 0

[16216.350217] Buffer I/O error on dev sdb, logical block 0, async page read

[16216.350231] print_req_error: I/O error, dev sdb, sector 0 flags 0

[16216.350233] Buffer I/O error on dev sdb, logical block 0, async page read

[16216.350239]  sdb: unable to read partition table

[16216.514973] sd 12:0:0:0: [sdb] Read Capacity(16) failed: Result:
hostbyte=DID_ERROR driverbyte=DRIVER_OK

[16216.514977] sd 12:0:0:0: [sdb] Sense not available.

[16216.634949] sd 12:0:0:0: [sdb] Read Capacity(10) failed: Result:
hostbyte=DID_ERROR driverbyte=DRIVER_OK

[16216.634952] sd 12:0:0:0: [sdb] Sense not available.

[16216.682978] sd 12:0:0:0: [sdb] 0 512-byte logical blocks: (0 B/0 B)

[16216.835113] sd 12:0:0:0: [sdb] Attached SCSI disk



After some quick digging I have noticed that I have added the following
quirk to my laptop's /etc/modprobe.d back in the day:



options usb-storage quirks=059f:1061:u



Adding the same quirk to the desktop has allowed the drive to work.
Strangely enough it was only needed for USB3, connecting via USB2 cable
worked without the quirk.

There are several other reports of this drive not working with uas:

https://www.reddit.com/r/archlinux/comments/bzm443/external_hdd_not_getting_recognised_on_relatively/
https://bbs.archlinux.org/viewtopic.php?id=211523

Hopefully UAS can be fixed for this USB drive, otherwise maybe the quirk
could be integrated upstream for others to benefit from.

Re: Lacie Rugged USB3-FW does not work with UAS

[Oliver Neukum]

Am Freitag, den 23.08.2019, 15:31 +0200 schrieb Julian Sikorski:
> it appears that lacie rugged usb3-fw is not compatible with UAS.
> I have just connected my few years old Lacie Rugged USB3-FW to my new
> desktop PC to see if the backups I have been creating on the laptop can
> actually be restored.

Hi,

does that mean that we have a regression? How did you create those
backups?

	Regards
		Oliver

Re: Lacie Rugged USB3-FW does not work with UAS

[Julian Sikorski]

W dniu 23.08.2019 o 15:39, Oliver Neukum pisze:
> Am Freitag, den 23.08.2019, 15:31 +0200 schrieb Julian Sikorski:
>> it appears that lacie rugged usb3-fw is not compatible with UAS.
>> I have just connected my few years old Lacie Rugged USB3-FW to my new
>> desktop PC to see if the backups I have been creating on the laptop can
>> actually be restored.
> 
> Hi,
> 
> does that mean that we have a regression? How did you create those
> backups?
> 
> 	Regards
> 		Oliver
> 
Hi,

it is not a regression to the best of my understanding. The backups were
created on another machine using the same uas blacklist quirk.
I for some reason never reported this properly and have been using the
workaround for years now. The issue only popped back up after I tried to
connect the drive to a new PC.

Best regards,
Julian

Re: Lacie Rugged USB3-FW does not work with UAS

[Julian Sikorski]

W dniu 23.08.2019 o 15:43, Julian Sikorski pisze:
> W dniu 23.08.2019 o 15:39, Oliver Neukum pisze:
>> Am Freitag, den 23.08.2019, 15:31 +0200 schrieb Julian Sikorski:
>>> it appears that lacie rugged usb3-fw is not compatible with UAS.
>>> I have just connected my few years old Lacie Rugged USB3-FW to my new
>>> desktop PC to see if the backups I have been creating on the laptop can
>>> actually be restored.
>>
>> Hi,
>>
>> does that mean that we have a regression? How did you create those
>> backups?
>>
>> 	Regards
>> 		Oliver
>>
> Hi,
> 
> it is not a regression to the best of my understanding. The backups were
> created on another machine using the same uas blacklist quirk.
> I for some reason never reported this properly and have been using the
> workaround for years now. The issue only popped back up after I tried to
> connect the drive to a new PC.
> 
> Best regards,
> Julian
> 
Hi,

I did some further digging regarding whether this is a regression: the
quirk file on the laptop is from 15 July 2014. The machine is from ca.
May 2011. Looking through my earlier posts to linux-usb it appears that
the addition of the quirk is related to this thread:

https://marc.info/?l=linux-usb&m=140537519907935&w=2

At the same time, back in 2011, I reported that the drive was working
after some fixes:

https://marc.info/?l=linux-usb&m=132276407611433&w=2

Summing up, if this is a regression, it is not a recent one. Moreover,
as the problem appears with two machines of mine and for two other
users, it seems more likely related to the usb drive and not to the
controller.

Best regards,
Julian

Re: Lacie Rugged USB3-FW does not work with UAS

[Oliver Neukum]

Am Freitag, den 23.08.2019, 16:21 +0200 schrieb Julian Sikorski:
> 
> I did some further digging regarding whether this is a regression: the
> quirk file on the laptop is from 15 July 2014. The machine is from ca.
> May 2011. Looking through my earlier posts to linux-usb it appears that
> the addition of the quirk is related to this thread:
> 
> https://marc.info/?l=linux-usb&m=140537519907935&w=2
> 
> At the same time, back in 2011, I reported that the drive was working
> after some fixes:
> 
> https://marc.info/?l=linux-usb&m=132276407611433&w=2

Hi,

this is alarming. Was this physically the same drive? I am asking
because we have seen cases where two different devices were sold
under the same name.

	Regards
		Oliver

Re: Lacie Rugged USB3-FW does not work with UAS

[Julian Sikorski]

W dniu 23.08.2019 o 23:23, Oliver Neukum pisze:
> Am Freitag, den 23.08.2019, 16:21 +0200 schrieb Julian Sikorski:
>>
>> I did some further digging regarding whether this is a regression: the
>> quirk file on the laptop is from 15 July 2014. The machine is from ca.
>> May 2011. Looking through my earlier posts to linux-usb it appears that
>> the addition of the quirk is related to this thread:
>>
>> https://marc.info/?l=linux-usb&m=140537519907935&w=2
>>
>> At the same time, back in 2011, I reported that the drive was working
>> after some fixes:
>>
>> https://marc.info/?l=linux-usb&m=132276407611433&w=2
> 
> Hi,
> 
> this is alarming. Was this physically the same drive? I am asking
> because we have seen cases where two different devices were sold
> under the same name.
> 
> 	Regards
> 		Oliver
> 
Hi,

I do indeed own two lacie rugged drives which do differ a bit. The older
one (which was definitely working without the need for the quirk) is at
work, I will bring it home and test it in a few days.
Having said that, it appears that July 2014 is about when uas was rolled
out to the public. So maybe the drive has worked using usb storage before.

Best regards,
Julian

Re: Lacie Rugged USB3-FW does not work with UAS

[Julian Sikorski]

W dniu 24.08.2019 o 09:08, Julian Sikorski pisze:
> W dniu 23.08.2019 o 23:23, Oliver Neukum pisze:
>> Am Freitag, den 23.08.2019, 16:21 +0200 schrieb Julian Sikorski:
>>>
>>> I did some further digging regarding whether this is a regression: the
>>> quirk file on the laptop is from 15 July 2014. The machine is from ca.
>>> May 2011. Looking through my earlier posts to linux-usb it appears that
>>> the addition of the quirk is related to this thread:
>>>
>>> https://marc.info/?l=linux-usb&m=140537519907935&w=2
>>>
>>> At the same time, back in 2011, I reported that the drive was working
>>> after some fixes:
>>>
>>> https://marc.info/?l=linux-usb&m=132276407611433&w=2
>>
>> Hi,
>>
>> this is alarming. Was this physically the same drive? I am asking
>> because we have seen cases where two different devices were sold
>> under the same name.
>>
>> 	Regards
>> 		Oliver
>>
> Hi,
> 
> I do indeed own two lacie rugged drives which do differ a bit. The older
> one (which was definitely working without the need for the quirk) is at
> work, I will bring it home and test it in a few days.
> Having said that, it appears that July 2014 is about when uas was rolled
> out to the public. So maybe the drive has worked using usb storage before.
> 
> Best regards,
> Julian
> 
Hi,

I have finally managed to try the second, older drive. It turns out that 
the USB IDs are different and that the older drive (059f:103e) does 
indeed appear to work with UAS whereas the newer one (059f:1031) does not.
I can now also confirm that I bought the newer drive in November 2013 
which means that the initial attempts of getting a drive to work from 
2011 must have been with the older (working) one. This makes a 
regression less likely. My educated guess is that the newer drive was 
working from November 2013 until July 2014 when linux 3.15 came out and 
uas rollout broke the drive, after which I added the quirk and have been 
using it since.
Below is the dmesg output from connecting and disconnecting both drives, 
older (working) first and newer (not working) second:

[  103.728860] usb 1-4: new full-speed USB device number 6 using xhci_hcd
[  103.933051] usb 1-4: device descriptor read/64, error -71
[  104.214040] usb 1-4: device descriptor read/64, error -71
[  104.494718] usb 1-4: new full-speed USB device number 7 using xhci_hcd
[  105.888012] usb 2-4: new SuperSpeed Gen 1 USB device number 2 using 
xhci_hcd
[  105.910020] usb 2-4: New USB device found, idVendor=059f, 
idProduct=103e, bcdDevice= 0.02
[  105.910023] usb 2-4: New USB device strings: Mfr=2, Product=3, 
SerialNumber=1
[  105.910025] usb 2-4: Product: Rugged USB 3
[  105.910027] usb 2-4: Manufacturer: LaCie
[  105.910029] usb 2-4: SerialNumber: ce0238914a4c0000000
[  105.960279] usb-storage 2-4:1.0: USB Mass Storage device detected
[  105.960654] scsi host12: usb-storage 2-4:1.0
[  105.960719] usbcore: registered new interface driver usb-storage
[  105.962877] usbcore: registered new interface driver uas
[  107.705420] scsi 12:0:0:0: Direct-Access     ST950032 5AS 
  0002 PQ: 0 ANSI: 0
[  107.706014] sd 12:0:0:0: [sdb] 976773168 512-byte logical blocks: 
(500 GB/466 GiB)
[  107.706101] sd 12:0:0:0: Attached scsi generic sg1 type 0
[  107.706935] sd 12:0:0:0: [sdb] Write Protect is off
[  107.706939] sd 12:0:0:0: [sdb] Mode Sense: 23 00 00 00
[  107.707942] sd 12:0:0:0: [sdb] No Caching mode page found
[  107.707945] sd 12:0:0:0: [sdb] Assuming drive cache: write through
[  107.842540]  sdb: sdb1 sdb2
[  107.845196] sd 12:0:0:0: [sdb] Attached SCSI disk
[  347.637498] usb 2-4: USB disconnect, device number 2
[  362.208749] usb 2-4: new SuperSpeed Gen 1 USB device number 3 using 
xhci_hcd
[  362.230833] usb 2-4: New USB device found, idVendor=059f, 
idProduct=1061, bcdDevice= 0.01
[  362.230837] usb 2-4: New USB device strings: Mfr=2, Product=3, 
SerialNumber=1
[  362.230839] usb 2-4: Product: Rugged USB3-FW
[  362.230841] usb 2-4: Manufacturer: LaCie
[  362.230842] usb 2-4: SerialNumber: 00000000157f928920fa
[  362.270100] scsi host12: uas
[  362.270720] scsi 12:0:0:0: Direct-Access     LaCie    Rugged FW USB3 
  051E PQ: 0 ANSI: 6
[  362.271472] sd 12:0:0:0: Attached scsi generic sg1 type 0
[  362.280344] sd 12:0:0:0: [sdb] 1953525168 512-byte logical blocks: 
(1.00 TB/932 GiB)
[  362.280422] sd 12:0:0:0: [sdb] Write Protect is off
[  362.280423] sd 12:0:0:0: [sdb] Mode Sense: 43 00 00 00
[  362.280544] sd 12:0:0:0: [sdb] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
[  392.672691] sd 12:0:0:0: tag#29 uas_eh_abort_handler 0 uas-tag 1 
inflight: IN
[  392.672697] sd 12:0:0:0: tag#29 CDB: Report supported operation codes 
a3 0c 01 12 00 00 00 00 02 00 00 00
[  392.678304] scsi host12: uas_eh_device_reset_handler start
[  392.800099] usb 2-4: reset SuperSpeed Gen 1 USB device number 3 using 
xhci_hcd
[  392.848154] scsi host12: uas_eh_device_reset_handler success
[  422.875443] scsi host12: uas_eh_device_reset_handler start
[  422.875650] sd 12:0:0:0: tag#16 uas_zap_pending 0 uas-tag 1 inflight:
[  422.875654] sd 12:0:0:0: tag#16 CDB: Report supported operation codes 
a3 0c 01 12 00 00 00 00 02 00 00 00
[  422.997556] usb 2-4: reset SuperSpeed Gen 1 USB device number 3 using 
xhci_hcd
[  423.046525] scsi host12: uas_eh_device_reset_handler success
[  431.853505] usb 2-4: USB disconnect, device number 3
[  431.903459] sd 12:0:0:0: [sdb] Optimal transfer size 33553920 bytes
[  432.064456] sd 12:0:0:0: [sdb] Read Capacity(16) failed: Result: 
hostbyte=DID_ERROR driverbyte=DRIVER_OK
[  432.064459] sd 12:0:0:0: [sdb] Sense not available.
[  432.184595] sd 12:0:0:0: [sdb] Read Capacity(10) failed: Result: 
hostbyte=DID_ERROR driverbyte=DRIVER_OK
[  432.184599] sd 12:0:0:0: [sdb] Sense not available.
[  432.232451] sd 12:0:0:0: [sdb] 0 512-byte logical blocks: (0 B/0 B)
[  432.424484] sd 12:0:0:0: [sdb] Attached SCSI disk

Best regards,
Julian

Re: Lacie Rugged USB3-FW does not work with UAS

[Oliver Neukum]

[-- Attachment #1: Type: text/plain, Size: 2801 bytes --]

Am Donnerstag, den 29.08.2019, 20:33 +0200 schrieb Julian Sikorski:

Hi,

this is a relief. If necessary we can blacklist the new device.
Howevera, as that costs performance, I would appriciate if
you take first try out an alternative approach.

> [  362.230833] usb 2-4: New USB device found, idVendor=059f, 
> idProduct=1061, bcdDevice= 0.01
> [  362.230837] usb 2-4: New USB device strings: Mfr=2, Product=3, 
> SerialNumber=1
> [  362.230839] usb 2-4: Product: Rugged USB3-FW
> [  362.230841] usb 2-4: Manufacturer: LaCie
> [  362.230842] usb 2-4: SerialNumber: 00000000157f928920fa
> [  362.270100] scsi host12: uas
> [  362.270720] scsi 12:0:0:0: Direct-Access     LaCie    Rugged FW USB3 
>   051E PQ: 0 ANSI: 6
> [  362.271472] sd 12:0:0:0: Attached scsi generic sg1 type 0
> [  362.280344] sd 12:0:0:0: [sdb] 1953525168 512-byte logical blocks: 
> (1.00 TB/932 GiB)
> [  362.280422] sd 12:0:0:0: [sdb] Write Protect is off
> [  362.280423] sd 12:0:0:0: [sdb] Mode Sense: 43 00 00 00
> [  362.280544] sd 12:0:0:0: [sdb] Write cache: enabled, read cache: 
> enabled, doesn't support DPO or FUA

This means that at least the earliest commandos did get through.

> [  392.672691] sd 12:0:0:0: tag#29 uas_eh_abort_handler 0 uas-tag 1 
> inflight: IN
> [  392.672697] sd 12:0:0:0: tag#29 CDB: Report supported operation codes 
> a3 0c 01 12 00 00 00 00 02 00 00 00
> [  392.678304] scsi host12: uas_eh_device_reset_handler start
> [  392.800099] usb 2-4: reset SuperSpeed Gen 1 USB device number 3 using 
> xhci_hcd
> [  392.848154] scsi host12: uas_eh_device_reset_handler success
> [  422.875443] scsi host12: uas_eh_device_reset_handler start
> [  422.875650] sd 12:0:0:0: tag#16 uas_zap_pending 0 uas-tag 1 inflight:
> [  422.875654] sd 12:0:0:0: tag#16 CDB: Report supported operation codes 
> a3 0c 01 12 00 00 00 00 02 00 00 00
> [  422.997556] usb 2-4: reset SuperSpeed Gen 1 USB device number 3 using 
> xhci_hcd
> [  423.046525] scsi host12: uas_eh_device_reset_handler success
> [  431.853505] usb 2-4: USB disconnect, device number 3
> [  431.903459] sd 12:0:0:0: [sdb] Optimal transfer size 33553920 bytes
> [  432.064456] sd 12:0:0:0: [sdb] Read Capacity(16) failed: Result: 
> hostbyte=DID_ERROR driverbyte=DRIVER_OK

Read Capacity(16) failed

> [  432.064459] sd 12:0:0:0: [sdb] Sense not available.
> [  432.184595] sd 12:0:0:0: [sdb] Read Capacity(10) failed: Result: 
> hostbyte=DID_ERROR driverbyte=DRIVER_OK

Read Capacity(10) failed

There is a chance that this device can deal only with Read Capacity(10)
and crashes on Read Capacity(16). One difference between Usb-storage
and UAS is the order in which the 10 and 16 versions are tried.
The attached patches introduce a quirk to reverse the order
for this particular device under UAS. Could you try them?

	Regards
		Oliver

[-- Attachment #2: 0001-uas-honor-flag-to-avoid-CAPACITY16.patch --]
[-- Type: text/x-patch, Size: 928 bytes --]

From 883355951a23d3c4b3c14ca0540972739ae6ffb2 Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum@suse.com>
Date: Mon, 2 Sep 2019 13:28:39 +0200
Subject: [PATCH 1/2] uas: honor flag to avoid CAPACITY16

Copy the support over from usb-storage

Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
 drivers/usb/storage/uas.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 68b1cb0f84e5..a8bd5ff5a4b9 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -854,6 +854,10 @@ static int uas_slave_configure(struct scsi_device *sdev)
 		sdev->wce_default_on = 1;
 	}
 
+	/* Some devices cannot handle READ_CAPACITY_16 */
+	if (devinfo->flags & US_FL_NO_READ_CAPACITY_16)
+		sdev->no_read_capacity_16 = 1;
+
 	/*
 	 * Some disks return the total number of blocks in response
 	 * to READ CAPACITY rather than the highest block number.
-- 
2.16.4


[-- Attachment #3: 0002-uas-quirk-for-LaCie-Rugged-USB-3.patch --]
[-- Type: text/x-patch, Size: 1006 bytes --]

From 115389ff678cae7cb636ac7e520f06e5182cd353 Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum@suse.com>
Date: Mon, 2 Sep 2019 13:30:00 +0200
Subject: [PATCH 2/2] uas: quirk for LaCie Rugged USB 3

No. CAPACITY16 for these devices.

Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
 drivers/usb/storage/unusual_devs.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h
index ea0d27a94afe..643bba41291e 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -806,6 +806,12 @@ UNUSUAL_DEV(  0x059f, 0x0651, 0x0000, 0x0000,
 		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
 		US_FL_NO_WP_DETECT ),
 
+UNUSUAL_DEV(  0x059f, 0x103e, 0x0002, 0x0002,
+		"LaCie",
+		"Rugged USB 3",
+		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+		US_FL_NO_READ_CAPACITY_16 ),
+
 /*
  * Submitted by Joel Bourquard <numlock@freesurf.ch>
  * Some versions of this device need the SubClass and Protocol overrides
-- 
2.16.4

Re: Lacie Rugged USB3-FW does not work with UAS

[Julian Sikorski]

[-- Attachment #1: Type: text/plain, Size: 7846 bytes --]

W dniu 02.09.2019 o 13:42, Oliver Neukum pisze:
> Am Donnerstag, den 29.08.2019, 20:33 +0200 schrieb Julian Sikorski:
> 
> Hi,
> 
> this is a relief. If necessary we can blacklist the new device.
> Howevera, as that costs performance, I would appriciate if
> you take first try out an alternative approach.
> 
>> [  362.230833] usb 2-4: New USB device found, idVendor=059f,
>> idProduct=1061, bcdDevice= 0.01
>> [  362.230837] usb 2-4: New USB device strings: Mfr=2, Product=3,
>> SerialNumber=1
>> [  362.230839] usb 2-4: Product: Rugged USB3-FW
>> [  362.230841] usb 2-4: Manufacturer: LaCie
>> [  362.230842] usb 2-4: SerialNumber: 00000000157f928920fa
>> [  362.270100] scsi host12: uas
>> [  362.270720] scsi 12:0:0:0: Direct-Access     LaCie    Rugged FW USB3
>>    051E PQ: 0 ANSI: 6
>> [  362.271472] sd 12:0:0:0: Attached scsi generic sg1 type 0
>> [  362.280344] sd 12:0:0:0: [sdb] 1953525168 512-byte logical blocks:
>> (1.00 TB/932 GiB)
>> [  362.280422] sd 12:0:0:0: [sdb] Write Protect is off
>> [  362.280423] sd 12:0:0:0: [sdb] Mode Sense: 43 00 00 00
>> [  362.280544] sd 12:0:0:0: [sdb] Write cache: enabled, read cache:
>> enabled, doesn't support DPO or FUA
> 
> This means that at least the earliest commandos did get through.
> 
>> [  392.672691] sd 12:0:0:0: tag#29 uas_eh_abort_handler 0 uas-tag 1
>> inflight: IN
>> [  392.672697] sd 12:0:0:0: tag#29 CDB: Report supported operation codes
>> a3 0c 01 12 00 00 00 00 02 00 00 00
>> [  392.678304] scsi host12: uas_eh_device_reset_handler start
>> [  392.800099] usb 2-4: reset SuperSpeed Gen 1 USB device number 3 using
>> xhci_hcd
>> [  392.848154] scsi host12: uas_eh_device_reset_handler success
>> [  422.875443] scsi host12: uas_eh_device_reset_handler start
>> [  422.875650] sd 12:0:0:0: tag#16 uas_zap_pending 0 uas-tag 1 inflight:
>> [  422.875654] sd 12:0:0:0: tag#16 CDB: Report supported operation codes
>> a3 0c 01 12 00 00 00 00 02 00 00 00
>> [  422.997556] usb 2-4: reset SuperSpeed Gen 1 USB device number 3 using
>> xhci_hcd
>> [  423.046525] scsi host12: uas_eh_device_reset_handler success
>> [  431.853505] usb 2-4: USB disconnect, device number 3
>> [  431.903459] sd 12:0:0:0: [sdb] Optimal transfer size 33553920 bytes
>> [  432.064456] sd 12:0:0:0: [sdb] Read Capacity(16) failed: Result:
>> hostbyte=DID_ERROR driverbyte=DRIVER_OK
> 
> Read Capacity(16) failed
> 
>> [  432.064459] sd 12:0:0:0: [sdb] Sense not available.
>> [  432.184595] sd 12:0:0:0: [sdb] Read Capacity(10) failed: Result:
>> hostbyte=DID_ERROR driverbyte=DRIVER_OK
> 
> Read Capacity(10) failed
> 
> There is a chance that this device can deal only with Read Capacity(10)
> and crashes on Read Capacity(16). One difference between Usb-storage
> and UAS is the order in which the 10 and 16 versions are tried.
> The attached patches introduce a quirk to reverse the order
> for this particular device under UAS. Could you try them?
> 
> 	Regards
> 		Oliver
> 

Hi,

thanks for the patch! It appears that we got the drives confused, the 
one needing quirks is 059f:1061. Unfortunately, even after hand-editing 
the patch to match (attached for confirmation), uas is still not 
working. The dmesg log is unchanged:

[   67.925435] usb 2-4: new SuperSpeed Gen 1 USB device number 2 using 
xhci_hcd
[   67.947738] usb 2-4: New USB device found, idVendor=059f, 
idProduct=1061, bcdDevice= 0.01
[   67.947739] usb 2-4: New USB device strings: Mfr=2, Product=3, 
SerialNumber=1
[   67.947740] usb 2-4: Product: Rugged USB3-FW
[   67.947741] usb 2-4: Manufacturer: LaCie
[   67.947742] usb 2-4: SerialNumber: 00000000157f928920fa
[   67.978140] usbcore: registered new interface driver usb-storage
[   68.007356] scsi host12: uas
[   68.007520] usbcore: registered new interface driver uas
[   68.007781] scsi 12:0:0:0: Direct-Access     LaCie    Rugged FW USB3 
  051E PQ: 0 ANSI: 6
[   68.008589] sd 12:0:0:0: Attached scsi generic sg1 type 0
[   68.017457] sd 12:0:0:0: [sdb] 1953525168 512-byte logical blocks: 
(1.00 TB/932 GiB)
[   68.017540] sd 12:0:0:0: [sdb] Write Protect is off
[   68.017542] sd 12:0:0:0: [sdb] Mode Sense: 43 00 00 00
[   68.017693] sd 12:0:0:0: [sdb] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
[   98.221259] sd 12:0:0:0: tag#7 uas_eh_abort_handler 0 uas-tag 1 
inflight: IN
[   98.221264] sd 12:0:0:0: tag#7 CDB: Report supported operation codes 
a3 0c 01 12 00 00 00 00 02 00 00 00
[   98.226869] scsi host12: uas_eh_device_reset_handler start
[   98.348671] usb 2-4: reset SuperSpeed Gen 1 USB device number 2 using 
xhci_hcd
[   98.397136] scsi host12: uas_eh_device_reset_handler success
[  128.428023] scsi host12: uas_eh_device_reset_handler start
[  128.428224] sd 12:0:0:0: tag#4 uas_zap_pending 0 uas-tag 1 inflight:
[  128.428228] sd 12:0:0:0: tag#4 CDB: Report supported operation codes 
a3 0c 01 12 00 00 00 00 02 00 00 00
[  128.549805] usb 2-4: reset SuperSpeed Gen 1 USB device number 2 using 
xhci_hcd
[  128.597949] scsi host12: uas_eh_device_reset_handler success
[  158.632176] scsi host12: uas_eh_device_reset_handler start
[  158.632382] sd 12:0:0:0: tag#5 uas_zap_pending 0 uas-tag 1 inflight:
[  158.632385] sd 12:0:0:0: tag#5 CDB: Report supported operation codes 
a3 0c 01 12 00 00 00 00 02 00 00 00
[  158.754653] usb 2-4: reset SuperSpeed Gen 1 USB device number 2 using 
xhci_hcd
[  158.803047] scsi host12: uas_eh_device_reset_handler success
[  188.840196] scsi host12: uas_eh_device_reset_handler start
[  188.840395] sd 12:0:0:0: tag#20 uas_zap_pending 0 uas-tag 1 inflight:
[  188.840399] sd 12:0:0:0: tag#20 CDB: Report supported operation codes 
a3 0c 01 12 00 00 00 00 02 00 00 00
[  188.962059] usb 2-4: reset SuperSpeed Gen 1 USB device number 2 using 
xhci_hcd
[  189.010354] scsi host12: uas_eh_device_reset_handler success
[  219.053201] sd 12:0:0:0: tag#21 uas_eh_abort_handler 0 uas-tag 1 
inflight: IN
[  219.053206] sd 12:0:0:0: tag#21 CDB: Report supported operation codes 
a3 0c 01 93 00 00 00 00 02 00 00 00
[  219.059167] scsi host12: uas_eh_device_reset_handler start
[  219.179898] usb 2-4: reset SuperSpeed Gen 1 USB device number 2 using 
xhci_hcd
[  219.227613] scsi host12: uas_eh_device_reset_handler success
[  225.587481] nf_conntrack: default automatic helper assignment has 
been turned off for security reasons and CT-based  firewall rule not 
found. Use the iptables CT target to attach helpers instead.
[  249.255814] scsi host12: uas_eh_device_reset_handler start
[  249.256019] sd 12:0:0:0: tag#0 uas_zap_pending 0 uas-tag 1 inflight:
[  249.256023] sd 12:0:0:0: tag#0 CDB: Report supported operation codes 
a3 0c 01 93 00 00 00 00 02 00 00 00
[  249.377558] usb 2-4: reset SuperSpeed Gen 1 USB device number 2 using 
xhci_hcd
[  249.425499] scsi host12: uas_eh_device_reset_handler success
[  279.464424] scsi host12: uas_eh_device_reset_handler start
[  279.464630] sd 12:0:0:0: tag#15 uas_zap_pending 0 uas-tag 1 inflight:
[  279.464634] sd 12:0:0:0: tag#15 CDB: Report supported operation codes 
a3 0c 01 93 00 00 00 00 02 00 00 00

---disconnect---

[  280.017821] usb 2-4: USB disconnect, device number 2
[  280.017869] scsi host12: uas_eh_device_reset_handler FAILED err -22
[  280.017876] sd 12:0:0:0: Device offlined - not ready after error recovery
[  280.043423] sd 12:0:0:0: [sdb] Optimal transfer size 33553920 bytes
[  280.204419] sd 12:0:0:0: [sdb] Read Capacity(16) failed: Result: 
hostbyte=DID_ERROR driverbyte=DRIVER_OK
[  280.204422] sd 12:0:0:0: [sdb] Sense not available.
[  280.324417] sd 12:0:0:0: [sdb] Read Capacity(10) failed: Result: 
hostbyte=DID_ERROR driverbyte=DRIVER_OK
[  280.324420] sd 12:0:0:0: [sdb] Sense not available.
[  280.372418] sd 12:0:0:0: [sdb] 0 512-byte logical blocks: (0 B/0 B)
[  280.524416] sd 12:0:0:0: [sdb] Attached SCSI disk

Would it make sense to enable some debugging options?

Best regards,
Julian

[-- Attachment #2: 0002-uas-quirk-for-LaCie-Rugged-USB-3.patch --]
[-- Type: text/x-patch, Size: 1008 bytes --]

From 115389ff678cae7cb636ac7e520f06e5182cd353 Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum@suse.com>
Date: Mon, 2 Sep 2019 13:30:00 +0200
Subject: [PATCH 2/2] uas: quirk for LaCie Rugged USB 3

No. CAPACITY16 for these devices.

Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
 drivers/usb/storage/unusual_devs.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h
index ea0d27a94afe..643bba41291e 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -806,6 +806,12 @@ UNUSUAL_DEV(  0x059f, 0x0651, 0x0000, 0x0000,
 		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
 		US_FL_NO_WP_DETECT ),
 
+UNUSUAL_DEV(  0x059f, 0x1061, 0x0002, 0x0002,
+		"LaCie",
+		"Rugged FW USB3",
+		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+		US_FL_NO_READ_CAPACITY_16 ),
+
 /*
  * Submitted by Joel Bourquard <numlock@freesurf.ch>
  * Some versions of this device need the SubClass and Protocol overrides
-- 
2.16.4

Re: Lacie Rugged USB3-FW does not work with UAS

[Nathan Stratton Treadway]

On Mon, Sep 02, 2019 at 22:10:01 +0200, Julian Sikorski wrote:
> thanks for the patch! It appears that we got the drives confused, the 
> one needing quirks is 059f:1061. Unfortunately, even after hand-editing 
> the patch to match (attached for confirmation), uas is still not 
> working. The dmesg log is unchanged:
> 
> [   67.925435] usb 2-4: new SuperSpeed Gen 1 USB device number 2 using 
> xhci_hcd
> [   67.947738] usb 2-4: New USB device found, idVendor=059f, 
> idProduct=1061, bcdDevice= 0.01
> [   67.947739] usb 2-4: New USB device strings: Mfr=2, Product=3, 
> SerialNumber=1
> [   67.947740] usb 2-4: Product: Rugged USB3-FW
> [   67.947741] usb 2-4: Manufacturer: LaCie
> [   67.947742] usb 2-4: SerialNumber: 00000000157f928920fa
> [   67.978140] usbcore: registered new interface driver usb-storage
> [   68.007356] scsi host12: uas
> [   68.007520] usbcore: registered new interface driver uas
> [   68.007781] scsi 12:0:0:0: Direct-Access     LaCie    Rugged FW USB3 
>  051E PQ: 0 ANSI: 6
[...] 
> [  280.017821] usb 2-4: USB disconnect, device number 2
> [  280.017869] scsi host12: uas_eh_device_reset_handler FAILED err -22
> [  280.017876] sd 12:0:0:0: Device offlined - not ready after error recovery
> [  280.043423] sd 12:0:0:0: [sdb] Optimal transfer size 33553920 bytes
> [  280.204419] sd 12:0:0:0: [sdb] Read Capacity(16) failed: Result: 
> hostbyte=DID_ERROR driverbyte=DRIVER_OK
> [  280.204422] sd 12:0:0:0: [sdb] Sense not available.
> [  280.324417] sd 12:0:0:0: [sdb] Read Capacity(10) failed: Result: 
> hostbyte=DID_ERROR driverbyte=DRIVER_OK
> [  280.324420] sd 12:0:0:0: [sdb] Sense not available.


Oliver, does the presence of the "Read Capacity(16)" message here
indicate that either the quirk was not applied to the device or that
the patch didn't have the expected effect?

(Is there any way to check what quirks flags are actually in effect for
a device attached to the UAS driver?  For the usb-storage driver there's
both a "Quirks match for vid..." dmesg line and the Quirks: line in the 
/proc/scsi/usb-storage/* file -- but neither of those seem to exist for
the UAS driver....)

							Nathan

Re: Lacie Rugged USB3-FW does not work with UAS

[Julian Sikorski]

W dniu 04.09.2019 o 17:58, Nathan Stratton Treadway pisze:
> On Mon, Sep 02, 2019 at 22:10:01 +0200, Julian Sikorski wrote:
>> thanks for the patch! It appears that we got the drives confused, the
>> one needing quirks is 059f:1061. Unfortunately, even after hand-editing
>> the patch to match (attached for confirmation), uas is still not
>> working. The dmesg log is unchanged:
>>
>> [   67.925435] usb 2-4: new SuperSpeed Gen 1 USB device number 2 using
>> xhci_hcd
>> [   67.947738] usb 2-4: New USB device found, idVendor=059f,
>> idProduct=1061, bcdDevice= 0.01
>> [   67.947739] usb 2-4: New USB device strings: Mfr=2, Product=3,
>> SerialNumber=1
>> [   67.947740] usb 2-4: Product: Rugged USB3-FW
>> [   67.947741] usb 2-4: Manufacturer: LaCie
>> [   67.947742] usb 2-4: SerialNumber: 00000000157f928920fa
>> [   67.978140] usbcore: registered new interface driver usb-storage
>> [   68.007356] scsi host12: uas
>> [   68.007520] usbcore: registered new interface driver uas
>> [   68.007781] scsi 12:0:0:0: Direct-Access     LaCie    Rugged FW USB3
>>   051E PQ: 0 ANSI: 6
> [...]
>> [  280.017821] usb 2-4: USB disconnect, device number 2
>> [  280.017869] scsi host12: uas_eh_device_reset_handler FAILED err -22
>> [  280.017876] sd 12:0:0:0: Device offlined - not ready after error recovery
>> [  280.043423] sd 12:0:0:0: [sdb] Optimal transfer size 33553920 bytes
>> [  280.204419] sd 12:0:0:0: [sdb] Read Capacity(16) failed: Result:
>> hostbyte=DID_ERROR driverbyte=DRIVER_OK
>> [  280.204422] sd 12:0:0:0: [sdb] Sense not available.
>> [  280.324417] sd 12:0:0:0: [sdb] Read Capacity(10) failed: Result:
>> hostbyte=DID_ERROR driverbyte=DRIVER_OK
>> [  280.324420] sd 12:0:0:0: [sdb] Sense not available.
> 
> 
> Oliver, does the presence of the "Read Capacity(16)" message here
> indicate that either the quirk was not applied to the device or that
> the patch didn't have the expected effect?
> 
> (Is there any way to check what quirks flags are actually in effect for
> a device attached to the UAS driver?  For the usb-storage driver there's
> both a "Quirks match for vid..." dmesg line and the Quirks: line in the
> /proc/scsi/usb-storage/* file -- but neither of those seem to exist for
> the UAS driver....)
> 
> 							Nathan
> 
Moreover, does this matter that the two Read Capacity errors only appear 
after the device is disconnected?

Best regards,
Julian

Re: Lacie Rugged USB3-FW does not work with UAS

[Oliver Neukum]

Am Mittwoch, den 04.09.2019, 19:10 +0200 schrieb Julian Sikorski:
> 
> 
> Moreover, does this matter that the two Read Capacity errors only appear 
> after the device is disconnected?

Hi,

yes it does. However, it didn't in the first log I looked at.
Could you check whether the command the failure happens on
is constant? That is, test a few times and look for differences.

	Regards
		Oliver

Re: Lacie Rugged USB3-FW does not work with UAS

[Julian Sikorski]

W dniu 09.09.2019 o 14:45, Oliver Neukum pisze:
> Am Mittwoch, den 04.09.2019, 19:10 +0200 schrieb Julian Sikorski:
>>
>>
>> Moreover, does this matter that the two Read Capacity errors only appear
>> after the device is disconnected?
> 
> Hi,
> 
> yes it does. However, it didn't in the first log I looked at.
> Could you check whether the command the failure happens on
> is constant? That is, test a few times and look for differences.
> 
> 	Regards
> 		Oliver
> 
Hello,

I can check again, but Idid at the old log again, the errors also 
happened after disconnect with both logs I shared earlier - with the 
first one there were some I/O errors in between:

[16216.299763] usb 6-3.4.2: USB disconnect, device number 4
[16216.350027] print_req_error: I/O error, dev sdb, sector 0 flags 0
[16216.350031] Buffer I/O error on dev sdb, logical block 0, async page read
[16216.350066] print_req_error: I/O error, dev sdb, sector 0 flags 0
[16216.350073] Buffer I/O error on dev sdb, logical block 0, async page read
[16216.350093] print_req_error: I/O error, dev sdb, sector 0 flags 0
[16216.350095] Buffer I/O error on dev sdb, logical block 0, async page read
[16216.350103] ldm_validate_partition_table(): Disk read failed.
[16216.350121] print_req_error: I/O error, dev sdb, sector 0 flags 0
[16216.350123] Buffer I/O error on dev sdb, logical block 0, async page read
[16216.350143] print_req_error: I/O error, dev sdb, sector 0 flags 0
[16216.350145] Buffer I/O error on dev sdb, logical block 0, async page read
[16216.350167] print_req_error: I/O error, dev sdb, sector 0 flags 0
[16216.350169] Buffer I/O error on dev sdb, logical block 0, async page read
[16216.350189] print_req_error: I/O error, dev sdb, sector 0 flags 0
[16216.350191] Buffer I/O error on dev sdb, logical block 0, async page read
[16216.350199] Dev sdb: unable to read RDB block 0
[16216.350215] print_req_error: I/O error, dev sdb, sector 0 flags 0
[16216.350217] Buffer I/O error on dev sdb, logical block 0, async page read
[16216.350231] print_req_error: I/O error, dev sdb, sector 0 flags 0
[16216.350233] Buffer I/O error on dev sdb, logical block 0, async page read
[16216.350239]  sdb: unable to read partition table
[16216.514973] sd 12:0:0:0: [sdb] Read Capacity(16) failed: Result: 
hostbyte=DID_ERROR driverbyte=DRIVER_OK
[16216.514977] sd 12:0:0:0: [sdb] Sense not available.
[16216.634949] sd 12:0:0:0: [sdb] Read Capacity(10) failed: Result:
hostbyte=DID_ERROR driverbyte=DRIVER_OK

and

[  431.853505] usb 2-4: USB disconnect, device number 3
[  431.903459] sd 12:0:0:0: [sdb] Optimal transfer size 33553920 bytes
[  432.064456] sd 12:0:0:0: [sdb] Read Capacity(16) failed: Result: 
hostbyte=DID_ERROR driverbyte=DRIVER_OK
[  432.064459] sd 12:0:0:0: [sdb] Sense not available.
[  432.184595] sd 12:0:0:0: [sdb] Read Capacity(10) failed: Result: 
hostbyte=DID_ERROR driverbyte=DRIVER_OK

Best regards,
Julian

Re: Lacie Rugged USB3-FW does not work with UAS

[Julian Sikorski]

Am 09.09.19 um 18:18 schrieb Julian Sikorski:
> W dniu 09.09.2019 o 14:45, Oliver Neukum pisze:
>> Am Mittwoch, den 04.09.2019, 19:10 +0200 schrieb Julian Sikorski:
>>>
>>>
>>> Moreover, does this matter that the two Read Capacity errors only appear
>>> after the device is disconnected?
>>
>> Hi,
>>
>> yes it does. However, it didn't in the first log I looked at.
>> Could you check whether the command the failure happens on
>> is constant? That is, test a few times and look for differences.
>>
>>     Regards
>>         Oliver
>>
> Hello,
> 
> I can check again, but Idid at the old log again, the errors also 
> happened after disconnect with both logs I shared earlier - with the 
> first one there were some I/O errors in between:
> 
> [16216.299763] usb 6-3.4.2: USB disconnect, device number 4
> [16216.350027] print_req_error: I/O error, dev sdb, sector 0 flags 0
> [16216.350031] Buffer I/O error on dev sdb, logical block 0, async page 
> read
> [16216.350066] print_req_error: I/O error, dev sdb, sector 0 flags 0
> [16216.350073] Buffer I/O error on dev sdb, logical block 0, async page 
> read
> [16216.350093] print_req_error: I/O error, dev sdb, sector 0 flags 0
> [16216.350095] Buffer I/O error on dev sdb, logical block 0, async page 
> read
> [16216.350103] ldm_validate_partition_table(): Disk read failed.
> [16216.350121] print_req_error: I/O error, dev sdb, sector 0 flags 0
> [16216.350123] Buffer I/O error on dev sdb, logical block 0, async page 
> read
> [16216.350143] print_req_error: I/O error, dev sdb, sector 0 flags 0
> [16216.350145] Buffer I/O error on dev sdb, logical block 0, async page 
> read
> [16216.350167] print_req_error: I/O error, dev sdb, sector 0 flags 0
> [16216.350169] Buffer I/O error on dev sdb, logical block 0, async page 
> read
> [16216.350189] print_req_error: I/O error, dev sdb, sector 0 flags 0
> [16216.350191] Buffer I/O error on dev sdb, logical block 0, async page 
> read
> [16216.350199] Dev sdb: unable to read RDB block 0
> [16216.350215] print_req_error: I/O error, dev sdb, sector 0 flags 0
> [16216.350217] Buffer I/O error on dev sdb, logical block 0, async page 
> read
> [16216.350231] print_req_error: I/O error, dev sdb, sector 0 flags 0
> [16216.350233] Buffer I/O error on dev sdb, logical block 0, async page 
> read
> [16216.350239]  sdb: unable to read partition table
> [16216.514973] sd 12:0:0:0: [sdb] Read Capacity(16) failed: Result: 
> hostbyte=DID_ERROR driverbyte=DRIVER_OK
> [16216.514977] sd 12:0:0:0: [sdb] Sense not available.
> [16216.634949] sd 12:0:0:0: [sdb] Read Capacity(10) failed: Result:
> hostbyte=DID_ERROR driverbyte=DRIVER_OK
> 
> and
> 
> [  431.853505] usb 2-4: USB disconnect, device number 3
> [  431.903459] sd 12:0:0:0: [sdb] Optimal transfer size 33553920 bytes
> [  432.064456] sd 12:0:0:0: [sdb] Read Capacity(16) failed: Result: 
> hostbyte=DID_ERROR driverbyte=DRIVER_OK
> [  432.064459] sd 12:0:0:0: [sdb] Sense not available.
> [  432.184595] sd 12:0:0:0: [sdb] Read Capacity(10) failed: Result: 
> hostbyte=DID_ERROR driverbyte=DRIVER_OK
> 
> Best regards,
> Julian

Hi all,

apologies for necro-ing this thread. I have just tried this drive with 
my new laptop (Asus ZenBook UM425IA) and the same quirk was needed to 
get the drive to work:
options usb-storage quirks=059f:1061:u

Should we still try to get uas working with this drive or should I send 
a patch hardcoding a quirk? I am on 5.13.2-300.fc34.x86_64 kernel now. 
Thanks for the feedback in advance.

Best regards,
Julian

Re: Lacie Rugged USB3-FW does not work with UAS

[Oliver Neukum]

> Hi all,
>
> apologies for necro-ing this thread. I have just tried this drive with
> my new laptop (Asus ZenBook UM425IA) and the same quirk was needed to
> get the drive to work:
> options usb-storage quirks=059f:1061:u
>
> Should we still try to get uas working with this drive or should I
> send a patch hardcoding a quirk? I am on 5.13.2-300.fc34.x86_64 kernel
> now. Thanks for the feedback in advance.
>

Hi,


sometimes we must give up. This thing is too elusive. Please send a
patch with a quirk.

    Regards

        Oliver

Re: Lacie Rugged USB3-FW does not work with UAS

[Julian Sikorski]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

W dniu 19.07.2021 o 14:47, Oliver Neukum pisze:
> 
>> Hi all,
>>
>> apologies for necro-ing this thread. I have just tried this drive with
>> my new laptop (Asus ZenBook UM425IA) and the same quirk was needed to
>> get the drive to work:
>> options usb-storage quirks=059f:1061:u
>>
>> Should we still try to get uas working with this drive or should I
>> send a patch hardcoding a quirk? I am on 5.13.2-300.fc34.x86_64 kernel
>> now. Thanks for the feedback in advance.
>>
> 
> Hi,
> 
> 
> sometimes we must give up. This thing is too elusive. Please send a
> patch with a quirk.
> 
>      Regards
> 
>          Oliver
> 
> 

Hi,

thanks for confirming. Patch is attached, it appears to be working 
correctly when applied against 5.13.3. Please let me know if changes are 
required.

Best regards,
Julian

[-- Attachment #2: 0001-Add-LaCie-Rugged-USB3-FW-to-IGNORE_UAS.patch --]
[-- Type: text/x-patch, Size: 1567 bytes --]

From 01057f40aaf0036271dc401add9310dc63bfbcc1 Mon Sep 17 00:00:00 2001
From: Julian Sikorski <belegdol+github@gmail.com>
Date: Mon, 19 Jul 2021 17:27:16 +0200
Subject: [PATCH] Add LaCie Rugged USB3-FW to IGNORE_UAS

LaCie Rugged USB3-FW appears to be incompatible with UAS. It generates
errors like:
[ 1151.582598] sd 14:0:0:0: tag#16 uas_eh_abort_handler 0 uas-tag 1 inflight: IN
[ 1151.582602] sd 14:0:0:0: tag#16 CDB: Report supported operation codes a3 0c 01 12 00 00 00 00 02 00 00 00
[ 1151.588594] scsi host14: uas_eh_device_reset_handler start
[ 1151.710482] usb 2-4: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 1151.741398] scsi host14: uas_eh_device_reset_handler success
[ 1181.785534] scsi host14: uas_eh_device_reset_handler start
---
 drivers/usb/storage/unusual_uas.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h
index f9677a5ec31b..c35a6db993f1 100644
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -45,6 +45,13 @@ UNUSUAL_DEV(0x059f, 0x105f, 0x0000, 0x9999,
 		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
 		US_FL_NO_REPORT_OPCODES | US_FL_NO_SAME),
 
+/* Reported-by: Julian Sikorski <belegdol@gmail.com> */
+UNUSUAL_DEV(0x059f, 0x1061, 0x0000, 0x9999,
+		"LaCie",
+		"Rugged USB3-FW",
+		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+		US_FL_IGNORE_UAS),
+
 /*
  * Apricorn USB3 dongle sometimes returns "USBSUSBSUSBS" in response to SCSI
  * commands in UAS mode.  Observed with the 1.28 firmware; are there others?
-- 
2.31.1


[-- Attachment #3: lsusb.txt --]
[-- Type: text/plain, Size: 4180 bytes --]

Bus 002 Device 002: ID 059f:1061 LaCie, Ltd Rugged USB3-FW
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         9
  idVendor           0x059f LaCie, Ltd
  idProduct          0x1061 Rugged USB3-FW
  bcdDevice            0.01
  iManufacturer           2 LaCie
  iProduct                3 Rugged USB3-FW
  iSerial                 1 00000000157f928920fa
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0079
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              896mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           4
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     98 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
        MaxStreams             32
        Data-in pipe (0x03)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
        MaxStreams             32
        Data-out pipe (0x04)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
        MaxStreams             32
        Status pipe (0x02)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
        Command pipe (0x01)

Re: Lacie Rugged USB3-FW does not work with UAS

[Greg KH]

On Mon, Jul 19, 2021 at 06:10:10PM +0200, Julian Sikorski wrote:
> W dniu 19.07.2021 o 14:47, Oliver Neukum pisze:
> > 
> > > Hi all,
> > > 
> > > apologies for necro-ing this thread. I have just tried this drive with
> > > my new laptop (Asus ZenBook UM425IA) and the same quirk was needed to
> > > get the drive to work:
> > > options usb-storage quirks=059f:1061:u
> > > 
> > > Should we still try to get uas working with this drive or should I
> > > send a patch hardcoding a quirk? I am on 5.13.2-300.fc34.x86_64 kernel
> > > now. Thanks for the feedback in advance.
> > > 
> > 
> > Hi,
> > 
> > 
> > sometimes we must give up. This thing is too elusive. Please send a
> > patch with a quirk.
> > 
> >      Regards
> > 
> >          Oliver
> > 
> > 
> 
> Hi,
> 
> thanks for confirming. Patch is attached, it appears to be working correctly
> when applied against 5.13.3. Please let me know if changes are required.
> 
> Best regards,
> Julian

> >From 01057f40aaf0036271dc401add9310dc63bfbcc1 Mon Sep 17 00:00:00 2001
> From: Julian Sikorski <belegdol+github@gmail.com>
> Date: Mon, 19 Jul 2021 17:27:16 +0200
> Subject: [PATCH] Add LaCie Rugged USB3-FW to IGNORE_UAS
> 
> LaCie Rugged USB3-FW appears to be incompatible with UAS. It generates
> errors like:
> [ 1151.582598] sd 14:0:0:0: tag#16 uas_eh_abort_handler 0 uas-tag 1 inflight: IN
> [ 1151.582602] sd 14:0:0:0: tag#16 CDB: Report supported operation codes a3 0c 01 12 00 00 00 00 02 00 00 00
> [ 1151.588594] scsi host14: uas_eh_device_reset_handler start
> [ 1151.710482] usb 2-4: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
> [ 1151.741398] scsi host14: uas_eh_device_reset_handler success
> [ 1181.785534] scsi host14: uas_eh_device_reset_handler start
> ---
>  drivers/usb/storage/unusual_uas.h | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h
> index f9677a5ec31b..c35a6db993f1 100644
> --- a/drivers/usb/storage/unusual_uas.h
> +++ b/drivers/usb/storage/unusual_uas.h
> @@ -45,6 +45,13 @@ UNUSUAL_DEV(0x059f, 0x105f, 0x0000, 0x9999,
>  		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
>  		US_FL_NO_REPORT_OPCODES | US_FL_NO_SAME),
>  
> +/* Reported-by: Julian Sikorski <belegdol@gmail.com> */
> +UNUSUAL_DEV(0x059f, 0x1061, 0x0000, 0x9999,
> +		"LaCie",
> +		"Rugged USB3-FW",
> +		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
> +		US_FL_IGNORE_UAS),
> +
>  /*
>   * Apricorn USB3 dongle sometimes returns "USBSUSBSUSBS" in response to SCSI
>   * commands in UAS mode.  Observed with the 1.28 firmware; are there others?
> -- 
> 2.31.1
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch was attached, please place it inline so that it can be
  applied directly from the email message itself.

- Your patch does not have a Signed-off-by: line.  Please read the
  kernel file, Documentation/SubmittingPatches and resend it after
  adding that line.  Note, the line needs to be in the body of the
  email, before the patch, not at the bottom of the patch or in the
  email signature.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Re: Lacie Rugged USB3-FW does not work with UAS

[Oliver Neukum]

> Hi,
>
> thanks for confirming. Patch is attached, it appears to be working
> correctly when applied against 5.13.3. Please let me know if changes
> are required.


Hi,

could you please resend inline in the mail, as documented in the
SubmittingPatches documentation,

so that Greg can pick it up?

    Regards

        Oliver

Re: Lacie Rugged USB3-FW does not work with UAS

[Hans de Goede]

Hi,

On 7/19/21 6:10 PM, Julian Sikorski wrote:
> W dniu 19.07.2021 o 14:47, Oliver Neukum pisze:
>>
>>> Hi all,
>>>
>>> apologies for necro-ing this thread. I have just tried this drive with
>>> my new laptop (Asus ZenBook UM425IA) and the same quirk was needed to
>>> get the drive to work:
>>> options usb-storage quirks=059f:1061:u
>>>
>>> Should we still try to get uas working with this drive or should I
>>> send a patch hardcoding a quirk? I am on 5.13.2-300.fc34.x86_64 kernel
>>> now. Thanks for the feedback in advance.
>>>
>>
>> Hi,
>>
>>
>> sometimes we must give up. This thing is too elusive. Please send a
>> patch with a quirk.
>>
>>      Regards
>>
>>          Oliver
>>
>>
> 
> Hi,
> 
> thanks for confirming. Patch is attached, it appears to be working correctly when applied against 5.13.3. Please let me know if changes are required.

I seem to have missed the earlier part of this thread somehow.

Looking at the USB-ids, your model seems mightily close to this existing quirk:

UNUSUAL_DEV(0x059f, 0x105f, 0x0000, 0x9999,
                "LaCie",
                "2Big Quadra USB3",
                USB_SC_DEVICE, USB_PR_DEVICE, NULL,
                US_FL_NO_REPORT_OPCODES | US_FL_NO_SAME),

Before we go with the suggested patch, can you give the uas driver one last
try with:

options usb-storage quirks=059f:1061:fk

? The fk translates like this:

f -> US_FL_NO_REPORT_OPCODES
k -> US_FL_NO_SAME

Regards,

Hans

Re: Lacie Rugged USB3-FW does not work with UAS

[Oliver Neukum]

On 28.07.21 19:29, Julian Sikorski wrote:
> Hi all,
>
> f quirk alone seems to be sufficient.
>
Hi,

OK. Let's not rush this. Could you do a bit of testing until you are
certain and then report back?

    Regards

        Oliver

Re: Lacie Rugged USB3-FW does not work with UAS

[Hans de Goede]

Hi,

On 7/28/21 7:29 PM, Julian Sikorski wrote:
> Hi all,
> 
> f quirk alone seems to be sufficient.

Thank you for testing, but I'm not sure using only the NO_REPORT_OPCODES
quirk is wise here, the other similar La Cie drive also started out with
just that quirk, only to have the NO_SAME quirk added later. See:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8010622c86ca5bb44bc98492f5968726fc7c7a21

Actually triggering a WRITE_SAME SCSI command is likely tricky, so
it likely requires a special workload to ensure that that flag is
not necessary.

As Oliver set with the quirk to disable UAS we at least have the
drive working (albeit slower then it would work with UAS) so we
can take our time to make sure that things work properly with
the combination of the f+k flags (at least using both seems
best to me) before re-enabling UAS.

Regards,

Hans




> 
> Best regards,
> Julian
> 
> Julian Sikorski <belegdol@gmail.com <mailto:belegdol@gmail.com>> schrieb am Mi., 28. Juli 2021, 01:14:
> 
>     Hi Hans,
> 
>     apologies for top-posting and HTML but I only can send emails from my mobile currently.
>     With fk quirk the drive indeed appears to be working with uas: I can decrypt and mount a veracrypt volume from it. Thanks!
>     The patch disabling uas has already made it to Linus' tree and is about to be added to stable:
>     https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6abf2fe6b4bf6e5256b80c5817908151d2d33e9f <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6abf2fe6b4bf6e5256b80c5817908151d2d33e9f>
>     As I have no working internet on any of my Linux machines and won't for the foreseeable future (thank you construction workers), would you mind taking care of amending the quirk accordingly? Thank you in advance.
> 
>     Best regards,
>     Julian
> 
> 
>     Hans de Goede <hdegoede@redhat.com <mailto:hdegoede@redhat.com>> schrieb am Di., 27. Juli 2021, 23:19:
> 
>         Hi,
> 
>         On 7/19/21 6:10 PM, Julian Sikorski wrote:
>         > W dniu 19.07.2021 o 14:47, Oliver Neukum pisze:
>         >>
>         >>> Hi all,
>         >>>
>         >>> apologies for necro-ing this thread. I have just tried this drive with
>         >>> my new laptop (Asus ZenBook UM425IA) and the same quirk was needed to
>         >>> get the drive to work:
>         >>> options usb-storage quirks=059f:1061:u
>         >>>
>         >>> Should we still try to get uas working with this drive or should I
>         >>> send a patch hardcoding a quirk? I am on 5.13.2-300.fc34.x86_64 kernel
>         >>> now. Thanks for the feedback in advance.
>         >>>
>         >>
>         >> Hi,
>         >>
>         >>
>         >> sometimes we must give up. This thing is too elusive. Please send a
>         >> patch with a quirk.
>         >>
>         >>      Regards
>         >>
>         >>          Oliver
>         >>
>         >>
>         >
>         > Hi,
>         >
>         > thanks for confirming. Patch is attached, it appears to be working correctly when applied against 5.13.3. Please let me know if changes are required.
> 
>         I seem to have missed the earlier part of this thread somehow.
> 
>         Looking at the USB-ids, your model seems mightily close to this existing quirk:
> 
>         UNUSUAL_DEV(0x059f, 0x105f, 0x0000, 0x9999,
>                         "LaCie",
>                         "2Big Quadra USB3",
>                         USB_SC_DEVICE, USB_PR_DEVICE, NULL,
>                         US_FL_NO_REPORT_OPCODES | US_FL_NO_SAME),
> 
>         Before we go with the suggested patch, can you give the uas driver one last
>         try with:
> 
>         options usb-storage quirks=059f:1061:fk
> 
>         ? The fk translates like this:
> 
>         f -> US_FL_NO_REPORT_OPCODES
>         k -> US_FL_NO_SAME
> 
>         Regards,
> 
>         Hans
> 

Re: Lacie Rugged USB3-FW does not work with UAS

[Julian Sikorski]

Am 29.07.21 um 11:08 schrieb Hans de Goede:
> Hi,
> 
> On 7/28/21 7:29 PM, Julian Sikorski wrote:
>> Hi all,
>>
>> f quirk alone seems to be sufficient.
> 
> Thank you for testing, but I'm not sure using only the NO_REPORT_OPCODES
> quirk is wise here, the other similar La Cie drive also started out with
> just that quirk, only to have the NO_SAME quirk added later. See:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8010622c86ca5bb44bc98492f5968726fc7c7a21
> 
> Actually triggering a WRITE_SAME SCSI command is likely tricky, so
> it likely requires a special workload to ensure that that flag is
> not necessary.
> 
> As Oliver set with the quirk to disable UAS we at least have the
> drive working (albeit slower then it would work with UAS) so we
> can take our time to make sure that things work properly with
> the combination of the f+k flags (at least using both seems
> best to me) before re-enabling UAS.
> 
> Regards,
> 
> Hans
> 
Hi,

are there some tests which I could run in particular to test whether 
WRITE_SAME is working as intended? I use this drive for backups which 
means I don't connect it all that often.

Best regards,
Julian

>>
>> Best regards,
>> Julian
>>
>> Julian Sikorski <belegdol@gmail.com <mailto:belegdol@gmail.com>> schrieb am Mi., 28. Juli 2021, 01:14:
>>
>>      Hi Hans,
>>
>>      apologies for top-posting and HTML but I only can send emails from my mobile currently.
>>      With fk quirk the drive indeed appears to be working with uas: I can decrypt and mount a veracrypt volume from it. Thanks!
>>      The patch disabling uas has already made it to Linus' tree and is about to be added to stable:
>>      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6abf2fe6b4bf6e5256b80c5817908151d2d33e9f <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6abf2fe6b4bf6e5256b80c5817908151d2d33e9f>
>>      As I have no working internet on any of my Linux machines and won't for the foreseeable future (thank you construction workers), would you mind taking care of amending the quirk accordingly? Thank you in advance.
>>
>>      Best regards,
>>      Julian
>>
>>
>>      Hans de Goede <hdegoede@redhat.com <mailto:hdegoede@redhat.com>> schrieb am Di., 27. Juli 2021, 23:19:
>>
>>          Hi,
>>
>>          On 7/19/21 6:10 PM, Julian Sikorski wrote:
>>          > W dniu 19.07.2021 o 14:47, Oliver Neukum pisze:
>>          >>
>>          >>> Hi all,
>>          >>>
>>          >>> apologies for necro-ing this thread. I have just tried this drive with
>>          >>> my new laptop (Asus ZenBook UM425IA) and the same quirk was needed to
>>          >>> get the drive to work:
>>          >>> options usb-storage quirks=059f:1061:u
>>          >>>
>>          >>> Should we still try to get uas working with this drive or should I
>>          >>> send a patch hardcoding a quirk? I am on 5.13.2-300.fc34.x86_64 kernel
>>          >>> now. Thanks for the feedback in advance.
>>          >>>
>>          >>
>>          >> Hi,
>>          >>
>>          >>
>>          >> sometimes we must give up. This thing is too elusive. Please send a
>>          >> patch with a quirk.
>>          >>
>>          >>      Regards
>>          >>
>>          >>          Oliver
>>          >>
>>          >>
>>          >
>>          > Hi,
>>          >
>>          > thanks for confirming. Patch is attached, it appears to be working correctly when applied against 5.13.3. Please let me know if changes are required.
>>
>>          I seem to have missed the earlier part of this thread somehow.
>>
>>          Looking at the USB-ids, your model seems mightily close to this existing quirk:
>>
>>          UNUSUAL_DEV(0x059f, 0x105f, 0x0000, 0x9999,
>>                          "LaCie",
>>                          "2Big Quadra USB3",
>>                          USB_SC_DEVICE, USB_PR_DEVICE, NULL,
>>                          US_FL_NO_REPORT_OPCODES | US_FL_NO_SAME),
>>
>>          Before we go with the suggested patch, can you give the uas driver one last
>>          try with:
>>
>>          options usb-storage quirks=059f:1061:fk
>>
>>          ? The fk translates like this:
>>
>>          f -> US_FL_NO_REPORT_OPCODES
>>          k -> US_FL_NO_SAME
>>
>>          Regards,
>>
>>          Hans
>>
> 

Re: Lacie Rugged USB3-FW does not work with UAS

[Hans de Goede]

Hi,

On 8/1/21 9:36 AM, Julian Sikorski wrote:
> Am 29.07.21 um 11:08 schrieb Hans de Goede:
>> Hi,
>>
>> On 7/28/21 7:29 PM, Julian Sikorski wrote:
>>> Hi all,
>>>
>>> f quirk alone seems to be sufficient.
>>
>> Thank you for testing, but I'm not sure using only the NO_REPORT_OPCODES
>> quirk is wise here, the other similar La Cie drive also started out with
>> just that quirk, only to have the NO_SAME quirk added later. See:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8010622c86ca5bb44bc98492f5968726fc7c7a21
>>
>> Actually triggering a WRITE_SAME SCSI command is likely tricky, so
>> it likely requires a special workload to ensure that that flag is
>> not necessary.
>>
>> As Oliver set with the quirk to disable UAS we at least have the
>> drive working (albeit slower then it would work with UAS) so we
>> can take our time to make sure that things work properly with
>> the combination of the f+k flags (at least using both seems
>> best to me) before re-enabling UAS.
>>
>> Regards,
>>
>> Hans
>>
> Hi,
> 
> are there some tests which I could run in particular to test whether WRITE_SAME is working as intended?

I don't know, but perhaps someone else reading this knows ?

> one more question: is there a way to force-enable UAS for testing now that the quirk has been upstreamed, other than reverting the patch and rebuilding the kernel?

The quirks on the commandline override any quirks from the quirk-table
inside the kernel, including the no-uas quirk.

Regards,

Hans



>>> Julian Sikorski <belegdol@gmail.com <mailto:belegdol@gmail.com>> schrieb am Mi., 28. Juli 2021, 01:14:
>>>
>>>      Hi Hans,
>>>
>>>      apologies for top-posting and HTML but I only can send emails from my mobile currently.
>>>      With fk quirk the drive indeed appears to be working with uas: I can decrypt and mount a veracrypt volume from it. Thanks!
>>>      The patch disabling uas has already made it to Linus' tree and is about to be added to stable:
>>>      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6abf2fe6b4bf6e5256b80c5817908151d2d33e9f <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6abf2fe6b4bf6e5256b80c5817908151d2d33e9f>
>>>      As I have no working internet on any of my Linux machines and won't for the foreseeable future (thank you construction workers), would you mind taking care of amending the quirk accordingly? Thank you in advance.
>>>
>>>      Best regards,
>>>      Julian
>>>
>>>
>>>      Hans de Goede <hdegoede@redhat.com <mailto:hdegoede@redhat.com>> schrieb am Di., 27. Juli 2021, 23:19:
>>>
>>>          Hi,
>>>
>>>          On 7/19/21 6:10 PM, Julian Sikorski wrote:
>>>          > W dniu 19.07.2021 o 14:47, Oliver Neukum pisze:
>>>          >>
>>>          >>> Hi all,
>>>          >>>
>>>          >>> apologies for necro-ing this thread. I have just tried this drive with
>>>          >>> my new laptop (Asus ZenBook UM425IA) and the same quirk was needed to
>>>          >>> get the drive to work:
>>>          >>> options usb-storage quirks=059f:1061:u
>>>          >>>
>>>          >>> Should we still try to get uas working with this drive or should I
>>>          >>> send a patch hardcoding a quirk? I am on 5.13.2-300.fc34.x86_64 kernel
>>>          >>> now. Thanks for the feedback in advance.
>>>          >>>
>>>          >>
>>>          >> Hi,
>>>          >>
>>>          >>
>>>          >> sometimes we must give up. This thing is too elusive. Please send a
>>>          >> patch with a quirk.
>>>          >>
>>>          >>      Regards
>>>          >>
>>>          >>          Oliver
>>>          >>
>>>          >>
>>>          >
>>>          > Hi,
>>>          >
>>>          > thanks for confirming. Patch is attached, it appears to be working correctly when applied against 5.13.3. Please let me know if changes are required.
>>>
>>>          I seem to have missed the earlier part of this thread somehow.
>>>
>>>          Looking at the USB-ids, your model seems mightily close to this existing quirk:
>>>
>>>          UNUSUAL_DEV(0x059f, 0x105f, 0x0000, 0x9999,
>>>                          "LaCie",
>>>                          "2Big Quadra USB3",
>>>                          USB_SC_DEVICE, USB_PR_DEVICE, NULL,
>>>                          US_FL_NO_REPORT_OPCODES | US_FL_NO_SAME),
>>>
>>>          Before we go with the suggested patch, can you give the uas driver one last
>>>          try with:
>>>
>>>          options usb-storage quirks=059f:1061:fk
>>>
>>>          ? The fk translates like this:
>>>
>>>          f -> US_FL_NO_REPORT_OPCODES
>>>          k -> US_FL_NO_SAME
>>>
>>>          Regards,
>>>
>>>          Hans
>>>
>>
> 

Re: Lacie Rugged USB3-FW does not work with UAS

[Julian Sikorski]

Am 01.08.21 um 09:35 schrieb Julian Sikorski:
> Am 29.07.21 um 11:08 schrieb Hans de Goede:
>> Hi,
>>
>> On 7/28/21 7:29 PM, Julian Sikorski wrote:
>>> Hi all,
>>>
>>> f quirk alone seems to be sufficient.
>>
>> Thank you for testing, but I'm not sure using only the NO_REPORT_OPCODES
>> quirk is wise here, the other similar La Cie drive also started out with
>> just that quirk, only to have the NO_SAME quirk added later. See:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8010622c86ca5bb44bc98492f5968726fc7c7a21 
>>
>>
>> Actually triggering a WRITE_SAME SCSI command is likely tricky, so
>> it likely requires a special workload to ensure that that flag is
>> not necessary.
>>
>> As Oliver set with the quirk to disable UAS we at least have the
>> drive working (albeit slower then it would work with UAS) so we
>> can take our time to make sure that things work properly with
>> the combination of the f+k flags (at least using both seems
>> best to me) before re-enabling UAS.
>>
>> Regards,
>>
>> Hans
>>
> Hi,
> 
> are there some tests which I could run in particular to test whether 
> WRITE_SAME is working as intended? I use this drive for backups which 
> means I don't connect it all that often.
> 
> Best regards,
> Julian

Hi,

one more question: is there a way to force-enable UAS for testing now 
that the quirk has been upstreamed, other than reverting the patch and 
rebuilding the kernel?

Best regards,
Julian
> 
>>>
>>> Best regards,
>>> Julian
>>>
>>> Julian Sikorski <belegdol@gmail.com <mailto:belegdol@gmail.com>> 
>>> schrieb am Mi., 28. Juli 2021, 01:14:
>>>
>>>      Hi Hans,
>>>
>>>      apologies for top-posting and HTML but I only can send emails 
>>> from my mobile currently.
>>>      With fk quirk the drive indeed appears to be working with uas: I 
>>> can decrypt and mount a veracrypt volume from it. Thanks!
>>>      The patch disabling uas has already made it to Linus' tree and 
>>> is about to be added to stable:
>>>      
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6abf2fe6b4bf6e5256b80c5817908151d2d33e9f 
>>> <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6abf2fe6b4bf6e5256b80c5817908151d2d33e9f> 
>>>
>>>      As I have no working internet on any of my Linux machines and 
>>> won't for the foreseeable future (thank you construction workers), 
>>> would you mind taking care of amending the quirk accordingly? Thank 
>>> you in advance.
>>>
>>>      Best regards,
>>>      Julian
>>>
>>>
>>>      Hans de Goede <hdegoede@redhat.com <mailto:hdegoede@redhat.com>> 
>>> schrieb am Di., 27. Juli 2021, 23:19:
>>>
>>>          Hi,
>>>
>>>          On 7/19/21 6:10 PM, Julian Sikorski wrote:
>>>          > W dniu 19.07.2021 o 14:47, Oliver Neukum pisze:
>>>          >>
>>>          >>> Hi all,
>>>          >>>
>>>          >>> apologies for necro-ing this thread. I have just tried 
>>> this drive with
>>>          >>> my new laptop (Asus ZenBook UM425IA) and the same quirk 
>>> was needed to
>>>          >>> get the drive to work:
>>>          >>> options usb-storage quirks=059f:1061:u
>>>          >>>
>>>          >>> Should we still try to get uas working with this drive 
>>> or should I
>>>          >>> send a patch hardcoding a quirk? I am on 
>>> 5.13.2-300.fc34.x86_64 kernel
>>>          >>> now. Thanks for the feedback in advance.
>>>          >>>
>>>          >>
>>>          >> Hi,
>>>          >>
>>>          >>
>>>          >> sometimes we must give up. This thing is too elusive. 
>>> Please send a
>>>          >> patch with a quirk.
>>>          >>
>>>          >>      Regards
>>>          >>
>>>          >>          Oliver
>>>          >>
>>>          >>
>>>          >
>>>          > Hi,
>>>          >
>>>          > thanks for confirming. Patch is attached, it appears to be 
>>> working correctly when applied against 5.13.3. Please let me know if 
>>> changes are required.
>>>
>>>          I seem to have missed the earlier part of this thread somehow.
>>>
>>>          Looking at the USB-ids, your model seems mightily close to 
>>> this existing quirk:
>>>
>>>          UNUSUAL_DEV(0x059f, 0x105f, 0x0000, 0x9999,
>>>                          "LaCie",
>>>                          "2Big Quadra USB3",
>>>                          USB_SC_DEVICE, USB_PR_DEVICE, NULL,
>>>                          US_FL_NO_REPORT_OPCODES | US_FL_NO_SAME),
>>>
>>>          Before we go with the suggested patch, can you give the uas 
>>> driver one last
>>>          try with:
>>>
>>>          options usb-storage quirks=059f:1061:fk
>>>
>>>          ? The fk translates like this:
>>>
>>>          f -> US_FL_NO_REPORT_OPCODES
>>>          k -> US_FL_NO_SAME
>>>
>>>          Regards,
>>>
>>>          Hans
>>>
>>

Re: Lacie Rugged USB3-FW does not work with UAS

[Julian Sikorski]

Am 29.07.21 um 11:08 schrieb Hans de Goede:
> Hi,
> 
> On 7/28/21 7:29 PM, Julian Sikorski wrote:
>> Hi all,
>>
>> f quirk alone seems to be sufficient.
> 
> Thank you for testing, but I'm not sure using only the NO_REPORT_OPCODES
> quirk is wise here, the other similar La Cie drive also started out with
> just that quirk, only to have the NO_SAME quirk added later. See:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8010622c86ca5bb44bc98492f5968726fc7c7a21
> 
> Actually triggering a WRITE_SAME SCSI command is likely tricky, so
> it likely requires a special workload to ensure that that flag is
> not necessary.
> 
> As Oliver set with the quirk to disable UAS we at least have the
> drive working (albeit slower then it would work with UAS) so we
> can take our time to make sure that things work properly with
> the combination of the f+k flags (at least using both seems
> best to me) before re-enabling UAS.
> 
> Regards,
> 
> Hans
> 
(final attempt)

Hi,

I have just updated my backups with f+k quirks enabled and everything 
worked without errors. Given that nobody appears to be aware of a sure 
test case for checking whether f alone is sufficient, should I just 
generate a patch enabling fk instead of u?

Best regards,
Julian

> 
> 
>>
>> Best regards,
>> Julian
>>
>> Julian Sikorski <belegdol@gmail.com <mailto:belegdol@gmail.com>> schrieb am Mi., 28. Juli 2021, 01:14:
>>
>>      Hi Hans,
>>
>>      apologies for top-posting and HTML but I only can send emails from my mobile currently.
>>      With fk quirk the drive indeed appears to be working with uas: I can decrypt and mount a veracrypt volume from it. Thanks!
>>      The patch disabling uas has already made it to Linus' tree and is about to be added to stable:
>>      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6abf2fe6b4bf6e5256b80c5817908151d2d33e9f <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6abf2fe6b4bf6e5256b80c5817908151d2d33e9f>
>>      As I have no working internet on any of my Linux machines and won't for the foreseeable future (thank you construction workers), would you mind taking care of amending the quirk accordingly? Thank you in advance.
>>
>>      Best regards,
>>      Julian
>>
>>
>>      Hans de Goede <hdegoede@redhat.com <mailto:hdegoede@redhat.com>> schrieb am Di., 27. Juli 2021, 23:19:
>>
>>          Hi,
>>
>>          On 7/19/21 6:10 PM, Julian Sikorski wrote:
>>          > W dniu 19.07.2021 o 14:47, Oliver Neukum pisze:
>>          >>
>>          >>> Hi all,
>>          >>>
>>          >>> apologies for necro-ing this thread. I have just tried this drive with
>>          >>> my new laptop (Asus ZenBook UM425IA) and the same quirk was needed to
>>          >>> get the drive to work:
>>          >>> options usb-storage quirks=059f:1061:u
>>          >>>
>>          >>> Should we still try to get uas working with this drive or should I
>>          >>> send a patch hardcoding a quirk? I am on 5.13.2-300.fc34.x86_64 kernel
>>          >>> now. Thanks for the feedback in advance.
>>          >>>
>>          >>
>>          >> Hi,
>>          >>
>>          >>
>>          >> sometimes we must give up. This thing is too elusive. Please send a
>>          >> patch with a quirk.
>>          >>
>>          >>      Regards
>>          >>
>>          >>          Oliver
>>          >>
>>          >>
>>          >
>>          > Hi,
>>          >
>>          > thanks for confirming. Patch is attached, it appears to be working correctly when applied against 5.13.3. Please let me know if changes are required.
>>
>>          I seem to have missed the earlier part of this thread somehow.
>>
>>          Looking at the USB-ids, your model seems mightily close to this existing quirk:
>>
>>          UNUSUAL_DEV(0x059f, 0x105f, 0x0000, 0x9999,
>>                          "LaCie",
>>                          "2Big Quadra USB3",
>>                          USB_SC_DEVICE, USB_PR_DEVICE, NULL,
>>                          US_FL_NO_REPORT_OPCODES | US_FL_NO_SAME),
>>
>>          Before we go with the suggested patch, can you give the uas driver one last
>>          try with:
>>
>>          options usb-storage quirks=059f:1061:fk
>>
>>          ? The fk translates like this:
>>
>>          f -> US_FL_NO_REPORT_OPCODES
>>          k -> US_FL_NO_SAME
>>
>>          Regards,
>>
>>          Hans
>>
> 

Re: Lacie Rugged USB3-FW does not work with UAS

[Hans de Goede]

Hi,

On 9/12/21 10:13 PM, Julian Sikorski wrote:
> Am 29.07.21 um 11:08 schrieb Hans de Goede:
>> Hi,
>>
>> On 7/28/21 7:29 PM, Julian Sikorski wrote:
>>> Hi all,
>>>
>>> f quirk alone seems to be sufficient.
>>
>> Thank you for testing, but I'm not sure using only the NO_REPORT_OPCODES
>> quirk is wise here, the other similar La Cie drive also started out with
>> just that quirk, only to have the NO_SAME quirk added later. See:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8010622c86ca5bb44bc98492f5968726fc7c7a21
>>
>> Actually triggering a WRITE_SAME SCSI command is likely tricky, so
>> it likely requires a special workload to ensure that that flag is
>> not necessary.
>>
>> As Oliver set with the quirk to disable UAS we at least have the
>> drive working (albeit slower then it would work with UAS) so we
>> can take our time to make sure that things work properly with
>> the combination of the f+k flags (at least using both seems
>> best to me) before re-enabling UAS.
>>
>> Regards,
>>
>> Hans
>>
> (final attempt)

Not sure why you tried 3 times, FWIW I successfully received all 3 emails...

> Hi,
> 
> I have just updated my backups with f+k quirks enabled and everything worked without errors. Given that nobody appears to be aware of a sure test case for checking whether f alone is sufficient, should I just generate a patch enabling fk instead of u?

Yes I believe that switching from fk to u, like done on the other Lacie entries is best.

Thanks & Regards,

Hans


>>> Julian Sikorski <belegdol@gmail.com <mailto:belegdol@gmail.com>> schrieb am Mi., 28. Juli 2021, 01:14:
>>>
>>>      Hi Hans,
>>>
>>>      apologies for top-posting and HTML but I only can send emails from my mobile currently.
>>>      With fk quirk the drive indeed appears to be working with uas: I can decrypt and mount a veracrypt volume from it. Thanks!
>>>      The patch disabling uas has already made it to Linus' tree and is about to be added to stable:
>>>      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6abf2fe6b4bf6e5256b80c5817908151d2d33e9f <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6abf2fe6b4bf6e5256b80c5817908151d2d33e9f>
>>>      As I have no working internet on any of my Linux machines and won't for the foreseeable future (thank you construction workers), would you mind taking care of amending the quirk accordingly? Thank you in advance.
>>>
>>>      Best regards,
>>>      Julian
>>>
>>>
>>>      Hans de Goede <hdegoede@redhat.com <mailto:hdegoede@redhat.com>> schrieb am Di., 27. Juli 2021, 23:19:
>>>
>>>          Hi,
>>>
>>>          On 7/19/21 6:10 PM, Julian Sikorski wrote:
>>>          > W dniu 19.07.2021 o 14:47, Oliver Neukum pisze:
>>>          >>
>>>          >>> Hi all,
>>>          >>>
>>>          >>> apologies for necro-ing this thread. I have just tried this drive with
>>>          >>> my new laptop (Asus ZenBook UM425IA) and the same quirk was needed to
>>>          >>> get the drive to work:
>>>          >>> options usb-storage quirks=059f:1061:u
>>>          >>>
>>>          >>> Should we still try to get uas working with this drive or should I
>>>          >>> send a patch hardcoding a quirk? I am on 5.13.2-300.fc34.x86_64 kernel
>>>          >>> now. Thanks for the feedback in advance.
>>>          >>>
>>>          >>
>>>          >> Hi,
>>>          >>
>>>          >>
>>>          >> sometimes we must give up. This thing is too elusive. Please send a
>>>          >> patch with a quirk.
>>>          >>
>>>          >>      Regards
>>>          >>
>>>          >>          Oliver
>>>          >>
>>>          >>
>>>          >
>>>          > Hi,
>>>          >
>>>          > thanks for confirming. Patch is attached, it appears to be working correctly when applied against 5.13.3. Please let me know if changes are required.
>>>
>>>          I seem to have missed the earlier part of this thread somehow.
>>>
>>>          Looking at the USB-ids, your model seems mightily close to this existing quirk:
>>>
>>>          UNUSUAL_DEV(0x059f, 0x105f, 0x0000, 0x9999,
>>>                          "LaCie",
>>>                          "2Big Quadra USB3",
>>>                          USB_SC_DEVICE, USB_PR_DEVICE, NULL,
>>>                          US_FL_NO_REPORT_OPCODES | US_FL_NO_SAME),
>>>
>>>          Before we go with the suggested patch, can you give the uas driver one last
>>>          try with:
>>>
>>>          options usb-storage quirks=059f:1061:fk
>>>
>>>          ? The fk translates like this:
>>>
>>>          f -> US_FL_NO_REPORT_OPCODES
>>>          k -> US_FL_NO_SAME
>>>
>>>          Regards,
>>>
>>>          Hans
>>>
>>
> 

Re: Lacie Rugged USB3-FW does not work with UAS

[Hans de Goede]

Hi,

On 9/13/21 1:06 PM, Oliver Neukum wrote:
> 
> On 13.09.21 09:38, Hans de Goede wrote:
>>> Hi,
>>>
>>> I have just updated my backups with f+k quirks enabled and everything worked without errors. Given that nobody appears to be aware of a sure test case for checking whether f alone is sufficient, should I just generate a patch enabling fk instead of u?
>> Yes I believe that switching from fk to u, like done on the other Lacie entries is best.
> 
> Hi,
> 
> just to be sure that we are really on the same page.
> 
> Do you really want to go to u - US_FL_IGNORE_UAS? The other one
> has fk - US_FL_NO_REPORT_OPCODES | US_FL_NO_SAME

We currently have u - US_FL_IGNORE_UAS, because Julian's initial patch
did that and that was merged.

What we are talking about now, is moving from the big-hammer 'u'
to fk - US_FL_NO_REPORT_OPCODES | US_FL_NO_SAME, since testing
has show that just 'fk' is enough, allowing us to keep using uas. 
> I may be a bit confused and I think we need to make sure first, that we are
> talking about the same things.

I hope that my reply above helps to clear things up.

Regards,

Hans