On 04/17/2012 09:50 AM, Dan Williams wrote:
On Tue, Apr 17, 2012 at 7:44 AM, Tom Rini<trini@xxxxxx> wrote:
On 04/16/2012 08:25 PM, Dan Williams wrote:
On Mon, 2012-04-16 at 18:53 -0700, Tom Rini wrote:
Thanks, yes it looks like a new regression. Can you tell me if the
following fixes it?
No joy, oopses. http://alnk.org/43youngkirby for the dmesg and oops.
Agh, sorry, I rushed that one. The phy array is initialized later, here
is another run at it:
No crash, but 2 out of 4 SSDs still: http://pastebin.com/PCUGTBqG
Ok, this looks like a different issue around the changes to ata reset.
The intent was to leave mvsas with its old behavior (of not waiting
for resets to complete) until it could be updated to the new reset
scheme. Can you send a log from a good run on 3.3?
I want to see if the timings are different, because:
[ 10.039490] sas: ata10: end_device-6:4: dev error handler
[ 10.198842] ata10.00: failed to IDENTIFY (INIT_DEV_PARAMS failed,
[ 25.684822] sas: ata11: end_device-6:5: dev error handler
[ 25.844299] ata11.00: failed to IDENTIFY (INIT_DEV_PARAMS failed,
Is shorter than I would expect.
The 3.3.0 dmesg is up at http://pastebin.com/cVTmpH1M
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html