From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 1 11:24:38 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 DB6CBF0E for ; Sat, 1 Feb 2014 11:24:38 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9229415CF for ; Sat, 1 Feb 2014 11:24:38 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id n7so8587119qcx.2 for ; Sat, 01 Feb 2014 03:24:37 -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; bh=zEp2heX9CQavTVpD/1EqpWTLqaSeBBDZBnZiI81VyKU=; b=wyJNJNC/sQtRSCGmr/a+8ovlkPjiO4c8cyVlFU0hiHDIjPDKC55JxmCPGf2enmaxkt 8TXb1Sgus4cjfFfuKx87dos3K3CDcY4kymF0h7c0m1BR5pHmG4u5trDNVJsLvPsVxdVb 0PyUgTU9tV5yY7gb1S27z+XjIQai9Y3PPLt0c7051Y8mTJaJZPTf1FgrfEp1CNhGXimS 7EbjDu1JaA/0WSGmbWpIAxuaDjNDPSakGs4uOQDqGZxfaxFKsfbEWDufbV930gWFm10Y zr3kJM0bqaXsO1+zPi84yGnScSzfj9Vob5098lGoqwE1+Oc9WXo/uoiONdKnpdQ4X4R9 e0pg== MIME-Version: 1.0 X-Received: by 10.224.3.10 with SMTP id 10mr39811108qal.58.1391253877657; Sat, 01 Feb 2014 03:24:37 -0800 (PST) Sender: benlaurie@gmail.com Received: by 10.96.142.194 with HTTP; Sat, 1 Feb 2014 03:24:37 -0800 (PST) In-Reply-To: References: <84D23688-DDC6-421E-9D21-3DA646229038@scsiguy.com> <8680A21D-78D7-4B65-A502-17F0C3B70291@scsiguy.com> <888F991A-96C7-48C0-AAC6-0D432BD78A46@scsiguy.com> <80532F4C-9206-4268-936E-66F352087052@scsiguy.com> Date: Sat, 1 Feb 2014 11:24:37 +0000 X-Google-Sender-Auth: 9XgnGORQDLyE926hl85S0UhuGHI Message-ID: Subject: Re: Dropped interrupts From: Ben Laurie To: "Justin T. Gibbs" Content-Type: text/plain; charset=ISO-8859-1 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: Sat, 01 Feb 2014 11:24:38 -0000 On 31 January 2014 17:32, Ben Laurie wrote: > On 31 January 2014 00:44, Justin T. Gibbs wrote: >> On Jan 30, 2014, at 3:21 PM, Ben Laurie wrote: >> >> 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 amount >> 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 consistent >> with this. The command was successfully transferred to the tape drive, but >> it never transitioned to data phase to allow us to begin the data transfer. >> (In parallel SCSI, the target controls all state transitions). >> >> Since there are no parity errors or other indications of a transport error, >> my hunch is that this is a tape drive issue. Are you running the latest >> 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 during >> load or unload to remove large particle contamination off the head. This >> increases the time interval between traditional cleanings, but doesn't make >> 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 indicator >> from working as expected. >> >> If the drive has over 500 hours on it, I would suggest a cleaning pass. > > Probably has. I don't have a cleaning tape, though. > >> Are you suggesting that a need for cleaning could cause this problem? >> >> >> I can't say why the drive isn't responding. But if it hasn't been cleaned >> since it was manufactured, you are probably getting less data per tape than >> optimal, slower transfer speeds than optimal, or both. >> >> I don't know if the LTO-2 model listed on this page is the same as what you >> have, but if it is, there were several firmware releases after 3AYC: >> >> http://www-01.ibm.com/support/docview.wss?uid=ssg1S4000055 > > The install instructions > (http://www-01.ibm.com/support/docview.wss?uid=ssg1S7000704&aid=1) > make no sense in the context of my drive, so I guess not. There does seem to be a firmware upgrade, though. http://www.dell.com/support/drivers/us/en/19/DriverDetails/Product/powervault-lto2-110t?driverId=H29Y4&osCode=WNET&fileId=2731097569&languageCode=en&categoryId=TH#OldVersion. But ... dunno how to install it. The Linux tools don't work under FreeBSD, it seems.