USB-Storage Quirk for 174c:1356

[Yuji Saeki]

A usb-storage quirk is needed for the Mediasonic ProRaid 2 Bay 2.5' SATA HDD / SSD Enclosure - USB 3.1 Gen-II Type-C (HUR6-SU31) for reliable use in Ubuntu/Kubuntu 14-17.10. Using quirk 'u' appears to have fixed disconnect issues during install and use.

Linux Version: Ubuntu 4.13.0-16.19-generic 4.13.4

Device ID:174c:1356 ASMedia Technology Inc.

usb 9-1: new SuperSpeed USB device number 2 using xhci_hcd
usb 9-1: New USB device found, idVendor=174c, idProduct=1356
usb 9-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
usb 9-1: Product: ASM1352R-Fast
usb 9-1: Manufacturer: ASMT
usb 9-1: SerialNumber: 0000000000000001
usb 9-1: UAS is blacklisted for this device, using usb-storage instead

Note: With/without UAS the issue persisted. I disabled UAS to prevent devices sleeping to eliminate that as a possibility.

Symptoms: Before using the quirk, the enclosure would completely stop responding during an install attempt, and the usb host would eventually be disabled. The device's LEDs would continue to blink as if being accessed.

Fix: I specified the quirk by appending "usb-storage.quirks=174c:1356:u" to the linux line in Grub. Hopefully others can verify this (if I'm not insane) and include a patch for this upstream in the Kernel.

Note: For those who install to a device such as this, you may need to modify your installation before booting it, by creating a file "/etc/modprobe.d/asm1352r-usb-quirk.conf" with contents "options usb-storage quirks=0x174c:0x1356:u". I have seen others (through Google) issuing the same "u" quirk for several ASMedia devices...Perhaps their chipsets need this?

This is my first bug report. If any more information is needed, please inform me. I'd like to thank a TJ- in Ubuntu's IRC for helping nail this down.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1742318

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Yuji Saeki (ysaeki-deactivatedaccount)]

In response to Ubuntu Kernel Bot:

Some of the log files that were automatically posted were sensitive. They were removed for this reason. I'll set this to confirmed in hopes that this can be overlooked. If any specific logs are needed, please follow up with which logs in particular.

[Yuji Saeki (ysaeki-deactivatedaccount)]

Some of the log files that were automatically posted were sensitive. They were removed for this reason. I'll set this to confirmed in hopes that this can be overlooked. If any specific logs are needed, please follow up with which logs in particular.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.15 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.15-rc7

[Yuji Saeki (ysaeki-deactivatedaccount)]

I am not aware of any method to use an upstream kernel during a Live CD/DVD/USB to install Ubuntu/Kubuntu. I have only noticed it happening during an install.

[Yuji Saeki (ysaeki-deactivatedaccount)]

I checked the usb/core/quirks.c and other various source code under driver/usb/storage, but only one file sticks out as targeting the vendor, and it doesn't have code related to this device.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/storage/uas-detect.h?h=v4.15-rc7

/*
 * ASMedia has a number of usb3 to sata bridge chips, at the time of
 * this writing the following versions exist:
 * ASM1051 - no uas support version
 * ASM1051 - with broken (*) uas support
 * ASM1053 - with working uas support, but problems with large xfers
 * ASM1153 - with working uas support
 *
 * Devices with these chips re-use a number of device-ids over the
 * entire line, so the device-id is useless to determine if we're
 * dealing with an ASM1051 (which we want to avoid).
 *
 * The ASM1153 can be identified by config.MaxPower == 0,
 * where as the ASM105x models have config.MaxPower == 36.
 *
 * Differentiating between the ASM1053 and ASM1051 is trickier, when
 * connected over USB-3 we can look at the number of streams supported,
 * ASM1051 supports 32 streams, where as early ASM1053 versions support
 * 16 streams, newer ASM1053-s also support 32 streams, but have a
 * different prod-id.
 *
 * (*) ASM1051 chips do work with UAS with some disks (with the
 * US_FL_NO_REPORT_OPCODES quirk), but are broken with other disks
 */
if (le16_to_cpu(udev->descriptor.idVendor) == 0x174c &&
  (le16_to_cpu(udev->descriptor.idProduct) == 0x5106 ||
   le16_to_cpu(udev->descriptor.idProduct) == 0x55aa)) {
 if (udev->actconfig->desc.bMaxPower == 0) {
  /* ASM1153, do nothing */
 } else if (udev->speed < USB_SPEED_SUPER) {
  /* No streams info, assume ASM1051 */
  flags |= US_FL_IGNORE_UAS;
 } else if (usb_ss_max_streams(&eps[1]->ss_ep_comp) == 32) {
  /* Possibly an ASM1051, disable uas */
  flags |= US_FL_IGNORE_UAS;
 } else {
  /* ASM1053, these have issues with large transfers */
  flags |= US_FL_MAX_SECTORS_240;
 }
}

It seems to be a case of simply adding this device into the routine.

[Yuji Saeki (ysaeki-deactivatedaccount)]

Another, more specific source code would be unusual_devs.h. Manually specified ASMedia devices:

/* Reported by Oliver Neukum <email address hidden> */
UNUSUAL_DEV( 0x174c, 0x55aa, 0x0100, 0x0100,
  "ASMedia",
  "AS2105",
  USB_SC_DEVICE, USB_PR_DEVICE, NULL,
  US_FL_NEEDS_CAP16)...

It may be more appropriate to add this device in either or both places. At the moment, I have only tested quirk US_FL_IGNORE_UAS (u) (which worked for an install).

[Kai-Heng Feng (kaihengfeng)]

Can you attach the full dmesg?

[Yuji Saeki (ysaeki-deactivatedaccount)]

Forget it. You don't want to know someone has an issue with the kernel, fine. Delete/close bug then.

[Yuji Saeki (ysaeki-deactivatedaccount)]

It'll definitely be the last time I file a report.

[Kai-Heng Feng (kaihengfeng)]

Adding a quirk for the device is easy. But since you stated that "With/without UAS the issue persisted", we need full dmesg to fully understand on the underlying problem.

[Johannes Choo (jhanschoo)]

Hi, I am facing a related bug. I am using an SSD enclosure utilizing the ASM1352R controller as well. This controller supports RAID-0, RAID-1 and other configurations with up to two SSDs, and I'm currently using it with only one SSD; the product advertises as ASM1352R-Safe in this configuration, which is also what it advertises as when in RAID-1. I am running Debian buster.

The advertised product IDs and serial, etc. are all different for me. Nevertheless, the bug still remains, and the fix proposed by OP works.

OP mentioned "With/without UAS the issue persisted". I suspect that OP might be confused and does not realize that the fix he proposes is responsible for the message "UAS is blacklisted for this device, using usb-storage instead"; the quirk he used disables UAS support from the kernel side.

Nevertheless, fix OP proposes is not a universal fix. ASMedia, reputable hardware manufacturer that it is, manufactures multiple chips with different architectures and capabilities under the same vendorId:productId identifier. Blacklisting this identifier will blacklist all its controllers, which may not exactly be a bad thing as multiple other models have issues with UAS under Linux as well.

Inspection of latest upstream source seems that it is not handled upstream, though I have not tried running it.

I'd be happy to contribute however I can but I have my hands tied if you need more info: I'm running Debian buster, and I'm running the controller with only one SSD. Nevertheless, it seems to me that this is an upstream bug and not Ubuntu-kernel specific.

[Kai-Heng Feng (kaihengfeng)]

> On 13 Jan 2018, at 6:20 PM, Johannes Choo <email address hidden> wrote:
>
> Hi, I am facing a related bug. I am using an SSD enclosure utilizing the
> ASM1352R controller as well. This controller supports RAID-0, RAID-1 and
> other configurations with up to two SSDs, and I'm currently using it
> with only one SSD; the product advertises as ASM1352R-Safe in this
> configuration, which is also what it advertises as when in RAID-1. I am
> running Debian buster.

Most issues like this are distro-agnostic.

>
> The advertised product IDs and serial, etc. are all different for me.
> Nevertheless, the bug still remains, and the fix proposed by OP works.

By disabling UAS, the speed should be slower.

>
> OP mentioned "With/without UAS the issue persisted". I suspect that OP
> might be confused and does not realize that the fix he proposes is
> responsible for the message "UAS is blacklisted for this device, using
> usb-storage instead"; the quirk he used disables UAS support from the
> kernel side.

Well, that’s the part I tried to understand, but apparently I offended him/her somehow =/

>
> Nevertheless, fix OP proposes is not a universal fix. ASMedia, reputable
> hardware manufacturer that it is, manufactures multiple chips with
> different architectures and capabilities under the same
> vendorId:productId identifier. Blacklisting this identifier will
> blacklist all its controllers, which may not exactly be a bad thing as
> multiple other models have issues with UAS under Linux as well.

Ideally we should solve this without having to disable UAS completely.

>
> Inspection of latest upstream source seems that it is not handled
> upstream, though I have not tried running it.
>
> I'd be happy to contribute however I can but I have my hands tied if you
> need more info: I'm running Debian buster, and I'm running the
> controller with only one SSD. Nevertheless, it seems to me that this is
> an upstream bug and not Ubuntu-kernel specific.

A full dmesg when this issue happens will be really helpful.

>
> --
> You received this bug notification because you are subscribed to linux
> in Ubuntu.
> https://bugs.launchpad.net/bugs/1742318
>
> Title:
> USB-Storage Quirk for 174c:1356
>
> Status in linux package in Ubuntu:
> Incomplete
>
> Bug description:
> A usb-storage quirk is needed for the Mediasonic ProRaid 2 Bay 2.5'
> SATA HDD / SSD Enclosure - USB 3.1 Gen-II Type-C (HUR6-SU31) for
> reliable use in Ubuntu/Kubuntu 14-17.10. Using quirk 'u' appears to
> have fixed disconnect issues during install and use.
>
> Linux Version: Ubuntu 4.13.0-16.19-generic 4.13.4
>
> Device ID:174c:1356 ASMedia Technology Inc.
>
> usb 9-1: new SuperSpeed USB device number 2 using xhci_hcd
> usb 9-1: New USB device found, idVendor=174c, idProduct=1356
> usb 9-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
> usb 9-1: Product: ASM1352R-Fast
> usb 9-1: Manufacturer: ASMT
> usb 9-1: SerialNumber: 0000000000000001
> usb 9-1: UAS is blacklisted for this device, using usb-storage instead
>
> Note: With/without UAS the issue persisted. I disabled UAS to prevent
> devices sleeping to eliminate that as a possibility.
>
> Symp...

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]