https://bugzilla.redhat.com/show_bug.cgi?id=243568
Using kernel 2.6.22:
Aug 29 17:08:11 itox kernel: ata2.00: ATAPI: Seagate STT8000A, 5.51, max MWDMA2
Aug 29 17:08:11 itox kernel: ata2.00: configured for MWDMA2
Aug 29 17:08:11 itox kernel: scsi 1:0:0:0: Sequential-Access Seagate STT8000A
On Wed, 29 Aug 2007 18:55:55 -0400
Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=243568
>
> Using kernel 2.6.22:
>
> Aug 29 17:08:11 itox kernel: ata2.00: ATAPI: Seagate STT8000A, 5.51, max
> MWDMA2
> Aug 29 17:08:11 itox kernel: ata2.00: configured for M
Chuck Ebbert wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=243568
Using kernel 2.6.22:
Aug 29 17:08:11 itox kernel: ata2.00: ATAPI: Seagate STT8000A, 5.51, max MWDMA2
Aug 29 17:08:11 itox kernel: ata2.00: configured for MWDMA2
Aug 29 17:08:11 itox kernel: scsi 1:0:0:0: Sequential-Access Se
On 08/29/2007 07:50 PM, Alan Cox wrote:
>
> Device Ready, Seek Complete, Data Request, Error
>
> DRQ and Error together is a bit odd to say the least
>
> It then commits suicide and falls off the bus. That may be due to the
> fact we use SRST on ATAPI device errors still rather than trying an AT
On Thu, 30 Aug 2007 12:11:39 -0400
Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> On 08/29/2007 07:50 PM, Alan Cox wrote:
> >
> > Device Ready, Seek Complete, Data Request, Error
> >
> > DRQ and Error together is a bit odd to say the least
> >
> > It then commits suicide and falls off the bus. That
Alan Cox wrote:
On Thu, 30 Aug 2007 12:11:39 -0400
Chuck Ebbert <[EMAIL PROTECTED]> wrote:
On 08/29/2007 07:50 PM, Alan Cox wrote:
Device Ready, Seek Complete, Data Request, Error
DRQ and Error together is a bit odd to say the least
It then commits suicide and falls off the bus. That may be
I added code in libata-core.c at ata_qc_issue & ata_qc_issue_prot
which dumps qc->cdb if protocol is ATAPI:
14:10:48 root: writing to the tape next
14:11:01 kernel: qc_issue: CDB 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
14:11:01 kernel: qc_issue_prot: CDB 00 00 00 00 00 00 00 00 00 0
14:10:48 root: writing to the tape next
14:11:01 kernel: qc_issue: CDB 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
14:11:01 kernel: qc_issue_prot: CDB 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
14:11:01 kernel: qc_issue: CDB 03 00 00 00 60 00 00 00 00 00 00 00 00 00
00 00
14:
14:26:48 root: writing
14:26:54 kernel: qc_issue: CDB 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
14:26:54 kernel: qc_issue_prot: CDB 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
14:26:54 kernel: qc_issue: CDB 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
14:26:54 kernel: qc_issue_prot
14:26:48 root: writing
14:26:54 kernel: qc_issue: CDB 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
14:26:54 kernel: qc_issue_prot: CDB 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
14:26:54 kernel: qc_issue: CDB 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
14:26:54 kernel: qc_issue_prot
> I can read and write the tape successfully, and the written data matches
> what is later read back from it.
>
> Here's the hack I used. Not ready for mainline, but perhaps it will
> help Alan or whomever come up with something nice for Jeff.
Its possible we should just scream and shout but fo
Mark Lord wrote:
>
> I can read and write the tape successfully, and the written data matches
> what is later read back from it.
>
> Here's the hack I used. Not ready for mainline, but perhaps it will
> help Alan or whomever come up with something nice for Jeff.
>
> --- 2.6.23-rc6/drivers/ata/l
Alan Cox wrote:
I can read and write the tape successfully, and the written data matches
what is later read back from it.
Here's the hack I used. Not ready for mainline, but perhaps it will
help Alan or whomever come up with something nice for Jeff.
Its possible we should just scream and shou
13 matches
Mail list logo