cam patch: reducing logging output for 'normal' failures

[Alexander Motin]

Andriy Gapon wrote:
> on 24/11/2010 10:50 Alexander Motin said the following:
>> Bruce Cran wrote:
>>> I came across http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/119668
>>> which contains a patch to reduce the verbosity of output from the cam
>>> subsystem. cam has a tendancy to be a bit spammy when it 
>>> comes across fairly normal situations such as the tray having been left 
>>> open, or there just not being a disc present. For example:
>>>
>>> (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 
>>> (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
>>> (probe0:umass-sim0:0:0:0): SCSI status: Check Condition
>>> (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed)
>>> cd0 at umass-sim0 bus 0 scbus9 target 0 lun 0
>>> cd0: <DVDRW USB H16X B02T> Removable CD-ROM SCSI-0 device 
>>> cd0: 40.000MB/s transfers
>>> cd0: Attempt to query device size failed: NOT READY, Medium not present
>>> - tray closed
>>>
>>> The first message, "Medium not present - tray closed" is unnecessary 
>>> since it's repeated a few lines later and can look as though 
>>> there's a real problem. I've attached an updated patch which adds the 
>>> the tray open warning too.
>>>
>>> Any comments?
>> I have feeling that it could depend on consumer: whether it wants kernel
>> should log it's errors or not. For example, it could be reasonable to
>> log errors for kernel drivers not doing it by themselves, such as "ad"
>> or "ada" (another question why they couldn't do it). Same time it is
>> probably impractical to log errors for requests coming from user-level
>> via "pass" driver.
> 
> So how would kernel know would a consumer wants?
> I think that kernel should log only the conditions that it knows to be fatal and
> serious.  The rest is up to the consumers.  Which, BTW, should have a better
> picture of what's going and should be able to produce a more meaningful message.

Reasonable. The only question is about situations when CAM does some
error recovery, visible to consumer only as retries without any details
until finally completed. Such cases include: sense fetching, media load
waiting, device busy retrying, etc. We may want to add some option to
make CAM log these things for debugging purposes. These messages could
be somehow integrated with CAM_DEBUG output. I would really like last
one to be cleaned/refactored somehow, because last times I tried to read
it -- it was real pain.

> I think that Bruce's example above demonstrates this quite good - compare
> "umass-sim0" messages with "cd0" messages.

Sure.

-- 
Alexander Motin