Dropped interrupts

[Ben Laurie]

FYI, since it seemed to not be possible to install the update, I've
now replaced the drive with an almost-identical LTO-3 drive.

So far seems to be working fine.

On 1 February 2014 11:24, Ben Laurie <ben at links.org> wrote:
> On 31 January 2014 17:32, Ben Laurie <ben at links.org> wrote:
>> On 31 January 2014 00:44, Justin T. Gibbs <gibbs at scsiguy.com> wrote:
>>> On Jan 30, 2014, at 3:21 PM, Ben Laurie <ben at links.org> wrote:
>>>
>>> On 26 January 2014 22:46, Justin T. Gibbs <gibbs at scsiguy.com> wrote:
>>>
>>> On Jan 26, 2014, at 1:52 AM, Ben Laurie <ben at links.org> wrote:
>>>
>>> On 25 January 2014 17:15, Justin T. Gibbs <gibbs at scsiguy.com> wrote:
>>>
>>> On Jan 24, 2014, at 10:44 PM, Ben Laurie <ben at links.org> 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.