Bug 119668

Summary: [cam] [patch] certain errors are too verbose comparing to their importance
Product: Base System Reporter: Andriy Gapon <avg>
Component: kernAssignee: Andriy Gapon <avg>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 6.2-RELEASE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
verboseness.diff none

Description Andriy Gapon 2008-01-14 17:20:02 UTC
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.

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

	
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
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2008-01-14 18:45:14 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-scsi

Over to maintainer(s).
Comment 2 Andriy Gapon freebsd_committer freebsd_triage 2010-12-05 15:31:59 UTC
Responsible Changed
From-To: freebsd-scsi->avg

I think the proposed change still has a merit.
Comment 3 Andriy Gapon freebsd_committer freebsd_triage 2011-04-07 08:12:33 UTC
State Changed
From-To: open->closed

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.