add NO_REPORT_LUNS quirk for at least a few Seagate external drives to fix smartctl with uas

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I found that for "smartctl" to work on my two Seagate Expansion
external USB3  I had to add the "j" usb-storage quirks ie
"US_FL_NO_REPORT_LUNS".
(They are years apart).



Bus 002 Device 008: ID 0bc2:231a Seagate RSS LLC Expansion Portable
Bus 002 Device 007: ID 0bc2:2037 Seagate RSS LLC Expansion HDD


Could these be added to drivers/usb/storage/unusual_uas.h
with the "US_FL_NO_REPORT_LUNS" quirk, after the existing
"UNUSUAL_DEV(0x0bc2, 0x331a, 0x0000, 0x9999," for the Seagate
"Expansion Desk"?

Or could you send me hacks to fix the REPORT_LUNS support for Seagate?

For now, I use "0bc2:2037:j" and "u,0x0bc2:0x231a:j" in
"/sys/module/usb_storage/parameters/quirks".


I got the idea from:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1363074667a6b7d0507527742ccd7bbed5e3ceaa
"
USB: uas: Add a new NO_REPORT_LUNS quirk
Add a new NO_REPORT_LUNS quirk and set it for Seagate drives with
an usb-id of: 0bc2:331a, as these will fail to respond to a
REPORT_LUNS command.
"

Discussion on
https://lore.kernel.org/all/1459426971-11927-1-git-send-email-hdegoede@xxxxxxxxxx/
of which 
https://lore.kernel.org/all/7977162.W24Fksp8b7@ok64/ tells that Seagate
at least back then had issues with REPORT_LUNS but not always: "
> Actually it does support REPORT LUNS, some of the time. When you first
> boot the computer with uas blacklisted for this device, so initialize
> it once with usb-storage, and then reboot with out the blacklist
> (and without removing power to the drive) uas will work with REPORT LUNS
> bit cold-booting directly into uas mode and then doing a REPORT LUNS
> upsets the drive / disk enclosure (this has all been observed by
> David Webb, I do not own such a drive).

Just to confirm what Hans has reported.  After power has been removed the 
Seagate Expansion usb disk always produces faults unless it has been 
blacklisted in some way.  Once the disk is working the computer can be powered 
off and restarted without the blacklist and, as long as its power has not been 
removed, the disk can be reconnected many times without any error.

With Hans's changes the disk mounts correctly with the uas module every time.

My guess is that one of the interface registers is not or cannot be 
initialized correctly.  If after a failure I try unplugging and reinserting 
the usb connector many times it has sometimes connected correctly - which to 
me means that some random bit eventually has the right value. 

"


Regards,
Alban





[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux