* Lacie Rugged USB3-FW does not work with UAS
@ 2019-08-23 13:31 Julian Sikorski
2019-08-23 13:39 ` Oliver Neukum
0 siblings, 1 reply; 27+ messages in thread
From: Julian Sikorski @ 2019-08-23 13:31 UTC (permalink / raw)
To: linux-usb
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2019-08-23 13:31 Lacie Rugged USB3-FW does not work with UAS Julian Sikorski
@ 2019-08-23 13:39 ` Oliver Neukum
2019-08-23 13:43 ` Julian Sikorski
0 siblings, 1 reply; 27+ messages in thread
From: Oliver Neukum @ 2019-08-23 13:39 UTC (permalink / raw)
To: Julian Sikorski, linux-usb
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2019-08-23 13:39 ` Oliver Neukum
@ 2019-08-23 13:43 ` Julian Sikorski
2019-08-23 14:21 ` Julian Sikorski
0 siblings, 1 reply; 27+ messages in thread
From: Julian Sikorski @ 2019-08-23 13:43 UTC (permalink / raw)
To: Oliver Neukum, linux-usb
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2019-08-23 13:43 ` Julian Sikorski
@ 2019-08-23 14:21 ` Julian Sikorski
2019-08-23 21:23 ` Oliver Neukum
0 siblings, 1 reply; 27+ messages in thread
From: Julian Sikorski @ 2019-08-23 14:21 UTC (permalink / raw)
To: Oliver Neukum, linux-usb
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2019-08-23 14:21 ` Julian Sikorski
@ 2019-08-23 21:23 ` Oliver Neukum
2019-08-24 7:08 ` Julian Sikorski
0 siblings, 1 reply; 27+ messages in thread
From: Oliver Neukum @ 2019-08-23 21:23 UTC (permalink / raw)
To: Julian Sikorski, linux-usb
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2019-08-23 21:23 ` Oliver Neukum
@ 2019-08-24 7:08 ` Julian Sikorski
2019-08-29 18:33 ` Julian Sikorski
0 siblings, 1 reply; 27+ messages in thread
From: Julian Sikorski @ 2019-08-24 7:08 UTC (permalink / raw)
To: Oliver Neukum, linux-usb
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2019-08-24 7:08 ` Julian Sikorski
@ 2019-08-29 18:33 ` Julian Sikorski
2019-09-02 11:42 ` Oliver Neukum
0 siblings, 1 reply; 27+ messages in thread
From: Julian Sikorski @ 2019-08-29 18:33 UTC (permalink / raw)
To: Oliver Neukum, linux-usb
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2019-08-29 18:33 ` Julian Sikorski
@ 2019-09-02 11:42 ` Oliver Neukum
2019-09-02 20:10 ` Julian Sikorski
0 siblings, 1 reply; 27+ messages in thread
From: Oliver Neukum @ 2019-09-02 11:42 UTC (permalink / raw)
To: Julian Sikorski, linux-usb
[-- 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
^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2019-09-02 11:42 ` Oliver Neukum
@ 2019-09-02 20:10 ` Julian Sikorski
2019-09-04 15:58 ` Nathan Stratton Treadway
0 siblings, 1 reply; 27+ messages in thread
From: Julian Sikorski @ 2019-09-02 20:10 UTC (permalink / raw)
To: Oliver Neukum, linux-usb
[-- 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
^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2019-09-02 20:10 ` Julian Sikorski
@ 2019-09-04 15:58 ` Nathan Stratton Treadway
2019-09-04 17:10 ` Julian Sikorski
0 siblings, 1 reply; 27+ messages in thread
From: Nathan Stratton Treadway @ 2019-09-04 15:58 UTC (permalink / raw)
To: Julian Sikorski; +Cc: Oliver Neukum, linux-usb
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2019-09-04 15:58 ` Nathan Stratton Treadway
@ 2019-09-04 17:10 ` Julian Sikorski
2019-09-09 12:45 ` Oliver Neukum
0 siblings, 1 reply; 27+ messages in thread
From: Julian Sikorski @ 2019-09-04 17:10 UTC (permalink / raw)
To: Nathan Stratton Treadway; +Cc: Oliver Neukum, linux-usb
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2019-09-04 17:10 ` Julian Sikorski
@ 2019-09-09 12:45 ` Oliver Neukum
2019-09-09 16:18 ` Julian Sikorski
0 siblings, 1 reply; 27+ messages in thread
From: Oliver Neukum @ 2019-09-09 12:45 UTC (permalink / raw)
To: Julian Sikorski, Nathan Stratton Treadway; +Cc: linux-usb
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2019-09-09 12:45 ` Oliver Neukum
@ 2019-09-09 16:18 ` Julian Sikorski
2021-07-17 8:28 ` Julian Sikorski
0 siblings, 1 reply; 27+ messages in thread
From: Julian Sikorski @ 2019-09-09 16:18 UTC (permalink / raw)
To: Oliver Neukum, Nathan Stratton Treadway; +Cc: linux-usb
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2019-09-09 16:18 ` Julian Sikorski
@ 2021-07-17 8:28 ` Julian Sikorski
2021-07-19 12:47 ` Oliver Neukum
0 siblings, 1 reply; 27+ messages in thread
From: Julian Sikorski @ 2021-07-17 8:28 UTC (permalink / raw)
To: Oliver Neukum, Nathan Stratton Treadway; +Cc: linux-usb
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2021-07-17 8:28 ` Julian Sikorski
@ 2021-07-19 12:47 ` Oliver Neukum
2021-07-19 16:10 ` Julian Sikorski
0 siblings, 1 reply; 27+ messages in thread
From: Oliver Neukum @ 2021-07-19 12:47 UTC (permalink / raw)
To: Julian Sikorski, Nathan Stratton Treadway; +Cc: linux-usb
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2021-07-19 12:47 ` Oliver Neukum
@ 2021-07-19 16:10 ` Julian Sikorski
2021-07-20 7:43 ` Greg KH
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Julian Sikorski @ 2021-07-19 16:10 UTC (permalink / raw)
To: Oliver Neukum, Nathan Stratton Treadway; +Cc: linux-usb, hdegoede
[-- 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)
^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2021-07-19 16:10 ` Julian Sikorski
@ 2021-07-20 7:43 ` Greg KH
2021-07-20 9:35 ` Oliver Neukum
2021-07-27 21:19 ` Hans de Goede
2 siblings, 0 replies; 27+ messages in thread
From: Greg KH @ 2021-07-20 7:43 UTC (permalink / raw)
To: Julian Sikorski
Cc: Oliver Neukum, Nathan Stratton Treadway, linux-usb, hdegoede
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2021-07-19 16:10 ` Julian Sikorski
2021-07-20 7:43 ` Greg KH
@ 2021-07-20 9:35 ` Oliver Neukum
2021-07-27 21:19 ` Hans de Goede
2 siblings, 0 replies; 27+ messages in thread
From: Oliver Neukum @ 2021-07-20 9:35 UTC (permalink / raw)
To: Julian Sikorski, Nathan Stratton Treadway; +Cc: linux-usb, hdegoede
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2021-07-19 16:10 ` Julian Sikorski
2021-07-20 7:43 ` Greg KH
2021-07-20 9:35 ` Oliver Neukum
@ 2021-07-27 21:19 ` Hans de Goede
[not found] ` <CA+xVL_QEgzb1tu-tzqYPxJF-G_a8czCp=uyZ1JJ9+5xmCcNp2Q@mail.gmail.com>
2 siblings, 1 reply; 27+ messages in thread
From: Hans de Goede @ 2021-07-27 21:19 UTC (permalink / raw)
To: Julian Sikorski, Oliver Neukum, Nathan Stratton Treadway; +Cc: linux-usb
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
[not found] ` <CA+xVL_QrJ9f8-BwVRq1oG_yo2Cd=yQH9=TCm5g=MUO9MmdvRVA@mail.gmail.com>
@ 2021-07-29 8:43 ` Oliver Neukum
2021-07-29 9:08 ` Hans de Goede
1 sibling, 0 replies; 27+ messages in thread
From: Oliver Neukum @ 2021-07-29 8:43 UTC (permalink / raw)
To: Julian Sikorski, Hans de Goede
Cc: Oliver Neukum, Nathan Stratton Treadway, USB list
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
[not found] ` <CA+xVL_QrJ9f8-BwVRq1oG_yo2Cd=yQH9=TCm5g=MUO9MmdvRVA@mail.gmail.com>
2021-07-29 8:43 ` Oliver Neukum
@ 2021-07-29 9:08 ` Hans de Goede
2021-08-01 7:36 ` Julian Sikorski
` (2 more replies)
1 sibling, 3 replies; 27+ messages in thread
From: Hans de Goede @ 2021-07-29 9:08 UTC (permalink / raw)
To: Julian Sikorski; +Cc: Oliver Neukum, Nathan Stratton Treadway, USB list
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
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2021-07-29 9:08 ` Hans de Goede
@ 2021-08-01 7:36 ` Julian Sikorski
2021-08-01 8:46 ` Hans de Goede
[not found] ` <a645c513-794f-5171-d383-7b40fbb1ba18@gmail.com>
2021-09-12 20:13 ` Julian Sikorski
2 siblings, 1 reply; 27+ messages in thread
From: Julian Sikorski @ 2021-08-01 7:36 UTC (permalink / raw)
To: Hans de Goede; +Cc: Oliver Neukum, Nathan Stratton Treadway, USB list
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
>>
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
[not found] ` <a645c513-794f-5171-d383-7b40fbb1ba18@gmail.com>
@ 2021-08-01 7:47 ` Julian Sikorski
0 siblings, 0 replies; 27+ messages in thread
From: Julian Sikorski @ 2021-08-01 7:47 UTC (permalink / raw)
To: Hans de Goede; +Cc: Oliver Neukum, Nathan Stratton Treadway, USB list
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
>>>
>>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2021-08-01 7:36 ` Julian Sikorski
@ 2021-08-01 8:46 ` Hans de Goede
0 siblings, 0 replies; 27+ messages in thread
From: Hans de Goede @ 2021-08-01 8:46 UTC (permalink / raw)
To: Julian Sikorski; +Cc: Oliver Neukum, Nathan Stratton Treadway, USB list
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
>>>
>>
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2021-07-29 9:08 ` Hans de Goede
2021-08-01 7:36 ` Julian Sikorski
[not found] ` <a645c513-794f-5171-d383-7b40fbb1ba18@gmail.com>
@ 2021-09-12 20:13 ` Julian Sikorski
2021-09-13 7:38 ` Hans de Goede
2 siblings, 1 reply; 27+ messages in thread
From: Julian Sikorski @ 2021-09-12 20:13 UTC (permalink / raw)
To: Hans de Goede; +Cc: Oliver Neukum, Nathan Stratton Treadway, USB list
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
>>
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
2021-09-12 20:13 ` Julian Sikorski
@ 2021-09-13 7:38 ` Hans de Goede
[not found] ` <1f6c3026-143a-2004-24da-1da56e6305be@suse.com>
0 siblings, 1 reply; 27+ messages in thread
From: Hans de Goede @ 2021-09-13 7:38 UTC (permalink / raw)
To: Julian Sikorski; +Cc: Oliver Neukum, Nathan Stratton Treadway, USB list
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
>>>
>>
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Lacie Rugged USB3-FW does not work with UAS
[not found] ` <1f6c3026-143a-2004-24da-1da56e6305be@suse.com>
@ 2021-09-13 11:50 ` Hans de Goede
0 siblings, 0 replies; 27+ messages in thread
From: Hans de Goede @ 2021-09-13 11:50 UTC (permalink / raw)
To: Oliver Neukum, Julian Sikorski; +Cc: Nathan Stratton Treadway, USB list
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
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2021-09-13 11:50 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-23 13:31 Lacie Rugged USB3-FW does not work with UAS Julian Sikorski
2019-08-23 13:39 ` Oliver Neukum
2019-08-23 13:43 ` Julian Sikorski
2019-08-23 14:21 ` Julian Sikorski
2019-08-23 21:23 ` Oliver Neukum
2019-08-24 7:08 ` Julian Sikorski
2019-08-29 18:33 ` Julian Sikorski
2019-09-02 11:42 ` Oliver Neukum
2019-09-02 20:10 ` Julian Sikorski
2019-09-04 15:58 ` Nathan Stratton Treadway
2019-09-04 17:10 ` Julian Sikorski
2019-09-09 12:45 ` Oliver Neukum
2019-09-09 16:18 ` Julian Sikorski
2021-07-17 8:28 ` Julian Sikorski
2021-07-19 12:47 ` Oliver Neukum
2021-07-19 16:10 ` Julian Sikorski
2021-07-20 7:43 ` Greg KH
2021-07-20 9:35 ` Oliver Neukum
2021-07-27 21:19 ` Hans de Goede
[not found] ` <CA+xVL_QEgzb1tu-tzqYPxJF-G_a8czCp=uyZ1JJ9+5xmCcNp2Q@mail.gmail.com>
[not found] ` <CA+xVL_QrJ9f8-BwVRq1oG_yo2Cd=yQH9=TCm5g=MUO9MmdvRVA@mail.gmail.com>
2021-07-29 8:43 ` Oliver Neukum
2021-07-29 9:08 ` Hans de Goede
2021-08-01 7:36 ` Julian Sikorski
2021-08-01 8:46 ` Hans de Goede
[not found] ` <a645c513-794f-5171-d383-7b40fbb1ba18@gmail.com>
2021-08-01 7:47 ` Julian Sikorski
2021-09-12 20:13 ` Julian Sikorski
2021-09-13 7:38 ` Hans de Goede
[not found] ` <1f6c3026-143a-2004-24da-1da56e6305be@suse.com>
2021-09-13 11:50 ` Hans de Goede
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.