Hello Eric,
I think it is not necessary and current behavior of kernel like 2.6.31
confuses QA people.
They need explanation that message like below:
sd 5:0:1:0: [sdb] Sense Key : Recovered Error [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
72 01 00 1d 00 00 00 0e 09 0c 00 00 00 00 00 00
00 00 00 00 00 50
sd 5:0:1:0: [sdb] Add. Sense: ATA pass through information available
stands for that sense data contains ata registers file and the command was
executed properly.
Here is additional condition i used in scsi_io_completion() which suppresses
this message. Is it okay ?
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index f3c4089..7e8555a 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -774,8 +774,18 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned
int good_bytes)
* is what gets returned to the user
*/
if (sense_valid && sshdr.sense_key == RECOVERED_ERROR) {
- if (!(req->cmd_flags & REQ_QUIET))
- scsi_print_sense("", cmd);
+ if (!(req->cmd_flags & REQ_QUIET) &&
+ !((req->cmd[0] == ATA_16 || req->cmd[0] == ATA_12)
+ && (req->cmd[2] & (1 << 5))) ) {
+ /* skip reporting sense data for satl
+ ATA_12/16 if CK_COND bit is set
+ because:
+ - sense is delivered to app,
+ - by default cmd ends up with
+ 0x50 status byte
+ */
+ scsi_print_sense("", cmd);
+ }
result = 0;
/* BLOCK_PC may have set error */
error = 0;
This is something offtopic but i don't know yet where to look for answer to
following issue with native 2.6.31.5. I noticed that very often there is
used oom killer on a box with xeon (dual core), 2G ram during e.g. make -j2
modules so make can be killed but also e.g. ssh, hald (saw in dmesg). Anyway
make modules (! without j2 !)somewhat works also this issue doesn't happen
with kernel like 2.6.27.19 (Suse patches) - no matter make forks any time it
wants.
Any ideas ?
Regards,
Krzysztof Blaszkowski
--
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
