Re: [PATCH] mvsas: fix default can_queue

[Jeff Garzik <jeff@garzik.org>]

James Bottomley wrote:
> On Thu, 2008-03-06 at 09:52 -0600, James Bottomley wrote:
>> 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).
> 
> Actually, I looked in your mvi->rx_fis area where the D2H FIS should be
> and there seems to be a correct one collected.  The problem is that if
> the slot returns RXQ_ERR without any other flags set (other than the
> slot number), the driver does nothing.  Shouldn't the slot be completed
> and the D2H FIS returned so we can then do a request sense?

That's a good question...  Ke?

I wrote that slot completion code according to the docs, which seemed to 
indicate that nothing associated with a slot could be touched until 
RXQ_DONE was set.

It seemed analagous to the 'OWN' bit of a DMA ring found in many other 
hardwares, where software should not touch anything related to the 
descriptor if that bit is not set.

	Jeff