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). James -- 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
