Re: [PATCH] log unhandled scsi error and sense messages via SCSI_LOG

[Rob Evers <revers@redhat.com>]

  On 10/07/2011 02:23 PM, James Bottomley wrote:
> On Fri, 2011-10-07 at 13:59 -0400, Rob Evers wrote:
>> ---
>>   drivers/scsi/scsi_lib.c |    6 ++++--
>>   1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index fc3f168..9905e2f 100644
>> --- a/drivers/scsi/scsi_lib.c
>> +++ b/drivers/scsi/scsi_lib.c
>> @@ -920,12 +920,14 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
>>   			action = ACTION_FAIL;
>>   			break;
>>   		default:
>> -			description = "Unhandled sense code";
>> +			SCSI_LOG_HLCOMPLETE(1, scmd_printk(KERN_INFO, cmd,
>> +							   "Unhandled sense code\n"));
>>   			action = ACTION_FAIL;
>>   			break;
>>   		}
>>   	} else {
>> -		description = "Unhandled error code";
>> +		SCSI_LOG_HLCOMPLETE(1, scmd_printk(KERN_INFO, cmd,
>> +						   "Unhandled error code\n"));
> I just don't understand the necessity of this.  We're going to fail the
> command and we'd like someone to understand why.

As someone who looks at this code and try's to understand what
happens, I agree but this is not always the case with our general
consumers of this code.

> Before this patch we print
>
> sdX: Unhandled sense code
> sdX:<sense information>
> sdX:<command information>
>
> Which hopefully causes someone to investigate what the actual problem
> is.
>
> If I apply this patch we're going to print
>
> sdX:<sense information>
> sdX:<command information>
>
> Which is even less helpful.
>
> If you're seeing some error or sense code that's causing a common retry,
> then perhaps we should add it to the codes we check for instead of
> trying to hide it?

I only currently have one example of multiple unhandled error and sense 
conditions.

Perhaps I could collect the others.

> James
>
>

According to the report I got, there is no functional problem, just
noise in /var/log/messages when fabric faults are occurring.

This is occurring for both un-handled error and un-handled sense codes.

I've been asked to reduce the noise as "Unhandled error code" and
"Unhandled sense code" seem to be causing some concern.

Can you suggest something to reduce the user concerns but doesn't
loose the information as to what code path is executing before other
informational prints occur?

This is what I was trying to get at in the previous post where Mike
Christie suggested the message be 'softened' but then Hannes suggested
the change I have here.  Perhaps softening is the best course until all the
cases are collected and appropriate decisions are made regarding
the types of messages for each of them?

Rob