Re: st.o module bug

Paul Matthews (paul@matthews.com)
Mon, 16 Jun 1997 10:21:55 -0400


Jon Lewis wrote:

> I'm playing with a SCSI DAT drive on a BT-946 on my test
> machine, and have
> noticed the following.
>
> The system did not have a tape before, so I'd compiled
> pre-2.0.30-1 with
> st as a module. If I tried to access /dev/st0 before loading
> the module
> (no kerneld), I'd get an error about no such device...duh. If I
> then
> insmod st.o, I still can't access /dev/st0 without rebooting
> first.
>
> ------
> -----------------------------------------------------------
> Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail
> will
> Network Administrator | be proof-read for $199/message.
> Florida Digital Turnpike |
> ________Finger jlewis@inorganic5.fdt.net for PGP public
> key_______

Jon,

As I mentioned in an earlier reply, I had a similar experience. I
have tried many combinations of the UltraStor SCSI drivers and a
SCSI tape drive. This morning I think I have stumbled onto a
workable set of options. There are two (apparently different)
UltraStor drivers, one known as ultrastor and the other as
u14-34f. For my UltraStor 34f the "u14-34f" driver simply won't
work. It is buggy. The "ultrastor" driver (that dates from
1992/3) does work, but it will only work if it is compiled into
the kernel. All attempts to compile a driver as a module create a
set of modules that either won't initialize or fail to work
properly.

Of course, the "st" driver is not trivial to use. It requires
very careful experimentation with the parameters shown in the
README.st file and the use of a nonstandard mt package to get it
to work correctly.

--
Regards,
Paul Matthews
email: paul@matthews.com