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@xxxxxxxxxxxxxxxxxxxxx> 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
--
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
