On Tuesday 22 December 2009 20:44, Douglas Gilbert wrote: > Krzysztof Błaszkowski wrote: > > 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 ? > > Close but I would like to see a filter on the additional > sense code ATA PASS-THROUGH INFORMATION AVAILABLE [0x0, 0x1d]. > There is nothing in SAT that precludes the return of a RECOVERED > ERROR sense code for a read on a SATA disk that was recovered > after some extra work (for example). of course but is it good idea to log sense data if: - it is created on demand by application. (sat-2 ch 12.2.2 and .3) - it doesn't contain some failure status ? > With that filter in place there is no need to filter on the command. right but OTOH if filter used asc/ascq then it would filter out all commands even these with some failures. i am not sure if this is really what you want to have, ie block all dumps of ATA PASS-THROUGH sense data. > > IOWs just filter on sense code RECOVERED ERROR and additional > sense code ATA PASS-THROUGH INFORMATION AVAILABLE. SAT and SAT-2 > compliant implementations should then dump less to the log. i would say that asc/ascq filter will stop logging all SAT/SAT-2 check conditions instead of "less". that improvement i sent has better "granularity". > > Doug Gilbert 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
