> Was this tested with uas or usb-storage?
On both. dd works either way.
> Are you certain Oliver's new code was executed? If you put
> US_FL_NO_WP_DETECT only in unusual_devs.h and not in ususual_uas.h then
> it would not affect the uas driver.
Yes, the code ran.
Further debugging shows that the code that causes the device to hang is in
drivers/scsi/sd.c:2698. So the reason why usb-storage works and UAS does
not is because the device setting both skip_ms_page_3f=1 and
skip_ms_page_8=1 is required. The US_FL_NO_WP_DETECT flag does the former,
and usb-storage (but not UAS) by default does the latter
(drivers/usb/storage/scsiglue.c:198):
/*
* A number of devices have problems with MODE SENSE for
* page x08, so we will skip it.
*/
sdev->skip_ms_page_8 = 1;
Forcing both skip_ms_page_3f and skip_ms_page_8 to 1 results in UAS and
usb-storage working. Oliver's code only set skip_ms_page_3f.
Do we want a patch to introduce a quirk flag for skip_ms_page_8, similar to
the US_FL_NO_WP_DETECT quirk bit for skip_ms_page_3f? This may even resolve
the issues with other devices in unusual_uas.h that currently have all UAS
support disabled. I'd be happy to write the patch, but I'm not sure we want
to reserve a quirk bit for what's currently only a single device known to
have this issue. Please advise.
On 05/17/2018 12:13 PM, Alan Stern wrote:
> On Thu, 17 May 2018, Alexander Kappner wrote:
>
>> Oliver and Alan,
>>
>> thank for investigating.
>>
>>> this is suspicious. You do not actually whether US_FL_NO_WP_DETECT
>>> by itself would make the device work. Can you please test that?
>>
>> US_FL_NO_WP_DETECT without US_FL_IGNORE_UAS does not make a difference,
>> even with the patch you included applied:
>
> Are you certain Oliver's new code was executed? If you put
> US_FL_NO_WP_DETECT only in unusual_devs.h and not in ususual_uas.h then
> it would not affect the uas driver.
>
>>> That's bizarre too. Even though the only difference is a MODE SENSE
>>> command, the command that actually faliled was WRITE(16).
>> It looks to me like the MODE SENSE simply hangs the drive, so anything
>> issued after that will fail. Of course the drive says it's the "current
>> command" that caused the failure, but I wouldn't give too much credence to
>> that. FYI -- this device is a consumer grade rotational drive that you can
>> get for less than $200, so I wouldn't be surprised if the implementations
>> have issues.
>>
>> Also, I noticed that copying onto the drive with dd works fine, whereas
>> trying to mount a filesystem immediately crashes it. I suspect this is
>> because check_disk_change is called on mount (which eventually calls down
>> to sd_read_write_protect_flag, which is where the US_FL_NO_WP_DETECT flag
>> comes into play).
>
> Was this tested with uas or usb-storage?
>
> Alan Stern
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
