From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Christie Subject: Re: [PATCH] log unhandled scsi error and sense messages via SCSI_LOG Date: Fri, 07 Oct 2011 14:28:43 -0500 Message-ID: <4E8F52EB.3070000@cs.wisc.edu> References: <1318010370-26976-1-git-send-email-revers@redhat.com> <1318011808.5071.90.camel@dabdike.int.hansenpartnership.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: Received: from sabe.cs.wisc.edu ([128.105.6.20]:58927 "EHLO sabe.cs.wisc.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753969Ab1JGT2z (ORCPT ); Fri, 7 Oct 2011 15:28:55 -0400 In-Reply-To: <1318011808.5071.90.camel@dabdike.int.hansenpartnership.com> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: James Bottomley Cc: Rob Evers , linux-scsi@vger.kernel.org, hare@suse.de On 10/07/2011 01:23 PM, James Bottomley wrote: > 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? We get questions about pretty much all of the error codes that do not have a extra string and can get failed here. The problem is with the use of the word unhandled. Users think for retryable errors we did not retry, or they think it means even if they have multipath/raid that the error is going to the application or FS so they get worried and make extra support requests. Was the patch that just changed the strings to ""Extended sense description not available" and "Extended error description not available": http://www.spinics.net/lists/linux-scsi/msg54874.html ok? I think in the end Rob is just trying to get out of having to figure out strings for all the error codes :)