LinuxLists.cc - 2.2.18 IDE tape problem, with ide-scsi

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

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 [email protected]

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
[email protected] Fort Collins, CO

2001-02-27 17:16:50

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

Greetings, and thanks for your reply!

Mark Hahn <[email protected]> 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. [email protected]
> http://java.mcmaster.ca/~hahn
>
>
>

--
Camm Maguire [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

2001-02-27 17:19:50

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

Greetings, and thanks so much for your helpful reply!

Khalid Aziz <[email protected]> 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 [email protected]
>
> 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
> [email protected] Fort Collins, CO
>
>

--
Camm Maguire [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

2001-02-27 17:33:22

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

> > 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

2001-02-27 17:35:21

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

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
[email protected] Fort Collins, CO

2001-02-27 18:32:19

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

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 <[email protected]> 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 [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

2001-02-27 18:35:09

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

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

2001-02-27 19:05:23

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

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?

2001-02-27 19:03:02

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

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: http://www.aslab.com

2001-02-27 19:07:06

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

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 [email protected]
> 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: http://www.aslab.com

2001-02-27 19:41:10

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

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 <[email protected]> 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 [email protected]
> > 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: http://www.aslab.com
>
>
>

--
Camm Maguire [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

2001-02-27 19:53:42

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

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 <[email protected]> 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
> [email protected] Fort Collins, CO
>
>

--
Camm Maguire [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

2001-02-27 20:18:23

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

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
[email protected] Fort Collins, CO

2001-02-27 20:28:03

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

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: http://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
> [email protected] 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: http://www.aslab.com

2001-02-27 22:20:51

by Alan

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

> 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.

2001-02-27 23:26:55

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

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
[email protected] Fort Collins, CO

2001-02-28 15:24:02

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

Greetings, and thank you so much for your helpful reply!!

Khalid Aziz <[email protected]> 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
> [email protected] Fort Collins, CO
>
>

--
Camm Maguire [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

2001-02-28 15:35:12

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

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

2001-03-01 19:02:58

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

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
[email protected] Fort Collins, CO

2001-03-07 00:38:13

by Chip Salzenberg

[permalink] [raw]

Subject: Re: [PATCH] 2.2.18 IDE tape problem, with ide-scsi

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. - <[email protected]>
"We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech

2001-03-07 01:10:56

[permalink] [raw]

Subject: Re: [PATCH] 2.2.18 IDE tape problem, with ide-scsi

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. - <[email protected]>
> "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 [email protected]
> 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: http://www.aslab.com

2001-03-07 22:55:38

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

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 <[email protected]> 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
> [email protected] Fort Collins, CO
>
>

--
Camm Maguire [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

2001-03-13 14:17:28

[permalink] [raw]

Subject: Re: 2.2.18 IDE tape problem, with ide-scsi

Thank you again, so much!

Take care,

Khalid Aziz <[email protected]> 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
> [email protected] Fort Collins, CO
>
>

--
Camm Maguire [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

2001-03-12 16:53:21