I've had a number of responses to the above original posting. Before I
summarize, I'd like to solve the problem, but it begs an answer to one
question.
Does *anyone* have an Exabyte 8200 (8mm) tape drive running successfully
on a box running DU 4.0b?
My box is an Alpha 3000/600 with firmware upgraded to v3.8, but I'm not
sure the model will matter with regard to this problem. Let me explain:
the respondent's diagnoses are in 2 categories -
1. tape drive has same scsi id as another device on the same scsi bus.
- I think I've ruled that one out, unless the tape drive's remote
id switch has gone south.
2. some incompatability with the old Exabyte 8200 tape drive and the
DU 4.0b firmware and/or drivers. (The tape drive's firmware level
is 2618.)
Ergo the question. ie., I've heard from someone who traced a similar
problem to number 2 above, but if there is a DU 4.0b box at firmware
v3.8 running an Exabyte 8200 on the 0 LUN only, then it's probably
number 1 above or something else.
Original posting:
=============================================================
DEC Alpha 3000/600
Just upgraded to DU 4.0b from 3.2
At halt prompt, a s'ho dev' shows that our old Exabyte 8200 drive is now
recognized as 8 (0-7) independent devices, one for each Logical Unit
Number. Building the kernel of course generates a /dev/*rmt* for each
one (eg. rmt0, rmt1, rmt2, ... rmt7).
Accessing the drive (eg. vdump) is noticably slower.
How did that happen? Why would I be seeing this?
=============================================================
--
Neil R. Smith, Res. Assoc./Sys. Admin. neils_at_csrp.tamu.edu
Dept. Meteorology, Texas A&M Univ. 409/862-4342
Received on Fri May 16 1997 - 01:58:32 NZST