Re: [PATCH 8/9] ide: switch to DMA-mapping API
On Dec 28, 2007 3:12 AM, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> * pci_map_sg() -> dma_map_sg() in ide_build_sglist().
>
> * pci_unmap_sg() -> dma_unmap_sg() in ide_destroy_dmatable().
>
> There should be no functionality changes caused by this patch except
> for blackfin arch whose dma_[un]map_sg() implementation differs from
> pci_[un]map_sg() one (on s390 arch there is no PCI, on avr32 and h8300
> archs PCI is currently unsupported, on m32r arch PCI support depends
> on BROKEN, on m68k arch PCI support depends on HADES which in turn
> depends on BROKEN, on all other archs dma_[un]map_sg() functionality
> matches with pci_[un]map_sg() one).
>
Thanks a lot for this carefully check with Blackfin.
Please go ahead with this patch change, we plan to remove PCI useless
header file in Blackfin like AVR32
-Bryan
> Cc: Bryan Wu <[EMAIL PROTECTED]>
> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> ---
> It seems like blackfin arch should be using
> in or drivers still using PCI DMA-mapping API instead
> of the generic one won't work but I'll leave this to blackfin gurus...
>
> [ Bryan, could you please take a look? Thanks. ]
>
> drivers/ide/ide-dma.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> Index: b/drivers/ide/ide-dma.c
> ===
> --- a/drivers/ide/ide-dma.c
> +++ b/drivers/ide/ide-dma.c
> @@ -85,6 +85,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -175,26 +176,26 @@ static int ide_dma_good_drive(ide_drive_
> * @drive: the drive to build the DMA table for
> * @rq: the request holding the sg list
> *
> - * Perform the PCI mapping magic necessary to access the source or
> - * target buffers of a request via PCI DMA. The lower layers of the
> + * Perform the DMA mapping magic necessary to access the source or
> + * target buffers of a request via DMA. The lower layers of the
> * kernel provide the necessary cache management so that we can
> - * operate in a portable fashion
> + * operate in a portable fashion.
> */
>
> int ide_build_sglist(ide_drive_t *drive, struct request *rq)
> {
> ide_hwif_t *hwif = HWIF(drive);
> - struct pci_dev *pdev = to_pci_dev(hwif->dev);
> struct scatterlist *sg = hwif->sg_table;
>
> ide_map_sg(drive, rq);
>
> if (rq_data_dir(rq) == READ)
> - hwif->sg_dma_direction = PCI_DMA_FROMDEVICE;
> + hwif->sg_dma_direction = DMA_FROM_DEVICE;
> else
> - hwif->sg_dma_direction = PCI_DMA_TODEVICE;
> + hwif->sg_dma_direction = DMA_TO_DEVICE;
>
> - return pci_map_sg(pdev, sg, hwif->sg_nents, hwif->sg_dma_direction);
> + return dma_map_sg(hwif->dev, sg, hwif->sg_nents,
> + hwif->sg_dma_direction);
> }
>
> EXPORT_SYMBOL_GPL(ide_build_sglist);
> @@ -308,9 +309,8 @@ EXPORT_SYMBOL_GPL(ide_build_dmatable);
> void ide_destroy_dmatable (ide_drive_t *drive)
> {
> ide_hwif_t *hwif = drive->hwif;
> - struct pci_dev *pdev = to_pci_dev(hwif->dev);
>
> - pci_unmap_sg(pdev, hwif->sg_table, hwif->sg_nents,
> + dma_unmap_sg(hwif->dev, hwif->sg_table, hwif->sg_nents,
> hwif->sg_dma_direction);
> }
>
> --
> 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/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ide-floppy redux p1
Hi Bart, here's the unfinished redux of ide-floppy which i'm sending now so that we could sinchronize trees. There are some things left to be done which are not so trivial and i'd like to give them a bit more thought :). drivers/ide/ide-floppy.c | 1248 +++--- drivers/ide/ide-floppy.h | 351 ++ include/linux/cdrom.h|1 + 4 files changed, 819 insertions(+), 845 deletions(-) -- Regards/Gruß, Boris. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
commit a258f183ee4e48e9352b408e8448467eebdc6cd2
Happy new year, Jeff, Alan. I'm curious why commit a258f183 got in? We already deal with this problem by executing SETXFER by polling. That's better IMHO for two reasons - no clutter in hot path && applies to drivers which use custom interrupt handlers. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ide-floppy redux p1
On Wed, Jan 02, 2008 at 10:25:05AM +0100, Borislav Petkov wrote: by the way, i messed up the numbering of the patches: their correct count is not 12 but 10 so you shouldn't be missing any even if it seems so at a first glance. -- Regards/Gruß, Boris. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sil4723 on ata2 - ICH7 - Timeouts - Suspend to RAM
Hello, This mail to confirm that the sil4723 sata "bridge" using 2.6.24-rc6 now: - has no timeouts anymore on boot & on first suspend - support a suspend to ram sleeping mode Wed, 2008-01-02 at 16:59 +0900, Tejun Heo wrote: > Jean-Yves Simon wrote: > > Hello Tejun, > > > > First of all, happy new year 2008 ;) > > > > I don't know if i should bother you with this, just an update on how > > well/bad the sil4723 works with fedora 8 (kernel 2.6.23.9-85 ) > > > > boot time: no timeouts anymore, > > but the device doesn't support the suspend to ram sleeping mode at all > > now > > > > > > I have no device connected through the port multiplier, so can't say if > > the basic functionnality works at all > > > > > > Can you help me to dig this out & fix it? Maybe the vanilla 2.6.3-12 > > could fix this? > > > > Can you please give a shot at 2.6.24-rc6? It's rc but should be ripe > enough for production use. > > Thanks. > -- Jean-Yves Simon <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sil4723 on ata2 - ICH7 - Timeouts - Suspend to RAM
Jean-Yves Simon wrote: > This mail to confirm that the sil4723 sata "bridge" using 2.6.24-rc6 > now: > - has no timeouts anymore on boot & on first suspend > - support a suspend to ram sleeping mode Note: This is about the dreaded ASUS P5W-DH w/ on board PMP, which wasn't fixed by PMP support but by adding a whole lot of ugly quirks to work around dumbass single disk emulation mode of the 4723. Anyways, it's good to hear all that ugliness does some good. :-) -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] sata_qstor: convert to new data_xfer prototype
While merging data_xfer prototype change, pata_pcmcia was left out.
Convert it.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/pata_pcmcia.c | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/ata/pata_pcmcia.c b/drivers/ata/pata_pcmcia.c
index ceba93b..3e7f6a9 100644
--- a/drivers/ata/pata_pcmcia.c
+++ b/drivers/ata/pata_pcmcia.c
@@ -102,10 +102,10 @@ static int pcmcia_set_mode_8bit(struct ata_link *link,
/**
* ata_data_xfer_8bit - Transfer data by 8bit PIO
- * @adev: device to target
+ * @dev: device to target
* @buf: data buffer
* @buflen: buffer length
- * @write_data: read/write
+ * @rw: read/write
*
* Transfer data from/to the device data register by 8 bit PIO.
*
@@ -113,14 +113,17 @@ static int pcmcia_set_mode_8bit(struct ata_link *link,
* Inherited from caller.
*/
-static void ata_data_xfer_8bit(struct ata_device *adev, unsigned char *buf,
- unsigned int buflen, int write_data)
+static unsigned int ata_data_xfer_8bit(struct ata_device *dev,
+ unsigned char *buf, unsigned int buflen, int rw)
{
- struct ata_port *ap = adev->link->ap;
- if (write_data)
- iowrite8_rep(ap->ioaddr.data_addr, buf, buflen);
- else
+ struct ata_port *ap = dev->link->ap;
+
+ if (rw == READ)
ioread8_rep(ap->ioaddr.data_addr, buf, buflen);
+ else
+ iowrite8_rep(ap->ioaddr.data_addr, buf, buflen);
+
+ return buflen;
}
--
1.5.2.4
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] libata: update ATAPI overflow draining
For misc ATAPI commands which transfer variable length data to the
host, overflow can occur due to application or hardware bug. Such
overflows can be ignored safely as long as overflow data is properly
drained. libata HSM implementation has this implemented in
__atapi_pio_bytes() and recently updated for 2.6.24-rc but it requires
further improvements. Improve drain logic such that...
* Report overflow errors using ehi desc mechanism instead of printing
directly.
* Properly calculate the number of bytes to be drained considering
actual number of consumed bytes for partial draining.
* Add and use ata_drain_page for draining. This change fixes the
problem where LLDs which do 32bit IOs consumes 4 bytes on each 2
byte draining resulting in draining twice more data than requested.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Acked-by: Albert Lee <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c | 104 +++--
1 files changed, 53 insertions(+), 51 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 9d040a3..3dbac19 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -84,8 +84,8 @@ static unsigned long ata_dev_blacklisted(const struct
ata_device *dev);
unsigned int ata_print_id = 1;
static struct workqueue_struct *ata_wq;
-
struct workqueue_struct *ata_aux_wq;
+static void *ata_drain_page;
int atapi_enabled = 1;
module_param(atapi_enabled, int, 0444);
@@ -4658,24 +4658,9 @@ int ata_check_atapi_dma(struct ata_queued_cmd *qc)
*/
static int atapi_qc_may_overflow(struct ata_queued_cmd *qc)
{
- if (qc->tf.protocol != ATAPI_PROT_PIO &&
- qc->tf.protocol != ATAPI_PROT_DMA)
- return 0;
-
- if (qc->tf.flags & ATA_TFLAG_WRITE)
- return 0;
-
- switch (qc->cdb[0]) {
- case READ_10:
- case READ_12:
- case WRITE_10:
- case WRITE_12:
- case GPCMD_READ_CD:
- case GPCMD_READ_CD_MSF:
- return 0;
- }
-
- return 1;
+ return ata_is_atapi(qc->tf.protocol) && ata_is_data(qc->tf.protocol) &&
+ atapi_cmd_type(qc->cdb[0]) == ATAPI_MISC &&
+ !(qc->tf.flags & ATA_TFLAG_WRITE);
}
/**
@@ -5129,13 +5114,14 @@ static void atapi_send_cdb(struct ata_port *ap, struct
ata_queued_cmd *qc)
*/
static int __atapi_pio_bytes(struct ata_queued_cmd *qc, unsigned int bytes)
{
- int do_write = (qc->tf.flags & ATA_TFLAG_WRITE);
+ int rw = (qc->tf.flags & ATA_TFLAG_WRITE) ? WRITE : READ;
struct ata_port *ap = qc->ap;
- struct ata_eh_info *ehi = &qc->dev->link->eh_info;
+ struct ata_device *dev = qc->dev;
+ struct ata_eh_info *ehi = &dev->link->eh_info;
struct scatterlist *sg;
struct page *page;
unsigned char *buf;
- unsigned int offset, count;
+ unsigned int offset, count, consumed;
next_sg:
sg = qc->cursg;
@@ -5147,27 +5133,29 @@ next_sg:
*- for read case, discard trailing data from the device
*- for write case, padding zero data to the device
*/
- u16 pad_buf[1] = { 0 };
- unsigned int i;
-
- if (bytes > qc->curbytes - qc->nbytes + ATAPI_MAX_DRAIN) {
+ if (qc->curbytes + bytes > qc->nbytes + ATAPI_MAX_DRAIN) {
ata_ehi_push_desc(ehi, "too much trailing data "
"buf=%u cur=%u bytes=%u",
qc->nbytes, qc->curbytes, bytes);
return -1;
}
-/* overflow is exptected for misc ATAPI commands */
- if (bytes && !atapi_qc_may_overflow(qc))
- ata_dev_printk(qc->dev, KERN_WARNING, "ATAPI %u bytes "
- "trailing data (cdb=%02x nbytes=%u)\n",
- bytes, qc->cdb[0], qc->nbytes);
+ /* allow overflow only for misc ATAPI commands */
+ if (!atapi_qc_may_overflow(qc)) {
+ ata_ehi_push_desc(ehi, "unexpected trailing data "
+ "%u bytes", bytes);
+ return -1;
+ }
- for (i = 0; i < (bytes + 1) / 2; i++)
- ap->ops->data_xfer(qc->dev, (unsigned char *)pad_buf,
2, do_write);
+ consumed = 0;
+ while (consumed < bytes) {
+ count = min_t(unsigned int,
+ bytes - consumed, PAGE_SIZE);
+ consumed += ap->ops->data_xfer(dev, ata_drain_page,
+ count, rw);
+ }
qc->curbytes += bytes;
-
return 0;
}
@@ -5194,18 +5182,16 @@ next_sg:
buf = kmap_atomic(page, KM_IRQ0);
[PATCHSET #upstream] libata: improve ATAPI data transfer handling, take #4
Hello, This is the fourth take of improve-ATAPI-data-transfer patchset. Changes from the last take [L] are * Patches other than 8, 13, 14 and 15 have been committed to #upstream and thus dropped from this patchset. * Due to merge order, pata_pcmcia is now out-of-sync with data_xfer prototype update. A patch was added to convert pata_pcmcia. * Patch 13, 14 and 15 are updated to apply on top of the current #upstream. This patchset is agaisnt the current #upstream (32a03e13). Thanks. -- tejun [L] http://thread.gmane.org/gmane.linux.ide/25938 - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] libata: implement ATAPI per-command-type DMA horkages
ATAPI DMA is filled with mines. Sector aligned READ transfers usually
work but many other commands transfer non-sector aligned or variable
number of bytes, and there are devices and controllers which have
problems dealing with such non-aligned DMA transactions.
This patch implement ATAPI per-command-type DMA horkages and EH logic
to set those quickly. This way, failures localized to certain command
type don't affect other operations (most importantly READs) and
working configuration is found quickly such that the device can be
used.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c | 21 +
drivers/ata/libata-eh.c | 35 +++
include/linux/libata.h|4
3 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index d763c07..32dde5b 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4628,6 +4628,27 @@ static void ata_fill_sg_dumb(struct ata_queued_cmd *qc)
int ata_check_atapi_dma(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc->ap;
+ unsigned int horkage = qc->dev->horkage;
+
+ switch (atapi_cmd_type(qc->cdb[0])) {
+ case ATAPI_READ:
+ break;
+
+ case ATAPI_WRITE:
+ if (horkage & ATAPI_DMA_HORKAGE_WRITE)
+ return 1;
+ break;
+
+ case ATAPI_READ_CD:
+ if (horkage & ATAPI_DMA_HORKAGE_READ_CD)
+ return 1;
+ break;
+
+ case ATAPI_MISC:
+ if (horkage & ATAPI_DMA_HORKAGE_MISC)
+ return 1;
+ break;
+ }
/* Don't allow DMA if it isn't multiple of 16 bytes. Quite a
* few ATAPI devices choke on such DMA requests.
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index e93dde1..4399e9e 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -1490,6 +1490,38 @@ static unsigned int ata_eh_analyze_tf(struct
ata_queued_cmd *qc,
return action;
}
+static void atapi_eh_dma_horkages(struct ata_queued_cmd *qc)
+{
+ struct ata_device *dev = qc->dev;
+ const char *type;
+
+ if (!ata_is_atapi(qc->tf.protocol) || !ata_is_dma(qc->tf.protocol) ||
+ !(qc->err_mask & (AC_ERR_HSM | AC_ERR_TIMEOUT)))
+ return;
+
+ switch (atapi_cmd_type(qc->cdb[0])) {
+ case ATAPI_WRITE:
+ type = "WRITE";
+ dev->horkage |= ATAPI_DMA_HORKAGE_WRITE;
+ break;
+ case ATAPI_READ_CD:
+ type = "READ CD [MSF]";
+ dev->horkage |= ATAPI_DMA_HORKAGE_READ_CD;
+ break;
+ case ATAPI_MISC:
+ type = "MISC";
+ dev->horkage |= ATAPI_DMA_HORKAGE_MISC;
+ break;
+ default:
+ return;
+ }
+
+ ata_dev_printk(dev, KERN_WARNING, "ATAPI DMA for %s disabled (0x%x). \n"
+ " If this continues to happen, please report to\n"
+ " [EMAIL PROTECTED]",
+ type, dev->horkage);
+}
+
static int ata_eh_categorize_error(unsigned int eflags, unsigned int err_mask,
int *xfer_ok)
{
@@ -1810,6 +1842,9 @@ static void ata_eh_link_autopsy(struct ata_link *link)
all_err_mask |= qc->err_mask;
if (qc->flags & ATA_QCFLAG_IO)
eflags |= ATA_EFLAG_IS_IO;
+
+ /* handle ATAPI DMA horkages */
+ atapi_eh_dma_horkages(qc);
}
/* enforce default EH actions */
diff --git a/include/linux/libata.h b/include/linux/libata.h
index 9fa49e9..1601bbd 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -341,6 +341,10 @@ enum {
ATA_HORKAGE_IVB = (1 << 8), /* cbl det validity bit bugs */
ATA_HORKAGE_STUCK_ERR = (1 << 9), /* stuck ERR on next PACKET */
+ ATAPI_DMA_HORKAGE_WRITE = (1 << 29), /* PIO for WRITEs */
+ ATAPI_DMA_HORKAGE_READ_CD = (1 << 30), /* PIO for READ_CDs */
+ ATAPI_DMA_HORKAGE_MISC = (1 << 31), /* PIO for MISC commands */
+
/* DMA mask for user DMA control: User visible values; DO NOT
renumber */
ATA_DMA_MASK_ATA= (1 << 0), /* DMA on ATA Disk */
--
1.5.2.4
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] libata: implement ATAPI drain buffer
Misc ATAPI commands may try to transfer more bytes than requested.
For PIO which is performed by libata HSM, this is worked around by
draining extra bytes from __atapi_pio_bytes().
This patch implements drain buffer to perform draining for DMA and
PIO-over-DMA cases. One page is allocated w/ GFP_DMA32 during libata
core layer initialization. On host registration, this drain page is
DMA mapped and ATAPI_MAX_DRAIN_PAGES sg entries are reserved.
ata_sg_setup_extra() uses these extra sg entries to map the drain page
ATAPI_MAX_DRAIN_PAGES times, extending sg list by ATAPI_MAX_DRAIN
bytes. This allows both DMA and PIO-over-DMA misc ATAPI commands to
overflow by ATAPI_MAX_DRAIN bytes just like PIO commands.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c | 116 -
drivers/ata/libata-scsi.c | 14 --
include/linux/libata.h|4 +-
3 files changed, 116 insertions(+), 18 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 3dbac19..d763c07 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4750,6 +4750,60 @@ void ata_sg_init(struct ata_queued_cmd *qc, struct
scatterlist *sg,
qc->cursg = qc->sg;
}
+/**
+ * ata_sg_setup_extra - Setup extra sg entries
+ * @qc: Command to setup extra sg entries for
+ * @n_elem_extra: Out parameter for the number of extra sg entries
+ * @nbytes_extra: Out parameter for the number of extra bytes
+ *
+ * Extra sg entries are used to deal with ATAPI peculiarities.
+ * First, the content to be transferred can be of any size but
+ * transfer length should be aligned to 4 bytes, so if data size
+ * isn't aligned, it needs to be padded.
+ *
+ * Second, for commands whose repsonse can be variable, due to
+ * userland bugs (more likely) and hardware bugs, devices can try
+ * to transfer more bytes than requested. This can be worked
+ * around by appending drain buffers at the end.
+ *
+ * This function sets up both padding and draining sg entries.
+ * For this purpose, each qc has 2 + ATAPI_MAX_DRAIN_PAGES extra
+ * sg entries. Each extra sg has assigned function.
+ *
+ *e[0] | e[1] | e[2] | ... | e[2 + ATAPI_MAX_DRAIN_PAGES - 1]
+ * --
+ *link | padding | draining ...
+ *or link
+ *
+ * After sg setup is complete, sg list looks like the following.
+ *
+ * 1. Padding necessary, padding doesn't replace the last sg
+ *
+ * o[0][1][2]...[last] e[0][1]([2]... if draining is necessary)
+ *|^
+ * \--/
+ *e[0] carries the original content of o[last].
+ *
+ * 2. Padding necessary, padding replaces the last sg
+ *
+ * o[0][1][2]...[last] e[0][1]([2]... if draining is necessary)
+ *| ^
+ * \-/
+ *e[1] completely includes what o[last] used to point to.
+ *
+ * 3. Only draining is necessary.
+ *
+ * [0][1][2]...[last] e[0][1][2]...
+ * | ^
+ * \-/
+ *e[1] carries the original conetent of o[last].
+ *
+ * LOCKING:
+ * spin_lock_irqsave(host lock)
+ *
+ * RETURNS:
+ * Adjusted n_elem which should be mapped.
+ */
static unsigned int ata_sg_setup_extra(struct ata_queued_cmd *qc,
unsigned int *n_elem_extra,
unsigned int *nbytes_extra)
@@ -4757,6 +4811,7 @@ static unsigned int ata_sg_setup_extra(struct
ata_queued_cmd *qc,
struct ata_port *ap = qc->ap;
unsigned int n_elem = qc->n_elem;
struct scatterlist *lsg, *copy_lsg = NULL, *tsg = NULL, *esg = NULL;
+ int drain;
*n_elem_extra = 0;
*nbytes_extra = 0;
@@ -4764,7 +4819,10 @@ static unsigned int ata_sg_setup_extra(struct
ata_queued_cmd *qc,
/* needs padding? */
qc->pad_len = qc->nbytes & 3;
- if (likely(!qc->pad_len))
+ /* needs drain? */
+ drain = atapi_qc_may_overflow(qc);
+
+ if (likely(!qc->pad_len && !drain))
return n_elem;
/* locate last sg and save it */
@@ -4826,6 +4884,29 @@ static unsigned int ata_sg_setup_extra(struct
ata_queued_cmd *qc,
(*nbytes_extra) += 4 - qc->pad_len;
}
+ if (drain) {
+ struct scatterlist *dsg = qc->extra_sg + 2;
+ int i;
+
+ for (i = 0; i < ATAPI_MAX_DRAIN_PAGES; i++) {
+ sg_set_page(dsg, virt_to_page(ata_drain_page),
+ PAGE_SIZE, 0);
+ sg_dma_address(dsg) = ap->host->drain_page_dma;
+ sg_dma_len(dsg) = PAGE_SIZE;
+ dsg++;
+ }
+
+ if (!tsg) {
+
PIIX driver
Hello For specific reason I need to install old FC4 ( kernel 2.6.11 ) to new hardware ( Intel DP35DP motherboard ). Installation failed and the reason I think is that FC4 ata-piix driver don't have ICH9 support. Is it possible to port new ata-piix driver ( from kernel 2.6.23 ) to old kernel. I had a look at the sources and the task seems difficult because changes from ver. 1.03 to 2.12 are signifficant. Or you can suggest some other solution to that problem. Kalev - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PIIX driver
Kalev Toots writes: > Hello > > For specific reason I need to install old FC4 ( kernel 2.6.11 ) to new > hardware ( Intel DP35DP motherboard ). > Installation failed and the reason I think is that FC4 ata-piix driver > don't have ICH9 support. > Is it possible to port new ata-piix driver ( from kernel 2.6.23 ) to > old kernel. Sounds like you're running the chip in compatibility mode. Maybe flip BIOS settings to AHCI mode and let FC4's kernel use its ahci driver instead? Backporting the entire driver would be painful. Perhaps adding some PCI IDs suffices? (I have no idea how much ICH9 differs from whatever FC4 supports.) I don't know if you need FC4 kernel or FC4 user-space, but one option is to install on an older supported machine, move the disk to the new one, and then boot a custom kernel. Finally you can buy a PCI PATA, SATA, or SCSI controller card supported by FC4 and forget about the mainboard's ICH9. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] libata: implement ATAPI per-command-type DMA horkages
> This patch implement ATAPI per-command-type DMA horkages and EH logic > to set those quickly. This way, failures localized to certain command > type don't affect other operations (most importantly READs) and > working configuration is found quickly such that the device can be > used. Seems sensible to treat them differently for different controllers. Have you considered re-issuing failing ATAPI DMA commands as PIO as an EH response ? - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] libata: implement ATAPI per-command-type DMA horkages
Alan Cox wrote: >> This patch implement ATAPI per-command-type DMA horkages and EH logic >> to set those quickly. This way, failures localized to certain command >> type don't affect other operations (most importantly READs) and >> working configuration is found quickly such that the device can be >> used. > > Seems sensible to treat them differently for different controllers. Have > you considered re-issuing failing ATAPI DMA commands as PIO as an EH > response ? I think determining whether to retry or not belongs to upper layer. Retrying random command can result in unexpected behavior. For things like device/media readiness testing, SCSI / cdrom layer will retry. For pass-through commands, I think it's better to leave it to the application. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] pata_pcmcia: convert to new data_xfer prototype
While merging data_xfer prototype change, pata_pcmcia was left out.
Convert it.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
Subject updated.
drivers/ata/pata_pcmcia.c | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/ata/pata_pcmcia.c b/drivers/ata/pata_pcmcia.c
index ceba93b..3e7f6a9 100644
--- a/drivers/ata/pata_pcmcia.c
+++ b/drivers/ata/pata_pcmcia.c
@@ -102,10 +102,10 @@ static int pcmcia_set_mode_8bit(struct ata_link *link,
/**
* ata_data_xfer_8bit - Transfer data by 8bit PIO
- * @adev: device to target
+ * @dev: device to target
* @buf: data buffer
* @buflen: buffer length
- * @write_data: read/write
+ * @rw: read/write
*
* Transfer data from/to the device data register by 8 bit PIO.
*
@@ -113,14 +113,17 @@ static int pcmcia_set_mode_8bit(struct ata_link *link,
* Inherited from caller.
*/
-static void ata_data_xfer_8bit(struct ata_device *adev, unsigned char *buf,
- unsigned int buflen, int write_data)
+static unsigned int ata_data_xfer_8bit(struct ata_device *dev,
+ unsigned char *buf, unsigned int buflen, int rw)
{
- struct ata_port *ap = adev->link->ap;
- if (write_data)
- iowrite8_rep(ap->ioaddr.data_addr, buf, buflen);
- else
+ struct ata_port *ap = dev->link->ap;
+
+ if (rw == READ)
ioread8_rep(ap->ioaddr.data_addr, buf, buflen);
+ else
+ iowrite8_rep(ap->ioaddr.data_addr, buf, buflen);
+
+ return buflen;
}
--
1.5.2.4
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: commit a258f183ee4e48e9352b408e8448467eebdc6cd2
On Wed, 02 Jan 2008 18:34:38 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > Happy new year, Jeff, Alan. > > I'm curious why commit a258f183 got in? Whats that commit in real code ? - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Maybe Sorry for that but where should i write .)
> Actually, the correct mailing list is linux-ide. Alan Cox began working > on the driver. Cc'ing both. Unless I get further info from Initio I don't expect anything to happen. They simply don't provide enough info to write a driver. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: commit a258f183ee4e48e9352b408e8448467eebdc6cd2
Alan Cox wrote:
> On Wed, 02 Jan 2008 18:34:38 +0900
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> Happy new year, Jeff, Alan.
>>
>> I'm curious why commit a258f183 got in?
>
> Whats that commit in real code ?
The attached one.
--
tejun
>From a258f183ee4e48e9352b408e8448467eebdc6cd2 Mon Sep 17 00:00:00 2001
From: Alan <[EMAIL PROTECTED]>
Date: Tue, 2 Oct 2007 13:53:05 -0700
Subject: [PATCH] libata: fix (hopefully) all the remaining problems with devices failing setup/identify
Two fixes in this test patch. One of them allows old CF cards to refuse
pio mode setting, and one to wait for the drive to settle after a set
features changes the speed settings, which is based upon the workarounds
used by drivers/ide.
Please test and report back if you have an afflicted system. This patch
isn't for merging just testing.
The CF card fix will still display errors when the card works (got fixes
for that once I know the cure works) but should then be found/usable.
Not signed off by anyone, not for merging
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 0c2f37e..2b24041 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6134,6 +6134,7 @@ inline unsigned int ata_host_intr(struct ata_port *ap,
{
struct ata_eh_info *ehi = &ap->link.eh_info;
u8 status, host_stat = 0;
+ int i;
VPRINTK("ata%u: protocol %d task_state %d\n",
ap->print_id, qc->tf.protocol, ap->hsm_task_state);
@@ -6190,6 +6191,20 @@ inline unsigned int ata_host_intr(struct ata_port *ap,
if (unlikely(status & ATA_BUSY))
goto idle_irq;
+ if (unlikely(qc->tf.command == ATA_CMD_SET_FEATURES &&
+ qc->tf.feature == SETFEATURES_XFER)) {
+ /* Let the timings change settle and the drive catch up as
+ some hardware needs up to 10uS to get its brain back in
+ gear. Taken from the workarounds in drivers/ide done by
+ Matthew Faupel/Niccolo Rigacci */
+ for (i = 0; i < 10; i++) {
+ if ((status & (ATA_BUSY | ATA_DRQ | ATA_ERR)) == 0)
+break;
+ udelay(1);
+ status = ata_chk_status(ap);
+ }
+ }
+
/* ack bmdma irq events */
ap->ops->irq_clear(ap);
--
1.5.2.4
Re: commit a258f183ee4e48e9352b408e8448467eebdc6cd2
On Wed, 02 Jan 2008 23:24:30 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > Alan Cox wrote: > > On Wed, 02 Jan 2008 18:34:38 +0900 > > Tejun Heo <[EMAIL PROTECTED]> wrote: > > > >> Happy new year, Jeff, Alan. > >> > >> I'm curious why commit a258f183 got in? > > > > Whats that commit in real code ? > > The attached one. Ok I don't see how that is related to the switch to polling. The old IDE code found it neccessary and always did polling. Alan - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: commit a258f183ee4e48e9352b408e8448467eebdc6cd2
Alan Cox wrote: > On Wed, 02 Jan 2008 23:24:30 +0900 > Tejun Heo <[EMAIL PROTECTED]> wrote: > >> Alan Cox wrote: >>> On Wed, 02 Jan 2008 18:34:38 +0900 >>> Tejun Heo <[EMAIL PROTECTED]> wrote: >>> Happy new year, Jeff, Alan. I'm curious why commit a258f183 got in? >>> Whats that commit in real code ? >> The attached one. > > Ok I don't see how that is related to the switch to polling. The > old IDE code found it neccessary and always did polling. ata_host_intr() is just never traveled while executing SETXFER because SETXFERs are executed using polling which nicely works around quirky controllers which raises interrupt a tad bit too early during SETXFER. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ide: use MODULE_VERSION()
Jon Masters wrote: > On Tue, 2008-01-01 at 22:46 -0600, Matt Domsch wrote: >> $ modinfo dell_rbu | grep version >> version:3.2 >> srcversion: 1D4815D7D6FBEE6612F3C18 > > Right. And I was referring to the is above (I forgot it's a CRC32 and > not a SHA1). But my point is why not codify some "policy" here with > respect to module versioning, rather than have the latter exist to > workaround the case that module versions aren't bumped manually. How about this version scheme: driver version == Linux kernel version -- Stefan Richter -=-==--- ---= ---=- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: commit a258f183ee4e48e9352b408e8448467eebdc6cd2
> ata_host_intr() is just never traveled while executing SETXFER because > SETXFERs are executed using polling which nicely works around quirky > controllers which raises interrupt a tad bit too early during SETXFER. Ok - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: commit a258f183ee4e48e9352b408e8448467eebdc6cd2
Alan Cox wrote: >> ata_host_intr() is just never traveled while executing SETXFER because >> SETXFERs are executed using polling which nicely works around quirky >> controllers which raises interrupt a tad bit too early during SETXFER. > > Ok Okay. Jeff, can you please revert the commit? Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH #upstream] libata: fix off-by-one in error categorization
ATA_ECAT_DUBIOUS_BASE was too high by one and thus all DUBIOUS error
categorizations were wrong. This passed test because only ATA_BUS and
UNK_DEV were used during testing and the ones after them - ATA_BUS and
an overflowed entry - behaved similarly.
This patch fixes the problem by adding DUBIOUS_NONE category and use
it as base.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/libata-eh.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 228a225..04b93a2 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -61,12 +61,11 @@ enum {
ATA_ECAT_ATA_BUS= 1,
ATA_ECAT_TOUT_HSM = 2,
ATA_ECAT_UNK_DEV= 3,
- ATA_ECAT_DUBIOUS_ATA_BUS= 4,
- ATA_ECAT_DUBIOUS_TOUT_HSM = 5,
- ATA_ECAT_DUBIOUS_UNK_DEV= 6,
- ATA_ECAT_NR = 7,
-
- ATA_ECAT_DUBIOUS_BASE = ATA_ECAT_DUBIOUS_ATA_BUS,
+ ATA_ECAT_DUBIOUS_NONE = 4,
+ ATA_ECAT_DUBIOUS_ATA_BUS= 5,
+ ATA_ECAT_DUBIOUS_TOUT_HSM = 6,
+ ATA_ECAT_DUBIOUS_UNK_DEV= 7,
+ ATA_ECAT_NR = 8,
};
/* Waiting in ->prereset can never be reliable. It's sometimes nice
@@ -1498,7 +1497,7 @@ static int ata_eh_categorize_error(unsigned int eflags,
unsigned int err_mask,
*xfer_ok = 1;
if (!*xfer_ok)
- base = ATA_ECAT_DUBIOUS_BASE;
+ base = ATA_ECAT_DUBIOUS_NONE;
if (err_mask & AC_ERR_ATA_BUS)
return base + ATA_ECAT_ATA_BUS;
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: sata_nv + ADMA + Samsung disk problem
> The question I had for NVIDIA regarding this that I never got > answered > was, is there any reason why we would need a delay when switching > between NCQ and non-NCQ commands on ADMA, and if not, is > there any known > cause that could cause the controller to get into this seemingly > locked-up state? When switching from NCQ to non NCQ or vice versa you must make sure all outstanding commands are completed before issuing the new command. The hardware doesn't do anything to prevent queued and non queued commands from going out on the wire at the same time which will certainly cause some drives to fail. -Allen --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_nv + ADMA + Samsung disk problem
Allen Martin wrote: The question I had for NVIDIA regarding this that I never got answered was, is there any reason why we would need a delay when switching between NCQ and non-NCQ commands on ADMA, and if not, is there any known cause that could cause the controller to get into this seemingly locked-up state? When switching from NCQ to non NCQ or vice versa you must make sure all outstanding commands are completed before issuing the new command. The hardware doesn't do anything to prevent queued and non queued commands from going out on the wire at the same time which will certainly cause some drives to fail. The software definitely provides that guarantee for all NCQ-capable controllers. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)
Holger Hoffstaette wrote: Another new "problem" (not as important) -- even though SATA disks are called with "sdX", my ATA disks that *were* at hda-hdc are now at hde-hdg. Devices hda-hdd are not populated in my dev directory on bootup. Of I think this is because the Promise SATA card also has one or more PATA channels, so if the card is activated it takes precedence over your old controller. But it should only be one channel, not four? As for the other problem - I plan on adding such a card to one of my systems during the week and might be able to contribute some findings. --- FYI - this specific card was sold as "4-SATA" channels. There were other contemporary (same package design) Promise cards offered that were advertised to 1) support 2-sata+2pata or 2) support RAID w/SATA. I think there was also a RAID card supporting PATA-only as well. It is quite possible (though thoroughly 'lame'), that they have 1 card providing, both 4 SATA and 4 PATA, but only provide the connectors for some subset, with the RAID being a firmware-only (software-only) option that is implemented in software on the card (as my web searching indicated was true for some Promise SATA cards). Perhaps an "RFE" for hdparm might be someway to specify the target device by using a label on one of the devices partitions, since my boot-time hdparm settings suffer from the same problems my /etc/fstab used to suffer before "labels" were available. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)
Alan Cox wrote:
rate began falling; at 128k block-reads-at-a-time or larger, it drops below
20MB/s (only on buffered SATA).
Try disabling NCQ - see if you've got a drive with the 'NCQ = no
readahead' flaw.
---
I'm not aware, off hand, how to disable NCQ. I haven't had any
NCQ- or SATA- capable disks before a few weeks ago.
The only way I could tell before was using hdparm to read the
parameters. Since that doesn't work, it's hard to tell if they
are set correctly...
hdparm supports identify to read modes on drives with libata. The one
thing you cannot do is force modes right now.
More importantly, how does one set parameters for acoustic and power
saving parameters? Some of my disks are used as 'backup' devices for my
hdparm or blktool
I have hdparm-v7.7.
There are some areas where it shows information, but areas where it
does not work jump out and lead me to suspect whether or not areas
that don't give explicit "ERROR" messages are presenting valid info.
Problem areas (using hdparm, disk=Seagate Barracuda 16MB cache, model=
ST3750640AS):
1) The drives current 'multicount' setting isn't readable or settable.
param "-i" shows "?16?" (with question marks around 16) and "-I" simply
shows "?" for the current setting. Attempting to it:
"HDIO__MULTCOUNT failed: Inappropriate ioctl for device"
2) Drive Advanced Power Management setting("-B") (write-only):
"HDIO_DRIVE_CMD failed: Input/output error"
3) Drive Acoustic ("-M"), read = " acoustic = not supported",
write = " HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error"
Note: drive detailed info from "-I" says:
"Recommended acoustic management value: 254, current value: 0"
(i.e. - there seems to be no way to set recommended value)
4) 32-bit IO setting ("-c") (don't know if this important given the disk's
raw-read speed, it may be meaningless for SATA)
"IO_support= 0 (default 16-bit)"*
*
FWIW -- the spindown/standby timeout ("S") does seem to work.
other computers. With the ATA disks, they were kept "spun down" when not
being used (only used, 'normally', in early AM hours).
Well for backup devices you can use the fact SATA is hot/warm plug.
---
I don't follow. It is an internal drive. Are their software "logically
unplug" commands that automatically re-"plug-in" the drive on access
and spin it back up like the spindown/standby timeout does? Or were
you referring to SATA's general hot/warm plug ability (if my hardware
setup, drive-slots, etc, permitted removability)?
Another new "problem" (not as important) -- even though SATA disks are
called with "sdX", my ATA disks that *were* at hda-hdc are now at hde-hdg.
NOTABUG - your BIOS has decided to move them from the legacy addresses so
they move from hda-d to e-g.
Sorry for my unclear usage -- by "problem" I meant that it was(is) an
"unexpected behavior". I'm sure the kernel is following the BIOS's
directions, I'm just not sure why a (supposedly), SATA-only card would
cause my BIOS to reserve 4 "[P]ATA-drives" after installing the
card. It may be symptomatic of some "cost-cutting" measure by the
card manufacurer. I just don't know why it's happening right now.
*however* -- it is "annoying" -- if the kernel reserves hda-hdd at the
request of the BIOS, it _might_ be useful if "udev" also populated
/dev/ with devices for hda-hdd. I.e. -- "something" on the linux-kernel
software-side of things knows that hda-hdd aren't really their as
the devices are not created in the udev-managed filesystem upon boot.
It may not be a kernel-bug insomuch as the kernel is intended to work,
but it doesn't seem that it is a "valuable feature". My reasoning:
"Hd" drive letters are "unstable" because plugging/unplugging HD
controllers and/or drives can change the HD lettering. Consequently,
it is considered "best practice" to mount disks by label instead of
by drive letter under linux. If it is acknowledged that the drive
letters are not stable, then why not have udev assign "hd" letters
only to drives that 'exist'?
Conversely, if udev had 'reserved' (created) hda-hdd devices because
the BIOS said they were 'reserved', then I can see it might have some
usefulness. This may be a 'udev'-specific concern or configuration
issue as well. I ran into it as I was going to try to use LILO's
"drive=" and "bios=" params to move the disks back to start with 'hda',
but lilo refused, saying 'hda' didn't exist (which it doesn't, as
indicated in the /dev-mounted udev 'filesystem'). It's not something
impossible to workaround or fix, just seemed odd to move the working
drives up to hde-g, when they could have been mapped to hda-c with
no apparent conflicts.
I know, it's a subtlety, but one not inconsistent with (wincing at
the admission of even knowing this, let along the comparison) WinXP's
feature set.
If a disk was mounted and associated with a specific letter, then
later another controller or disk is added that would cause 're-lettering'
under linux, it w
Sg/libata hotplug kernel error
Hi All, Has anyone seen this kernel error before? The controller is Sil3124 and kernel version 2.6.18-rc2. This seems to happen very rarely since this is the first time I 've seen this error message. Thanks for your feedback! Fajun ~ $ dmesg 0608 394833] SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) [1198330608 395174] sda: Write Protect is off [1198330608 395226] sda: Mode Sense: 00 3a 00 00 [1198330608 395654] SCSI device sda: drive cache: write back [1198330608 396194] SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) [1198330608 398800] sda: Write Protect is off [1198330608 398862] sda: Mode Sense: 00 3a 00 00 [1198330608 399293] SCSI device sda: drive cache: write back [1198330608 399391] sda: unknown partition table [1198330608 415346] sd 0:0:0:0: Attached scsi disk sda [1198330608 415668] sd 0:0:0:0: Attached scsi generic sg0 type 0 [1198339284 728601] ata1 port frozen [1198339284 728681] ata1: exception Emask 0x10 SAct 0x0 SErr 0x8 action 0x2 frozen [1198339284 728749] ata1: (irq_stat 0x01100010, PHY RDY changed) [1198339284 728802] ata1 port frozen [1198339284 728841] ata1: hard resetting port [1198339285 277716] ata1: SATA link down (SStatus 0 SControl 300) [1198339285 29] ata1 port thawed [1198339285 277818] ata1.00: disabled [1198339285 787776] ata1: EH complete [1198339285 787854] ata1.00: detaching (SCSI 0:0:0:0) [1198339314 961020] ata1 port frozen [1198339314 961097] ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x2 frozen [1198339314 961164] ata1: (irq_stat 0x00b40090, PHY RDY changed) [1198339314 961219] ata1 port frozen [1198339314 961258] ata1: hard resetting port [1198339318 701017] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [1198339318 701090] ata1 port thawed [1198339318 702326] ata1.00: ATA-7, max UDMA/133, 312581808 sectors: LBA48 NCQ (depth 31/32) [1198339318 703916] ata1.00: configured for UDMA/100 [1198339318 703980] ata1: EH complete [1198339318 704735] Vendor: ATA Model: ST9160823AS Rev: AAZ2 [1198339318 704850] Type: Direct-Access ANSI SCSI revision: 05 [1198339318 705847] SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) [1198339318 706165] sda: Write Protect is off [1198339318 706230] sda: Mode Sense: 00 3a 00 00 [1198339318 706657] SCSI device sda: drive cache: write back [1198339318 707194] SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) [1198339318 707480] sda: Write Protect is off [1198339318 707541] sda: Mode Sense: 00 3a 00 00 [1198339318 707964] SCSI device sda: drive cache: write back [1198339318 708031] sda: unknown partition table [1198339318 727956] sd 0:0:0:0: Attached scsi disk sda [1198339318 728265] sd 0:0:0:0: Attached scsi generic sg0 type 0 [1198350170 540587] ata1 port frozen [1198350170 540662] ata1: exception Emask 0x10 SAct 0x0 SErr 0x8 action 0x2 frozen [1198350170 540730] ata1: (irq_stat 0x01100010, PHY RDY changed) [1198350170 540780] ata1 port frozen [1198350170 540819] ata1: hard resetting port [1198350171 109527] ata1: SATA link down (SStatus 0 SControl 300) [1198350171 109592] ata1 port thawed [1198350171 109631] ata1.00: disabled [1198350171 619603] ata1: EH complete [1198350171 619683] ata1.00: detaching (SCSI 0:0:0:0) [1198350200 751481] ata1 port frozen [1198350200 751563] ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x2 frozen [1198350200 751630] ata1: (irq_stat 0x00b40090, PHY RDY changed) [1198350200 751685] ata1 port frozen [1198350200 751725] ata1: hard resetting port [1198350204 482807] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [1198350204 482878] ata1 port thawed [1198350204 496761] ata1.00: ATA-7, max UDMA/133, 312581808 sectors: LBA48 NCQ (depth 31/32) [1198350204 498302] ata1.00: configured for UDMA/100 [1198350204 498370] ata1: EH complete [1198350204 499202] Vendor: ATA Model: ST9160823AS Rev: AAZ2 [1198350204 499320] Type: Direct-Access ANSI SCSI revision: 05 [1198350204 500328] SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) [1198350204 500664] sda: Write Protect is off [1198350204 500716] sda: Mode Sense: 00 3a 00 00 [1198350204 501161] SCSI device sda: drive cache: write back [1198350204 501697] SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) [1198350204 501987] sda: Write Protect is off [1198350204 502049] sda: Mode Sense: 00 3a 00 00 [1198350204 502472] SCSI device sda: drive cache: write back [1198350204 502540] sda: unknown partition table [1198350204 513485] sd 0:0:0:0: Attached scsi disk sda [1198350204 513870] sd 0:0:0:0: Attached scsi generic sg0 type 0 [1198358880 722104] ata1 port frozen [1198358880 722185] ata1: exception Emask 0x10 SAct 0x0 SErr 0x8 action 0x2 frozen [1198358880 722254] ata1: (irq_stat 0x01100010, PHY RDY changed) [1198358880 722304] ata1 port frozen [1198358880 722343] ata1: hard resetting port [1198358881 291114] ata1: SATA link down (SStatus 0 SControl 300) [1198358881 291176] ata1 p
Re: [PATCH 1/3] ide: use MODULE_VERSION()
On Wednesday 02 January 2008, Matt Domsch wrote: > On Tue, Jan 01, 2008 at 09:32:36PM -0500, Jon Masters wrote: > > On Tue, 2008-01-01 at 19:33 +0100, Bartlomiej Zolnierkiewicz wrote: > > > > > On the second thought: maybe we will be better off with limiting > > > MODULE_VERSION() to the device drivers and the IDE core module for now, > > > and just removing all these private version numbers from host drivers > > > (with one or two exceptions they are not printed or exported currently, > > > moreover exceptions are the cases like stale version numbers from 199x)? > > > > Things like checkpatch could help advise people to bump the version > > number, but it's a bit iffy. Matt D. actually uses the special source > > version modinfo for DKMS - which is different - but it makes me wonder > > whether dynamically generating a version based on source SHA1 wouldn't > > be a better idea in most cases than an outdated hard-coded one. > > We've got that already, it's called 'srcversion', and it's a CRC32 Neat. > IIRC after some limited parsing to let it ignore whitspace changes and > comment changes only. > > $ modinfo dell_rbu | grep version > version:3.2 > srcversion: 1D4815D7D6FBEE6612F3C18 Unfortunately 'srcversion' is set only if MODULE_VERSION() is used... :( Anyway I'm dropping this patch and removing all versions from comments for now (patch #2 respin in few minutes)... Thanks, Bart - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ide: use MODULE_VERSION()
On Wed, Jan 02, 2008 at 11:45:17PM +0100, Bartlomiej Zolnierkiewicz wrote: > Unfortunately 'srcversion' is set only if MODULE_VERSION() is used... :( or CONFIG_MODULE_SRCVERSION_ALL=y. I see Fedora doesn't use that :-( but Ubuntu, openSUSE do. /me files a change request... -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: sata_nv + ADMA + Samsung disk problem
> The software definitely provides that guarantee for all NCQ-capable
> controllers.
>
Well if that's not it, it must be some problem entering ADMA legacy
mode. Here's what the Windows driver does:
ADMACtrl.aGO = 0
ADMACtrl.aEIEN = 0
poll {
until ADMAStatus.aLGCY = 1 || timeout
}
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ide: delete filenames/versions from comments
Delete filenames/versions from comments. I'm leaving decisions about adding DRV_VERSION defines and MODULE_VERSION()-s to maintainers of the respective drivers. While at it: * Remove unused VERSION define from ide.c. * Remove unused/stale DRV_VERSION define from au1xxx-ide.c. Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> --- a replacement patch for "ide: delete filenames from comments" one drivers/ide/arm/bast-ide.c |3 +-- drivers/ide/arm/icside.c |2 -- drivers/ide/arm/rapide.c |2 -- drivers/ide/cris/ide-cris.c|3 +-- drivers/ide/h8300/ide-h8300.c |1 - drivers/ide/ide-acpi.c |1 - drivers/ide/ide-cd.h |2 -- drivers/ide/ide-disk.c |2 -- drivers/ide/ide-dma.c |3 +-- drivers/ide/ide-floppy.c |2 -- drivers/ide/ide-iops.c |2 -- drivers/ide/ide-pnp.c |2 -- drivers/ide/ide-probe.c|2 -- drivers/ide/ide-proc.c |2 -- drivers/ide/ide-tape.c |2 -- drivers/ide/ide-taskfile.c |2 -- drivers/ide/ide-timing.h |2 -- drivers/ide/ide.c |3 --- drivers/ide/legacy/ali14xx.c |2 -- drivers/ide/legacy/buddha.c|2 +- drivers/ide/legacy/dtc2278.c |2 -- drivers/ide/legacy/falconide.c |2 +- drivers/ide/legacy/gayle.c |2 +- drivers/ide/legacy/ht6560b.c |2 -- drivers/ide/legacy/ide-cs.c|2 -- drivers/ide/legacy/macide.c|2 +- drivers/ide/legacy/q40ide.c|2 +- drivers/ide/legacy/qd65xx.c|2 -- drivers/ide/legacy/qd65xx.h|2 -- drivers/ide/legacy/umc8672.c |2 -- drivers/ide/mips/au1xxx-ide.c |3 --- drivers/ide/pci/aec62xx.c |2 -- drivers/ide/pci/alim15x3.c |2 -- drivers/ide/pci/amd74xx.c |2 -- drivers/ide/pci/atiixp.c |2 -- drivers/ide/pci/cmd640.c |2 -- drivers/ide/pci/cmd64x.c |2 -- drivers/ide/pci/cs5530.c |2 -- drivers/ide/pci/cs5535.c |2 -- drivers/ide/pci/cy82c693.c |2 -- drivers/ide/pci/delkin_cb.c|2 -- drivers/ide/pci/generic.c |2 -- drivers/ide/pci/hpt34x.c |3 +-- drivers/ide/pci/hpt366.c |2 -- drivers/ide/pci/it821x.c |3 --- drivers/ide/pci/ns87415.c |2 -- drivers/ide/pci/opti621.c |2 -- drivers/ide/pci/pdc202xx_old.c |2 -- drivers/ide/pci/piix.c |2 -- drivers/ide/pci/rz1000.c |2 -- drivers/ide/pci/sc1200.c |2 -- drivers/ide/pci/serverworks.c |2 -- drivers/ide/pci/siimage.c |2 -- drivers/ide/pci/sis5513.c |2 -- drivers/ide/pci/sl82c105.c |2 -- drivers/ide/pci/slc90e66.c |2 -- drivers/ide/pci/tc86c001.c |2 -- drivers/ide/pci/triflex.c |2 -- drivers/ide/pci/trm290.c |3 +-- drivers/ide/pci/via82cxxx.c|3 --- drivers/ide/ppc/mpc8xx.c |2 -- drivers/ide/ppc/pmac.c |3 +-- drivers/ide/setup-pci.c|4 +--- drivers/scsi/ide-scsi.c|2 -- 64 files changed, 12 insertions(+), 126 deletions(-) Index: b/drivers/ide/arm/bast-ide.c === --- a/drivers/ide/arm/bast-ide.c +++ b/drivers/ide/arm/bast-ide.c @@ -1,5 +1,4 @@ -/* linux/drivers/ide/arm/bast-ide.c - * +/* * Copyright (c) 2003-2004 Simtec Electronics * Ben Dooks <[EMAIL PROTECTED]> * Index: b/drivers/ide/arm/icside.c === --- a/drivers/ide/arm/icside.c +++ b/drivers/ide/arm/icside.c @@ -1,6 +1,4 @@ /* - * linux/drivers/ide/arm/icside.c - * * Copyright (c) 1996-2004 Russell King. * * Please note that this platform does not support 32-bit IDE IO. Index: b/drivers/ide/arm/rapide.c === --- a/drivers/ide/arm/rapide.c +++ b/drivers/ide/arm/rapide.c @@ -1,6 +1,4 @@ /* - * linux/drivers/ide/arm/rapide.c - * * Copyright (c) 1996-2002 Russell King. */ Index: b/drivers/ide/cris/ide-cris.c === --- a/drivers/ide/cris/ide-cris.c +++ b/drivers/ide/cris/ide-cris.c @@ -1,5 +1,4 @@ -/* $Id: cris-ide-driver.patch,v 1.1 2005/06/29 21:39:07 akpm Exp $ - * +/* * Etrax specific IDE functions, like init and PIO-mode setting etc. * Almost the entire ide.c is used for the rest of the Etrax ATA driver. * Copyright (c) 2000-2005 Axis Communications AB Index: b/drivers/ide/h8300/ide-h8300.c === --- a/drivers/ide/h8300/ide-h8300.c +++ b/drivers/ide/h8300/ide-h8300.c @@ -1,5 +1,4 @@ /* - * drivers/ide/h8300/ide-h8300.c * H8/300 generic IDE interface */ Index: b/drivers/ide/ide-acpi.c === --- a/drivers/ide/ide-acpi.c +++ b/drivers/ide/ide-acpi.c @@ -1,5 +1,4 @@
Re: sata_nv + ADMA + Samsung disk problem
Allen Martin wrote:
The software definitely provides that guarantee for all NCQ-capable
controllers.
Well if that's not it, it must be some problem entering ADMA legacy
mode. Here's what the Windows driver does:
ADMACtrl.aGO = 0
ADMACtrl.aEIEN = 0
poll {
until ADMAStatus.aLGCY = 1 || timeout
}
What we're doing to enter legacy mode is essentially:
-wait until ADMA status indicates IDLE bit set (max wait of 1 microsecond)
-clear GO bit in control register
-wait until status indicates LEGACY bit set (max wait of 1 microsecond)
and to enter ADMA mode:
-set GO bit in control register
-wait until status indicates LEGACY bit cleared and IDLE bit set (max
wait of 1 microsecond)
The 1 microsecond timeout is pretty aggressive admittedly, but it
apparently isn't being broken (the only timeouts when switching modes
I've seen are during error handling after a command timeout has already
occurred). What timeout value is the Windows driver using?
Also, I see you are clearing the AEIN bit when in register mode, while
we're not. Is that important/necessary?
Aside from all this though, in the case of NCQ writes followed by a
cache flush, that sequence of commands won't put us into legacy mode at
all since the cache flush is a no-data command which we should be able
to handle in ADMA mode, from my understanding (correct me if I'm wrong).
So I don't imagine legacy/ADMA mode switch could be the cause of this
problem.
I also saw in my previous investigation that a flush immediately
followed by a write could cause the write to time out as well.
From some of the traces I took previously (posted on LKML as "sata_nv
ADMA controller lockup investigation" way back in Feb 07), what seems to
occur is that when the second command is issued very rapidly (within
less than 20 microseconds, or potentially longer) after the previous
command's completion, the ADMA status changes from 0x500 (STOPPED and
IDLE) to 0x400 (just IDLE) as it typically does, but then it sticks
there, no interrupt is ever raised, and CPB response flags remain at 0.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)
Linda Walsh wrote:
Alan Cox wrote:
rate began falling; at 128k block-reads-at-a-time or larger, it drops
below
20MB/s (only on buffered SATA).
Try disabling NCQ - see if you've got a drive with the 'NCQ = no
readahead' flaw.
---
I'm not aware, off hand, how to disable NCQ. I haven't had any
NCQ- or SATA- capable disks before a few weeks ago.
See here:
http://linux-ata.org/faq.html#ncq
The only way I could tell before was using hdparm to read the
parameters. Since that doesn't work, it's hard to tell if they
are set correctly...
hdparm supports identify to read modes on drives with libata. The one
thing you cannot do is force modes right now.
More importantly, how does one set parameters for acoustic and power
saving parameters? Some of my disks are used as 'backup' devices for my
hdparm or blktool
I have hdparm-v7.7. There are some areas where it shows information,
but areas where it
does not work jump out and lead me to suspect whether or not areas
that don't give explicit "ERROR" messages are presenting valid info.
Problem areas (using hdparm, disk=Seagate Barracuda 16MB cache, model=
ST3750640AS):
1) The drives current 'multicount' setting isn't readable or settable.
param "-i" shows "?16?" (with question marks around 16) and "-I" simply
shows "?" for the current setting. Attempting to it:
"HDIO__MULTCOUNT failed: Inappropriate ioctl for device"
I don't think you can get or get the multi count currently, it just uses
the best supported value.
2) Drive Advanced Power Management setting("-B") (write-only):
"HDIO_DRIVE_CMD failed: Input/output error"
3) Drive Acoustic ("-M"), read = " acoustic = not supported",
write = " HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error"
Note: drive detailed info from "-I" says:
"Recommended acoustic management value: 254, current value: 0"
(i.e. - there seems to be no way to set recommended value)
Not sure about these ones.. Does anything show up in dmesg when you do this?
4) 32-bit IO setting ("-c") (don't know if this important given the disk's
raw-read speed, it may be meaningless for SATA)
"IO_support= 0 (default 16-bit)"*
*
This setting is not meaningful for anything using DMA.
FWIW -- the spindown/standby timeout ("S") does seem to work.
other computers. With the ATA disks, they were kept "spun down" when
not
being used (only used, 'normally', in early AM hours).
Well for backup devices you can use the fact SATA is hot/warm plug.
---
I don't follow. It is an internal drive. Are their software "logically
unplug" commands that automatically re-"plug-in" the drive on access
and spin it back up like the spindown/standby timeout does? Or were
you referring to SATA's general hot/warm plug ability (if my hardware
setup, drive-slots, etc, permitted removability)?
I think they were referring to physically hotplugging the drive. This is
more practical if you have a removable drive caddy, or if the drive is
hooked up through eSATA.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_nv + ADMA + Samsung disk problem
Tejun Heo wrote: Robert Hancock wrote: Jeff Garzik wrote: Tejun Heo wrote: Thanks a lot for the detailed explanation. Nvidia ppl, any ideas? FLUSH is used regularly. We really need to fix this. I reiterate my opinion :) ... We should remove ADMA support from sata_nv. It's only in a few chips, it's not appearing in any new chips, and nasty problems have lingered since ADMA support was introduced. Definitely sounds like we should disable ADMA by default for 2.6.24-rc, too. I wouldn't agree.. It's only in a few chips (CK804/MCP04), but those chips are very common in desktop, workstation, even some server machines. Given the huge number of these chips out there, problem reports have been quite rare. I agree with Jeff here. Maybe not remove but disable it by default and when enabling warn loudly. NCQ just doesn't enough for its cost when the cost includes erratic behaviors. Only very small fraction of error cases actually make to bugzilla or this mailing list. Nvidia gents, is there anyway (be it NDA or whatever) to get Robert or any of us technical documentation? Thanks. Last I heard, NVIDIA management gave the thumbs down to any more NDAs for ADMA documentation. It would be nice if they would reconsider. Apparently Jeff does have the docs, though.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ide: delete filenames/versions from comments
Bartlomiej Zolnierkiewicz wrote: Delete filenames/versions from comments. I'm leaving decisions about adding DRV_VERSION defines and MODULE_VERSION()-s to maintainers of the respective drivers. While at it: * Remove unused VERSION define from ide.c. * Remove unused/stale DRV_VERSION define from au1xxx-ide.c. Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> How about getting rid of this stupid thing in drivers/ide/ide.c: #define REVISION"Revision: 7.00alpha2" which is used in: printk(KERN_INFO "Uniform Multi-Platform E-IDE driver " REVISION "\n"); It's been 7.00alpha2 for god knows how long, so clearly this version number is not useful.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_nv + ADMA + Samsung disk problem
Robert Hancock wrote: What we're doing to enter legacy mode is essentially: -wait until ADMA status indicates IDLE bit set (max wait of 1 microsecond) -clear GO bit in control register -wait until status indicates LEGACY bit set (max wait of 1 microsecond) and to enter ADMA mode: -set GO bit in control register -wait until status indicates LEGACY bit cleared and IDLE bit set (max wait of 1 microsecond) .. If there are outstanding TCQ/NCQ commands (any drive), then this could take (much) longer to enter legacy mode, as the ADMA engine will wait for them all to finish. But for normal, "nothing outstanding" mode, it should be very quick. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_nv + ADMA + Samsung disk problem
Robert Hancock wrote: .. From some of the traces I took previously (posted on LKML as "sata_nv ADMA controller lockup investigation" way back in Feb 07), what seems to occur is that when the second command is issued very rapidly (within less than 20 microseconds, or potentially longer) after the previous command's completion, the ADMA status changes from 0x500 (STOPPED and IDLE) to 0x400 (just IDLE) as it typically does, but then it sticks there, no interrupt is ever raised, and CPB response flags remain at 0. .. Assuming that NVidia got their ADMA core logic from Pacific Digital (the inventors), then it may have some of the same bugs as the original. One of those bugs is that the aGO trigger is sampled in a "racey" way, such that it sometimes may miss a recent addition to the ring. The *only* way to guarantee things with the original Pacific Digital core was to (1) always retrigger aGO for a full ring scan with each new addition, and (2) poll periodically (every half second or so) rather than relying exclusively on the IRQ actually working.. Dunno about the NVidia version. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)
Robert Hancock wrote:
Linda Walsh wrote:
Alan Cox wrote:
rate began falling; at 128k block-reads-at-a-time or larger, it
drops below
20MB/s (only on buffered SATA).
Try disabling NCQ - see if you've got a drive with the 'NCQ = no
readahead' flaw.
http://linux-ata.org/faq.html#ncq
---
When drive initializes, dmesg says it has NCQ (depth 0/32)
Reading the queue_depth under /sys, shows a queuedepth of "1".
But more importantly -- I notice a chronic error message associate
with this drive that may be causing some or all of the problem:
---
Jan 2 20:06:10 Ishtar kernel: ata1.00: exception Emask 0x0 SAct 0x0
SErr 0x0 action 0x2
Jan 2 20:06:10 Ishtar kernel: ata1.00: port_status 0x2008
Jan 2 20:06:10 Ishtar kernel: ata1.00: cmd
c8/00:10:30:06:03/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in
Jan 2 20:06:10 Ishtar kernel: res
50/00:00:3f:06:03/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
Jan 2 20:06:13 Ishtar kernel: ata1: limiting SATA link speed to 1.5 Gbps
Jan 2 20:06:13 Ishtar kernel: ata1.00: exception Emask 0x0 SAct 0x0
SErr 0x0 action 0x6
Jan 2 20:06:13 Ishtar kernel: ata1.00: port_status 0x2008
Jan 2 20:06:13 Ishtar kernel: ata1.00: cmd
c8/00:10:00:8b:04/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in
Jan 2 20:06:13 Ishtar kernel: res
50/00:00:0f:8b:04/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
Jan 2 20:06:14 Ishtar kernel: ata1: exception Emask 0x10 SAct 0x0 SErr
0x0 action 0x3
Jan 2 20:06:14 Ishtar kernel: ata1: hotplug_status 0x80
Jan 2 20:06:15 Ishtar kernel: ata1: exception Emask 0x10 SAct 0x0 SErr
0x0 action 0x3
Jan 2 20:06:15 Ishtar kernel: ata1: hotplug_status 0x80
---
What da heck? Note, this is with NCQ-queuing set to "1". Only
reference I could find for this error referred to "older drives", but
this is a
2007-model year drive with ATA-7 and udma-6.
I don't think you can get or get the multi count currently, it just
uses the best supported value.
ok
2) Drive Advanced Power Management setting("-B") (write-only):
"HDIO_DRIVE_CMD failed: Input/output error"
3) Drive Acoustic ("-M"), read = " acoustic = not supported",
write = " HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error"
Not sure about these ones.. Does anything show up in dmesg when you do
this?
---
Yes:
(for "-B", power-management)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: port_status 0x2020
ata1.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0
res 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1 (device error)
ata1.00: configured for UDMA/133
ata1: EH complete
sd 1:0:0:0: [sdb] 1465149168 512-byte hardware sectors (750156 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
(for "-M" acoustic management):
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: port_status 0x2020
ata1.00: cmd ef/42:fe:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0
res 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1 (device error)
ata1.00: configured for UDMA/133
ata1: EH complete
sd 1:0:0:0: [sdb] 1465149168 512-byte hardware sectors (750156 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_nv + ADMA + Samsung disk problem
Mark Lord wrote: Robert Hancock wrote: .. From some of the traces I took previously (posted on LKML as "sata_nv ADMA controller lockup investigation" way back in Feb 07), what seems to occur is that when the second command is issued very rapidly (within less than 20 microseconds, or potentially longer) after the previous command's completion, the ADMA status changes from 0x500 (STOPPED and IDLE) to 0x400 (just IDLE) as it typically does, but then it sticks there, no interrupt is ever raised, and CPB response flags remain at 0. .. Assuming that NVidia got their ADMA core logic from Pacific Digital (the inventors), then it may have some of the same bugs as the original. One of those bugs is that the aGO trigger is sampled in a "racey" way, such that it sometimes may miss a recent addition to the ring. The *only* way to guarantee things with the original Pacific Digital core was to (1) always retrigger aGO for a full ring scan with each new addition, and (2) poll periodically (every half second or so) rather than relying exclusively on the IRQ actually working.. Dunno about the NVidia version. Theirs works rather differently - the GO bit is there, but there's another append register which is used to tell the controller that a new tag has been added to the CPB list. The only thing we currently use the GO bit for is to switch between ADMA and port register mode. Could be there's something we need to do there, though, who knows.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
