Re: st.c broken ? (may have been: Re: CVS commit: src/sys - remove b_flags manipulation)

[Andrew Doran <ad%netbsd.org@localhost>]

Hi Frank,

Sorry about the delay in replying.

On Sat, Aug 25, 2007 at 10:24:01AM +0200, Frank Kardel wrote:

> I am experiencing quite a few strange error with my DAT tape since about
> this checkin. A kernel from the beginning of July works flawlessly with the
> drive and the tape.
> 
> Symptoms:
>     I/O errors claimed where no real I/O error where. Possibly
>    triggered by length indicator mismatches reported by the drive. These
>   are ok for variable block size formatted media. Those indications where
>   handled properly at the beginning of July and years before.
> 
> The dmesg output shows a READ that is terminated with an I/O error,
> but data was transferred (with the size mismatch indication).
> The requested block was just too big - a smaller block was read.
> The second attempt with a block too small was terminated with a panic 
> instead
> of an I/O error.
> 
> Could somebody check what broke st.c between beginning of July and now ?
> Currently st.c is unusable for variable block size tape I/O.
> 
> dmesg atteched.

I was worried about something this. I do have a few tape drives, but
unfortunatley I have no tapes any more. Juergen sent me through a patch
that should fix the issue. I'll have a look at it and buy some tapes. :-)
I hear this also affects EOM on block media, so hopefully it will not be
so hard to test immediately.

Thanks,
Andrew