This appears only to fix a SMP problem.
I'm also seeing the following here and would like to find a fix or workaround.
This is against UP Pentium machines with kernel versions 2.2.6, 2.0.36, 2.0.35
and 2.0.34. Tape-streamers involved are Colorado HP 8Gb and Seagate ST8000's.
I can test here against the HPs easily, the seagates are more difficult,
not being in machines to hand.
OK now the problem, essentially streaming operations (particularly reading
back a backup) fail with -EIO, the kernel message log then contains the
following:- (Long lined)
nicole kernel: ide-tape: ht0: I/O error, pc = 8, key = 2, asc = 4, ascq = 1
nicole last message repeated 2 times
nicole kernel: ide-tape: ht0: I/O error, pc = 1, key = 2, asc = 4, ascq = 1
My guess is that since err [k/a/aq] 2/4/1 is described in QIC157rD as
"Not ready in the process of becoming ready", it would be wise to add to
the retry handling in idetape_issue_packet_command(), a clause which detects
this error and retries for say 1minute instead of just three times. Comments?
Additionally today I saw this:-
nicole kernel: hdc: irq timeout: status=0xd8 { Busy }
nicole kernel: hdc: ATAPI reset complete
nicole kernel: ide-tape: ht0: I/O error, pc = 8, key = 6, asc = 29, ascq = 0
nicole kernel: ide-tape: bh == NULL in idetape_copy_stage_to_user
nicole kernel: ide-tape: bh == NULL in idetape_copy_stage_to_user
nicole kernel: ide-tape: ht0: I/O error, pc = 8, key = 2, asc = 4, ascq = 1
nicole last message repeated 2 times
nicole kernel: ide-tape: ht0: I/O error, pc = 1, key = 2, asc = 4, ascq = 1
Although I suppose in principle this is a similiar problem (ie. tapedrive is busy
for an excessively long period)?.
On a different problem I also saw 'mt -f /dev/ht0 rewind' hung in the second
to last word, on _down_failed.
Umm, help. Any ideas? I am happy to test/code patches with advice.
TTFN
--
Roger Gammans
"If I have trouble installing Linux, something is wrong. Very wrong."
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/