>> There's not really enough information here to even start debugging
>> this.
> It's all the information I have.

Then about all anyone can do is look sad and say "gee, that's too bad".

>> Firstly, does the kernel print anything on the console when the
>> error occurs?
> You consider me stupid, don't you?  If there were any output I would
> have send it to you.

Anyone who sends a "bug report" with that little information,
especially without stating all the negative information (like, no
console messages) can expect a response like Jason's, asking about the
things left unstated.

>> There are a number of places where st.c returns EIO to the user.
>> Maybe you could put some printfs in those places and tell us which
>> one of those places is setting EIO?
> I tried this, too.  But no result, too.

That's quite bizarre.  Something _somewhere_ along the line is
returning EIO.  Perhaps scatter printfs along the call chain from
write() all the way down to st.c, and find out where the EIO is being
generated?  That's probably what I'd do in a case like this.  Indeed,
if I were debugging that problem (assuming I could reproduce it, of
course) that's what I'd do.

>> SCSI tape support is far from broken ...
> It *IS* broken.

Define "broken", then.  It obviously works for some people.  It fails
for you and for some other people.  It's obviously not _completely_
broken.  (Just as obviously not completely working, either.)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu