Sorry for the long delay on this. I finally have working tape again, got
it fixxed about 3 weeks ago. Upgraded to current as of May 24th and put
the old drive back in. Everything is working correctly again. I'm a bit
scared to change out the tape drive for more testing.
Chris
On
On Fri, Apr 30, 1999 at 12:36:25AM +0200, Wilko Bulte wrote:
As Bob Willcox wrote ...
On Thu, Apr 29, 1999 at 10:26:36PM +0200, Wilko Bulte wrote:
As Bob Willcox wrote ...
On Wed, Apr 28, 1999 at 08:45:36PM +0200, Wilko Bulte wrote:
shipping 8200's (this was right at their
[ should we keep this on -current ?? ]
As Bob Willcox wrote ...
On Fri, Apr 30, 1999 at 12:36:25AM +0200, Wilko Bulte wrote:
As Bob Willcox wrote ...
On Thu, Apr 29, 1999 at 10:26:36PM +0200, Wilko Bulte wrote:
As Bob Willcox wrote ...
On Wed, Apr 28, 1999 at 08:45:36PM +0200,
On Wed, Apr 28, 1999 at 08:45:36PM +0200, Wilko Bulte wrote:
Exabyte is not particularly famous for stable firmware.
I have quite a number of 8200's here (though I don't really use them
much anymore since I now have a Mammoth) that I have installed new
firmware in. From an email discussion
and/or CAM issues.
Has anyone tried a CAMDEBUG kernel and camcontrol tracing on?
I'll be glad to turn it on if you tell me how to do it on only that
tape drive. I'm getting ready for another mt erase test and that
will take about an hour and a half.
I'm rebuilding
On Wed, Apr 28, 1999 at 08:45:36PM +0200, Wilko Bulte wrote:
Exabyte is not particularly famous for stable firmware.
I have quite a number of 8200's here (though I don't really use them
much anymore since I now have a Mammoth) that I have installed new
firmware in. From an email
As Bob Willcox wrote ...
On Wed, Apr 28, 1999 at 08:45:36PM +0200, Wilko Bulte wrote:
Exabyte is not particularly famous for stable firmware.
I have quite a number of 8200's here (though I don't really use them
much anymore since I now have a Mammoth) that I have installed new
firmware
On Thu, Apr 29, 1999 at 10:26:36PM +0200, Wilko Bulte wrote:
As Bob Willcox wrote ...
On Wed, Apr 28, 1999 at 08:45:36PM +0200, Wilko Bulte wrote:
Exabyte is not particularly famous for stable firmware.
I have quite a number of 8200's here (though I don't really use them
much
As Christopher T. Johnson wrote ...
On Wed, Apr 28, 1999 at 08:45:36PM +0200, Wilko Bulte wrote:
Exabyte is not particularly famous for stable firmware.
I have quite a number of 8200's here (though I don't really use them
much anymore since I now have a Mammoth) that I have
As Bob Willcox wrote ...
On Thu, Apr 29, 1999 at 10:26:36PM +0200, Wilko Bulte wrote:
As Bob Willcox wrote ...
On Wed, Apr 28, 1999 at 08:45:36PM +0200, Wilko Bulte wrote:
shipping 8200's (this was right at their end-of-life) was:
MX: 2680
SV: C034
This is for generic
Some extra information on tape problems:
FreeBSD neunacht.netgsi.com 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Thu Apr 22
16:50:33 EDT 1999 root@:/m/src/sys/compile/NEUNACHT i386
This is SMP machine with scsi only.
The tape drive is an EXABYTE-8200.
When doing tape IO that lasts for an extend period
The amber LED on exabytes typically means 'drive needs cleaning'. Exabyte
drives should be cleaned once or twice a week depending on how heavily
you use them. If an exabyte drive is not cleaned on a regular basis, the
transfer rate will drop steadily as the drive is forced to
Matthew,
Thanks I should have been more clear.
The amber LED on 8205s and 8505s and any of the half hight drives blink when
they need cleaning. This is the original 8200 full hight drives. They
have no cleaning indicator.
The drive is cleaned every monday before the amflush. We use exabyte
As Christopher T. Johnson wrote ...
Some extra information on tape problems:
FreeBSD neunacht.netgsi.com 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Thu Apr 22
16:50:33 EDT 1999 root@:/m/src/sys/compile/NEUNACHT i386
This is SMP machine with scsi only.
The tape drive is an EXABYTE-8200.
When
As Christopher T. Johnson wrote ...
REGARDLESS!
The drive is reporting an error condition and that error is NOT
getting back to user land. I've verified the problem with amdump
Oh? Where/what is the error, does the console tell you?
amflush and dd. In ALL cases once the
As Matthew Dillon wrote ...
The amber LED on exabytes typically means 'drive needs cleaning'. Exabyte
drives should be cleaned once or twice a week depending on how heavily
you use them. If an exabyte drive is not cleaned on a regular basis, the
transfer rate will drop
As Christopher T. Johnson wrote ...
REGARDLESS!
The drive is reporting an error condition and that error is NOT
getting back to user land. I've verified the problem with amdump
Oh? Where/what is the error, does the console tell you?
Sorry, no error reported, just the lights.
That sounds like a bug. But it could be CAM not understanding that the
8200 firmware went to Nowhere-land. If I got a dime for each Exabyte
lockup..
Yep, been there done that. But these drives have been rock solid. It is
not the case of putting in a new, unknown drive and finding
I'm sorry- I missed the front end of this. I've had pretty good luck with
getting the 8200 to work. What f/w level are you at for the 8200?
-matt
Matt, it isn't a tape drive problem. Nor is it directly and exabyte problem.
It is a problem where an error from the tape drive is
As Christopher T. Johnson wrote ...
As Christopher T. Johnson wrote ...
REGARDLESS!
The drive is reporting an error condition and that error is NOT
getting back to user land. I've verified the problem with amdump
Oh? Where/what is the error, does the console tell you?
When the tape hangs with an unkillable process, its relevant PS flags are
physstrat and DL+. It doesn't hang forever, just a very long time, like
someone's confused milliseconds with microseconds, or some such.
Also, when writing to the 2nd tape in a CPIO archive, it doesn't actually
write to
21 matches
Mail list logo