From owner-freebsd-questions@FreeBSD.ORG Thu Apr 3 13:24:41 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A1C7169 for ; Thu, 3 Apr 2014 13:24:41 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B224BC49 for ; Thu, 3 Apr 2014 13:24:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s33DOTpe098671; Fri, 4 Apr 2014 00:24:30 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 4 Apr 2014 00:24:29 +1100 (EST) From: Ian Smith To: kpneal@pobox.com Subject: Re: CAM status: CCB request completed with an error In-Reply-To: Message-ID: <20140403231108.F92606@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-questions@freebsd.org, "Ronald F. Guilmette" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 13:24:41 -0000 In freebsd-questions Digest, Vol 513, Issue 5, Message: 29 On Thu, 3 Apr 2014 03:40:09 -0400 kpneal@pobox.com wrote: > On Wed, Apr 02, 2014 at 03:48:21AM -0700, Ronald F. Guilmette wrote: > > > > What the bleep is a "CCB request", and why would it fail, over and over and over > > again, ad infinitum? > > Dunno. Try asking on either one of the freebsd-scsi or freebsd-geom lists. Sure, but meanwhile there's plenty of useful information "out there" .. googling 'SCSI CCB'; very first hit here is "The Design and Implementation of the FreeBSD SCSI Subsystem" by Justin Gibbs: http://people.freebsd.org/~gibbs/ARTICLE-0001.html googling 'SCSI CDB'; first hit is http://en.wikipedia.org/wiki/SCSI_CDB which leads to http://en.wikipedia.org/wiki/SCSI_command and such. > Maybe for the same reason I can't sleep despite trying over and over again > for hours now? Nevermind. :) > > > Obviously, this has something to do with the second drive in my system, but I > > mean seriously (?) Come on! Did somebody fail to implement some logic that > > would recognize when there have been several thousand such errors already > > logged and then, you know, avoid filling up /var/log/messages with even more > > of these utterly incomprehensible (and thus utterly useless) error messages? > > Well, syslogd does eliminate duplicate messages with a message about having > avoiding repeating itself X number of times. But that only works for log > lines that are a single line long. > > It would be a useful addition to have syslogd recognize repeated groups > of log lines and give them the same treatment. > > It would be a shame to have various subsystems in the kernel have to roll > their own. And it wouldn't solve the problem of userland users of the > syslog service having the same problem. Really, the best place for this > deduplication would be in syslogd. That could be nice indeed, Kevin, as perhaps would compressing at least some of the CAM messages into more human-comprehensible form. However, the messages in question: | Apr 2 03:40:31 segfault kernel: (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 1e 6f ff 0 0 1 0 | Apr 2 03:40:31 segfault kernel: (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error | Apr 2 03:40:31 segfault kernel: (da0:umass-sim0:0:0:0): Retrying command | Apr 2 03:40:37 segfault kernel: (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 1e 6f ff 0 0 1 0 | Apr 2 03:40:37 segfault kernel: (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error | Apr 2 03:40:37 segfault kernel: (da0:umass-sim0:0:0:0): Retrying command repeated every few seconds clearly enough indicate disk READ(10) errors, all apparently at the same place, and should most likely be considered serious enough to warrant knowing about .. maybe doing something about? cheers, Ian