From: "Albert Lee" <albertcc@tw.ibm.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: IDE Linux <linux-ide@vger.kernel.org>, Doug Maxey <dwm@maxeymade.com>
Subject: [PATCH] libata: Use ATAPI PIO mode for specific request buffer sizes
Date: Tue, 30 Nov 2004 16:44:31 +0800 [thread overview]
Message-ID: <00ce01c4d6b8$d222d080$bc604109@tw.ibm.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 5783 bytes --]
Hi, Jeff:
After some testing, it seems that some PATA host adapter (ex. pdc20275) cannot
work reliably with specific request buffer sizes under ATAPI DMA mode.
Detailed test result:
4096, 2048, 1024, 512, 256: OK
384, 257, 255, 128, 96, 64, 32: failed (irq lost)
It seems multiple of 256 bytes are the safe ATAPI DMA buffer sizes to use.
Attached please find the patch against libata-dev-2.6 for your review.
Two changes:
1. Use ATAPI PIO mode for ATAPI REQUEST_SENSE
2. Use ATAPI PIO mode for specific SCSI commands issued to ATAPI device that
buffer_size % 256 != 0.
Since for most commands, buffer_size % 256 is 0, this patch
won't introduce big impact to the performance of libata (hopefully).
Tested OK on on my machine with pdc20275 and ASUS CD-RW drive.
Albert
Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
---------------------------------------------------------------------
diff -Nru libata-dev-2.6-ori/drivers/scsi/libata-core.c libata-dev-2.6/drivers/scsi/libata-core.c
--- libata-dev-2.6-ori/drivers/scsi/libata-core.c 2004-11-30 12:52:28.000000000 +0800
+++ libata-dev-2.6/drivers/scsi/libata-core.c 2004-11-30 13:49:36.000000000 +0800
@@ -2435,7 +2435,6 @@
DECLARE_COMPLETION(wait);
struct ata_queued_cmd *qc;
unsigned long flags;
- int using_pio = dev->flags & ATA_DFLAG_PIO;
int rc;
DPRINTK("ATAPI request sense\n");
@@ -2456,16 +2455,10 @@
qc->tf.flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE;
qc->tf.command = ATA_CMD_PACKET;
- if (using_pio) {
- qc->tf.protocol = ATA_PROT_ATAPI;
- qc->tf.lbam = (8 * 1024) & 0xff;
- qc->tf.lbah = (8 * 1024) >> 8;
-
- qc->nbytes = SCSI_SENSE_BUFFERSIZE;
- } else {
- qc->tf.protocol = ATA_PROT_ATAPI_DMA;
- qc->tf.feature |= ATAPI_PKT_DMA;
- }
+ qc->tf.protocol = ATA_PROT_ATAPI;
+ qc->tf.lbam = (8 * 1024) & 0xff;
+ qc->tf.lbah = (8 * 1024) >> 8;
+ qc->nbytes = SCSI_SENSE_BUFFERSIZE;
qc->waiting = &wait;
qc->complete_fn = ata_qc_complete_noop;
diff -Nru libata-dev-2.6-ori/drivers/scsi/libata-scsi.c libata-dev-2.6/drivers/scsi/libata-scsi.c
--- libata-dev-2.6-ori/drivers/scsi/libata-scsi.c 2004-11-30 12:52:28.000000000 +0800
+++ libata-dev-2.6/drivers/scsi/libata-scsi.c 2004-11-30 15:37:38.584941309 +0800
@@ -1558,6 +1558,10 @@
int using_pio = (dev->flags & ATA_DFLAG_PIO);
int nodata = (cmd->sc_data_direction == SCSI_DATA_NONE);
+ /* Use ATAPI PIO for specific buffer sizes */
+ if (cmd->request_bufflen % 256)
+ using_pio = 1;
+
memcpy(&qc->cdb, scsicmd, qc->ap->cdb_len);
qc->complete_fn = atapi_qc_complete;
----- Original Message -----
From: "Albert Lee" <albertcc@tw.ibm.com>
To: "Bartlomiej Zolnierkiewicz" <bzolnier@gmail.com>; "Jeff Garzik" <jgarzik@pobox.com>
Cc: "Doug Maxey" <dwm@maxeymade.com>; "IDE Linux" <linux-ide@vger.kernel.org>
Sent: Tuesday, November 16, 2004 5:03 PM
Subject: libata-dev-2.6 ATAPI interrupt lost problem with pdc2027x under UDMA mode
> Hi,
> I am testing ATAPI device with libata-dev.2.6 code and the pdc2027x driver.
>
> Environment:
> - pdc20275 on the MSI P4HS-4 mainboard
> - Maxtor 6Y080L0 as primary dev0
> - Seagate ST380011A as primary dev1
> - Asus CRW-5232AS as secondard dev0
>
> The following are the results:
>
> 1. All the harddisk drives works fine with either PIO or DMA
> 2. For the ATAPI device, READ and other commands works fine with ATAPI UDMA protocol.
> However, when REQUEST_SENSE / MODE_SENSE is issued to the CD-RW drive with
> ATAPI DMA protocol, the interrupt is lost.
> 3. All commands, including REQUEST_SENSE/MODE_SENSE, work fine with ATAPI PIO protocol.
> 4. PIIX and the same Asus drive work fine, both UDMA and PIO.
>
> For the problem of lost interrupt, I've checked the pdc2027x global control register (which shows
> the status of INTRQ and DMARQ directly), the Asus drive already report INTRQ and
> said UDMA completed. However, pdc20275 does not report interrupt and said DMA on going.
>
> Any clue or idea for this problem? Thanks.
> Albert
> =============================================================
> (dmesg log attached)
> ata_scsi_dump_cdb: CDB (2:0,0,0) 12 00 00 00 60 00 20 00 00
> atapi_xlat: nodata[0]
> ata_sg_setup_one: mapped buffer of 96 bytes for read
> ata_exec_command_pio: ata2: cmd 0xA0
> atapi_packet_task: busy wait
> atapi_packet_task: send cdb
> ata_host_intr: ata2: protocol 7 (dev_stat 0x50) => "inquiry" is successful
> ata_sg_clean: unmapping 1 sg elements
> Vendor: ASUS Model: CRW-5232AS Rev: 1.02
> Type: CD-ROM ANSI SCSI revision: 05
> ata_scsi_dump_cdb: CDB (2:0,0,0) 00 00 00 00 00 00 00 00 00
> ata_exec_command_pio: ata2: cmd 0xA0
> atapi_packet_task: busy wait
> atapi_packet_task: send cdb
> ata_host_intr: ata2: protocol 6 (dev_stat 0x50) => "test unit ready" is successful
> ata_scsi_dump_cdb: CDB (2:0,0,0) 5a 00 2a 00 00 00 00 00 80 => "mode sense" fails
> atapi_xlat: nodata[0]
> ata_sg_setup_one: mapped buffer of 128 bytes for read
> ata_exec_command_pio: ata2: cmd 0xA0
> atapi_packet_task: busy wait
> atapi_packet_task: send cdb
> ata_scsi_error: ENTER => Promise pdc2027x timeout here. Interrupt lost. (PIIX works.)
> ata_eng_timeout: ENTER
> ata_qc_timeout: ENTER
> ata2: command 0xa0 timeout, stat 0x50 host_stat 0x1 => Device: OK, host: DMA on going.
> ata_sg_clean: unmapping 1 sg elements
> ata_qc_timeout: EXIT
> ata_eng_timeout: EXIT
> ata_scsi_error: EXIT
> sr0: scsi3-mmc drive: 0x/0x caddy
> => should be sr0: scsi3-mmc drive: 52x/52x writer cd/rw xa/form2 cdda tray
> Uniform CD-ROM driver Revision: 3.20
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: atapi_dma.patch --]
[-- Type: application/octet-stream, Size: 1679 bytes --]
diff -Nru libata-dev-2.6-ori/drivers/scsi/libata-core.c libata-dev-2.6/drivers/scsi/libata-core.c
--- libata-dev-2.6-ori/drivers/scsi/libata-core.c 2004-11-30 12:52:28.000000000 +0800
+++ libata-dev-2.6/drivers/scsi/libata-core.c 2004-11-30 13:49:36.000000000 +0800
@@ -2435,7 +2435,6 @@
DECLARE_COMPLETION(wait);
struct ata_queued_cmd *qc;
unsigned long flags;
- int using_pio = dev->flags & ATA_DFLAG_PIO;
int rc;
DPRINTK("ATAPI request sense\n");
@@ -2456,16 +2455,10 @@
qc->tf.flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE;
qc->tf.command = ATA_CMD_PACKET;
- if (using_pio) {
- qc->tf.protocol = ATA_PROT_ATAPI;
- qc->tf.lbam = (8 * 1024) & 0xff;
- qc->tf.lbah = (8 * 1024) >> 8;
-
- qc->nbytes = SCSI_SENSE_BUFFERSIZE;
- } else {
- qc->tf.protocol = ATA_PROT_ATAPI_DMA;
- qc->tf.feature |= ATAPI_PKT_DMA;
- }
+ qc->tf.protocol = ATA_PROT_ATAPI;
+ qc->tf.lbam = (8 * 1024) & 0xff;
+ qc->tf.lbah = (8 * 1024) >> 8;
+ qc->nbytes = SCSI_SENSE_BUFFERSIZE;
qc->waiting = &wait;
qc->complete_fn = ata_qc_complete_noop;
diff -Nru libata-dev-2.6-ori/drivers/scsi/libata-scsi.c libata-dev-2.6/drivers/scsi/libata-scsi.c
--- libata-dev-2.6-ori/drivers/scsi/libata-scsi.c 2004-11-30 12:52:28.000000000 +0800
+++ libata-dev-2.6/drivers/scsi/libata-scsi.c 2004-11-30 15:37:38.584941309 +0800
@@ -1558,6 +1558,10 @@
int using_pio = (dev->flags & ATA_DFLAG_PIO);
int nodata = (cmd->sc_data_direction == SCSI_DATA_NONE);
+ /* Use ATAPI PIO for specific buffer sizes */
+ if (cmd->request_bufflen % 256)
+ using_pio = 1;
+
memcpy(&qc->cdb, scsicmd, qc->ap->cdb_len);
qc->complete_fn = atapi_qc_complete;
next reply other threads:[~2004-11-30 8:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-30 8:44 Albert Lee [this message]
2004-12-02 11:21 ` [PATCH] libata: Use ATAPI PIO mode for specific request buffer sizes Jeff Garzik
2004-12-03 7:18 ` Albert Lee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='00ce01c4d6b8$d222d080$bc604109@tw.ibm.com' \
--to=albertcc@tw.ibm.com \
--cc=dwm@maxeymade.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).