Re: [PATCH 1/2] uas: Set no_report_opcodes

2014-09-10 Thread Hans de Goede
Hi,

On 09/09/2014 09:21 PM, Hans de Goede wrote:
 Hi,
 
 On 09/09/2014 06:01 PM, Christoph Hellwig wrote:
 On Tue, Sep 09, 2014 at 04:59:59PM +0200, Hans de Goede wrote:
 asm1051e usb - sata bridges hang when receiving a report opcodes scsi 
 cmnd.
 Take a page out of the usb-storage book, and simple disable 
 no_report_opcodes
 outright.

 Given that this device also seems broken in other ways can we wait a bit
 before using the big hammer?
 
 Actually the big hammer I would like to avoid is disabling uas all together
 on these devices, as they work fine with 2 out of 3 of the 3 disks I've
 tested with, as long as no report opcodes is not used.
 
 Which is why my other patch also includes a log message to explain how
 to enable uas despite the blacklist, but that will only work if we don't
 send report opcodes.
 
 I'm still hoping UAS might give us some
 better SCSI implementation so that we don't have to disable any kind of
 advanced feature.
 
 I understand, so an alternative would be to make this a quirk and only
 set it for ASM1051/ASM1053 bridges.

So further (stress) testing of ASM1051 bridges with disks with which they
do work under normal conditions have shown that even with those disks
they can get stuck / hang in a state which can only be recovered by an
unplug + replug (power cycle).

So basically ASM1051 bridges should just never be used together with uas,
which means that this patch can be dropped.

So: self-nak.

I'll respin the second patch in this set to change the log messages a
bit to reflect this new insight.

Regards,

Hans
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/2] uas: Set no_report_opcodes

2014-09-09 Thread Christoph Hellwig
On Tue, Sep 09, 2014 at 04:59:59PM +0200, Hans de Goede wrote:
 asm1051e usb - sata bridges hang when receiving a report opcodes scsi cmnd.
 Take a page out of the usb-storage book, and simple disable no_report_opcodes
 outright.

Given that this device also seems broken in other ways can we wait a bit
before using the big hammer?  I'm still hoping UAS might give us some
better SCSI implementation so that we don't have to disable any kind of
advanced feature.

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/2] uas: Set no_report_opcodes

2014-09-09 Thread Hans de Goede

Hi,

On 09/09/2014 06:01 PM, Christoph Hellwig wrote:

On Tue, Sep 09, 2014 at 04:59:59PM +0200, Hans de Goede wrote:

asm1051e usb - sata bridges hang when receiving a report opcodes scsi cmnd.
Take a page out of the usb-storage book, and simple disable no_report_opcodes
outright.


Given that this device also seems broken in other ways can we wait a bit
before using the big hammer?


Actually the big hammer I would like to avoid is disabling uas all together
on these devices, as they work fine with 2 out of 3 of the 3 disks I've
tested with, as long as no report opcodes is not used.

Which is why my other patch also includes a log message to explain how
to enable uas despite the blacklist, but that will only work if we don't
send report opcodes.

 I'm still hoping UAS might give us some

better SCSI implementation so that we don't have to disable any kind of
advanced feature.


I understand, so an alternative would be to make this a quirk and only
set it for ASM1051/ASM1053 bridges.

Even better would be to combine this with figuring out why the bridge is
becoming unhappy when paired with a crucial m500 ssd, and fix that +
a report opcodes quirk, so that we don't have the blacklist it at all.

Any ideas how to fix the unhappiness ? I've already tried setting all
the sdev flags the usb-storage driver sets, but that does not help.

Regards,

Hans



--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html