ARCHIVE tape drive

ARCHIVE tape drive

Post by Gregg Brek » Thu, 14 Jul 1994 05:55:12

I have an Archive 402 (QIC-02, 150 meg) tape drive set to:

        IRQ 5
        DMA 1
        IO  0x200

It initializes fine at system startup but none of the tape devices
seem to work.  mt and tar tell me that there is no device
/dev/nrst0 or /dev/rst0 available, although I point right to them.

Do I need to make a new device?  If so what mknod command should I use?

        mknod /dev/nrstX c ??? ???

Thanks for the help in advance,

    Gregg D. Brekke                           Minnesota Regional Network

  Voice: (612) 342-2894   Pager: (612) 969-4614   FAX: (612) 342-2873


ARCHIVE tape drive

Post by Clarence Wilkers » Fri, 15 Jul 1994 02:58:35

Am I the only one who thinks that the procedure to set up the
proper qic02 tape support is awkward, undocumented in the
kernel, and stupid. We manage to have all sorts of cdroms,
soundcards, etc supported directly by the kernel config
script. Why can't this be done for tape devices also?



ARCHIVE tape drive

Post by Hennus Bergm » Tue, 19 Jul 1994 00:56:38

>>Am I the only one who thinks that the procedure to set up the
>>proper qic02 tape support is awkward, undocumented in the
>>kernel, and stupid. We manage to have all sorts of cdroms,
>>soundcards, etc supported directly by the kernel config
>>script. Why can't this be done for tape devices also?

Because I don't have the time to recompile the entire kernel every time
I have to test the zillion different QIC-02 compile-time combinations!

QIC-02 interface cards are generally pretty old, dumb cards that are not
suited to fancy autodetect stuff. You want to use it? Fine. Then you'll
have to configure it manually. If you wanted fancy hardware with real
auto-detect capabilities where the OS can identify every card
automagically without tripping over other cards while trying, then
you should have bought yourself a different computer. The ISA bus is
simply not suited for that kind of thing.

If you want a better kernel config system, one where not every single
sourcefile depends on one global config file, you are welcome to write one.
I think that lots of people would appreciate that. I just don't have the
time to do it.


>The QIC-02 support used to be a separate package.  When it was, it was
>distributed as a tar file including documentation.

Back then people were continually asking me to add it to the standard
kernel so that they wouldn't have to patch it in every time there was a
new kernel version...


>At some point it was merged with the standard distribution, which was
>good in that it meant the driver was kept uptodate when things changed
>in the kernel interface, but the bad point was the users of the driver
>do not automatically have access to the documentation.

And they have to go out and find the support programs like 'mt`, `cpio',
`buffer' and `edd' too...


>The configuration could be better but the "make config" tool is not
>clever enough to do it.  The soundcard driver author took the approach

I tried it, but nearly the entire kernel is dependent on the generated
autoconf.h file, so checking all of the different compile-time options
for my driver became a *very* time-consuming business.

Quote:>of writing a separate program that runs during configuration.  Such a
>thing could be done for QIC-02 as well.
>Besides, there is a test version of the driver which can be configured
>at runtime.  So this problem should go away by itself, I think.

Yes. Unless I get some complaints about the dynamic config stuff being
much more `expensive' in runtime cost than the current `static' version,
I will probably make the dynamic stuff the default in future versions.
Maybe even take the static stuff out completely, because it's getting a
bit messy now, and I am sick of having to check all of the static compile
time options every time I change something.

(I have a bit more time to play with Linux these days, so
that's not just some idle threat any more ;-)

Quote:>For now I think that most of the critisism in the quoted posting refers
>to lack of reading of documentation which surely exists, although it may
>be difficult to find.


I posted the announcement below to the TAPE channel ages ago. The next
release of the support package (RSN) will actually contain some useful
updated docs! [Thanks to Jeff Stern, who actually did something about
the lack of proper documentation, instead of complaining.]





[Old announcement for 1.6 follows -- 1.6b should be out Really Soon Now.
Mountain stuff doesn't quite work yet -- patches welcome...]

I uploaded a new version of my QIC-02 driver in
[Usually I use "", but that didn't work
today. "" did work.]

This version adds (untested) support for Mountain 7150
tape drive interfaces.

 (MD5 checksum)                    (filename)
5fcdfd8503f88ab9f00e4f43846dc026  tpqic02-
a0186801d142ade0cb954a61f73b3805  tpqic02-support-1.6.tar.gz

``tpqic02-support-1.6.tar.gz'' replaces the old ``tpqic02-support.tar.gz''.
The only important change in 1.6 is the addition of a Mountain-interface id
to qic02conf.

Note that I haven't had the time to do any real testing other than
trying some very simple stuff and thinking "Yeah, looks like it still
kind-of works". Especially the Mountain stuff is completely untested.
If you have a Mountain interface card, I'd like to hear whether
this works or not. If I don't get too many complaints, I'll
probably send the new version off to Linus RSN.


PGP (includes md5sum) is also available from,
in /pub/unix/security/crypt/pgp23A.*


   PGP fingerprint: 76 99 FD 31 91 E1 96 1C  90 BB 22 80 62 F6 BD 63


1. ROMless FD 1670 and Archive tape drive.

I have a PC with a Tekram DC390F/U and a Future Domain
1670.  The disks and CDROM are connected to the Tekram
and all that is connected to the FD controller is an
Archive Anaconda.  In order to speed up the boot process
I pulled the ROM of the FD card.  The tape drive is now
acting wierd under OS/2 and Windows 95 and not at all
under Linux.  Windows 95 seems to be able to find the drive
OK but unable to stream data to it. (Seagate Backup Exec)
OS/2 can stream data to the drive but loses contact
with it, when trying to verify (BackupWiz).  Linux cannot
find the FD controller at all.

Basically my Linux question is does Linux support ROMless
SCSI controllers?

In the FD manual it says the tape drive should be ID 7
for ROMless operation.  I have my tape drive set to ID 5
and it is the only device on the FD bus. Could this be
causing my problem?  I currently cannot set the tape drive
to ID 7 because I have no jumpers that fit the jumper
block.  The pins appear to be on 0.08 inch centers instead
of the common 0.1 inch.

#       Fred Heitkamp                   #
#  Merlin, AmigaOS, Linux m68k/x86      #

2. Image Magick - Help!

3. Archive Tape Drive Installation

4. DNS problem

5. Archive Tape Drive Question

6. ADVERT: Secure communications

7. Problem with Archive Tape Drive writing over 60Meg

8. Linux/Unix Programming Contest

9. ROMless FD 1670 and Archive tape drive.

10. Archive Tape drive under 99.14 dist

11. ARCHIVE tape drive

12. ARCHIVE tape drive help needed

13. Where is Archive Tape drive corp ?