From avg@cybervisiontech.com.ua  Mon Jan 14 17:19:31 2008
Return-Path: <avg@cybervisiontech.com.ua>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 1F6D216A469
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 14 Jan 2008 17:19:31 +0000 (UTC)
	(envelope-from avg@cybervisiontech.com.ua)
Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9])
	by mx1.freebsd.org (Postfix) with ESMTP id C2ABF13C45D
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 14 Jan 2008 17:19:29 +0000 (UTC)
	(envelope-from avg@cybervisiontech.com.ua)
Received: from localhost (localhost [127.0.0.1])
	by falcon.cybervisiontech.com (Postfix) with ESMTP id 893EB74400E
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 14 Jan 2008 19:19:28 +0200 (EET)
Received: from falcon.cybervisiontech.com ([127.0.0.1])
	by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id nG5kAThkMKAK for <FreeBSD-gnats-submit@freebsd.org>;
	Mon, 14 Jan 2008 19:19:28 +0200 (EET)
Received: from rein.cybervisiontech.com.ua (gateway.cybervisiontech.com.ua [88.81.251.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by falcon.cybervisiontech.com (Postfix) with ESMTP id 1DA75744008
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 14 Jan 2008 19:19:28 +0200 (EET)
Received: from rein.cybervisiontech.com.ua (localhost [127.0.0.1])
	by rein.cybervisiontech.com.ua (8.13.8/8.13.8) with ESMTP id m0EHJRQ7074949
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 14 Jan 2008 19:19:27 +0200 (EET)
	(envelope-from avg@rein.cybervisiontech.com.ua)
Received: (from avg@localhost)
	by rein.cybervisiontech.com.ua (8.13.8/8.13.8/Submit) id m0EHJRh8074948;
	Mon, 14 Jan 2008 19:19:27 +0200 (EET)
	(envelope-from avg)
Message-Id: <200801141719.m0EHJRh8074948@rein.cybervisiontech.com.ua>
Date: Mon, 14 Jan 2008 19:19:27 +0200 (EET)
From: Andriy Gapon <avg@icyb.net.ua>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: scsi/cam: certain errors are too verbose comparing to their importance
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         119668
>Category:       kern
>Synopsis:       [cam] [patch] certain errors are too verbose comparing to their importance
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    avg
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jan 14 17:20:02 UTC 2008
>Closed-Date:    Thu Apr 07 07:14:41 UTC 2011
>Last-Modified:  Thu Apr 07 07:14:41 UTC 2011
>Originator:     Andriy Gapon
>Release:        FreeBSD 6.2-RELEASE-p6 amd64
>Organization:
>Environment:
System: FreeBSD 6.2-RELEASE-p6 amd64


	
>Description:
Rationale for this request is that kernel messages easily get spammed
with the error reports which do not really mean error conditions. Some
amount of such noise comes from the kernel-land actions, lots more can
come from user-land programs unwittingly trying to do certain things on
the devices with no media or wrong media (example: hald).

Examples of such conditions: empty slots in card reader, changed media,
attempts to read audio CD as data CD. Typical CAM messages:
ILLEGAL REQUEST Illegal mode for this track
ILLEGAL REQUEST Medium removal prevented
NOT READY       Medium not present
UNIT ATTENTION  Not ready to ready change, medium may have changed

All of the above don't really mean any problem with a device or media,
in this sense the conditions can be called normal operation situations.

The following is proposed:
1. introduce new scsi_sense_action_qualifier value
SSQ_PRINT_SENSE_VERBOSE, which would mean that detailed command and
response information is to be printed only if bootverbose==1;

2. introduce new define SS_FATAL_NORMAL with value of
(SS_FAIL|SSQ_PRINT_SENSE_VERBOSE), which would mean a fatal SCSI error
that can happen in "normal conditions", i.e. in the most cases the error
doesn't imply a problem with a peripheral device, media, bus,
controller, etc;

3. use the above SS_FATAL_NORMAL for at least the conditions mentioned above;

4. modify camperiphscsisenseerror() to honor the new flag defined above;

P.S. the names I used above are no very good but I couldn't come up
with anything better.

>How-To-Repeat:
Couple of links describing end-user experience (mine included):
http://lists.freebsd.org/pipermail/freebsd-gnome/2007-January/016544.html
http://forums.pcbsd.org/viewtopic.php?f=7&t=7044
http://lists.freebsd.org/pipermail/freebsd-gnome/2007-December/018816.html

>Fix:
The attached patch doesn't include code for 'Medium removal prevented'
condition.

	

--- verboseness.diff begins here ---
--- sys/cam/scsi/scsi_all.h.orig	Fri Dec 21 17:52:50 2007
+++ sys/cam/scsi/scsi_all.h	Fri Dec 21 17:57:29 2007
@@ -90,6 +90,7 @@ typedef enum {
 					    * and text.
 					    */
 	SSQ_PRINT_SENSE		= 0x0800,
+	SSQ_PRINT_SENSE_VERBOSE	= 0x1000,
 	SSQ_MASK		= 0xff00
 } scsi_sense_action_qualifier;
 
@@ -104,6 +105,12 @@ typedef enum {
 
 /* Fatal error action, with table specified error code */
 #define SS_FATAL	SS_FAIL|SSQ_PRINT_SENSE
+
+/* Fatal error action, with table specified error code */
+/* This type of error doesn't imply malfunction of hardware and
+ * and indicates conditions that can occur in "normal" circumstances
+ */
+#define SS_FATAL_NORMAL	SS_FAIL|SSQ_PRINT_SENSE_VERBOSE
 
 struct scsi_generic
 {
--- sys/cam/scsi/scsi_all.c.orig	Fri Dec 21 17:54:50 2007
+++ sys/cam/scsi/scsi_all.c	Tue Dec 25 14:07:45 2007
@@ -1102,7 +1102,7 @@ static struct asc_table_entry asc_table[
 			"Persistent write protect") },
 /*  T           */{SST(0x27, 0x05, SS_FATAL|EACCES,
 			"Permanent write protect") },
-/* DTLPWRSOMCAE */{SST(0x28, 0x00, SS_FATAL|ENXIO,
+/* DTLPWRSOMCAE */{SST(0x28, 0x00, SS_FATAL_NORMAL|ENXIO,
 			"Not ready to ready change, medium may have changed") },
 /* DTLPWRSOMCAE */{SST(0x28, 0x01, SS_FATAL|ENXIO,
 			"Import or export element accessed") },
@@ -1197,7 +1197,7 @@ static struct asc_table_entry asc_table[
 			"Rounded parameter") },
 /* DTL WRSOMCAE */{SST(0x39, 0x00, SS_RDEF,
 			"Saving parameters not supported") },
-/* DTL WRSOM    */{SST(0x3A, 0x00, SS_FATAL|ENXIO,
+/* DTL WRSOM    */{SST(0x3A, 0x00, SS_FATAL_NORMAL|ENXIO,
 			"Medium not present") },
 /* DT  WR OM    */{SST(0x3A, 0x01, SS_FATAL|ENXIO,
 			"Medium not present - tray closed") },
@@ -1395,7 +1395,7 @@ static struct asc_table_entry asc_table[
 			"End of user area encountered on this track") },
 /*      R       */{SST(0x63, 0x01, SS_FATAL|ENOSPC,
 			"Packet does not fit in available space") },
-/*      R       */{SST(0x64, 0x00, SS_FATAL|ENXIO,
+/*      R       */{SST(0x64, 0x00, SS_FATAL_NORMAL|ENXIO,
 			"Illegal mode for this track") },
 /*      R       */{SST(0x64, 0x01, SS_RDEF,
 			"Invalid packet size") },
--- sys/cam/cam_periph.c.orig	Fri Dec 21 17:57:53 2007
+++ sys/cam/cam_periph.c	Fri Dec 21 18:00:13 2007
@@ -1515,7 +1515,8 @@ camperiphscsisenseerror(union ccb *ccb, 
 		}
 
 sense_error_done:
-		if ((err_action & SSQ_PRINT_SENSE) != 0
+		if (((err_action & SSQ_PRINT_SENSE) != 0
+		    || ((err_action & SSQ_PRINT_SENSE_VERBOSE) != 0 && bootverbose))
 		 && (ccb->ccb_h.status & CAM_AUTOSNS_VALID) != 0) {
 			cam_error_print(print_ccb, CAM_ESF_ALL, CAM_EPF_ALL);
 			xpt_print_path(ccb->ccb_h.path);
--- verboseness.diff ends here ---


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-scsi 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon Jan 14 18:45:14 UTC 2008 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=119668 
Responsible-Changed-From-To: freebsd-scsi->avg 
Responsible-Changed-By: avg 
Responsible-Changed-When: Sun Dec 5 15:31:59 UTC 2010 
Responsible-Changed-Why:  
I think the proposed change still has a merit. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=119668 
State-Changed-From-To: open->closed 
State-Changed-By: avg 
State-Changed-When: Thu Apr 7 07:12:33 UTC 2011 
State-Changed-Why:  
Having thought about this issue more it seems that the suggested 
approach is too simplistic because it lacks any context awareness. 
I think that it's better to achieve the goal by judgeous use of 
SF_NO_PRINT and custom error handling logic in peripheral drivers. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=119668 
>Unformatted:
