From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Description of problem: I have Seagate STT3401A tape drive for backups. Using ide_scsi. tar cf /dev/st0 some_files will run generating lots of errors (see below) and end with an error unfinished. log excerpt --------------------------------------- kernel: Additional sense: Invalid command operation code kernel: st0: Error with sense data: <6>st0: Current: sense key: Illegal Request kernel: Additional sense: Invalid command operation code kernel: st0: Error with sense data: <6>st0: Current: sense key: Illegal Request kernel: Additional sense: Invalid command operation code kernel: st0: Error with sense data: <6>st0: Current: sense key: Illegal Request kernel: Additional sense: Invalid command operation code kernel: ide-scsi: CoD != 0 in idescsi_pc_intr duron kernel: hde: ATAPI reset complete duron kernel: st0: Error with sense data: <6>st0: Current: sense key: Unit Attention kernel: Additional sense: Power on, reset, or bus device reset occurred kernel: Info fld=0x14 kernel: st0: Error with sense data: <6>st0: Current: sense key: Not Ready kernel: Additional sense: Logical unit is in process of becoming ready kernel: Info fld=0x1 kernel: st0: Error on write filemark. kernel: st0: Error with sense data: <6>st0: Current: sense key: Not Ready kernel: Additional sense: Logical unit is in process of becoming ready S Version-Release number of selected component (if applicable): kernel-2.6.12-1.1447_FC4 How reproducible: Always Steps to Reproduce: 1. modprobe ide_scsi 2. 3. Additional info:
I have a similar problem with a Seagate STT20000A using ide_scsi and kernel 2.6.12-1.1376_FC3 >mt status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 512 bytes. Density code 0x47 (TR-5). Soft error count since last status=0 General status bits on (41010000): BOT ONLINE IM_REP_EN From >tail /var/log/messages st0: Error with sense data: <6>st0: Current: sense key: Illegal Request Additional sense: Invalid command operation code > tar cvf /dev/st0 some_dir appears to work but... tar tvf /dev/st0 returns with no files listed This used to work in earlier kernels
Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (2.6.13.2). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks.
(In reply to comment #2) > Mass update to all FC4 bugs: > > An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream > kernel (2.6.13.2). As there were ~3500 changes upstream between this and the > previous kernel, it's possible your bug has been fixed already. It's still broken. tar cfv /dev/st0 some_files finishes, but during the run errors (see below) appear and aftr each of them the tape is rewinded so the archive is incomplete and broken. For the same reason tar tvf /dev/st0 never fineshed... ------------- ide-scsi: CoD != 0 in idescsi_pc_intr hde: ATAPI reset timed-out, status=0x80 de2: reset: success
Still broken with 2.6.13-1.1532_FC4
I have a potential fix. I compiled a kernel from the 2.6.13 sources, enabling SCSI tape in device drivers as a module. Add hdc=ide-tape in the grub config file. The tape drive is now at /dev/ht0. Running FC3. I havn't tried the pre-compiled kernel as there isn't a FC3 build.
I tried ide-tape with 2.6.12 with no luck. Will try again with 2.6.13 when time permits.
Further to my last comment... Trying again with the standard 2.6.12-1.1380_FC3 kernel. and (re)adding hdc=ide-scsi With a Seagate STT20000A I found that tar cvf /dev/st0 -b 1 * and tar xvf /dev/st0 -b 1 will archive and restore files. Large files obviously make the process very slow with lots of tape rewinding. Doing tar cvf /dev/st0 * without the block size, and dd if=/dev/st0 of=test.tar then looking at the restored archive with hexedit revealed no data, all zeros, although of the correct number of zeros. However dd if=some_File.txt of=/dev/st0 bs=512 and dd if=/dev/st0 of=restored.txt also works fine. This also works tar cv * | dd of=/dev/st0 dd if=/dev/st0 | tar tv But again very slow with lots of tape rewinding Seems to a block size issue. Incidentally my last "solution" turned out to be a bit flakey. Sorry.
I can write smaller archives onto the tape this way. But doing my full (several giga) backup failed even when using 512 blocks.
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
Well, 2.6.14-1.1637_FC4 breaks 8139too and I can't have that machine offline.
Please forget my last email. I got complaints about unknown symbol when loading 8139too. It was caused by unrecognized option irq in modprobe.conf.
Tried to write an archive of cca 8GB onto the tape. It was runnig for about an 2 hours and then failed with: ide-scsi: CoD != 0 in idescsi_pc_intr hde: ATAPI reset complete st0: Error with sense data: <6>st0: Current: sense key: Unit Attention Additional sense: Power on, reset, or bus device reset occurred Info fld=0x14 st0: Error with sense data: <6>st0: Current: sense key: Not Ready Additional sense: Medium not present Info fld=0x1 st0: Error on write filemark. st0: Error with sense data: <6>st0: Current: sense key: Not Ready Additional sense: Medium not present
After an upgrade to 2.6.14-1.1644_FC4 it seems working