public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ke Wei <kewei.mv@gmail.com>
Cc: linux-scsi <linux-scsi@vger.kernel.org>, jgarzik <jgarzik@redhat.com>
Subject: Re: [PATCH] mvsas: fix default can_queue
Date: Thu, 06 Mar 2008 09:52:04 -0600	[thread overview]
Message-ID: <1204818725.3062.14.camel@localhost.localdomain> (raw)
In-Reply-To: <6b2481670803060646m54675625g729a82c4da33ce05@mail.gmail.com>

On Thu, 2008-03-06 at 22:46 +0800, Ke Wei wrote:
> On Thu, Mar 6, 2008 at 5:02 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> 
> 1.
> > >
> > > OK, I instrumented more ... you're right, the first failing command is
> > > REPORT_LUNS.  The failure isn't because the DVD doesn't accept the
> > > command, but because it gets errored and we fail to report back the
> > > error data.
> 
> First, I noticed that scsi_probe_and_add_lun function has changed
> since v2.6.17-git4.
> It will cause bflagsp to miss BLIST_NOREPORTLUN flag after calling scsi_add_lun.
> On the other hand,  Even though mvsas driver can succeed in reporting
> back the error data, scsi subsystem also will force device to reset
> because of wrong REPORTLUN status. But Error again, then reset.
> Maybe I may write simulation codes for this command.

But this isn't the problem.

I'll look into the mid layer changes and see if we have a problem.
However, this device does respond correctly (with an error) to
REPORT_LUNS (however, at the moment, for me, the current setup is a
great test of ATA error handling).

When I have it on the aic94xx it terminates the command and sends back a
Register D2H FIS with

error = 0x54 (sense key ILLEGAL REQUEST, ABRT)
status = 0x51 (DRDY, SERV, CHK)

So the device does a correct termination for an unsupported command.
The problem seems to be that mvsas isn't terminating and picking up the
register D2H fis properly.  Which, in turn seems to be connected with
the way it's not really processing a RXQ_ERR return.

This is a perfectly proper termination, and the scan routine will
proceed normally without invoking any error handling (it's aware of the
conflict between SPC and MMC regarding REPORT_LUNS).

James



  reply	other threads:[~2008-03-06 15:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-29 18:01 [PATCH] mvsas: fix default can_queue James Bottomley
2008-03-03  0:42 ` James Bottomley
2008-03-03  8:17   ` Ke Wei
2008-03-03 14:59     ` James Bottomley
2008-03-03 16:40       ` James Bottomley
2008-03-05  2:07       ` James Bottomley
2008-03-05 21:02         ` James Bottomley
2008-03-06 14:46           ` Ke Wei
2008-03-06 15:52             ` James Bottomley [this message]
2008-03-06 17:44               ` James Bottomley
2008-03-06 17:59                 ` Jeff Garzik
2008-03-07 10:50                   ` Ke Wei
2008-03-07 15:03                     ` James Bottomley
2008-03-07 15:31                       ` Ke Wei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1204818725.3062.14.camel@localhost.localdomain \
    --to=james.bottomley@hansenpartnership.com \
    --cc=jgarzik@redhat.com \
    --cc=kewei.mv@gmail.com \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox