* 2.2.18 IDE tape problem, with ide-scsi @ 2001-02-27 16:06 Camm Maguire 2001-02-27 15:07 ` Khalid Aziz 2001-03-07 0:34 ` [PATCH] " Chip Salzenberg 0 siblings, 2 replies; 25+ messages in thread From: Camm Maguire @ 2001-02-27 16:06 UTC (permalink / raw) To: linux-kernel Greetings! Two ide tapes, both on second ide channel, both using ide-scsi. One works perfectly, the other basically works, but gives errors, and occasionally doesn't write full 32k blocks to tape, causing amanda errors. Feb 25 06:14:22 intech9 kernel: ALI15X3: IDE controller on PCI bus 00 dev 78 Feb 25 06:14:22 intech9 kernel: ALI15X3: not 100%% native mode: will probe irqs later Feb 25 06:14:22 intech9 kernel: ide0: BM-DMA at 0xb400-0xb407, BIOS settings: hda:DMA, hdb:DMA Feb 25 06:14:22 intech9 kernel: Feb 25 06:14:22 intech9 kernel: ************************************ Feb 25 06:14:22 intech9 kernel: * ALi IDE driver (1.0 beta3) * Feb 25 06:14:22 intech9 kernel: * Chip Revision is C1 * Feb 25 06:14:22 intech9 kernel: * Maximum capability is - UDMA 33 * Feb 25 06:14:22 intech9 kernel: ************************************ Feb 25 06:14:22 intech9 kernel: Feb 25 06:14:22 intech9 kernel: ide1: BM-DMA at 0xb408-0xb40f, BIOS settings: hdc:pio, hdd:pio Feb 25 06:14:22 intech9 kernel: hda: FUJITSU MPE3064AT, ATA DISK drive Feb 25 06:14:22 intech9 kernel: hdb: ST32140A, ATA DISK drive Feb 25 06:14:22 intech9 kernel: hdc: CONNER CTT8000-A, ATAPI TAPE drive Feb 25 06:14:22 intech9 kernel: hdd: HP COLORADO 14GB, ATAPI TAPE drive Feb 25 06:14:22 intech9 kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Feb 25 06:14:22 intech9 kernel: ide1 at 0x170-0x177,0x376 on irq 15 Feb 25 06:14:22 intech9 kernel: ALI15X3: Ultra DMA enabled Feb 25 06:14:22 intech9 kernel: hda: FUJITSU MPE3064AT, 6187MB w/512kB Cache, CHS=788/255/63, (U)DMA Feb 25 06:14:22 intech9 kernel: ALI15X3: MultiWord DMA enabled Feb 25 06:14:22 intech9 kernel: hdb: ST32140A, 2015MB w/128kB Cache, CHS=4095/16/63, DMA Feb 25 06:14:22 intech9 kernel: hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 > Feb 25 06:14:22 intech9 kernel: hdb: hdb1 hdb2 The Conner gives the problem: Feb 27 06:23:16 intech9 kernel: st0: Error with sense data: [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 Feb 27 06:23:16 intech9 kernel: ASC=20 ASCQ= 0 Feb 27 06:23:16 intech9 kernel: Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 and occaisional 'gunzip: unexpected end of file' errors on verifying the tape. Take care, -- Camm Maguire camm@enhanced.com ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 16:06 2.2.18 IDE tape problem, with ide-scsi Camm Maguire @ 2001-02-27 15:07 ` Khalid Aziz 2001-02-27 17:19 ` Camm Maguire 2001-03-07 0:34 ` [PATCH] " Chip Salzenberg 1 sibling, 1 reply; 25+ messages in thread From: Khalid Aziz @ 2001-02-27 15:07 UTC (permalink / raw) To: Camm Maguire; +Cc: linux-kernel Camm Maguire wrote: > > The Conner gives the problem: > > Feb 27 06:23:16 intech9 kernel: st0: Error with sense data: [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 > Feb 27 06:23:16 intech9 kernel: ASC=20 ASCQ= 0 > Feb 27 06:23:16 intech9 kernel: Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 > > and occaisional 'gunzip: unexpected end of file' errors on verifying > the tape. > > Take care, > > -- > Camm Maguire camm@enhanced.com ASC/ASCQ of 0x20/0x00 means "Invalid command operation code". So the drive is rejecting a command sent to it by the driver. If the other drive that is working is identical to seemingly non-working one, maybe this drive is going bad. st driver prints the SCSI command that may have caused this error only when compiled with debug turned on. Maybe st driver should always print the command that results in a check condition as long as the command is not a Test Unit Ready or Mode Sense. ==================================================================== Khalid Aziz Linux Development Laboratory (970)898-9214 Hewlett-Packard khalid@fc.hp.com Fort Collins, CO ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 15:07 ` Khalid Aziz @ 2001-02-27 17:19 ` Camm Maguire 2001-02-27 15:34 ` Khalid Aziz 2001-02-27 17:32 ` Mike Dresser 0 siblings, 2 replies; 25+ messages in thread From: Camm Maguire @ 2001-02-27 17:19 UTC (permalink / raw) To: Khalid Aziz; +Cc: linux-kernel Greetings, and thanks so much for your helpful reply! Khalid Aziz <khalid@fc.hp.com> writes: > Camm Maguire wrote: > > > > The Conner gives the problem: > > > > Feb 27 06:23:16 intech9 kernel: st0: Error with sense data: [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 > > Feb 27 06:23:16 intech9 kernel: ASC=20 ASCQ= 0 > > Feb 27 06:23:16 intech9 kernel: Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 > > > > and occaisional 'gunzip: unexpected end of file' errors on verifying > > the tape. > > > > Take care, > > > > -- > > Camm Maguire camm@enhanced.com > > ASC/ASCQ of 0x20/0x00 means "Invalid command operation code". So the > drive is rejecting a command sent to it by the driver. If the other > drive that is working is identical to seemingly non-working one, maybe > this drive is going bad. > Thanks for the error identification. The other drive is of a *different* model. This drive showed this behavior from the day I bought it. The drive could be going bad, but I doubt it. Is it possible that this manufacturer (Conner) has some peculiar implementation of the spec? I recall reading on this list sometime back of similar workarounds to unusual drives. > st driver prints the SCSI command that may have caused this error only > when compiled with debug turned on. Maybe st driver should always print > the command that results in a check condition as long as the command is > not a Test Unit Ready or Mode Sense. > Can I turn on debug mode in runtime, or do I need to recompile ide-scsi? Take care, > ==================================================================== > Khalid Aziz Linux Development Laboratory > (970)898-9214 Hewlett-Packard > khalid@fc.hp.com Fort Collins, CO > > -- Camm Maguire camm@enhanced.com ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 17:19 ` Camm Maguire @ 2001-02-27 15:34 ` Khalid Aziz 2001-02-27 19:52 ` Camm Maguire 2001-02-27 17:32 ` Mike Dresser 1 sibling, 1 reply; 25+ messages in thread From: Khalid Aziz @ 2001-02-27 15:34 UTC (permalink / raw) To: Camm Maguire; +Cc: linux-kernel Camm Maguire wrote: > > Thanks for the error identification. The other drive is of a > *different* model. This drive showed this behavior from the day I > bought it. The drive could be going bad, but I doubt it. Is it > possible that this manufacturer (Conner) has some peculiar > implementation of the spec? I recall reading on this list sometime > back of similar workarounds to unusual drives. Since the non-wroking drive is a different model, other drive working does not mean the st driver is sending only valid commands to the drives. st driver is sending a command to this drive which the drive does not like. It will help to know what that command is. > > > st driver prints the SCSI command that may have caused this error only > > when compiled with debug turned on. Maybe st driver should always print > > the command that results in a check condition as long as the command is > > not a Test Unit Ready or Mode Sense. > > > > Can I turn on debug mode in runtime, or do I need to recompile > ide-scsi? This is a compile time option, so you will have to recompile "st" driver. If you look at drivers/scsi/st.c, near the top of the file (line 44 for 2.4.2) you will see a line #define DEBUG 0 Change this line to set DEBUG to 1 and recompile. This may generate lot of messages from Test Unit Ready and Mode Sense commands. You can suppress these messages by replacing the code block within "if (debugging)" conditional at line 241 with following: if (SRpnt->sr_cmnd[0] != MODE_SENSE && SRpnt->sr_cmnd[0] != TEST_UNIT_READY) { printk(ST_DEB_MSG "st%d: Error: %x, cmd: %x %x %x %x %x %x Len: %d\n", dev, result, SRpnt->sr_cmnd[0], SRpnt->sr_cmnd[1], SRpnt->sr_cmnd[2], SRpnt->sr_cmnd[3], SRpnt->sr_cmnd[4], SRpnt->sr_cmnd[5], SRpnt->sr_bufflen); if (driver_byte(result) & DRIVER_SENSE) print_req_sense("st", SRpnt); } ==================================================================== Khalid Aziz Linux Development Laboratory (970)898-9214 Hewlett-Packard khalid@fc.hp.com Fort Collins, CO ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 15:34 ` Khalid Aziz @ 2001-02-27 19:52 ` Camm Maguire 2001-02-27 18:18 ` Khalid Aziz 0 siblings, 1 reply; 25+ messages in thread From: Camm Maguire @ 2001-02-27 19:52 UTC (permalink / raw) To: Khalid Aziz; +Cc: linux-kernel Greetings! OK, with st debugging, here are the most common errors with the Conner: Feb 27 14:46:39 intech9 kernel: st0: Error: 28000000, cmd: 8 1 0 0 40 0 Len: 16 Feb 27 14:46:39 intech9 kernel: Info fld=0x24, Current st09:00: sns = f0 8 Feb 27 14:46:39 intech9 kernel: ASC=14 ASCQ= 3 Feb 27 14:46:39 intech9 kernel: Raw sense data:0xf0 0x00 0x08 0x00 0x00 0x00 0x24 0x0a 0x00 0x00 0x00 0x00 0x14 0x03 0x00 0x00 Feb 27 14:46:39 intech9 kernel: st0: Sense: f0 0 8 0 0 0 24 a Feb 27 14:46:39 intech9 kernel: st0: Tape error while reading. Feb 27 14:46:40 intech9 kernel: st0: Error: 28000000, cmd: 5 0 0 0 0 0 Len: 16 Feb 27 14:46:40 intech9 kernel: [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 Feb 27 14:46:40 intech9 kernel: ASC=20 ASCQ= 0 Feb 27 14:46:40 intech9 kernel: Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 Feb 27 14:46:40 intech9 kernel: st0: Can't read block limits. Feb 27 14:46:40 intech9 kernel: st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8 Feb 27 14:46:40 intech9 kernel: st0: Density 45, tape length: 0, drv buffer: 1 Feb 27 14:46:40 intech9 kernel: st0: Block size: 512, buffer size: 32768 (64 blocks). Any advice appreciated! Khalid Aziz <khalid@fc.hp.com> writes: > Camm Maguire wrote: > > > > Thanks for the error identification. The other drive is of a > > *different* model. This drive showed this behavior from the day I > > bought it. The drive could be going bad, but I doubt it. Is it > > possible that this manufacturer (Conner) has some peculiar > > implementation of the spec? I recall reading on this list sometime > > back of similar workarounds to unusual drives. > > Since the non-wroking drive is a different model, other drive working > does not mean the st driver is sending only valid commands to the > drives. st driver is sending a command to this drive which the drive > does not like. It will help to know what that command is. > > > > > > st driver prints the SCSI command that may have caused this error only > > > when compiled with debug turned on. Maybe st driver should always print > > > the command that results in a check condition as long as the command is > > > not a Test Unit Ready or Mode Sense. > > > > > > > Can I turn on debug mode in runtime, or do I need to recompile > > ide-scsi? > > This is a compile time option, so you will have to recompile "st" > driver. If you look at drivers/scsi/st.c, near the top of the file (line > 44 for 2.4.2) you will see a line > > #define DEBUG 0 > > Change this line to set DEBUG to 1 and recompile. This may generate lot > of messages from Test Unit Ready and Mode Sense commands. You can > suppress these messages by replacing the code block within "if > (debugging)" conditional at line 241 with following: > > if (SRpnt->sr_cmnd[0] != MODE_SENSE && > SRpnt->sr_cmnd[0] != TEST_UNIT_READY) { > printk(ST_DEB_MSG "st%d: Error: %x, cmd: %x %x %x %x %x > %x Len: %d\n", > dev, result, > SRpnt->sr_cmnd[0], SRpnt->sr_cmnd[1], > SRpnt->sr_cmnd[2], > SRpnt->sr_cmnd[3], SRpnt->sr_cmnd[4], > SRpnt->sr_cmnd[5], > SRpnt->sr_bufflen); > if (driver_byte(result) & DRIVER_SENSE) > print_req_sense("st", SRpnt); > } > > > ==================================================================== > Khalid Aziz Linux Development Laboratory > (970)898-9214 Hewlett-Packard > khalid@fc.hp.com Fort Collins, CO > > -- Camm Maguire camm@enhanced.com ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 19:52 ` Camm Maguire @ 2001-02-27 18:18 ` Khalid Aziz 2001-02-27 20:26 ` Andre Hedrick ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: Khalid Aziz @ 2001-02-27 18:18 UTC (permalink / raw) To: Camm Maguire; +Cc: linux-kernel Camm Maguire wrote: > > Greetings! OK, with st debugging, here are the most common errors > with the Conner: > > Feb 27 14:46:39 intech9 kernel: st0: Error: 28000000, cmd: 8 1 0 0 40 0 Len: 16 > Feb 27 14:46:39 intech9 kernel: Info fld=0x24, Current st09:00: sns = f0 8 > Feb 27 14:46:39 intech9 kernel: ASC=14 ASCQ= 3 > Feb 27 14:46:39 intech9 kernel: Raw sense data:0xf0 0x00 0x08 0x00 0x00 0x00 0x24 0x0a 0x00 0x00 0x00 0x00 0x14 0x03 0x00 0x00 > Feb 27 14:46:39 intech9 kernel: st0: Sense: f0 0 8 0 0 0 24 a > Feb 27 14:46:39 intech9 kernel: st0: Tape error while reading. This was a read command that failed. Request sense information shows a sense key of 0x08 which is a "Blank check". This sense key indicates either a blank medium found or another error at EOD. ASC/ASCQ of 0x14/0x03 say "End-Of-Data not found". This indicates something wrong with the tape or maybe the drive needs cleaning. Do you get this error with more than one tape? > Feb 27 14:46:40 intech9 kernel: st0: Error: 28000000, cmd: 5 0 0 0 0 0 Len: 16 > Feb 27 14:46:40 intech9 kernel: [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 > Feb 27 14:46:40 intech9 kernel: ASC=20 ASCQ= 0 > Feb 27 14:46:40 intech9 kernel: Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 > Feb 27 14:46:40 intech9 kernel: st0: Can't read block limits. This was a "Read Block Limits" command which the drive claimed it does not recognize. "Read Block Limits" is a mandatory command for SCSI sequential access devices which is why "st" is issuing this command. The tape drive you have is not SCSI, so the manufacturer chose not to implement this command. The driver may still be able to work after "Read Block Limits" fails, but I have not read enough code to be sure. > Feb 27 14:46:40 intech9 kernel: st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8 > Feb 27 14:46:40 intech9 kernel: st0: Density 45, tape length: 0, drv buffer: 1 > Feb 27 14:46:40 intech9 kernel: st0: Block size: 512, buffer size: 32768 (64 blocks). > > Any advice appreciated! ==================================================================== Khalid Aziz Linux Development Laboratory (970)898-9214 Hewlett-Packard khalid@fc.hp.com Fort Collins, CO ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 18:18 ` Khalid Aziz @ 2001-02-27 20:26 ` Andre Hedrick 2001-02-27 21:26 ` Khalid Aziz 2001-02-28 15:23 ` Camm Maguire 2001-03-07 22:54 ` Camm Maguire 2 siblings, 1 reply; 25+ messages in thread From: Andre Hedrick @ 2001-02-27 20:26 UTC (permalink / raw) To: Khalid Aziz; +Cc: Camm Maguire, linux-kernel Hi Khalid, So, is HP going to allow linux to publsih "Tape Alert" as a means to assist with error checking and testing in general? Also why did HP take the 14GB/20GB models and move off the standard QIC or TR-4 IO-Firmware? Cheers, Andre Hedrick Linux ATA Development ASL Kernel Development ----------------------------------------------------------------------------- ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035 Web: www.aslab.com On Tue, 27 Feb 2001, Khalid Aziz wrote: > Camm Maguire wrote: > > > > Greetings! OK, with st debugging, here are the most common errors > > with the Conner: > > > > Feb 27 14:46:39 intech9 kernel: st0: Error: 28000000, cmd: 8 1 0 0 40 0 Len: 16 > > Feb 27 14:46:39 intech9 kernel: Info fld=0x24, Current st09:00: sns = f0 8 > > Feb 27 14:46:39 intech9 kernel: ASC=14 ASCQ= 3 > > Feb 27 14:46:39 intech9 kernel: Raw sense data:0xf0 0x00 0x08 0x00 0x00 0x00 0x24 0x0a 0x00 0x00 0x00 0x00 0x14 0x03 0x00 0x00 > > Feb 27 14:46:39 intech9 kernel: st0: Sense: f0 0 8 0 0 0 24 a > > Feb 27 14:46:39 intech9 kernel: st0: Tape error while reading. > > This was a read command that failed. Request sense information shows a > sense key of 0x08 which is a "Blank check". This sense key indicates > either a blank medium found or another error at EOD. ASC/ASCQ of > 0x14/0x03 say "End-Of-Data not found". This indicates something wrong > with the tape or maybe the drive needs cleaning. Do you get this error > with more than one tape? > > > > Feb 27 14:46:40 intech9 kernel: st0: Error: 28000000, cmd: 5 0 0 0 0 0 Len: 16 > > Feb 27 14:46:40 intech9 kernel: [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 > > Feb 27 14:46:40 intech9 kernel: ASC=20 ASCQ= 0 > > Feb 27 14:46:40 intech9 kernel: Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 > > Feb 27 14:46:40 intech9 kernel: st0: Can't read block limits. > > This was a "Read Block Limits" command which the drive claimed it does > not recognize. "Read Block Limits" is a mandatory command for SCSI > sequential access devices which is why "st" is issuing this command. The > tape drive you have is not SCSI, so the manufacturer chose not to > implement this command. The driver may still be able to work after "Read > Block Limits" fails, but I have not read enough code to be sure. > > > Feb 27 14:46:40 intech9 kernel: st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8 > > Feb 27 14:46:40 intech9 kernel: st0: Density 45, tape length: 0, drv buffer: 1 > > Feb 27 14:46:40 intech9 kernel: st0: Block size: 512, buffer size: 32768 (64 blocks). > > > > Any advice appreciated! > > ==================================================================== > Khalid Aziz Linux Development Laboratory > (970)898-9214 Hewlett-Packard > khalid@fc.hp.com Fort Collins, CO Andre Hedrick Linux ATA Development ASL Kernel Development ----------------------------------------------------------------------------- ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035 Web: www.aslab.com ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 20:26 ` Andre Hedrick @ 2001-02-27 21:26 ` Khalid Aziz 0 siblings, 0 replies; 25+ messages in thread From: Khalid Aziz @ 2001-02-27 21:26 UTC (permalink / raw) To: Andre Hedrick; +Cc: Camm Maguire, linux-kernel Andre Hedrick wrote: > > Hi Khalid, > > So, is HP going to allow linux to publsih "Tape Alert" as a means to > assist with error checking and testing in general? Also why did HP > take the 14GB/20GB models and move off the standard QIC or TR-4 > IO-Firmware? > > Cheers, > > Andre Hedrick > Linux ATA Development > ASL Kernel Development Hi Andre, Unfortunately I am not in a position to know answers to these questions. These questions would need to go way higher up than to a lowly software engineer :-) BTW, I am not familar with "Tape alert". Can you give me more info. A private email might be more approrpiate. -- Khalid ==================================================================== Khalid Aziz Linux Development Laboratory (970)898-9214 Hewlett-Packard khalid@fc.hp.com Fort Collins, CO ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 18:18 ` Khalid Aziz 2001-02-27 20:26 ` Andre Hedrick @ 2001-02-28 15:23 ` Camm Maguire 2001-02-28 15:34 ` Mike Dresser 2001-03-07 22:54 ` Camm Maguire 2 siblings, 1 reply; 25+ messages in thread From: Camm Maguire @ 2001-02-28 15:23 UTC (permalink / raw) To: Khalid Aziz; +Cc: linux-kernel Greetings, and thank you so much for your helpful reply!! Khalid Aziz <khalid@fc.hp.com> writes: > Camm Maguire wrote: > > > > Greetings! OK, with st debugging, here are the most common errors > > with the Conner: > > > > Feb 27 14:46:39 intech9 kernel: st0: Error: 28000000, cmd: 8 1 0 0 40 0 Len: 16 > > Feb 27 14:46:39 intech9 kernel: Info fld=0x24, Current st09:00: sns = f0 8 > > Feb 27 14:46:39 intech9 kernel: ASC=14 ASCQ= 3 > > Feb 27 14:46:39 intech9 kernel: Raw sense data:0xf0 0x00 0x08 0x00 0x00 0x00 0x24 0x0a 0x00 0x00 0x00 0x00 0x14 0x03 0x00 0x00 > > Feb 27 14:46:39 intech9 kernel: st0: Sense: f0 0 8 0 0 0 24 a > > Feb 27 14:46:39 intech9 kernel: st0: Tape error while reading. > > This was a read command that failed. Request sense information shows a > sense key of 0x08 which is a "Blank check". This sense key indicates > either a blank medium found or another error at EOD. ASC/ASCQ of > 0x14/0x03 say "End-Of-Data not found". This indicates something wrong > with the tape or maybe the drive needs cleaning. Do you get this error > with more than one tape? > Tape drive has been cleaned, but I'll look into behavior with other tapes. Thanks for the tip! One thing I miss about ide tapes (compared to the old floppy tapes) is the apparent inability to reformat them. > > > Feb 27 14:46:40 intech9 kernel: st0: Error: 28000000, cmd: 5 0 0 0 0 0 Len: 16 > > Feb 27 14:46:40 intech9 kernel: [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 > > Feb 27 14:46:40 intech9 kernel: ASC=20 ASCQ= 0 > > Feb 27 14:46:40 intech9 kernel: Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 > > Feb 27 14:46:40 intech9 kernel: st0: Can't read block limits. > > This was a "Read Block Limits" command which the drive claimed it does > not recognize. "Read Block Limits" is a mandatory command for SCSI > sequential access devices which is why "st" is issuing this command. The > tape drive you have is not SCSI, so the manufacturer chose not to > implement this command. The driver may still be able to work after "Read > Block Limits" fails, but I have not read enough code to be sure. > > > Feb 27 14:46:40 intech9 kernel: st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8 > > Feb 27 14:46:40 intech9 kernel: st0: Density 45, tape length: 0, drv buffer: 1 > > Feb 27 14:46:40 intech9 kernel: st0: Block size: 512, buffer size: 32768 (64 blocks). > > OK, great! Thanks for pointing this out! I think I may be having a problem with blocking on this drive, so I'll dig a little into st.c and see if it handles this case OK. The third error I get is: Feb 27 16:01:45 intech9 kernel: st0: Error: 28000000, cmd: 8 1 0 0 40 0 Len: 16 Feb 27 16:01:45 intech9 kernel: Info fld=0x40, FMK Current st09:00: sns = f0 80 Feb 27 16:01:45 intech9 kernel: ASC= 0 ASCQ= 1 Feb 27 16:01:45 intech9 kernel: Raw sense data:0xf0 0x00 0x80 0x00 0x00 0x00 0x40 0x0a 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 Feb 27 16:01:45 intech9 kernel: st0: Sense: f0 0 80 0 0 0 40 a Feb 27 16:01:45 intech9 kernel: st0: EOF detected (0 bytes read). Restoring a tape typically then says 'gunzip: unexpected end of file'. My guess was that the last fractional block of 32k wasn't flushed to the drive. Of course, if I'm having media troubles indicated by the first error above, then something else could be happening, I suppose. But does erroneous block flushing in the driver sound like a possibility? Take care, > > Any advice appreciated! > > ==================================================================== > Khalid Aziz Linux Development Laboratory > (970)898-9214 Hewlett-Packard > khalid@fc.hp.com Fort Collins, CO > > -- Camm Maguire camm@enhanced.com ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-28 15:23 ` Camm Maguire @ 2001-02-28 15:34 ` Mike Dresser 0 siblings, 0 replies; 25+ messages in thread From: Mike Dresser @ 2001-02-28 15:34 UTC (permalink / raw) To: Camm Maguire; +Cc: Khalid Aziz, linux-kernel I ran into a problem with tar and taper, with blocking, so what i do is backup a 128k file of emptiness, to guarantee that the last block of the real backup fit. > Restoring a tape typically then says 'gunzip: unexpected end of > file'. My guess was that the last fractional block of 32k wasn't > flushed to the drive. Of course, if I'm having media troubles > indicated by the first error above, then something else could be > happening, I suppose. But does erroneous block flushing in the driver > sound like a possibility? Mike Dresser ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 18:18 ` Khalid Aziz 2001-02-27 20:26 ` Andre Hedrick 2001-02-28 15:23 ` Camm Maguire @ 2001-03-07 22:54 ` Camm Maguire 2001-03-12 16:52 ` Khalid Aziz 2 siblings, 1 reply; 25+ messages in thread From: Camm Maguire @ 2001-03-07 22:54 UTC (permalink / raw) To: Khalid Aziz; +Cc: linux-kernel Thank you again for your help. While I do seem to get more errors with the ide-tape driver, I am also seeing some problems on further examination which are common to both ide-tape and st over ide-scsi, so perhaps I have a bad drive or tape. When trying to mt eom, for example, I get ============================================================================= st0: Error: 28000000, cmd: 5 0 0 0 0 0 Len: 16 [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 ASC=20 ASCQ= 0 Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 st0: Can't read block limits. st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8 st0: Density 45, tape length: 0, drv buffer: 1 st0: Block size: 512, buffer size: 32768 (64 blocks). st0: Retensioning tape. st0: Error: 28000000, cmd: 5 0 0 0 0 0 Len: 16 [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 ASC=20 ASCQ= 0 Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 st0: Can't read block limits. st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8 st0: Density 45, tape length: 0, drv buffer: 1 st0: Block size: 512, buffer size: 32768 (64 blocks). st0: Spacing tape forward over 16383 filemarks. st0: Spacing to end of recorded medium. st0: Error: 28000000, cmd: 11 3 0 0 0 0 Len: 16 Info fld=0x3feb, Deferred st09:00: sns = f1 3 ASC=11 ASCQ= 3 Raw sense data:0xf1 0x00 0x03 0x00 0x00 0x3f 0xeb 0x0a 0x00 0x00 0x00 0x00 0x11 0x03 0x00 0x00 st0: Error: 28000000, cmd: 5 0 0 0 0 0 Len: 16 [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 ASC=20 ASCQ= 0 Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 st0: Can't read block limits. st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8 st0: Density 45, tape length: 0, drv buffer: 1 st0: Block size: 512, buffer size: 32768 (64 blocks). st0: Rewinding tape. ============================================================================= What is the 11,3? Where can I find these codes listed? Why is the drive having trouble finding the end of the tape? I'll be testing more tapes soon, but this definitely happens with at least several. The mt command returned to the prompt with 'Input/ouput error'. Many Thanks again, Khalid Aziz <khalid@fc.hp.com> writes: > Camm Maguire wrote: > > > > Greetings! OK, with st debugging, here are the most common errors > > with the Conner: > > > > Feb 27 14:46:39 intech9 kernel: st0: Error: 28000000, cmd: 8 1 0 0 40 0 Len: 16 > > Feb 27 14:46:39 intech9 kernel: Info fld=0x24, Current st09:00: sns = f0 8 > > Feb 27 14:46:39 intech9 kernel: ASC=14 ASCQ= 3 > > Feb 27 14:46:39 intech9 kernel: Raw sense data:0xf0 0x00 0x08 0x00 0x00 0x00 0x24 0x0a 0x00 0x00 0x00 0x00 0x14 0x03 0x00 0x00 > > Feb 27 14:46:39 intech9 kernel: st0: Sense: f0 0 8 0 0 0 24 a > > Feb 27 14:46:39 intech9 kernel: st0: Tape error while reading. > > This was a read command that failed. Request sense information shows a > sense key of 0x08 which is a "Blank check". This sense key indicates > either a blank medium found or another error at EOD. ASC/ASCQ of > 0x14/0x03 say "End-Of-Data not found". This indicates something wrong > with the tape or maybe the drive needs cleaning. Do you get this error > with more than one tape? > > > > Feb 27 14:46:40 intech9 kernel: st0: Error: 28000000, cmd: 5 0 0 0 0 0 Len: 16 > > Feb 27 14:46:40 intech9 kernel: [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 > > Feb 27 14:46:40 intech9 kernel: ASC=20 ASCQ= 0 > > Feb 27 14:46:40 intech9 kernel: Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 > > Feb 27 14:46:40 intech9 kernel: st0: Can't read block limits. > > This was a "Read Block Limits" command which the drive claimed it does > not recognize. "Read Block Limits" is a mandatory command for SCSI > sequential access devices which is why "st" is issuing this command. The > tape drive you have is not SCSI, so the manufacturer chose not to > implement this command. The driver may still be able to work after "Read > Block Limits" fails, but I have not read enough code to be sure. > > > Feb 27 14:46:40 intech9 kernel: st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8 > > Feb 27 14:46:40 intech9 kernel: st0: Density 45, tape length: 0, drv buffer: 1 > > Feb 27 14:46:40 intech9 kernel: st0: Block size: 512, buffer size: 32768 (64 blocks). > > > > Any advice appreciated! > > ==================================================================== > Khalid Aziz Linux Development Laboratory > (970)898-9214 Hewlett-Packard > khalid@fc.hp.com Fort Collins, CO > > -- Camm Maguire camm@enhanced.com ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-03-07 22:54 ` Camm Maguire @ 2001-03-12 16:52 ` Khalid Aziz 2001-03-13 14:14 ` Camm Maguire 0 siblings, 1 reply; 25+ messages in thread From: Khalid Aziz @ 2001-03-12 16:52 UTC (permalink / raw) To: Camm Maguire; +Cc: linux-kernel 11,3 is "Multiple read errors". You can find all of the ASC and ASCQ listed in any SCSI spec document. You can find the SCSI-2 specs at <ftp://ftp.t10.org/t10/drafts/s2/s2-r10l.pdf>. -- Khalid Camm Maguire wrote: > > Thank you again for your help. While I do seem to get more errors > with the ide-tape driver, I am also seeing some problems on further > examination which are common to both ide-tape and st over ide-scsi, so > perhaps I have a bad drive or tape. > > When trying to mt eom, for example, I get > > ============================================================================= > st0: Error: 28000000, cmd: 5 0 0 0 0 0 Len: 16 > [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 > ASC=20 ASCQ= 0 > Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 > st0: Can't read block limits. > st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8 > st0: Density 45, tape length: 0, drv buffer: 1 > st0: Block size: 512, buffer size: 32768 (64 blocks). > st0: Retensioning tape. > st0: Error: 28000000, cmd: 5 0 0 0 0 0 Len: 16 > [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 > ASC=20 ASCQ= 0 > Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 > st0: Can't read block limits. > st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8 > st0: Density 45, tape length: 0, drv buffer: 1 > st0: Block size: 512, buffer size: 32768 (64 blocks). > st0: Spacing tape forward over 16383 filemarks. > st0: Spacing to end of recorded medium. > st0: Error: 28000000, cmd: 11 3 0 0 0 0 Len: 16 > Info fld=0x3feb, Deferred st09:00: sns = f1 3 > ASC=11 ASCQ= 3 > Raw sense data:0xf1 0x00 0x03 0x00 0x00 0x3f 0xeb 0x0a 0x00 0x00 0x00 0x00 0x11 0x03 0x00 0x00 > st0: Error: 28000000, cmd: 5 0 0 0 0 0 Len: 16 > [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 > ASC=20 ASCQ= 0 > Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 > st0: Can't read block limits. > st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8 > st0: Density 45, tape length: 0, drv buffer: 1 > st0: Block size: 512, buffer size: 32768 (64 blocks). > st0: Rewinding tape. > ============================================================================= > > What is the 11,3? Where can I find these codes listed? Why is the > drive having trouble finding the end of the tape? I'll be testing > more tapes soon, but this definitely happens with at least several. > The mt command returned to the prompt with 'Input/ouput error'. > > Many Thanks again, > -- ==================================================================== Khalid Aziz Linux Development Laboratory (970)898-9214 Hewlett-Packard khalid@fc.hp.com Fort Collins, CO ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-03-12 16:52 ` Khalid Aziz @ 2001-03-13 14:14 ` Camm Maguire 0 siblings, 0 replies; 25+ messages in thread From: Camm Maguire @ 2001-03-13 14:14 UTC (permalink / raw) To: Khalid Aziz; +Cc: linux-kernel Thank you again, so much! Take care, Khalid Aziz <khalid@fc.hp.com> writes: > 11,3 is "Multiple read errors". You can find all of the ASC and ASCQ > listed in any SCSI spec document. You can find the SCSI-2 specs at > <ftp://ftp.t10.org/t10/drafts/s2/s2-r10l.pdf>. > > -- > Khalid > > Camm Maguire wrote: > > > > Thank you again for your help. While I do seem to get more errors > > with the ide-tape driver, I am also seeing some problems on further > > examination which are common to both ide-tape and st over ide-scsi, so > > perhaps I have a bad drive or tape. > > > > When trying to mt eom, for example, I get > > > > ============================================================================= > > st0: Error: 28000000, cmd: 5 0 0 0 0 0 Len: 16 > > [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 > > ASC=20 ASCQ= 0 > > Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 > > st0: Can't read block limits. > > st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8 > > st0: Density 45, tape length: 0, drv buffer: 1 > > st0: Block size: 512, buffer size: 32768 (64 blocks). > > st0: Retensioning tape. > > st0: Error: 28000000, cmd: 5 0 0 0 0 0 Len: 16 > > [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 > > ASC=20 ASCQ= 0 > > Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 > > st0: Can't read block limits. > > st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8 > > st0: Density 45, tape length: 0, drv buffer: 1 > > st0: Block size: 512, buffer size: 32768 (64 blocks). > > st0: Spacing tape forward over 16383 filemarks. > > st0: Spacing to end of recorded medium. > > st0: Error: 28000000, cmd: 11 3 0 0 0 0 Len: 16 > > Info fld=0x3feb, Deferred st09:00: sns = f1 3 > > ASC=11 ASCQ= 3 > > Raw sense data:0xf1 0x00 0x03 0x00 0x00 0x3f 0xeb 0x0a 0x00 0x00 0x00 0x00 0x11 0x03 0x00 0x00 > > st0: Error: 28000000, cmd: 5 0 0 0 0 0 Len: 16 > > [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 > > ASC=20 ASCQ= 0 > > Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 > > st0: Can't read block limits. > > st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8 > > st0: Density 45, tape length: 0, drv buffer: 1 > > st0: Block size: 512, buffer size: 32768 (64 blocks). > > st0: Rewinding tape. > > ============================================================================= > > > > What is the 11,3? Where can I find these codes listed? Why is the > > drive having trouble finding the end of the tape? I'll be testing > > more tapes soon, but this definitely happens with at least several. > > The mt command returned to the prompt with 'Input/ouput error'. > > > > Many Thanks again, > > > > -- > ==================================================================== > Khalid Aziz Linux Development Laboratory > (970)898-9214 Hewlett-Packard > khalid@fc.hp.com Fort Collins, CO > > -- Camm Maguire camm@enhanced.com ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 17:19 ` Camm Maguire 2001-02-27 15:34 ` Khalid Aziz @ 2001-02-27 17:32 ` Mike Dresser 2001-02-27 18:31 ` Camm Maguire 2001-02-27 19:01 ` Andre Hedrick 1 sibling, 2 replies; 25+ messages in thread From: Mike Dresser @ 2001-02-27 17:32 UTC (permalink / raw) To: Camm Maguire; +Cc: Khalid Aziz, linux-kernel > > ASC/ASCQ of 0x20/0x00 means "Invalid command operation code". So the > > drive is rejecting a command sent to it by the driver. If the other > > drive that is working is identical to seemingly non-working one, maybe > > this drive is going bad. > > > > Thanks for the error identification. The other drive is of a > *different* model. This drive showed this behavior from the day I > bought it. The drive could be going bad, but I doubt it. Is it > possible that this manufacturer (Conner) has some peculiar > implementation of the spec? I recall reading on this list sometime > back of similar workarounds to unusual drives. When you go to 2.4.x, you'll likely run into the problem of your HP 14Gb not able to restore anymore. Same as if you apply the linux-ide patches to 2.2.x Mike Dresser sysadmin Windsor Machine & Stamping ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 17:32 ` Mike Dresser @ 2001-02-27 18:31 ` Camm Maguire 2001-02-27 18:34 ` Mike Dresser 2001-02-27 19:01 ` Andre Hedrick 1 sibling, 1 reply; 25+ messages in thread From: Camm Maguire @ 2001-02-27 18:31 UTC (permalink / raw) To: Mike Dresser; +Cc: Khalid Aziz, linux-kernel Greetings! You are certainly right here, at least in part. The ide patches for 2.2 definitely impair tape operation on these boxes. There was a crude workaround suggested on this list to use the ide-scsi driver -- this basically worked, but gave *many* error messages in the kernel log, and was significantly less reliable than stock 2.2.18. I'm still using ide-scsi out of inertia, but I suspect that ide-tape might be just fine with stock 2.2.18 too. And when I saw some support for the ALI chipset, the decision was clear to drop the latest ide stuff. This has been the situation for some time. Is this going to be resolved soon? Mike Dresser <mdresser@windsormachine.com> writes: > > > ASC/ASCQ of 0x20/0x00 means "Invalid command operation code". So the > > > drive is rejecting a command sent to it by the driver. If the other > > > drive that is working is identical to seemingly non-working one, maybe > > > this drive is going bad. > > > > > > > Thanks for the error identification. The other drive is of a > > *different* model. This drive showed this behavior from the day I > > bought it. The drive could be going bad, but I doubt it. Is it > > possible that this manufacturer (Conner) has some peculiar > > implementation of the spec? I recall reading on this list sometime > > back of similar workarounds to unusual drives. > > When you go to 2.4.x, you'll likely run into the problem of your HP 14Gb not able to restore anymore. Same as if you apply the > linux-ide patches to 2.2.x > > Mike Dresser > sysadmin > Windsor Machine & Stamping > > > -- Camm Maguire camm@enhanced.com ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 18:31 ` Camm Maguire @ 2001-02-27 18:34 ` Mike Dresser 2001-02-27 19:05 ` Andre Hedrick 2001-02-27 22:21 ` Alan Cox 0 siblings, 2 replies; 25+ messages in thread From: Mike Dresser @ 2001-02-27 18:34 UTC (permalink / raw) To: Camm Maguire; +Cc: Khalid Aziz, linux-kernel Camm Maguire wrote: > Greetings! You are certainly right here, at least in part. The ide > patches for 2.2 definitely impair tape operation on these boxes. > There was a crude workaround suggested on this list to use the > ide-scsi driver -- this basically worked, but gave *many* error > messages in the kernel log, and was significantly less reliable than > stock 2.2.18. I'm still using ide-scsi out of inertia, but I suspect > that ide-tape might be just fine with stock 2.2.18 too. And when I > saw some support for the ALI chipset, the decision was clear to drop > the latest ide stuff. > > This has been the situation for some time. Is this going to be > resolved soon? Wish i knew, I'm praying that 2.2.19 hasn't/doesn't implement the ide patches like 2.4.x did. If so, and a major problem is found in 2.2.18, then I have to maintain another machine running 2.2.18 to restore tapes. Also means i'd have to stop using taper or dump, and stick to tar only, as both want to read the tape back in at some point. Mike ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 18:34 ` Mike Dresser @ 2001-02-27 19:05 ` Andre Hedrick 2001-02-27 19:40 ` Camm Maguire 2001-02-27 22:21 ` Alan Cox 1 sibling, 1 reply; 25+ messages in thread From: Andre Hedrick @ 2001-02-27 19:05 UTC (permalink / raw) To: Mike Dresser; +Cc: Camm Maguire, Khalid Aziz, linux-kernel Maybe you should check to find out which devices are supported and which are not. HP messed up a good device class by doing something like a modified TR-4 or TR-5; however, it may be a QIC157 that is better supported under emulation. On Tue, 27 Feb 2001, Mike Dresser wrote: > Camm Maguire wrote: > > > Greetings! You are certainly right here, at least in part. The ide > > patches for 2.2 definitely impair tape operation on these boxes. > > There was a crude workaround suggested on this list to use the > > ide-scsi driver -- this basically worked, but gave *many* error > > messages in the kernel log, and was significantly less reliable than > > stock 2.2.18. I'm still using ide-scsi out of inertia, but I suspect > > that ide-tape might be just fine with stock 2.2.18 too. And when I > > saw some support for the ALI chipset, the decision was clear to drop > > the latest ide stuff. > > > > This has been the situation for some time. Is this going to be > > resolved soon? > > Wish i knew, I'm praying that 2.2.19 hasn't/doesn't implement the ide patches like 2.4.x did. If so, and a major problem is found in > 2.2.18, then I have to maintain another machine running 2.2.18 to restore tapes. Also means i'd have to stop using taper or dump, > and stick to tar only, as both want to read the tape back in at some point. > > Mike > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > Andre Hedrick Linux ATA Development ASL Kernel Development ----------------------------------------------------------------------------- ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035 Web: www.aslab.com ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 19:05 ` Andre Hedrick @ 2001-02-27 19:40 ` Camm Maguire 2001-03-01 17:02 ` Khalid Aziz 0 siblings, 1 reply; 25+ messages in thread From: Camm Maguire @ 2001-02-27 19:40 UTC (permalink / raw) To: Andre Hedrick; +Cc: Mike Dresser, Khalid Aziz, linux-kernel Hi Andre, and thanks for this note (and of course, your work on ide!). 1) I assume you are referring to the HP colorado 14G, and not the Conner (Seagate) TR-4 8G mentioned in my original note. 2) If so, what could be wrong with the Conner? 3) Where can I find what is supported and what not? The Conner is a standard TR-4, and I thought that was supported. 4) Can one signal the driver to try qic157 emulation? 5) Separately, Since the Colorado 14G seems so popular, is there any chance of getting what it is that works currently into the new ide stuff? After all, it *does* work at present with stock 2.2.x. Thanks again for all your hard work! Andre Hedrick <andre@linux-ide.org> writes: > Maybe you should check to find out which devices are supported and which > are not. HP messed up a good device class by doing something like a > modified TR-4 or TR-5; however, it may be a QIC157 that is better > supported under emulation. > > On Tue, 27 Feb 2001, Mike Dresser wrote: > > > Camm Maguire wrote: > > > > > Greetings! You are certainly right here, at least in part. The ide > > > patches for 2.2 definitely impair tape operation on these boxes. > > > There was a crude workaround suggested on this list to use the > > > ide-scsi driver -- this basically worked, but gave *many* error > > > messages in the kernel log, and was significantly less reliable than > > > stock 2.2.18. I'm still using ide-scsi out of inertia, but I suspect > > > that ide-tape might be just fine with stock 2.2.18 too. And when I > > > saw some support for the ALI chipset, the decision was clear to drop > > > the latest ide stuff. > > > > > > This has been the situation for some time. Is this going to be > > > resolved soon? > > > > Wish i knew, I'm praying that 2.2.19 hasn't/doesn't implement the ide patches like 2.4.x did. If so, and a major problem is found in > > 2.2.18, then I have to maintain another machine running 2.2.18 to restore tapes. Also means i'd have to stop using taper or dump, > > and stick to tar only, as both want to read the tape back in at some point. > > > > Mike > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > > Andre Hedrick > Linux ATA Development > ASL Kernel Development > ----------------------------------------------------------------------------- > ASL, Inc. Toll free: 1-877-ASL-3535 > 1757 Houret Court Fax: 1-408-941-2071 > Milpitas, CA 95035 Web: www.aslab.com > > > -- Camm Maguire camm@enhanced.com ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 19:40 ` Camm Maguire @ 2001-03-01 17:02 ` Khalid Aziz 0 siblings, 0 replies; 25+ messages in thread From: Khalid Aziz @ 2001-03-01 17:02 UTC (permalink / raw) To: Camm Maguire; +Cc: linux-kernel Camm Maguire wrote: >The third error I get is: > >Feb 27 16:01:45 intech9 kernel: st0: Error: 28000000, cmd: 8 1 0 0 40 0 Len: 16 >Feb 27 16:01:45 intech9 kernel: Info fld=0x40, FMK Current st09:00: sns = f0 80 >Feb 27 16:01:45 intech9 kernel: ASC= 0 ASCQ= 1 >Feb 27 16:01:45 intech9 kernel: Raw sense data:0xf0 0x00 0x80 0x00 0x00 0x00 0x40 0x0a 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 >Feb 27 16:01:45 intech9 kernel: st0: Sense: f0 0 80 0 0 0 40 a >Feb 27 16:01:45 intech9 kernel: st0: EOF detected (0 bytes read). > >Restoring a tape typically then says 'gunzip: unexpected end of >file'. My guess was that the last fractional block of 32k wasn't >flushed to the drive. Of course, if I'm having media troubles >indicated by the first error above, then something else could be >happening, I suppose. But does erroneous block flushing in the driver >sound like a possibility? Above sense data indicates drive has encountered a filemark on a READ command. This READ did not read a partial block since the residual count in Sense data is set to 0x40 which is the same block count requested by the READ command. If you were writing 32K blocks to the tape and there indeed was a partial block at the end, the current position of the tape is not at that partial block. Tape seems to be positioned immediately after the last block where a filemark was written indicating end of archive. Looking at the READ command (8 1 0 0 40 0), the "fixed" bit is set which means the tape is being read in fixed block length mode. This read command is trying to read 64 blocks from the tape. If the application is reading data in blocks of 32K, it implies the block size on the physical media is 512 Bytes. So when you say last 32K block may not have been flushed to the drive, I am assuming you mean not being flushed from the host to the tape drive. This is possible but there may be something else going on. I would suggest setting no block limits on the drive using "mt stsetoptions no-blklimits". See if that helps. ==================================================================== Khalid Aziz Linux Development Laboratory (970)898-9214 Hewlett-Packard khalid@fc.hp.com Fort Collins, CO ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 18:34 ` Mike Dresser 2001-02-27 19:05 ` Andre Hedrick @ 2001-02-27 22:21 ` Alan Cox 1 sibling, 0 replies; 25+ messages in thread From: Alan Cox @ 2001-02-27 22:21 UTC (permalink / raw) To: Mike Dresser; +Cc: Camm Maguire, Khalid Aziz, linux-kernel > Wish i knew, I'm praying that 2.2.19 hasn't/doesn't implement the ide patches like 2.4.x did. If so, and a major problem is found in > 2.2.18, then I have to maintain another machine running 2.2.18 to restore tapes. Also means i'd have to stop using taper or dump, > and stick to tar only, as both want to read the tape back in at some point. 2.2 isnt likely to ever see the IDE patches as standard. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 17:32 ` Mike Dresser 2001-02-27 18:31 ` Camm Maguire @ 2001-02-27 19:01 ` Andre Hedrick 2001-02-27 19:04 ` Mike Dresser 1 sibling, 1 reply; 25+ messages in thread From: Andre Hedrick @ 2001-02-27 19:01 UTC (permalink / raw) To: Mike Dresser; +Cc: Camm Maguire, Khalid Aziz, linux-kernel On Tue, 27 Feb 2001, Mike Dresser wrote: > When you go to 2.4.x, you'll likely run into the problem of your HP 14Gb not able to restore anymore. Same as if you apply the > linux-ide patches to 2.2.x Because the HP 14Gb is not a standard QIC device. Andre Hedrick Linux ATA Development ASL Kernel Development ----------------------------------------------------------------------------- ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035 Web: www.aslab.com ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 19:01 ` Andre Hedrick @ 2001-02-27 19:04 ` Mike Dresser 0 siblings, 0 replies; 25+ messages in thread From: Mike Dresser @ 2001-02-27 19:04 UTC (permalink / raw) To: Andre Hedrick; +Cc: Camm Maguire, Khalid Aziz, linux-kernel Andre Hedrick wrote: > On Tue, 27 Feb 2001, Mike Dresser wrote: > > > When you go to 2.4.x, you'll likely run into the problem of your HP 14Gb not able to restore anymore. Same as if you apply the > > linux-ide patches to 2.2.x > > Because the HP 14Gb is not a standard QIC device. any change of a work-around then? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] 2.2.18 IDE tape problem, with ide-scsi 2001-02-27 16:06 2.2.18 IDE tape problem, with ide-scsi Camm Maguire 2001-02-27 15:07 ` Khalid Aziz @ 2001-03-07 0:34 ` Chip Salzenberg 2001-03-07 1:09 ` Andre Hedrick 1 sibling, 1 reply; 25+ messages in thread From: Chip Salzenberg @ 2001-03-07 0:34 UTC (permalink / raw) To: Camm Maguire; +Cc: linux-kernel With Andre's IDE subsystem, I found the below patch necessary to use my IDE tape drive (Exabyte Eagle TR-4). Frankly, it's been so long since I created this patch that I can't remember the detailed reasons for the changes. But I knew them once. :-) And it works for me. Reminder, this is against Andre Hedrick's 2.2 IDE subsystem. Index: drivers/block/ide-tape.c --- drivers/block/ide-tape.c.prev +++ drivers/block/ide-tape.c Tue Dec 5 01:17:32 2000 @@ -3096,7 +3096,10 @@ static int idetape_queue_pc_tail (ide_dr static int idetape_flush_tape_buffers (ide_drive_t *drive) { + idetape_tape_t *tape = drive->driver_data; idetape_pc_t pc; int rc; + if (tape->chrdev_direction != idetape_direction_write) + return 0; idetape_create_write_filemark_cmd(drive, &pc, 0); if ((rc = idetape_queue_pc_tail (drive,&pc))) @@ -5199,12 +5202,15 @@ static int idetape_chrdev_open (struct i if (tape->chrdev_direction == idetape_direction_none) { MOD_INC_USE_COUNT; + if (tape->onstream) { #if ONSTREAM_DEBUG - if (tape->debug_level >= 6) - printk(KERN_INFO "ide-tape: MOD_INC_USE_COUNT in idetape_chrdev_open-2\n"); + if (tape->debug_level >= 6) + printk(KERN_INFO "ide-tape: MOD_INC_USE_COUNT" + " in idetape_chrdev_open-2\n"); #endif - idetape_create_prevent_cmd(drive, &pc, 1); - if (!idetape_queue_pc_tail (drive,&pc)) { - if (tape->door_locked != DOOR_EXPLICITLY_LOCKED) - tape->door_locked = DOOR_LOCKED; + idetape_create_prevent_cmd(drive, &pc, 1); + if (!idetape_queue_pc_tail (drive,&pc)) { + if (tape->door_locked != DOOR_EXPLICITLY_LOCKED) + tape->door_locked = DOOR_LOCKED; + } } idetape_analyze_headers(drive); @@ -5258,14 +5264,17 @@ static int idetape_chrdev_release (struc (void) idetape_rewind_tape (drive); if (tape->chrdev_direction == idetape_direction_none) { - if (tape->door_locked != DOOR_EXPLICITLY_LOCKED) { - idetape_create_prevent_cmd(drive, &pc, 0); - if (!idetape_queue_pc_tail (drive,&pc)) - tape->door_locked = DOOR_UNLOCKED; - } - MOD_DEC_USE_COUNT; + if (tape->onstream) { + if (tape->door_locked != DOOR_EXPLICITLY_LOCKED) { + idetape_create_prevent_cmd(drive, &pc, 0); + if (!idetape_queue_pc_tail (drive,&pc)) + tape->door_locked = DOOR_UNLOCKED; + } #if ONSTREAM_DEBUG - if (tape->debug_level >= 6) - printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in idetape_chrdev_release\n"); + if (tape->debug_level >= 6) + printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT" + " in idetape_chrdev_release\n"); #endif + } + MOD_DEC_USE_COUNT; } clear_bit (IDETAPE_BUSY, &tape->flags); -- Chip Salzenberg - a.k.a. - <chip@valinux.com> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] 2.2.18 IDE tape problem, with ide-scsi 2001-03-07 0:34 ` [PATCH] " Chip Salzenberg @ 2001-03-07 1:09 ` Andre Hedrick 0 siblings, 0 replies; 25+ messages in thread From: Andre Hedrick @ 2001-03-07 1:09 UTC (permalink / raw) To: Chip Salzenberg; +Cc: Camm Maguire, linux-kernel Chip, I thought O grabbed that from you... On Tue, 6 Mar 2001, Chip Salzenberg wrote: > With Andre's IDE subsystem, I found the below patch necessary to use > my IDE tape drive (Exabyte Eagle TR-4). Frankly, it's been so long > since I created this patch that I can't remember the detailed reasons > for the changes. But I knew them once. :-) And it works for me. > > Reminder, this is against Andre Hedrick's 2.2 IDE subsystem. > > Index: drivers/block/ide-tape.c > --- drivers/block/ide-tape.c.prev > +++ drivers/block/ide-tape.c Tue Dec 5 01:17:32 2000 > @@ -3096,7 +3096,10 @@ static int idetape_queue_pc_tail (ide_dr > static int idetape_flush_tape_buffers (ide_drive_t *drive) > { > + idetape_tape_t *tape = drive->driver_data; > idetape_pc_t pc; > int rc; > > + if (tape->chrdev_direction != idetape_direction_write) > + return 0; > idetape_create_write_filemark_cmd(drive, &pc, 0); > if ((rc = idetape_queue_pc_tail (drive,&pc))) > @@ -5199,12 +5202,15 @@ static int idetape_chrdev_open (struct i > if (tape->chrdev_direction == idetape_direction_none) { > MOD_INC_USE_COUNT; > + if (tape->onstream) { > #if ONSTREAM_DEBUG > - if (tape->debug_level >= 6) > - printk(KERN_INFO "ide-tape: MOD_INC_USE_COUNT in idetape_chrdev_open-2\n"); > + if (tape->debug_level >= 6) > + printk(KERN_INFO "ide-tape: MOD_INC_USE_COUNT" > + " in idetape_chrdev_open-2\n"); > #endif > - idetape_create_prevent_cmd(drive, &pc, 1); > - if (!idetape_queue_pc_tail (drive,&pc)) { > - if (tape->door_locked != DOOR_EXPLICITLY_LOCKED) > - tape->door_locked = DOOR_LOCKED; > + idetape_create_prevent_cmd(drive, &pc, 1); > + if (!idetape_queue_pc_tail (drive,&pc)) { > + if (tape->door_locked != DOOR_EXPLICITLY_LOCKED) > + tape->door_locked = DOOR_LOCKED; > + } > } > idetape_analyze_headers(drive); > @@ -5258,14 +5264,17 @@ static int idetape_chrdev_release (struc > (void) idetape_rewind_tape (drive); > if (tape->chrdev_direction == idetape_direction_none) { > - if (tape->door_locked != DOOR_EXPLICITLY_LOCKED) { > - idetape_create_prevent_cmd(drive, &pc, 0); > - if (!idetape_queue_pc_tail (drive,&pc)) > - tape->door_locked = DOOR_UNLOCKED; > - } > - MOD_DEC_USE_COUNT; > + if (tape->onstream) { > + if (tape->door_locked != DOOR_EXPLICITLY_LOCKED) { > + idetape_create_prevent_cmd(drive, &pc, 0); > + if (!idetape_queue_pc_tail (drive,&pc)) > + tape->door_locked = DOOR_UNLOCKED; > + } > #if ONSTREAM_DEBUG > - if (tape->debug_level >= 6) > - printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in idetape_chrdev_release\n"); > + if (tape->debug_level >= 6) > + printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT" > + " in idetape_chrdev_release\n"); > #endif > + } > + MOD_DEC_USE_COUNT; > } > clear_bit (IDETAPE_BUSY, &tape->flags); > > -- > Chip Salzenberg - a.k.a. - <chip@valinux.com> > "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > Andre Hedrick Linux ATA Development ASL Kernel Development ----------------------------------------------------------------------------- ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035 Web: www.aslab.com ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <Pine.LNX.4.10.10102271153560.29323-100000@coffee.psychology.mcmaster.ca>]
* Re: 2.2.18 IDE tape problem, with ide-scsi [not found] <Pine.LNX.4.10.10102271153560.29323-100000@coffee.psychology.mcmaster.ca> @ 2001-02-27 17:16 ` Camm Maguire 0 siblings, 0 replies; 25+ messages in thread From: Camm Maguire @ 2001-02-27 17:16 UTC (permalink / raw) To: Mark Hahn; +Cc: linux-kernel Greetings, and thanks for your reply! Mark Hahn <hahn@coffee.psychology.mcmaster.ca> writes: > > Greetings! Two ide tapes, both on second ide channel, both using > > mixing devices from different vendors on the same channel > often gives this kind of problem. sticking in even a cheap > PCI ide controller would pretty dramatically improve your > system (since you could put one device on each channel). > > Good advice, but the problem persists even when the offending drive is alone on the secondary ide channel. In fact, this the configuration in which I first came upon the problem. I installed the second drive later, and when that worked, I suspected a model-specific bug in the driver. One gets an analogous kernel error when using the straight ide-tape driver. Take care, > > > ide-scsi. One works perfectly, the other basically works, but gives > > errors, and occasionally doesn't write full 32k blocks to tape, > > causing amanda errors. > > > > Feb 25 06:14:22 intech9 kernel: ALI15X3: IDE controller on PCI bus 00 dev 78 > > Feb 25 06:14:22 intech9 kernel: ALI15X3: not 100%% native mode: will probe irqs later > > Feb 25 06:14:22 intech9 kernel: ide0: BM-DMA at 0xb400-0xb407, BIOS settings: hda:DMA, hdb:DMA > > Feb 25 06:14:22 intech9 kernel: > > Feb 25 06:14:22 intech9 kernel: ************************************ > > Feb 25 06:14:22 intech9 kernel: * ALi IDE driver (1.0 beta3) * > > Feb 25 06:14:22 intech9 kernel: * Chip Revision is C1 * > > Feb 25 06:14:22 intech9 kernel: * Maximum capability is - UDMA 33 * > > Feb 25 06:14:22 intech9 kernel: ************************************ > > Feb 25 06:14:22 intech9 kernel: > > Feb 25 06:14:22 intech9 kernel: ide1: BM-DMA at 0xb408-0xb40f, BIOS settings: hdc:pio, hdd:pio > > Feb 25 06:14:22 intech9 kernel: hda: FUJITSU MPE3064AT, ATA DISK drive > > Feb 25 06:14:22 intech9 kernel: hdb: ST32140A, ATA DISK drive > > Feb 25 06:14:22 intech9 kernel: hdc: CONNER CTT8000-A, ATAPI TAPE drive > > Feb 25 06:14:22 intech9 kernel: hdd: HP COLORADO 14GB, ATAPI TAPE drive > > Feb 25 06:14:22 intech9 kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > > Feb 25 06:14:22 intech9 kernel: ide1 at 0x170-0x177,0x376 on irq 15 > > Feb 25 06:14:22 intech9 kernel: ALI15X3: Ultra DMA enabled > > Feb 25 06:14:22 intech9 kernel: hda: FUJITSU MPE3064AT, 6187MB w/512kB Cache, CHS=788/255/63, (U)DMA > > Feb 25 06:14:22 intech9 kernel: ALI15X3: MultiWord DMA enabled > > Feb 25 06:14:22 intech9 kernel: hdb: ST32140A, 2015MB w/128kB Cache, CHS=4095/16/63, DMA > > Feb 25 06:14:22 intech9 kernel: hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 > > > Feb 25 06:14:22 intech9 kernel: hdb: hdb1 hdb2 > > > > The Conner gives the problem: > > > > Feb 27 06:23:16 intech9 kernel: st0: Error with sense data: [valid=0] Info fld=0x0, Current st09:00: sns = 70 5 > > Feb 27 06:23:16 intech9 kernel: ASC=20 ASCQ= 0 > > Feb 27 06:23:16 intech9 kernel: Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 > > > > and occaisional 'gunzip: unexpected end of file' errors on verifying > > the tape. > > > > Take care, > > > > > > > > -- > operator may differ from spokesperson. hahn@coffee.mcmaster.ca > http://java.mcmaster.ca/~hahn > > > -- Camm Maguire camm@enhanced.com ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2001-03-13 14:17 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-02-27 16:06 2.2.18 IDE tape problem, with ide-scsi Camm Maguire
2001-02-27 15:07 ` Khalid Aziz
2001-02-27 17:19 ` Camm Maguire
2001-02-27 15:34 ` Khalid Aziz
2001-02-27 19:52 ` Camm Maguire
2001-02-27 18:18 ` Khalid Aziz
2001-02-27 20:26 ` Andre Hedrick
2001-02-27 21:26 ` Khalid Aziz
2001-02-28 15:23 ` Camm Maguire
2001-02-28 15:34 ` Mike Dresser
2001-03-07 22:54 ` Camm Maguire
2001-03-12 16:52 ` Khalid Aziz
2001-03-13 14:14 ` Camm Maguire
2001-02-27 17:32 ` Mike Dresser
2001-02-27 18:31 ` Camm Maguire
2001-02-27 18:34 ` Mike Dresser
2001-02-27 19:05 ` Andre Hedrick
2001-02-27 19:40 ` Camm Maguire
2001-03-01 17:02 ` Khalid Aziz
2001-02-27 22:21 ` Alan Cox
2001-02-27 19:01 ` Andre Hedrick
2001-02-27 19:04 ` Mike Dresser
2001-03-07 0:34 ` [PATCH] " Chip Salzenberg
2001-03-07 1:09 ` Andre Hedrick
[not found] <Pine.LNX.4.10.10102271153560.29323-100000@coffee.psychology.mcmaster.ca>
2001-02-27 17:16 ` Camm Maguire
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).