Forget kernel problems. At least for the errors you've detailed.
> Here are some messages from the logs...
>
> Jul 12 20:58:44 fangorn kernel: st0: Error 18000002. extra data not valid
Current error st0: sns = 70 3
> Jul 12 20:58:44 fangorn kernel: Raw sense data:0x70 0x00 0x03 0x00 0x00
0x00 0x00 0x12 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> Jul 12 20:58:44 fangorn kernel: st0: Error 18000002. Current error st0:
sns = f0 3
> Jul 12 20:58:44 fangorn kernel: Raw sense data:0xf0 0x00 0x03 0x00 0x00
0x00 0x17 0x12 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> Jul 12 20:58:44 fangorn kernel: st0: Error on write filemark.
>
> the kernel is 1.3.9, though I have tried it with 1.1.90 and 1.2.11 as well.
> Both of the later kernels are a.out compiled with gcc-2.7.0.
>
> I don't know where the problem is, I actually have two tape drives (the above
> is an Exebyte 8200, the other is a 6525) and wondered if the newly lengthened
> SCSI cable causes the problem, but since it has been hot recently I wondered
> about that...
>
The errors you've given details on are tape drive errors - most particularly
media errors (parity errors) - there is a problem with the drive writing to
tape. Could be caused by bad tapes, a dirty head, faulty drive or even being
too hot.
The third byte of the sense data is the basic error code from the drive and
you can use these to get a general idea of the errors. The main errors codes
returned in the sense data from the drive are:
0x00 - no error code available
0x01 - recovered error (a read or write error was handled internally in
the drive and succeeded)
0x02 - not ready (e.g. no tape in drive)
0x03 - media error (parity error)
0x04 - hardware error (drive broken or bad tape often causes this
error)
0x05 - illegal command (driver code sent a command the drive couldn't
understand)
0x06 - tape changed/power on/reset
0x07 - write protected tape
0x08 - blank tape detected (reading off the end of recorded data)
0x80 - filemark detected (combination of no error 0x00 and bit 7 set)
These can be modified by setting bits 5-7 depending on command and results.
e.g. bit 7 set indicates a filemark has been found while reading. The 13th
and 14th bytes can give additional data but the 8200 is not very informative
in this respect.
> Here is my plea...
>
> What is the current status of the SCSI tape code, how can I diagnose
> the problem, and where (apart from the tsx-11:/*/ALPHA/scsi directory)
> can I find some more help?
>
Using the list above you will be able to see if its your drive thats causing
the problems as opposed to the driver/software.
I'm not sure of the current status of the tape drive code but it seems
reluctant to report errors, or probably its the applications not picking
them up. Its causing me some problems as I have some bits of kit that
deliberately generate errors to flag events back to the application and most
of the time the errors are blissfully ignored. I would at least expect an
application that is writing to take notice of a write protected tape and say
something.
I've made some simple modifications for my own use e.g allowing use of lun's
so I can drive several tapes with the same scsi id from a single controller
and may be some time I will take a closer look at the code to see how the
error hand is done. But don't hold your breath.
Richard