Mike Hardy <[EMAIL PROTECTED]> writes:
> I think this is why I always resort to formatting (attempting to format)
> under Linux - after formatting the tape successfully under OS/2:
>
> .../~ > mt -f /dev/qft0 erase
> /dev/qft0: Input/output error
[snip]
> Jul 21 19:28:55 analog kernel: [002] 0 ftape-read.c
>(ftape_decode_header_segment) - Tape parameters inconsistency, please report.
> Jul 21 19:28:55 analog kernel: [003] 0 ftape-read.c
>(ftape_decode_header_segment) - reported = 2/150/28/6/254/128.
> Jul 21 19:28:55 analog kernel: [004] 0 ftape-read.c
>(ftape_decode_header_segment) - required = 2/150/28/4/254/128.
> Do you know what this problem indicates? (I'm pretty sure it happens
> with any tape I put in the drive) Incidentally, I've fully cleaned the
> tape position sensor on the drive with compressed air and 91% alcohol
> but have used the drive since with my one good tape (I feel like an old
> sailor when I say that - 'That be me one good eye matey').
Assuming that ftape is bug-free (i.e. conforming to the QIC specs)
this means that your OS/2 program has a bug. The pre-last number, the
number of floppy tracks, should be 149.
Can you please load the driver with trace level set to "4" as proposed
in my last posting? This will give us the values stored in the header
segment.
I'll add that case to ftape-read.c and you will be able to use the
cartridges formatted by the OS/2 software.
>From a previous posting:
> Using the newest ftape and ftape-tools (although I've had this error
> before this newest rev), any time I try to format a 307' QIC-80 tape in
> a Colorado Jumbo 250 I get right to the very end of formatting (when
> it's verifying) and it craps out with:
>
> ftape-io.c (ftape_seek_head_to_track) - track out of bounds.
so this happens during verifying? Can you please hack your copy of
ftape. Load the file ftape/lowlevel/ftape-io.c with your favourite
text editor. Then search for the function ftape_seek_head_to_track()
(around line 965 in the same file). You'll find this:
int ftape_seek_head_to_track(ftape_info_t *ftape, unsigned int track)
{
int status;
TRACE_FUN(ft_t_any);
ftape->location.track = -1; /* remains set in case of error */
if (track >= ftape->tracks_per_tape) {
TRACE_ABORT(-EINVAL, ft_t_bug, "track out of bounds");
}
[snip]
Please change it to that:
int ftape_seek_head_to_track(ftape_info_t *ftape, unsigned int track)
{
int status;
TRACE_FUN(ft_t_any);
ftape->location.track = -1; /* remains set in case of error */
if (track >= ftape->tracks_per_tape) {
TRACE(ft_t_err,
"track: %d, max track: %d\n",
track, ftape->tracks_per_tape);
TRACE_ABORT(-EINVAL, ft_t_bug, "track out of bounds");
}
[snip]
(without the [snip] :-) )
Then please recompile, then
a) run ftformat with the "--mode=probe" switch and send me the output.
b) re-rerun ftformat the usual (like you did before). If you have use
the tcl interface (i.e. that "ftape-tool" stuff) to do so, then
please send me the command line ftape-tool uses to run
ftformat. That command line is displayed on the status display of
ftformat.
The format should trigger the "track out of bounds" bug. Send me
the output produced by the hacked version of ftape-io.c
c) re-run ftformat with "--mode=auto --format-parameters qic80-307ft"
Maybe this works better.
You may wish to decrease the trace level back to "3" before
formatting.
Claus
--
Claus-Justus Heine
[EMAIL PROTECTED]
http://www.instmath.rwth-aachen.de/~heine/
Ftape - the Linux Floppy Tape Project
Home Page : http://www.instmath.rwth-aachen.de/~heine/ftape/
Mailing-list: [EMAIL PROTECTED]
