Can anyone (Artem?) comment on why exactly this piece of code from hal's solaris uscsi() implementation is needed:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/hal/utils/cdutils.c#104 104 /* 105 * Blank Sense, we don't know what the error is or if 106 * the command succeeded, Hope for the best. Some 107 * drives return blank sense periodically and will 108 * fail if this is removed. 109 */ 110 if ((SENSE_KEY(rqbuf) == 0) && (ASC(rqbuf) == 0) && 111 (ASCQ(rqbuf) == 0)) { 112 ret = 0; 113 break; 114 } Shouldn't the uscsi() code handle the case where a SCSI command has failed with status STATUS_CHECK (= 2), but there is is not enough request sense data returned by the device? Amount of sense data returned is "scmd->uscsi_rqlen - scmd->uscsi_rqresid", and if the amount of sense data returned is less than sizeof(struct scsi_extended_sense), the code probably shouldn't look at SENSE_KEY, ASC or ASCQ. I think this problem is occurrring with current opensolaris bits on P-ATA ATAPI devices, after the December, 5th putback for these CRs: PSARC 2001/252 Recovering SCSI Sense Data 4046204 USCSICMD fails to pass back more than 20 bytes ARQ Sense DATA; 6603211 the uscsi_cdb should not restrict bp->b_back in the st driver It seems that this putback has broken auto request sense on atapi p-ata devices on the x86 platform; the ata driver doesn't return request sense data any more when a scsi command has failed and the request sense data buffer had a size of more than 20 bytes... And with cdutils.c just accepting the blank sense data as if no error has happend, hald seems to detect either an "cd-rom media" or an "audio cd media", when no media in present in an atapi p-ata device. I think this needs to be fixed in the "ata" driver. But the code in hal'd uscsi() function doesn't look quite right, either... -- This message posted from opensolaris.org
