----------------
Unless someone has the hardware in question and wants to fix this for good I
think the only option is to blacklist this device for SMART. DK-disks won't be
able to use the SMART data of these USB bridges then.
Could someone please do the following for me:
Check the results of the following commands on the hdds in question. I'd assume
that they either trigger the reset problem or won't produce any SMART data.
Then, please include the lsusb -v data for this drive, so that I know what to
check against in the blacklist.
-----------------
Please do the four skdump commands (prefixed with sudo) and copy&paste their outputs. Then do "lsusb -v > /tmp/lsusb.txt" and attach /tmp/lsusb.txt. After each skdump command, please unplug and replug the drive, so that they all start from a defined state and aren't affected by the previous command.
Upstream response:
----------------
Unless someone has the hardware in question and wants to fix this for good I
think the only option is to blacklist this device for SMART. DK-disks won't be
able to use the SMART data of these USB bridges then.
Could someone please do the following for me:
Check the results of the following commands on the hdds in question. I'd assume
that they either trigger the reset problem or won't produce any SMART data.
skdump sat16:/dev/sdXXX
skdump sat12:/dev/sdXXX
skdump sunplus:/dev/sdXXX
skdump jmicron:/dev/sdXXX
Then, please include the lsusb -v data for this drive, so that I know what to
check against in the blacklist.
-----------------
Please do the four skdump commands (prefixed with sudo) and copy&paste their outputs. Then do "lsusb -v > /tmp/lsusb.txt" and attach /tmp/lsusb.txt. After each skdump command, please unplug and replug the drive, so that they all start from a defined state and aren't affected by the previous command.
Preferably you could send the results directly to https:/ /bugzilla. redhat. com/show_ bug.cgi? id=515881, but sending them here is fine as well, I'll forward them.
Thanks everyone!