From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: 'Device not ready' issue on mpt2sas since 3.1.10 Date: Tue, 17 Jul 2012 13:01:36 -0700 Message-ID: <20120717200136.GC24336@google.com> References: <4FE454CA.6080007@matthiasprager.de> <4FFAED4F.3080100@matthiasprager.de> <4FFB32E5.1050109@farcaster.org> <4FFB7354.8040809@matthiasprager.de> <4FFB8A86.7000009@farcaster.org> <4FFCBA4C.4000502@farcaster.org> <4FFD6F3D.2030708@matthiasprager.de> <4FFD8410.7050604@matthiasprager.de> <20120717180932.GB2878@google.com> <5005BF7D.2050703@matthiasprager.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-yw0-f46.google.com ([209.85.213.46]:38560 "EHLO mail-yw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755072Ab2GQUBl (ORCPT ); Tue, 17 Jul 2012 16:01:41 -0400 Received: by yhmm54 with SMTP id m54so819875yhm.19 for ; Tue, 17 Jul 2012 13:01:41 -0700 (PDT) Content-Disposition: inline In-Reply-To: <5005BF7D.2050703@matthiasprager.de> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Matthias Prager Cc: Robert Trace , linux-scsi@vger.kernel.org, Jens Axboe , Eric Moore , "James E.J. Bottomley" Hello, On Tue, Jul 17, 2012 at 09:39:41PM +0200, Matthias Prager wrote: > I could not however reproduce the issue on any other device than a LSI > SAS controller (using SATA disks) - on a regular ICH10 using AHCI and a > SATA drive I don't see these i/o errors. But since I'm experiencing > these issues on two different systems (both with lsi controllers while > running vmware-guests on them) and Robert sees them on his > (non-virtualized) system with the same lsi controller (9211-8i), I'm > inclined to make the following assumptions: > Either it is an issue which is limited to this controller and possibly > sata disks hanging off it or it is a more general issue with sas > controllers and sata disks (again it could well affect sas disks too). > Lacking other controllers or sas disks I can't be sure. So, nothing in the libata stack generates NOT_READY - "initializing command required". I suppose it's LSI firmware / driver translating TUR to CHECK_POWER_MODE and generating NOT_READY. I don't know what SAT says about this but this can't be correct. An ATA device in standby mode is ready to process any commands. It should be able to come back to full operation on demand as necessary and that's why it can be transparently enabled from device side. Eric? Thanks. -- tejun