Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

SCSI tape driver problem

4 views
Skip to first unread message

Nils-Henner Krueger

unread,
Oct 3, 1994, 8:49:26 AM10/3/94
to
I've got an annoying problem with my scsi tape drive.
From other systems like Sun I'm used to put several archives on
one tape by skipping the previously written archives with "mt fsf"
and then writing the next one. When I do this on my linux system
it constantly fails, regardless of which kernel I'm using.

That's the drive specification as it is recognized by the kernel:

Sep 26 19:03:51 catwalk kernel: Configuring Adaptec at IO:330, IRQ 11, DMA priority 5
Sep 26 19:03:51 catwalk kernel: scsi0 : Adaptec 1542
Sep 26 19:03:51 catwalk kernel: scsi : 1 hosts.
Sep 26 19:03:51 catwalk kernel: Vendor: TANDBERG Model: TDC 3600 Rev: -07:
Sep 26 19:03:51 catwalk kernel: Type: Sequential-Access ANSI SCSI revision: 01
Sep 26 19:03:51 catwalk kernel: Detected scsi tape st0 at scsi0, id 4, lun 0

I'm currently running kernel 1.1.51, tar 1.11.2, st-mt from slackware 2.0.

The device should be ok:

/home/nhk> ls -l /dev/nrmt0
crw-rw-rw- 1 root root 9, 128 Nov 30 1993 /dev/nrmt0

That's what I try to do:

/home/nhk> mt -f /dev/nrmt0 fsf 1
/home/nhk> tar cvf /dev/nrmt0 doom
doom/
doom/doom1.wad
tar: can't write to /dev/nrmt0 : I/O error
/home/nhk>

And that's the debug output if I activate "#define DEBUG" in
/usr/src/linux/drivers/scsi/st.c:

st0: Block limits 512 - 512 bytes.
st0: Mode sense. Length 23, medium 0, WBS 10, BLL 8
st0: Density 10, tape length: 0, blocksize: 512, drv buffer: 1
st0: Block size: 512, buffer size: 32768 (64 blocks).
st0: Spacing tape forward over 1 filemarks.
st0: Block limits 512 - 512 bytes.
st0: Mode sense. Length 23, medium 0, WBS 10, BLL 8
st0: Density 10, tape length: 0, blocksize: 512, drv buffer: 1
st0: Block size: 512, buffer size: 32768 (64 blocks).
st0: Error: 28000002, cmd: a 1 0 0 3c 0 Len: 30720
extra data not valid Current error st0: sense key Illegal Request
st0: Async write error (write) 28000002.
st0: File length 30720 bytes.
st0: Error: 28000002, cmd: 10 0 0 0 1 0 Len: 0
extra data not valid Current error st0: sense key Illegal Request
st0: Error on write filemark.
st0: Buffer flushed, 1 EOF(s) written

I'm not used to interpreting such messages. Could some wizzard tell me
what's going wrong here and what I could do to append archives to a tape?

btw: The tape is NOT write protected. :-)


nils-henner


--
Nils-Henner Krueger Tel: xx49/431/86267
Waitzstr. 98 email: n...@informatik.uni-kiel.de
24118 Kiel nhk...@geomar.de
Germany

Eyal Lebedinsky

unread,
Oct 3, 1994, 5:58:42 PM10/3/94
to
In <36oukm$n...@link.informatik.uni-kiel.de> n...@informatik.uni-kiel.d400.de (Nils-Henner Krueger) writes:

>I've got an annoying problem with my scsi tape drive.
>From other systems like Sun I'm used to put several archives on
>one tape by skipping the previously written archives with "mt fsf"
>and then writing the next one. When I do this on my linux system
>it constantly fails, regardless of which kernel I'm using.

>That's the drive specification as it is recognized by the kernel:

>That's what I try to do:

>/home/nhk> mt -f /dev/nrmt0 fsf 1
>/home/nhk> tar cvf /dev/nrmt0 doom
>doom/
>doom/doom1.wad
>tar: can't write to /dev/nrmt0 : I/O error
>/home/nhk>

>And that's the debug output if I activate "#define DEBUG" in
>/usr/src/linux/drivers/scsi/st.c:

>st0: Block limits 512 - 512 bytes.

Not sure, but maybe you need to add '-b 1' to 'tar' so as to comply with
the 512 bytes block size limit?
--
Regards
Eyal Lebedinsky ey...@ise.canberra.edu.au

Nils-Henner Krueger

unread,
Oct 7, 1994, 5:18:02 AM10/7/94
to
In <36oukm$n...@link.informatik.uni-kiel.de> n...@informatik.uni-kiel.d400.de (Nils-Henner Krueger) writes:

>I've got an annoying problem with my scsi tape drive.
>From other systems like Sun I'm used to put several archives on
>one tape by skipping the previously written archives with "mt fsf"
>and then writing the next one. When I do this on my linux system
>it constantly fails, regardless of which kernel I'm using.

I finally solved this problem.

The solution for me was to remove any old data from the tape before using it
again. It seems to me that the kernel tape driver or the tape bios don't like
it if there is allready something one the tape even if it is logically invalid.

What you have to do is to run mt -f /dev/tape erase on a previously used tape
before writing on it again. After that it was no problem for me to skip the first
archive with mt fsf and append another one behind.

Thanks to everybody who mailed me suggestions.

0 new messages