Ext. HDDs not working under Linux via USB 3.0 but under Windows

Ext. HDDs not working under Linux via USB 3.0 but under Windows

[Till Dörges]

Hello all,

I'm trying to get external HDDs from Sony to work under Linux with USB 3.0.

They do work OK under Windows (USB 2.0 and 3.0).

They also work OK under Linux for USB 2.0.


The drives are from the PSZ-HA
(https://pro.sony/en_AU/products/portable-storage/psz-ha-series) and PSZ-HC
(https://pro.sony/ue_US/products/portable-storage/psz-hc-series) series.

I know those are both discontinued, but there still seem to be quite a few of those
around.

The drives I'm looking at have these vendor and product IDs:

 - PSZ-HA2T: idVendor=054c, idProduct=087d
 - PSZ-HA1T: idVendor=054c, idProduct=087d
 - PSZ-HA50: idVendor=054c, idProduct=087d
 - PSZ-HC1T: idVendor=054c, idProduct=0c4f


I've tried several Linux Kernels (4.4.x and 5.3.x) and several USB 3.0 host
controllers, e.g.
 - Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI
 - Renesas Technology Corp. uPD720202 USB 3.0 Host Controller
 - NEC Corporation uPD720200 USB 3.0 Host Controller


I've also tried several of the quirk settings
(https://github.com/torvalds/linux/blob/ead751507de86d90fa250431e9990a8b881f713c/drivers/usb/storage/usb.c#L527).


Unfortunately the problem (drives won't work under Linux when attached via USB 3.0)
persists.


For example, when attaching a PSZ-HA2T via USB 3.0 with Kernel 5.3.18 (from upcoming
openSUSE Leap 15.2) I get this in dmesg:

--- snip ---
[  767.481938] usb 6-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[  767.505381] usb 6-1: New USB device found, idVendor=054c, idProduct=087d,
bcdDevice= 0.0a
[  767.505385] usb 6-1: New USB device strings: Mfr=10, Product=11, SerialNumber=3
[  767.505387] usb 6-1: Product: Portable Storage
[  767.505388] usb 6-1: Manufacturer: Sony
[  767.505389] usb 6-1: SerialNumber: 230877290443
[  767.522588] scsi host5: uas
[  771.524123] scsi 5:0:0:0: Direct-Access     Sony     PSZ-H            320: PQ: 0
ANSI: 6
[  777.526863] sd 5:0:0:0: Attached scsi generic sg7 type 0
[  777.527091] sd 5:0:0:0: [sdf] Spinning up disk...
[  778.537372]
..................................................................................................not
responding...
[  885.868786] sd 5:0:0:0: [sdf] 281474976710656 512-byte logical blocks: (144 PB/128
PiB)
[  885.868789] sd 5:0:0:0: [sdf] 4096-byte physical blocks
[  887.869495] sd 5:0:0:0: [sdf] Write Protect is off
[  887.869498] sd 5:0:0:0: [sdf] Mode Sense: 67 00 10 08
[  891.870798] sd 5:0:0:0: [sdf] Write cache: enabled, read cache: enabled, supports
DPO and FUA
[  922.741387] sd 5:0:0:0: tag#11 uas_eh_abort_handler 0 uas-tag 1 inflight: IN
[  922.741393] sd 5:0:0:0: tag#11 CDB: Report supported operation codes a3 0c 01 12
00 00 00 00 02 00 00 00
[  922.757393] scsi host5: uas_eh_device_reset_handler start
[  922.887214] usb 6-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[  922.917578] scsi host5: uas_eh_device_reset_handler success
[  953.465374] scsi host5: uas_eh_device_reset_handler start
[  953.465837] sd 5:0:0:0: tag#11 uas_zap_pending 0 uas-tag 1 inflight:
[  953.465842] sd 5:0:0:0: tag#11 CDB: Report supported operation codes a3 0c 01 12
00 00 00 00 02 00 00 00
[  953.595235] usb 6-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
--- snap ---


So, when I blacklist UAS for the drive:
--- snip ---
$  cat /sys/module/usb_storage/parameters/quirks
054c:087d:u,054c:0c4f:u
--- snap ---


dmesg shows this when attaching the PSZ-HA2T:
--- snip ---
[87130.955521] usb 4-2: new SuperSpeed Gen 1 USB device number 13 using xhci_hcd
[87130.979047] usb 4-2: New USB device found, idVendor=054c, idProduct=087d,
bcdDevice= 0.0a
[87130.979051] usb 4-2: New USB device strings: Mfr=10, Product=11, SerialNumber=3
[87130.979052] usb 4-2: Product: Portable Storage
[87130.979053] usb 4-2: Manufacturer: Sony
[87130.979054] usb 4-2: SerialNumber: 230877290443
[87130.983677] usb 4-2: UAS is blacklisted for this device, using usb-storage instead
[87130.983679] usb-storage 4-2:1.0: USB Mass Storage device detected
[87130.983753] usb-storage 4-2:1.0: Quirks match for vid 054c pid 087d: 800000
[87130.983770] scsi host5: usb-storage 4-2:1.0
[87134.003728] scsi 5:0:0:0: Direct-Access     Sony     PSZ-H            320: PQ: 0
ANSI: 6
[87134.003936] sd 5:0:0:0: Attached scsi generic sg7 type 0
[87140.006762] sd 5:0:0:0: [sdf] Spinning up disk...
[87143.042934] ................not responding...
[87254.168509] sd 5:0:0:0: [sdf] Read Capacity(10) failed: Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[87254.168513] sd 5:0:0:0: [sdf] Sense Key : Not Ready [current]
[87254.168515] sd 5:0:0:0: [sdf] Add. Sense: Logical unit is in process of becoming ready
[87254.168518] sd 5:0:0:0: [sdf] 0 512-byte logical blocks: (0 B/0 B)
[87254.168519] sd 5:0:0:0: [sdf] 0-byte physical blocks
[87256.170408] sd 5:0:0:0: [sdf] Test WP failed, assume Write Enabled
[87258.172158] sd 5:0:0:0: [sdf] Asking for cache data failed
[87258.172172] sd 5:0:0:0: [sdf] Assuming drive cache: write through
[87268.192507] sd 5:0:0:0: [sdf] Spinning up disk...
--- snap ---


So UAS might not be the problem after all. Particularly because when attaching the
drive in Windows 10 I notice some popup saying something about "UAS".


Since the drives do work under Windows with USB 3.0 I'm still guessing that the
drives fail to correctly implement parts of USB 3.0.


Is there any way to pinpoint the problem(s)? Or do I have to try all possible quirk
combinations and hope I find the one that's working?


Any insights on this would greatly be appreciated!


Thanks and regards -- Till
-- 
Dipl.-Inform. Till Dörges                  doerges@pre-sense.de
PRESENSE Technologies GmbH             Nagelsweg 41, D-20097 HH
Geschäftsführer/Managing Directors       AG Hamburg, HRB 107844
Till Dörges, Jürgen Sander               USt-IdNr.: DE263765024

Re: Ext. HDDs not working under Linux via USB 3.0 but under Windows

[Alan Stern]

On Sat, May 23, 2020 at 04:57:50PM +0200, Till Dörges wrote:
> Hello all,
> 
> I'm trying to get external HDDs from Sony to work under Linux with USB 3.0.
> 
> They do work OK under Windows (USB 2.0 and 3.0).
> 
> They also work OK under Linux for USB 2.0.
> 
> 
> The drives are from the PSZ-HA
> (https://pro.sony/en_AU/products/portable-storage/psz-ha-series) and PSZ-HC
> (https://pro.sony/ue_US/products/portable-storage/psz-hc-series) series.
> 
> I know those are both discontinued, but there still seem to be quite a few of those
> around.
> 
> The drives I'm looking at have these vendor and product IDs:
> 
>  - PSZ-HA2T: idVendor=054c, idProduct=087d
>  - PSZ-HA1T: idVendor=054c, idProduct=087d
>  - PSZ-HA50: idVendor=054c, idProduct=087d
>  - PSZ-HC1T: idVendor=054c, idProduct=0c4f
> 
> 
> I've tried several Linux Kernels (4.4.x and 5.3.x) and several USB 3.0 host
> controllers, e.g.
>  - Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI
>  - Renesas Technology Corp. uPD720202 USB 3.0 Host Controller
>  - NEC Corporation uPD720200 USB 3.0 Host Controller
> 
> 
> I've also tried several of the quirk settings
> (https://github.com/torvalds/linux/blob/ead751507de86d90fa250431e9990a8b881f713c/drivers/usb/storage/usb.c#L527).

Unfortunately, the uas driver ignores those settings.

> Unfortunately the problem (drives won't work under Linux when attached via USB 3.0)
> persists.
> 
> 
> For example, when attaching a PSZ-HA2T via USB 3.0 with Kernel 5.3.18 (from upcoming
> openSUSE Leap 15.2) I get this in dmesg:
> 
> --- snip ---
> [  767.481938] usb 6-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
> [  767.505381] usb 6-1: New USB device found, idVendor=054c, idProduct=087d,
> bcdDevice= 0.0a
> [  767.505385] usb 6-1: New USB device strings: Mfr=10, Product=11, SerialNumber=3
> [  767.505387] usb 6-1: Product: Portable Storage
> [  767.505388] usb 6-1: Manufacturer: Sony
> [  767.505389] usb 6-1: SerialNumber: 230877290443
> [  767.522588] scsi host5: uas
> [  771.524123] scsi 5:0:0:0: Direct-Access     Sony     PSZ-H            320: PQ: 0
> ANSI: 6
> [  777.526863] sd 5:0:0:0: Attached scsi generic sg7 type 0
> [  777.527091] sd 5:0:0:0: [sdf] Spinning up disk...
> [  778.537372]
> ..................................................................................................not
> responding...
> [  885.868786] sd 5:0:0:0: [sdf] 281474976710656 512-byte logical blocks: (144 PB/128
> PiB)
> [  885.868789] sd 5:0:0:0: [sdf] 4096-byte physical blocks
> [  887.869495] sd 5:0:0:0: [sdf] Write Protect is off
> [  887.869498] sd 5:0:0:0: [sdf] Mode Sense: 67 00 10 08
> [  891.870798] sd 5:0:0:0: [sdf] Write cache: enabled, read cache: enabled, supports
> DPO and FUA
> [  922.741387] sd 5:0:0:0: tag#11 uas_eh_abort_handler 0 uas-tag 1 inflight: IN
> [  922.741393] sd 5:0:0:0: tag#11 CDB: Report supported operation codes a3 0c 01 12
> 00 00 00 00 02 00 00 00
> [  922.757393] scsi host5: uas_eh_device_reset_handler start
> [  922.887214] usb 6-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
> [  922.917578] scsi host5: uas_eh_device_reset_handler success
> [  953.465374] scsi host5: uas_eh_device_reset_handler start
> [  953.465837] sd 5:0:0:0: tag#11 uas_zap_pending 0 uas-tag 1 inflight:
> [  953.465842] sd 5:0:0:0: tag#11 CDB: Report supported operation codes a3 0c 01 12
> 00 00 00 00 02 00 00 00
> [  953.595235] usb 6-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
> --- snap ---

It looks like the device needs the USB_FL_NO_REPORT_OPCODES flag.

> So, when I blacklist UAS for the drive:
> --- snip ---
> $  cat /sys/module/usb_storage/parameters/quirks
> 054c:087d:u,054c:0c4f:u
> --- snap ---
> 
> 
> dmesg shows this when attaching the PSZ-HA2T:
> --- snip ---
> [87130.955521] usb 4-2: new SuperSpeed Gen 1 USB device number 13 using xhci_hcd
> [87130.979047] usb 4-2: New USB device found, idVendor=054c, idProduct=087d,
> bcdDevice= 0.0a
> [87130.979051] usb 4-2: New USB device strings: Mfr=10, Product=11, SerialNumber=3
> [87130.979052] usb 4-2: Product: Portable Storage
> [87130.979053] usb 4-2: Manufacturer: Sony
> [87130.979054] usb 4-2: SerialNumber: 230877290443
> [87130.983677] usb 4-2: UAS is blacklisted for this device, using usb-storage instead
> [87130.983679] usb-storage 4-2:1.0: USB Mass Storage device detected
> [87130.983753] usb-storage 4-2:1.0: Quirks match for vid 054c pid 087d: 800000
> [87130.983770] scsi host5: usb-storage 4-2:1.0
> [87134.003728] scsi 5:0:0:0: Direct-Access     Sony     PSZ-H            320: PQ: 0
> ANSI: 6
> [87134.003936] sd 5:0:0:0: Attached scsi generic sg7 type 0
> [87140.006762] sd 5:0:0:0: [sdf] Spinning up disk...
> [87143.042934] ................not responding...
> [87254.168509] sd 5:0:0:0: [sdf] Read Capacity(10) failed: Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> [87254.168513] sd 5:0:0:0: [sdf] Sense Key : Not Ready [current]
> [87254.168515] sd 5:0:0:0: [sdf] Add. Sense: Logical unit is in process of becoming ready
> [87254.168518] sd 5:0:0:0: [sdf] 0 512-byte logical blocks: (0 B/0 B)
> [87254.168519] sd 5:0:0:0: [sdf] 0-byte physical blocks
> [87256.170408] sd 5:0:0:0: [sdf] Test WP failed, assume Write Enabled
> [87258.172158] sd 5:0:0:0: [sdf] Asking for cache data failed
> [87258.172172] sd 5:0:0:0: [sdf] Assuming drive cache: write through
> [87268.192507] sd 5:0:0:0: [sdf] Spinning up disk...
> --- snap ---

It's hard to tell from this what went wrong.  The device seems to be 
acting as though it takes more than 110 seconds to spin up, which is 
obviously ridiculous.

> So UAS might not be the problem after all. Particularly because when attaching the
> drive in Windows 10 I notice some popup saying something about "UAS".
> 
> 
> Since the drives do work under Windows with USB 3.0 I'm still guessing that the
> drives fail to correctly implement parts of USB 3.0.

No, the drive implements USB 3.0 just fine.  But it doesn't implement 
the SCSI protocol properly, in particular, the REPORT OPCODES 
subcommand.

> Is there any way to pinpoint the problem(s)? Or do I have to try all possible quirk
> combinations and hope I find the one that's working?

Try adding an entry to the unusual_uas.h file for the device, specifying 
the USB_FL_NO_REPORT_OPCODES flag.

Alan Stern

Re: Ext. HDDs not working under Linux via USB 3.0 but under Windows

[Till Dörges]

Hi Alan,

thanks for the really quick response!

Am 23.05.20 um 17:48 schrieb Alan Stern:

>> I'm trying to get external HDDs from Sony to work under Linux with USB 3.0.
[...]
>>  - PSZ-HA2T: idVendor=054c, idProduct=087d
>>  - PSZ-HA1T: idVendor=054c, idProduct=087d
>>  - PSZ-HA50: idVendor=054c, idProduct=087d
>>  - PSZ-HC1T: idVendor=054c, idProduct=0c4f
[...]
>> I've also tried several of the quirk settings
>> (https://github.com/torvalds/linux/blob/ead751507de86d90fa250431e9990a8b881f713c/drivers/usb/storage/usb.c#L527).
> 
> Unfortunately, the uas driver ignores those settings.
[...]
> Try adding an entry to the unusual_uas.h file for the device, specifying 
> the USB_FL_NO_REPORT_OPCODES flag.

I'm not sure I understand correctly. Do I have to compile the uas Kernel module
myself if I want to test a flag?

Because with setting the f flag (via options usb-storage quirks=054c:087d:f) the
PSZ-HA*1*T starts behaving nicely.

--- snip ---
$ cat /sys/module/usb_storage/parameters/quirks
054c:087d:f,054c:0c4f:f
--- snip ---


The PSZ-HA*2*T, however, still doesn't work with that.

dmesg shows:
--- snip ---
[613960.192066] scsi host5: uas
[613960.192179] usbcore: registered new interface driver uas
[613960.195028] usb 6-2: cmd cmplt err -71
[613980.764509] scsi 5:0:0:0: tag#12 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[613980.764513] scsi 5:0:0:0: tag#12 CDB: Inquiry 12 00 00 00 24 00
[613980.780506] scsi host5: uas_eh_device_reset_handler start
[613980.910565] usb 6-2: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd
[613980.940879] scsi host5: uas_eh_device_reset_handler success
[613984.957905] scsi 5:0:0:0: Direct-Access     Sony     PSZ-H            320: PQ: 0
ANSI: 6
[613990.960817] sd 5:0:0:0: Attached scsi generic sg3 type 0
[613990.961028] sd 5:0:0:0: [sdb] Spinning up disk...
[613991.984560] .ready
[613999.987984] sd 5:0:0:0: [sdb] 281474976710656 512-byte logical blocks: (144
PB/128 PiB)
[613999.987988] sd 5:0:0:0: [sdb] 4096-byte physical blocks
[614001.988698] sd 5:0:0:0: [sdb] Write Protect is off
[614001.988702] sd 5:0:0:0: [sdb] Mode Sense: 67 00 10 08
[614005.989956] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports
DPO and FUA
[614007.990627] sd 5:0:0:0: [sdb] Optimal transfer size 524287 logical blocks > sd
driver limit (65535 logical blocks)
[614008.004886] sd 5:0:0:0: [sdb] Spinning up disk...
[614009.040540] .ready
[614056.540501] sd 5:0:0:0: [sdb] tag#13 uas_eh_abort_handler 0 uas-tag 1 inflight:
CMD IN
[614056.540507] sd 5:0:0:0: [sdb] tag#13 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00
00 00 00 08 00 00
[614056.556501] scsi host5: uas_eh_device_reset_handler start
[614056.686376] usb 6-2: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd
[614056.716509] scsi host5: uas_eh_device_reset_handler success
[614066.768485] sd 5:0:0:0: [sdb] tag#13 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
[614066.768490] sd 5:0:0:0: [sdb] tag#13 CDB: Test Unit Ready 00 00 00 00 00 00
[614066.768493] scsi host5: uas_eh_device_reset_handler start
[614072.144648] xhci_hcd 0000:06:00.0: Timeout while waiting for setup device command
[614072.353271] usb 6-2: Device not responding to setup address.
[614072.354062] debugfs: Directory '01' with parent 'devices' already present!
[614072.560471] usb 6-2: device not accepting address 3, error -71
[614078.032657] xhci_hcd 0000:06:00.0: Timeout while waiting for setup device command
[614078.240963] usb 6-2: Device not responding to setup address.
[614078.241423] debugfs: Directory '01' with parent 'devices' already present!
[614078.448469] usb 6-2: device not accepting address 3, error -71
[614083.920631] xhci_hcd 0000:06:00.0: Timeout while waiting for setup device command
[614084.128937] usb 6-2: Device not responding to setup address.
[614084.129413] debugfs: Directory '01' with parent 'devices' already present!
[614084.336459] usb 6-2: device not accepting address 3, error -71
[614089.808656] xhci_hcd 0000:06:00.0: Timeout while waiting for setup device command
[614090.017000] usb 6-2: Device not responding to setup address.
[614090.017527] debugfs: Directory '01' with parent 'devices' already present!
[614090.224459] usb 6-2: device not accepting address 3, error -71
[614090.280517] scsi host5: uas_eh_device_reset_handler FAILED err -19
[614090.280522] sd 5:0:0:0: Device offlined - not ready after error recovery
[614090.280529] sd 5:0:0:0: [sdb] tag#13 FAILED Result: hostbyte=DID_OK
driverbyte=DRIVER_TIMEOUT
[614090.280531] sd 5:0:0:0: [sdb] tag#13 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00
00 00 00 08 00 00
[614090.280533] print_req_error: 1 callbacks suppressed
[614090.280534] blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 0
[614090.280537] buffer_io_error: 1 callbacks suppressed
[614090.280538] Buffer I/O error on dev sdb, logical block 0, async page read
[614090.280567] usb 6-2: USB disconnect, device number 3
[614090.280571] sd 5:0:0:0: rejecting I/O to offline device
[614090.280574] blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 0
[614090.280576] Buffer I/O error on dev sdb, logical block 0, async page read
[614090.280597] blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 0
[614090.280598] Buffer I/O error on dev sdb, logical block 0, async page read
[614090.280601] ldm_validate_partition_table(): Disk read failed.
[614090.280607] blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 0
[614090.280608] Buffer I/O error on dev sdb, logical block 0, async page read
[614090.280615] blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 0
[614090.280616] Buffer I/O error on dev sdb, logical block 0, async page read
[614090.280624] blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 0
[614090.280625] Buffer I/O error on dev sdb, logical block 0, async page read
[614090.280632] blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 0
[614090.280633] Buffer I/O error on dev sdb, logical block 0, async page read
[614090.280640] blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 0
[614090.280642] Buffer I/O error on dev sdb, logical block 0, async page read
[614090.280655] blk_update_request: I/O error, dev sdb, sector 24 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 0
[614090.280657] Buffer I/O error on dev sdb, logical block 3, async page read
[614090.280664] blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 0
[614090.280665] Buffer I/O error on dev sdb, logical block 0, async page read
[614090.280674]  sdb: unable to read partition table
[614090.604487] sd 5:0:0:0: [sdb] Read Capacity(16) failed: Result:
hostbyte=DID_ERROR driverbyte=DRIVER_OK
[614090.604491] sd 5:0:0:0: [sdb] Sense not available.
[614090.844483] sd 5:0:0:0: [sdb] Read Capacity(10) failed: Result:
hostbyte=DID_ERROR driverbyte=DRIVER_OK
[614090.844487] sd 5:0:0:0: [sdb] Sense not available.
[614090.940485] sd 5:0:0:0: [sdb] 0 512-byte logical blocks: (0 B/0 B)
[614090.940488] sd 5:0:0:0: [sdb] 4096-byte physical blocks
[614091.020504] sd 5:0:0:0: [sdb] Write Protect is on
[614091.020507] sd 5:0:0:0: [sdb] Mode Sense: 27 40 bb f7
[614091.228484] sd 5:0:0:0: [sdb] Attached SCSI disk
[614091.285557] debugfs: Directory '01' with parent 'devices' already present!
[614096.720608] xhci_hcd 0000:06:00.0: Timeout while waiting for setup device command
[614096.928929] usb 6-2: Device not responding to setup address.
[614096.929337] debugfs: Directory '01' with parent 'devices' already present!
[614097.136449] usb 6-2: device not accepting address 4, error -71
--- snap ---


Do you have any idea what to try there?


Thanks and regards -- Till
-- 
Dipl.-Inform. Till Dörges                  doerges@pre-sense.de
PRESENSE Technologies GmbH             Nagelsweg 41, D-20097 HH
Geschäftsführer/Managing Directors       AG Hamburg, HRB 107844
Till Dörges, Jürgen Sander               USt-IdNr.: DE263765024

Re: Ext. HDDs not working under Linux via USB 3.0 but under Windows

[Alan Stern]

On Sat, May 23, 2020 at 10:05:48PM +0200, Till Dörges wrote:
> Hi Alan,
> 
> thanks for the really quick response!
> 
> Am 23.05.20 um 17:48 schrieb Alan Stern:
> 
> >> I'm trying to get external HDDs from Sony to work under Linux with USB 3.0.
> [...]
> >>  - PSZ-HA2T: idVendor=054c, idProduct=087d
> >>  - PSZ-HA1T: idVendor=054c, idProduct=087d
> >>  - PSZ-HA50: idVendor=054c, idProduct=087d
> >>  - PSZ-HC1T: idVendor=054c, idProduct=0c4f
> [...]
> >> I've also tried several of the quirk settings
> >> (https://github.com/torvalds/linux/blob/ead751507de86d90fa250431e9990a8b881f713c/drivers/usb/storage/usb.c#L527).
> > 
> > Unfortunately, the uas driver ignores those settings.

Whoops.  I was wrong about this; uas does indeed use the quirk settings.

> [...]
> > Try adding an entry to the unusual_uas.h file for the device, specifying 
> > the USB_FL_NO_REPORT_OPCODES flag.
> 
> I'm not sure I understand correctly. Do I have to compile the uas Kernel module
> myself if I want to test a flag?
> 
> Because with setting the f flag (via options usb-storage quirks=054c:087d:f) the
> PSZ-HA*1*T starts behaving nicely.
> 
> --- snip ---
> $ cat /sys/module/usb_storage/parameters/quirks
> 054c:087d:f,054c:0c4f:f
> --- snip ---
> 
> 
> The PSZ-HA*2*T, however, still doesn't work with that.
> 
> dmesg shows:
> --- snip ---
> [613960.192066] scsi host5: uas
> [613960.192179] usbcore: registered new interface driver uas
> [613960.195028] usb 6-2: cmd cmplt err -71
> [613980.764509] scsi 5:0:0:0: tag#12 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
> [613980.764513] scsi 5:0:0:0: tag#12 CDB: Inquiry 12 00 00 00 24 00
> [613980.780506] scsi host5: uas_eh_device_reset_handler start
> [613980.910565] usb 6-2: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd
> [613980.940879] scsi host5: uas_eh_device_reset_handler success
> [613984.957905] scsi 5:0:0:0: Direct-Access     Sony     PSZ-H            320: PQ: 0
> ANSI: 6
> [613990.960817] sd 5:0:0:0: Attached scsi generic sg3 type 0
> [613990.961028] sd 5:0:0:0: [sdb] Spinning up disk...
> [613991.984560] .ready
> [613999.987984] sd 5:0:0:0: [sdb] 281474976710656 512-byte logical blocks: (144
> PB/128 PiB)
> [613999.987988] sd 5:0:0:0: [sdb] 4096-byte physical blocks
> [614001.988698] sd 5:0:0:0: [sdb] Write Protect is off
> [614001.988702] sd 5:0:0:0: [sdb] Mode Sense: 67 00 10 08
> [614005.989956] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports
> DPO and FUA
> [614007.990627] sd 5:0:0:0: [sdb] Optimal transfer size 524287 logical blocks > sd
> driver limit (65535 logical blocks)
> [614008.004886] sd 5:0:0:0: [sdb] Spinning up disk...
> [614009.040540] .ready
> [614056.540501] sd 5:0:0:0: [sdb] tag#13 uas_eh_abort_handler 0 uas-tag 1 inflight:
> CMD IN
> [614056.540507] sd 5:0:0:0: [sdb] tag#13 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00
> 00 00 00 08 00 00
> [614056.556501] scsi host5: uas_eh_device_reset_handler start
> [614056.686376] usb 6-2: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd
> [614056.716509] scsi host5: uas_eh_device_reset_handler success
> [614066.768485] sd 5:0:0:0: [sdb] tag#13 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
> [614066.768490] sd 5:0:0:0: [sdb] tag#13 CDB: Test Unit Ready 00 00 00 00 00 00
> [614066.768493] scsi host5: uas_eh_device_reset_handler start
> [614072.144648] xhci_hcd 0000:06:00.0: Timeout while waiting for setup device command
> [614072.353271] usb 6-2: Device not responding to setup address.
> [614072.354062] debugfs: Directory '01' with parent 'devices' already present!

...

> --- snap ---
> 
> 
> Do you have any idea what to try there?

That device seems to be behaving so badly, it's hard to tell what the 
underlying problem is.

I'd start by blacklisting the device for UAS, so forcing it to use 
usb-storage, which is a somewhat simpler protocol.  Next, you should 
collect a usbmon trace showing what happens when you plug in the 
PSZ-HA2T.  That will tell us what's going on, even if it doesn't suggest 
a way to work around the problems.

(The instructions for usbmon are in the kernel source file 
Documentation/usb/usbmon.rst.)

Alan Stern

Re: Ext. HDDs not working under Linux via USB 3.0 but under Windows

[Till Dörges]

Am 23.05.20 um 22:33 schrieb Alan Stern:

>>>> I'm trying to get external HDDs from Sony to work under Linux with USB 3.0.
>> [...]
>>>>  - PSZ-HA2T: idVendor=054c, idProduct=087d
>>>>  - PSZ-HA1T: idVendor=054c, idProduct=087d
>>>>  - PSZ-HA50: idVendor=054c, idProduct=087d
>>>>  - PSZ-HC1T: idVendor=054c, idProduct=0c4f
[...]
>> Because with setting the f flag (via options usb-storage quirks=054c:087d:f) the
>> PSZ-HA*1*T starts behaving nicely.
[...]
>> The PSZ-HA*2*T, however, still doesn't work with that.
[...]
> That device seems to be behaving so badly, it's hard to tell what the 
> underlying problem is.
> 
> I'd start by blacklisting the device for UAS, so forcing it to use 
> usb-storage, which is a somewhat simpler protocol.  Next, you should 
> collect a usbmon trace showing what happens when you plug in the 
> PSZ-HA2T.  That will tell us what's going on, even if it doesn't suggest 
> a way to work around the problems.
> 
> (The instructions for usbmon are in the kernel source file 
> Documentation/usb/usbmon.rst.)

Thanks. Will give that a shot.


Is there any way to differentiate between devices other than vendor and product ID?

Because the PSZ-HA1T (which seems to be working thanks to your help) and the PSZ-HA2T
(which still refuses to work) have the *same* vendor and product ID.


Regards -- Till
-- 
Dipl.-Inform. Till Dörges                  doerges@pre-sense.de
                                  Tel. +49 - 40 - 244 2407 -  0
                                  Fax  +49 - 40 - 244 2407 - 24
PRESENSE Technologies GmbH             Nagelsweg 41, D-20097 HH
Geschäftsführer/Managing Directors       AG Hamburg, HRB 107844
Till Dörges, Jürgen Sander               USt-IdNr.: DE263765024

Re: Ext. HDDs not working under Linux via USB 3.0 but under Windows

[Alan Stern]

On Sun, May 24, 2020 at 09:46:06AM +0200, Till Dörges wrote:
> Am 23.05.20 um 22:33 schrieb Alan Stern:
> 
> >>>> I'm trying to get external HDDs from Sony to work under Linux with USB 3.0.
> >> [...]
> >>>>  - PSZ-HA2T: idVendor=054c, idProduct=087d
> >>>>  - PSZ-HA1T: idVendor=054c, idProduct=087d
> >>>>  - PSZ-HA50: idVendor=054c, idProduct=087d
> >>>>  - PSZ-HC1T: idVendor=054c, idProduct=0c4f
> [...]
> >> Because with setting the f flag (via options usb-storage quirks=054c:087d:f) the
> >> PSZ-HA*1*T starts behaving nicely.
> [...]
> >> The PSZ-HA*2*T, however, still doesn't work with that.
> [...]
> > That device seems to be behaving so badly, it's hard to tell what the 
> > underlying problem is.
> > 
> > I'd start by blacklisting the device for UAS, so forcing it to use 
> > usb-storage, which is a somewhat simpler protocol.  Next, you should 
> > collect a usbmon trace showing what happens when you plug in the 
> > PSZ-HA2T.  That will tell us what's going on, even if it doesn't suggest 
> > a way to work around the problems.
> > 
> > (The instructions for usbmon are in the kernel source file 
> > Documentation/usb/usbmon.rst.)
> 
> Thanks. Will give that a shot.
> 
> 
> Is there any way to differentiate between devices other than vendor and product ID?
> 
> Because the PSZ-HA1T (which seems to be working thanks to your help) and the PSZ-HA2T
> (which still refuses to work) have the *same* vendor and product ID.

There's also the bcdDevice value.  It is ignored for quirks specified by 
the "quirks=" module parameter, but it is used for quirks stored in the 
unusual_devs.h or unusual_uas.h files in the kernel source code.

Alan Stern

Re: Ext. HDDs not working under Linux via USB 3.0 but under Windows

[Till Dörges]

Hi Alan,

sorry for the delay. It took me a while to get back to this.

Am 23.05.20 um 22:33 schrieb Alan Stern:

>>>> I'm trying to get external HDDs from Sony to work under Linux with USB 3.0.
>> [...]
>>>>  - PSZ-HA2T: idVendor=054c, idProduct=087d
>>>>  - PSZ-HA1T: idVendor=054c, idProduct=087d
>>>>  - PSZ-HA50: idVendor=054c, idProduct=087d
>>>>  - PSZ-HC1T: idVendor=054c, idProduct=0c4f
>> [...]
>>>> I've also tried several of the quirk settings
>>>> (https://github.com/torvalds/linux/blob/ead751507de86d90fa250431e9990a8b881f713c/drivers/usb/storage/usb.c#L527).

[...]
>>> Try adding an entry to the unusual_uas.h file for the device, specifying 
>>> the USB_FL_NO_REPORT_OPCODES flag.
>>
>> I'm not sure I understand correctly. Do I have to compile the uas Kernel module
>> myself if I want to test a flag?
>>
>> Because with setting the f flag (via options usb-storage quirks=054c:087d:f) the
>> PSZ-HA*1*T starts behaving nicely.
>>
>> --- snip ---
>> $ cat /sys/module/usb_storage/parameters/quirks
>> 054c:087d:f,054c:0c4f:f
>> --- snip ---
>>
>>
>> The PSZ-HA*2*T, however, still doesn't work with that.
Since the device stopped working under windows, I'm guessing that it's simply broken.

I'll try to get my hands on a new sample.


The PSZ-HA50 and the PSZ-HA1T work nicely when attached to USB 3.0 with this setting:

--- snip ---
$ cat /sys/module/usb_storage/parameters/quirks
054c:087d:u
--- snip ---

W/o this quirk they do not work.


I'd be surprised if a non-broken PSZ-HA2T behaved any differently.

So perhaps you might want to consider adding that quirk directly into the Kernel?


FTR, the PSZ-HC1T just worked.


Thanks again!


Regards -- Till
-- 
Dipl.-Inform. Till Dörges                  doerges@pre-sense.de
PRESENSE Technologies GmbH             Nagelsweg 41, D-20097 HH
Geschäftsführer/Managing Directors       AG Hamburg, HRB 107844
Till Dörges, Jürgen Sander               USt-IdNr.: DE263765024

Re: Ext. HDDs not working under Linux via USB 3.0 but under Windows

[Alan Stern]

On Wed, Jun 17, 2020 at 06:02:32PM +0200, Till Dörges wrote:
> Hi Alan,
> 
> sorry for the delay. It took me a while to get back to this.
> 
> Am 23.05.20 um 22:33 schrieb Alan Stern:
> 
> >>>> I'm trying to get external HDDs from Sony to work under Linux with USB 3.0.
> >> [...]
> >>>>  - PSZ-HA2T: idVendor=054c, idProduct=087d
> >>>>  - PSZ-HA1T: idVendor=054c, idProduct=087d
> >>>>  - PSZ-HA50: idVendor=054c, idProduct=087d
> >>>>  - PSZ-HC1T: idVendor=054c, idProduct=0c4f
> >> [...]
> >>>> I've also tried several of the quirk settings
> >>>> (https://github.com/torvalds/linux/blob/ead751507de86d90fa250431e9990a8b881f713c/drivers/usb/storage/usb.c#L527).
> 
> [...]
> >>> Try adding an entry to the unusual_uas.h file for the device, specifying 
> >>> the USB_FL_NO_REPORT_OPCODES flag.
> >>
> >> I'm not sure I understand correctly. Do I have to compile the uas Kernel module
> >> myself if I want to test a flag?
> >>
> >> Because with setting the f flag (via options usb-storage quirks=054c:087d:f) the
> >> PSZ-HA*1*T starts behaving nicely.
> >>
> >> --- snip ---
> >> $ cat /sys/module/usb_storage/parameters/quirks
> >> 054c:087d:f,054c:0c4f:f
> >> --- snip ---
> >>
> >>
> >> The PSZ-HA*2*T, however, still doesn't work with that.
> Since the device stopped working under windows, I'm guessing that it's simply broken.
> 
> I'll try to get my hands on a new sample.
> 
> 
> The PSZ-HA50 and the PSZ-HA1T work nicely when attached to USB 3.0 with this setting:
> 
> --- snip ---
> $ cat /sys/module/usb_storage/parameters/quirks
> 054c:087d:u
> --- snip ---
> 
> W/o this quirk they do not work.
> 
> 
> I'd be surprised if a non-broken PSZ-HA2T behaved any differently.
> 
> So perhaps you might want to consider adding that quirk directly into the Kernel?
> 
> 
> FTR, the PSZ-HC1T just worked.

Okay.  If you would like to write a patch for the quirk and submit it, you 
can.  Otherwise I'll write one for you.

Alan Stern

Re: Ext. HDDs not working under Linux via USB 3.0 but under Windows

[Till Dörges]

Am 17.06.20 um 18:37 schrieb Alan Stern:
> On Wed, Jun 17, 2020 at 06:02:32PM +0200, Till Dörges wrote:
>> Hi Alan,
>>
>> sorry for the delay. It took me a while to get back to this.
>>
>> Am 23.05.20 um 22:33 schrieb Alan Stern:
>>
>>>>>> I'm trying to get external HDDs from Sony to work under Linux with USB 3.0.
>>>> [...]
>>>>>>  - PSZ-HA2T: idVendor=054c, idProduct=087d
>>>>>>  - PSZ-HA1T: idVendor=054c, idProduct=087d
>>>>>>  - PSZ-HA50: idVendor=054c, idProduct=087d
>>>>>>  - PSZ-HC1T: idVendor=054c, idProduct=0c4f
>>>> [...]
>>>>>> I've also tried several of the quirk settings
>>>>>> (https://github.com/torvalds/linux/blob/ead751507de86d90fa250431e9990a8b881f713c/drivers/usb/storage/usb.c#L527).
>>
>> [...]
>>>>> Try adding an entry to the unusual_uas.h file for the device, specifying 
>>>>> the USB_FL_NO_REPORT_OPCODES flag.
>>>>
>>>> I'm not sure I understand correctly. Do I have to compile the uas Kernel module
>>>> myself if I want to test a flag?
>>>>
>>>> Because with setting the f flag (via options usb-storage quirks=054c:087d:f) the
>>>> PSZ-HA*1*T starts behaving nicely.
>>>>
>>>> --- snip ---
>>>> $ cat /sys/module/usb_storage/parameters/quirks
>>>> 054c:087d:f,054c:0c4f:f
>>>> --- snip ---
>>>>
>>>>
>>>> The PSZ-HA*2*T, however, still doesn't work with that.
>> Since the device stopped working under windows, I'm guessing that it's simply broken.
>>
>> I'll try to get my hands on a new sample.
>>
>>
>> The PSZ-HA50 and the PSZ-HA1T work nicely when attached to USB 3.0 with this setting:
>>
>> --- snip ---
>> $ cat /sys/module/usb_storage/parameters/quirks
>> 054c:087d:u
>> --- snip ---
>>
>> W/o this quirk they do not work.
>>
>>
>> I'd be surprised if a non-broken PSZ-HA2T behaved any differently.
>>
>> So perhaps you might want to consider adding that quirk directly into the Kernel?
>>
>>
>> FTR, the PSZ-HC1T just worked.
> 
> Okay.  If you would like to write a patch for the quirk and submit it, you 
> can.  Otherwise I'll write one for you.

I'd gladly take your offer of writing one for me. :-)

Thanks -- Till
-- 
Dipl.-Inform. Till Dörges                  doerges@pre-sense.de
PRESENSE Technologies GmbH             Nagelsweg 41, D-20097 HH
Geschäftsführer/Managing Directors       AG Hamburg, HRB 107844
Till Dörges, Jürgen Sander               USt-IdNr.: DE263765024

Re: Ext. HDDs not working under Linux via USB 3.0 but under Windows

[Till Dörges]

Am 18.06.20 um 08:07 schrieb Till Dörges:
> Am 17.06.20 um 18:37 schrieb Alan Stern:
>> On Wed, Jun 17, 2020 at 06:02:32PM +0200, Till Dörges wrote:
>>> Hi Alan,
>>>
>>> sorry for the delay. It took me a while to get back to this.
>>>
>>> Am 23.05.20 um 22:33 schrieb Alan Stern:
>>>
>>>>>>> I'm trying to get external HDDs from Sony to work under Linux with USB 3.0.
>>>>> [...]
>>>>>>>  - PSZ-HA2T: idVendor=054c, idProduct=087d
>>>>>>>  - PSZ-HA1T: idVendor=054c, idProduct=087d
>>>>>>>  - PSZ-HA50: idVendor=054c, idProduct=087d
[...]
>>>>> --- snip ---
>>>>> $ cat /sys/module/usb_storage/parameters/quirks
>>>>> 054c:087d:f,054c:0c4f:f
>>>>> --- snip ---
[...]
>>> --- snip ---
>>> $ cat /sys/module/usb_storage/parameters/quirks
>>> 054c:087d:u
>>> --- snip ---
>>>
>>> W/o this quirk they do not work.
>>>
>>>
>>> I'd be surprised if a non-broken PSZ-HA2T behaved any differently.
>>>
>>> So perhaps you might want to consider adding that quirk directly into the Kernel?
>>>
>>>
>>> FTR, the PSZ-HC1T just worked.
>>
>> Okay.  If you would like to write a patch for the quirk and submit it, you 
>> can.  Otherwise I'll write one for you.
> 
> I'd gladly take your offer of writing one for me. :-)

Maybe I spoke too soon.

I reported my results when setting the quirk 054c:087d:*u* (ignore UAS).

It just occurred to me that 054c:087d:*f* (NO_REPORT_OPCODES) might be sufficient.
Before going ahead with the patch I suggest I check that, too.

Thanks -- Till
-- 
Dipl.-Inform. Till Dörges                  doerges@pre-sense.de
PRESENSE Technologies GmbH             Nagelsweg 41, D-20097 HH
Geschäftsführer/Managing Directors       AG Hamburg, HRB 107844
Till Dörges, Jürgen Sander               USt-IdNr.: DE263765024

Re: Ext. HDDs not working under Linux via USB 3.0 but under Windows

[Till Dörges]

Am 18.06.20 um 09:30 schrieb Till Dörges:
> Am 18.06.20 um 08:07 schrieb Till Dörges:
>> Am 17.06.20 um 18:37 schrieb Alan Stern:
>>> On Wed, Jun 17, 2020 at 06:02:32PM +0200, Till Dörges wrote:
>>>> Hi Alan,
>>>>
>>>> sorry for the delay. It took me a while to get back to this.
>>>>
>>>> Am 23.05.20 um 22:33 schrieb Alan Stern:
>>>>
>>>>>>>> I'm trying to get external HDDs from Sony to work under Linux with USB 3.0.
>>>>>> [...]
>>>>>>>>  - PSZ-HA2T: idVendor=054c, idProduct=087d
>>>>>>>>  - PSZ-HA1T: idVendor=054c, idProduct=087d
>>>>>>>>  - PSZ-HA50: idVendor=054c, idProduct=087d
> [...]
>>>>>> --- snip ---
>>>>>> $ cat /sys/module/usb_storage/parameters/quirks
>>>>>> 054c:087d:f,054c:0c4f:f
>>>>>> --- snip ---
> [...]
>>>> --- snip ---
>>>> $ cat /sys/module/usb_storage/parameters/quirks
>>>> 054c:087d:u
>>>> --- snip ---
>>>>
>>>> W/o this quirk they do not work.
>>>>
>>>>
>>>> I'd be surprised if a non-broken PSZ-HA2T behaved any differently.
>>>>
>>>> So perhaps you might want to consider adding that quirk directly into the Kernel?
>>>>
>>>>
>>>> FTR, the PSZ-HC1T just worked.
>>>
>>> Okay.  If you would like to write a patch for the quirk and submit it, you 
>>> can.  Otherwise I'll write one for you.
>>
>> I'd gladly take your offer of writing one for me. :-)
> 
> Maybe I spoke too soon.

I actually did.

> I reported my results when setting the quirk 054c:087d:*u* (ignore UAS).
> 
> It just occurred to me that 054c:087d:*f* (NO_REPORT_OPCODES) might be sufficient.
> Before going ahead with the patch I suggest I check that, too.

It is. Both PSZ-HA drives work fine with just

--- snip ---
$ cat /sys/module/usb_storage/parameters/quirks
054c:087d:f
--- snap ---

Thanks -- Till
-- 
Dipl.-Inform. Till Dörges                  doerges@pre-sense.de
PRESENSE Technologies GmbH             Nagelsweg 41, D-20097 HH
Geschäftsführer/Managing Directors       AG Hamburg, HRB 107844
Till Dörges, Jürgen Sander               USt-IdNr.: DE263765024

Re: Ext. HDDs not working under Linux via USB 3.0 but under Windows

[Alan Stern]

> > I reported my results when setting the quirk 054c:087d:*u* (ignore UAS).
> > 
> > It just occurred to me that 054c:087d:*f* (NO_REPORT_OPCODES) might be sufficient.
> > Before going ahead with the patch I suggest I check that, too.
> 
> It is. Both PSZ-HA drives work fine with just
> 
> --- snip ---
> $ cat /sys/module/usb_storage/parameters/quirks
> 054c:087d:f
> --- snap ---
> 
> Thanks -- Till

Can you build and test a kernel with the patch below, to make sure it does 
what you want?

Alan Stern


Index: usb-devel/drivers/usb/storage/unusual_uas.h
===================================================================
--- usb-devel.orig/drivers/usb/storage/unusual_uas.h
+++ usb-devel/drivers/usb/storage/unusual_uas.h
@@ -28,6 +28,13 @@
  * and don't forget to CC: the USB development list <linux-usb@vger.kernel.org>
  */
 
+/* Reported-by: Till Dörges <doerges@pre-sense.de> */
+UNUSUAL_DEV(0x054c, 0x087d, 0x0000, 0x9999,
+		"Sony",
+		"PSZ-HA*",
+		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+		US_FL_NO_REPORT_OPCODES),
+
 /*
  * Apricorn USB3 dongle sometimes returns "USBSUSBSUSBS" in response to SCSI
  * commands in UAS mode.  Observed with the 1.28 firmware; are there others?

Re: Ext. HDDs not working under Linux via USB 3.0 but under Windows

[Till Dörges]

Am 19.06.20 um 17:05 schrieb Alan Stern:

> Can you build and test a kernel with the patch below, to make sure it does 
> what you want?

I was afraid you might say that. ;-)

I don't have a kernel dev environment handy (that was the main reason why I was happy
with your offer of writing the patch).

I'll try setting one up, but it may take a moment.

Regards -- Till
-- 
Dipl.-Inform. Till Dörges                  doerges@pre-sense.de
PRESENSE Technologies GmbH             Nagelsweg 41, D-20097 HH
Geschäftsführer/Managing Directors       AG Hamburg, HRB 107844
Till Dörges, Jürgen Sander               USt-IdNr.: DE263765024

Re: Ext. HDDs not working under Linux via USB 3.0 but under Windows

[Alan Stern]

On Fri, Jun 19, 2020 at 08:01:57PM +0200, Till Dörges wrote:
> Am 19.06.20 um 17:05 schrieb Alan Stern:
> 
> > Can you build and test a kernel with the patch below, to make sure it does 
> > what you want?
> 
> I was afraid you might say that. ;-)
> 
> I don't have a kernel dev environment handy (that was the main reason why I was happy
> with your offer of writing the patch).
> 
> I'll try setting one up, but it may take a moment.

It has been a couple of months.  Did you make any progress on this?

Alan Stern

Re: Ext. HDDs not working under Linux via USB 3.0 but under Windows

[Till Dörges]

Am 25.08.20 um 20:45 schrieb Alan Stern:
> On Fri, Jun 19, 2020 at 08:01:57PM +0200, Till Dörges wrote:
>> Am 19.06.20 um 17:05 schrieb Alan Stern:
>>
>>> Can you build and test a kernel with the patch below, to make sure it does 
>>> what you want?
>>
>> I was afraid you might say that. ;-)
>>
>> I don't have a kernel dev environment handy (that was the main reason why I was happy
>> with your offer of writing the patch).
>>
>> I'll try setting one up, but it may take a moment.
> 
> It has been a couple of months.  Did you make any progress on this?


Thanks for the reminder and sorry for the delay.


I just tested your patch and it works like a charm.


Testing was performed on:

--- snip ---
user@box:~> lsb-release -d
Description:    openSUSE Leap 15.1

user@box:~> uname -a
Linux box.none 4.12.14-lp151.28.59-default #1 SMP Wed Aug 5 10:58:34 UTC 2020
(337e42e) x86_64 x86_64 x86_64 GNU/Linux
--- snip ---


against the Kernel distributed by openSUSE:

--- snip ---
user@box:~> rpm -q kernel-source
kernel-source-4.12.14-lp151.28.59.1.noarch
--- snip ---


The patch applied and after loading the new uas.ko the HDDs which didn't work before
worked just fine.


I understand the openSUSE Leap Kernel is somewhat different from Kernel HEAD but I'd
assume that for the purpose of this test these differences are acceptable.


Is there anything else I can do to help?


Thanks again and regards -- Till
-- 
Dipl.-Inform. Till Dörges                  doerges@pre-sense.de
PRESENSE Technologies GmbH             Nagelsweg 41, D-20097 HH
Geschäftsführer/Managing Directors       AG Hamburg, HRB 107844
Till Dörges, Jürgen Sander               USt-IdNr.: DE263765024

Re: Ext. HDDs not working under Linux via USB 3.0 but under Windows

[Alan Stern]

On Wed, Aug 26, 2020 at 01:51:58PM +0200, Till Dörges wrote:
> Am 25.08.20 um 20:45 schrieb Alan Stern:
> > On Fri, Jun 19, 2020 at 08:01:57PM +0200, Till Dörges wrote:
> >> Am 19.06.20 um 17:05 schrieb Alan Stern:
> >>
> >>> Can you build and test a kernel with the patch below, to make sure it does 
> >>> what you want?
> >>
> >> I was afraid you might say that. ;-)
> >>
> >> I don't have a kernel dev environment handy (that was the main reason why I was happy
> >> with your offer of writing the patch).
> >>
> >> I'll try setting one up, but it may take a moment.
> > 
> > It has been a couple of months.  Did you make any progress on this?
> 
> 
> Thanks for the reminder and sorry for the delay.
> 
> 
> I just tested your patch and it works like a charm.
> 
> 
> Testing was performed on:
> 
> --- snip ---
> user@box:~> lsb-release -d
> Description:    openSUSE Leap 15.1
> 
> user@box:~> uname -a
> Linux box.none 4.12.14-lp151.28.59-default #1 SMP Wed Aug 5 10:58:34 UTC 2020
> (337e42e) x86_64 x86_64 x86_64 GNU/Linux
> --- snip ---
> 
> 
> against the Kernel distributed by openSUSE:
> 
> --- snip ---
> user@box:~> rpm -q kernel-source
> kernel-source-4.12.14-lp151.28.59.1.noarch
> --- snip ---
> 
> 
> The patch applied and after loading the new uas.ko the HDDs which didn't work before
> worked just fine.
> 
> 
> I understand the openSUSE Leap Kernel is somewhat different from Kernel HEAD but I'd
> assume that for the purpose of this test these differences are acceptable.
> 
> 
> Is there anything else I can do to help?

Nope, this is all set.  I'll go ahead and submit the patch.

Alan Stern

[PATCH] usb: storage: Add unusual_uas entry for Sony PSZ drives

[Alan Stern]

The PSZ-HA* family of USB disk drives from Sony can't handle the
REPORT OPCODES command when using the UAS protocol.  This patch adds
an appropriate quirks entry.

Reported-and-tested-by: Till Dörges <doerges@pre-sense.de>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>

---


[as1942]


 drivers/usb/storage/unusual_uas.h |    7 +++++++
 1 file changed, 7 insertions(+)

Index: usb-devel/drivers/usb/storage/unusual_uas.h
===================================================================
--- usb-devel.orig/drivers/usb/storage/unusual_uas.h
+++ usb-devel/drivers/usb/storage/unusual_uas.h
@@ -28,6 +28,13 @@
  * and don't forget to CC: the USB development list <linux-usb@vger.kernel.org>
  */
 
+/* Reported-by: Till Dörges <doerges@pre-sense.de> */
+UNUSUAL_DEV(0x054c, 0x087d, 0x0000, 0x9999,
+		"Sony",
+		"PSZ-HA*",
+		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+		US_FL_NO_REPORT_OPCODES),
+
 /* Reported-by: Julian Groß <julian.g@posteo.de> */
 UNUSUAL_DEV(0x059f, 0x105f, 0x0000, 0x9999,
 		"LaCie",