From owner-freebsd-scsi@FreeBSD.ORG Thu Jan 30 22:21:43 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0F99756 for ; Thu, 30 Jan 2014 22:21:42 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 98E1E1D2B for ; Thu, 30 Jan 2014 22:21:42 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id i17so5953148qcy.39 for ; Thu, 30 Jan 2014 14:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=r6hZhqojbYF80e/6udxqIkMtGf5ruc+nIp4DQeFSGpY=; b=kROn9k5l1zUC+/coZ+ilfO8nu1kdoOGSxH810Wdrc33RT7rs/RAtJKhpdGYZnb3S5Z bqM0wD1I9XEjvQMKh5ck0tdkBSkGBiJswhgUF5h0aPkiwBrh7KF3J+rCmgD/JzH0NJuV wlN4vO/4n6wHPkKh33NntNTk+/DFQcOOU0hre+7eHPwnGnAImMsNCECi9ys125kqoeEG CnOr6jCdbx0WVNjXgy2Q6xC6L2K4WYE4ZFVBoM/K5k7ICUoN9mer5NHJUcsE0KYKsoOm B2tji+e2wQhit1J1rUDEFhMTLvZVxOeGOoQp6iWlsVtW9doSmojQUetTM5QekUxGPqA0 GnBw== MIME-Version: 1.0 X-Received: by 10.224.5.69 with SMTP id 5mr26268774qau.11.1391120501830; Thu, 30 Jan 2014 14:21:41 -0800 (PST) Sender: benlaurie@gmail.com Received: by 10.96.142.194 with HTTP; Thu, 30 Jan 2014 14:21:41 -0800 (PST) In-Reply-To: <888F991A-96C7-48C0-AAC6-0D432BD78A46@scsiguy.com> References: <84D23688-DDC6-421E-9D21-3DA646229038@scsiguy.com> <8680A21D-78D7-4B65-A502-17F0C3B70291@scsiguy.com> <888F991A-96C7-48C0-AAC6-0D432BD78A46@scsiguy.com> Date: Thu, 30 Jan 2014 22:21:41 +0000 X-Google-Sender-Auth: zZ40bAc8yeOO3K3WEEQYO746VhY Message-ID: Subject: Re: Dropped interrupts From: Ben Laurie To: "Justin T. Gibbs" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 22:21:43 -0000 On 26 January 2014 22:46, Justin T. Gibbs wrote: > On Jan 26, 2014, at 1:52 AM, Ben Laurie wrote: > >> On 25 January 2014 17:15, Justin T. Gibbs wrote: >>> On Jan 24, 2014, at 10:44 PM, Ben Laurie wrote: >>> >>>> Aha, finally got the error again... >>> >>> I don't know enough about your backup or Bacula to know if this is amou= nt that should be written, but we attempted a write in variable block mode = of 64512 bytes. >> >> I don;t think there's anything wrong with that. Not at the machine >> right now, but I think that's actually the default max block. No idea >> why. >> >>> The command, data transfer list, and controller state are all consisten= t with this. The command was successfully transferred to the tape drive, b= ut it never transitioned to data phase to allow us to begin the data transf= er. (In parallel SCSI, the target controls all state transitions). >>> >>> Since there are no parity errors or other indications of a transport er= ror, my hunch is that this is a tape drive issue. Are you running the late= st available firmware for it? >> >> No idea, its a very old LTO-2 drive. I'll see if I can find an update. >> >>> How many write cycles do you have on your media? >> >> I have seen this error on brand new media. I'd guess the most cycles >> any tape has had is around 10. >> >>> When was the last time you cleaned the drive? >> >> LTO drives are self-cleaning. So ... never. > > This is a popular misconception. LTO drives include brushes deployed dur= ing load or unload to remove large particle contamination off the head. Th= is increases the time interval between traditional cleanings, but doesn't m= ake them unnecessary. Certain LTO drives will tell you (e.g. light a LED) = when they require cleaning, but I don't know if this is one of them. There= have also been firmware bugs on some drives that prevent the cleaning indi= cator from working as expected. > > If the drive has over 500 hours on it, I would suggest a cleaning pass. Are you suggesting that a need for cleaning could cause this problem? > > -- > Justin