Re: [2.6 patch] libata-core.c: make 2 functions static
Adrian Bunk wrote: strn_pattern_cmp() and ata_port_detach() can become static. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- drivers/ata/libata-core.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) applied - 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] libata: cosmetic clean up in ata_eh_reset()
Tejun Heo wrote: Local variable @action usage in ata_eh_reset() is a bit confusing. It's used only to cache ehc-i.action to test reset masks after clearing it; however, due to the generic name action, it's easy to misinterpret the local variable as containing the selected reset method later. Also, the reason for caching the original value is easy to miss. This patch renames @action to @tmp_action and make it buffer newly selected value instead to improve readability. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- drivers/ata/libata-eh.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) applied - 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] ata: sata_nv MCP61 using GENERIC instead of SWNCQ
jeff wrote: Kuan Luo wrote: hi, The mcp61 has bug with ncq. The patch only changes SWNCQ to GENERIC on MCP61 in nv_pci_tbl structure. Do I have your permission to merge this patch with a Signed-off-by: Kuan Luo [EMAIL PROTECTED] ? Each patch needs a Signed-off-By line, which essentially provides a legal release to the patch. See Developer's Certificate of Origin in Documentation/SubmittingPatches or http://linux.yyz.us/patch-format.html Jeff Yes, you can merge Signed-off-by: Kuan Luo [EMAIL PROTECTED]. Next time i will sumbit the patch according completely with the patch format. Best regards, Kuan Luo --- 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: [PATCH] libata-core: Don't have screaming fits over DF/ERR combinations
Alan Cox wrote: Some hardware seems to get this wrong in a non-harmful way, and there are some devices that seem to do it deliberately for various reasons. Just take it as a device error not a catastrophic state machine explosion. Signed-off-by: Alan Cox [EMAIL PROTECTED] applied to #for-testing branch, let me know when you think its suitable for upstream - 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: [git patches] IDE updates (part 2)
Al Viro wrote: Proposed addition to icside part, provided that ARM folks ACK it - gets icside to build and AFAICS it's correct: diff --git a/drivers/ata/pata_icside.c b/drivers/ata/pata_icside.c index be30923..842fe08 100644 --- a/drivers/ata/pata_icside.c +++ b/drivers/ata/pata_icside.c @@ -332,12 +332,13 @@ static void ata_dummy_noret(struct ata_port *port) applied - 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] ahci: ahci: implement workaround for ASUS P5W-DH Deluxe ahci_broken_hardreset(), take #2
Tejun Heo wrote: P5W-DH Deluxe has ICH9 which doesn't have PMP support but SIMG 4726 hardwired to the second port of AHCI controller at PCI device 1f.2. The 4726 doesn't work as PMP but as a storage processor which can do hardware RAID on downstream ports. When no device is attached to the downstream port of the 4726, pseudo ATA device for configuration appears. Unfortunately, ATA emulation on the device is very lousy and causes long hang during boot. This patch implements workaround for the board. If the mainboard is P5W-DH Deluxe (matched using DMI), only hardreset is used on the second port of AHCI controller @ 1f.2 and the hardreset doesn't depend on receiving the first FIS and just proceed to IDENTIFY. This workaround fixes bugzilla #8923. http://bugzilla.kernel.org/show_bug.cgi?id=8923 Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- Okay, here's improved version. p5wdh hardreset is sufficiently different from vt8251, so it now has its own hardreset and ops. It now also has two secs + 150ms delay after hardreset so that devices which are slow to respond after hardreset don't fail. Most devices will respond in time unless it's spinning up. Spin up is handled by reset retrials. Also, it sets BSY before initiating BSY and performs CLO afterward if BSY isn't cleared during the wait. Change from the first take are minor but make the workaoround fit the problem better. Tested on a setup which behaves the same way as P5W-DH (non-PMP capable ICH AHCI + SIMG 4726) with some number of harddrives and ATAPI devices. Everything including hotplug works fine. drivers/ata/ahci.c | 144 + 1 file changed, 144 insertions(+) applied - 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] libata-core: Be a bit more relaxed about early DMA zero devices
Alan Cox wrote: I guess Windows didn't care about the command so neither did they Signed-off-by: Alan Cox [EMAIL PROTECTED] applied - 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/2 -stable] libata: backport ATA_FLAG_NO_SRST and ATA_FLAG_ASSUME_ATA
P5W-DH Deluxe has ICH7R which doesn't have PMP support but SIMG 4726
hardwired to the second port of AHCI controller at PCI device 1f.2.
The 4726 doesn't work as PMP but as a storage processor which can do
hardware RAID on downstream ports.
When no device is attached to the downstream port of the 4726, pseudo
ATA device for configuration appears. Unfortunately, ATA emulation on
the device is very lousy and causes long hang during boot.
This patch implements workaround for the board. If the mainboard is
P5W-DH Deluxe (matched using DMI), only hardreset is used on the
second port of AHCI controller @ 1f.2 and the hardreset doesn't depend
on receiving the first FIS and just proceed to IDENTIFY.
This workaround fixes bugzilla #8923.
http://bugzilla.kernel.org/show_bug.cgi?id=8923
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/ahci.c | 143 +
1 file changed, 143 insertions(+)
Index: tree0/drivers/ata/ahci.c
===
--- tree0.orig/drivers/ata/ahci.c
+++ tree0/drivers/ata/ahci.c
@@ -41,6 +41,7 @@
#include linux/interrupt.h
#include linux/dma-mapping.h
#include linux/device.h
+#include linux/dmi.h
#include scsi/scsi_host.h
#include scsi/scsi_cmnd.h
#include linux/libata.h
@@ -231,6 +232,7 @@ static void ahci_freeze(struct ata_port
static void ahci_thaw(struct ata_port *ap);
static void ahci_error_handler(struct ata_port *ap);
static void ahci_vt8251_error_handler(struct ata_port *ap);
+static void ahci_p5wdh_error_handler(struct ata_port *ap);
static void ahci_post_internal_cmd(struct ata_queued_cmd *qc);
static int ahci_port_resume(struct ata_port *ap);
static unsigned int ahci_fill_sg(struct ata_queued_cmd *qc, void *cmd_tbl);
@@ -329,6 +331,40 @@ static const struct ata_port_operations
.port_stop = ahci_port_stop,
};
+static const struct ata_port_operations ahci_p5wdh_ops = {
+ .port_disable = ata_port_disable,
+
+ .check_status = ahci_check_status,
+ .check_altstatus= ahci_check_status,
+ .dev_select = ata_noop_dev_select,
+
+ .tf_read= ahci_tf_read,
+
+ .qc_prep= ahci_qc_prep,
+ .qc_issue = ahci_qc_issue,
+
+ .irq_clear = ahci_irq_clear,
+ .irq_on = ata_dummy_irq_on,
+ .irq_ack= ata_dummy_irq_ack,
+
+ .scr_read = ahci_scr_read,
+ .scr_write = ahci_scr_write,
+
+ .freeze = ahci_freeze,
+ .thaw = ahci_thaw,
+
+ .error_handler = ahci_p5wdh_error_handler,
+ .post_internal_cmd = ahci_post_internal_cmd,
+
+#ifdef CONFIG_PM
+ .port_suspend = ahci_port_suspend,
+ .port_resume= ahci_port_resume,
+#endif
+
+ .port_start = ahci_port_start,
+ .port_stop = ahci_port_stop,
+};
+
static const struct ata_port_info ahci_port_info[] = {
/* board_ahci */
{
@@ -1176,6 +1212,52 @@ static int ahci_vt8251_hardreset(struct
return rc ?: -EAGAIN;
}
+static int ahci_p5wdh_hardreset(struct ata_port *ap, unsigned int *class,
+ unsigned long deadline)
+{
+ struct ahci_port_priv *pp = ap-private_data;
+ u8 *d2h_fis = pp-rx_fis + RX_FIS_D2H_REG;
+ struct ata_taskfile tf;
+ int rc;
+
+ ahci_stop_engine(ap);
+
+ /* clear D2H reception area to properly wait for D2H FIS */
+ ata_tf_init(ap-device, tf);
+ tf.command = 0x80;
+ ata_tf_to_fis(tf, 0, 0, d2h_fis);
+
+ rc = sata_port_hardreset(ap, sata_ehc_deb_timing(ap-eh_context),
+deadline);
+
+ ahci_start_engine(ap);
+
+ if (rc || ata_port_offline(ap))
+ return rc;
+
+ /* spec mandates = 2ms before checking status */
+ msleep(150);
+
+ /* The pseudo configuration device on SIMG4726 attached to
+* ASUS P5W-DH Deluxe doesn't send signature FIS after
+* hardreset if no device is attached to the first downstream
+* port the pseudo device locks up on SRST w/ PMP==0. To
+* work around this, wait for !BSY only briefly. If BSY isn't
+* cleared, perform CLO and proceed to IDENTIFY (achieved by
+* ATA_LFLAG_NO_SRST and ATA_LFLAG_ASSUME_ATA).
+*
+* Wait for two seconds. Devices attached to downstream port
+* which can't process the following IDENTIFY after this will
+* have to be reset again. For most cases, this should
+* suffice while making probing snappish enough.
+*/
+ rc = ata_wait_ready(ap, jiffies + 2 * HZ);
+ if (rc)
+ ahci_kick_engine(ap, 0);
+
+ return 0;
+}
+
static void ahci_postreset(struct ata_port *ap, unsigned int *class)
{
Re: [patch 3/4] scsi: expose AN support to user space
[EMAIL PROTECTED] wrote:
From: Kristen Carlson Accardi [EMAIL PROTECTED]
If a scsi_device supports async notification for media change, then let user
space know this capability exists by creating a new sysfs entry
media_change_notify, which will be 1 if it is supported, and 0 if not
supported. Create a routine which allows scsi devices to send a uevent when
media change events occur.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Acked-by: Jeff Garzik [EMAIL PROTECTED]
Cc: Tejun Heo [EMAIL PROTECTED]
Cc: James Bottomley [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/scsi/scsi_lib.c| 83 +++
drivers/scsi/scsi_scan.c |1
drivers/scsi/scsi_sysfs.c | 13 +
include/scsi/scsi_device.h | 15 +-
4 files changed, 111 insertions(+), 1 deletion(-)
committed to libata-dev.git#an as the attached patch
I changed the interface such that it takes a mask of events. We only
have one event right now, but it is now trivial to add more events
within the same interface.
commit 4e0af19e75e40d71181c4e515009e81f19a0fc04
Author: Jeff Garzik [EMAIL PROTECTED]
Date: Thu Oct 25 03:13:46 2007 -0400
[SCSI] Emit asynchronous media events
Based originally on a patch by
Kristen Carlson Accardi [EMAIL PROTECTED]
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
drivers/scsi/scsi_lib.c| 58 +
drivers/scsi/scsi_sysfs.c | 13 ++
include/scsi/scsi_device.h | 13 +-
3 files changed, 83 insertions(+), 1 deletion(-)
4e0af19e75e40d71181c4e515009e81f19a0fc04
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 61fdaf0..46a7f50 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -2115,6 +2115,64 @@ scsi_device_set_state(struct scsi_device *sdev, enum
scsi_device_state state)
EXPORT_SYMBOL(scsi_device_set_state);
/**
+ * scsi_device_event_notify_thread - send a uevent for each scsi event
+ * @work: work struct for scsi_device
+ *
+ * Emit all queued media events as environment variables
+ * sent during a uevent.
+ */
+static void scsi_event_notify_thread(struct work_struct *work)
+{
+ struct scsi_device *sdev;
+ char *envp[3];
+ unsigned long flags, mask;
+ int i, idx;
+
+ /* must match scsi_device_event enum in scsi_device.h */
+ static char *scsi_device_event_strings[] = {
+ [SDEV_MEDIA_CHANGE] = SDEV_MEDIA_CHANGE=1,
+ };
+
+ sdev = container_of(work, struct scsi_device, ew.work);
+
+ spin_lock_irqsave(sdev-list_lock, flags);
+ mask = sdev-event_mask;
+ sdev-event_mask = 0;
+ spin_unlock_irqrestore(sdev-list_lock, flags);
+
+ idx = 0;
+ for (i = 0; i SDEV_MEDIA_LAST; i++)
+ if (mask (1UL i))
+ envp[idx++] = scsi_device_event_strings[i];
+ envp[idx++] = NULL;
+
+ kobject_uevent_env(sdev-sdev_gendev.kobj, KOBJ_CHANGE, envp);
+}
+
+/**
+ * scsi_device_event_notify - store event info and send an event
+ * @sdev: scsi_device event occurred on
+ * @mask: the scsi device event mask
+ *
+ * Store the event information and then switch process context
+ * so that the event may be sent to user space.
+ * This may be called from interrupt context.
+ *
+ * Returns 0 if successful, -ENOMEM otherwise.
+ */
+void scsi_device_event_notify(struct scsi_device *sdev, unsigned long mask)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(sdev-list_lock, flags);
+ sdev-event_mask |= mask;
+ spin_unlock_irqrestore(sdev-list_lock, flags);
+
+ execute_in_process_context(scsi_event_notify_thread, sdev-ew);
+}
+EXPORT_SYMBOL_GPL(scsi_device_event_notify);
+
+/**
* scsi_device_quiesce - Block user issued commands.
* @sdev: scsi device to quiesce.
*
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index d531cee..d6e765c 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -614,6 +614,18 @@ sdev_show_modalias(struct device *dev, struct
device_attribute *attr, char *buf)
}
static DEVICE_ATTR(modalias, S_IRUGO, sdev_show_modalias, NULL);
+static ssize_t
+sdev_show_media_events(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct scsi_device *sdev = to_scsi_device(dev);
+ if (sdev-media_events)
+ return snprintf(buf, 20, %d\n, 1);
+ else
+ return snprintf(buf, 20, %d\n, 0);
+}
+static DEVICE_ATTR(media_events, S_IRUGO, sdev_show_media_events, NULL);
+
/* Default template for device attributes. May NOT be modified */
static struct attribute *scsi_sdev_attrs[] = {
dev_attr_device_blocked.attr,
@@ -631,6 +643,7 @@ static struct attribute *scsi_sdev_attrs[] = {
dev_attr_iodone_cnt.attr,
dev_attr_ioerr_cnt.attr,
Re: [patch 4/4] libata: expose AN to user space
[EMAIL PROTECTED] wrote:
From: Kristen Carlson Accardi [EMAIL PROTECTED]
If Asynchronous Notification of media change events is supported, pass that
information up to the SCSI layer.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Cc: Tejun Heo [EMAIL PROTECTED]
Cc: James Bottomley [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/ata/libata-scsi.c |3 +++
1 file changed, 3 insertions(+)
diff -puN drivers/ata/libata-scsi.c~libata-expose-an-to-user-space
drivers/ata/libata-scsi.c
--- a/drivers/ata/libata-scsi.c~libata-expose-an-to-user-space
+++ a/drivers/ata/libata-scsi.c
@@ -773,6 +773,9 @@ static void ata_scsi_dev_config(struct s
blk_queue_max_hw_segments(q, q-max_hw_segments - 1);
}
+ if (dev-flags ATA_DFLAG_AN)
+ sdev-media_change_notify = 1;
+
Methinks this wasn't tested, as you missed removal of the crucial
OTHER_AN_PATCHES_HAVE_BEEN_APPLIED ifdef-ery... :)
Anyway, I updated the patch for the media_event thingy in the last
email, and applied the attached patch
commit 6ba2326c804e2d449c2f40a63ba0a9ea650bef47
Author: Jeff Garzik [EMAIL PROTECTED]
Date: Thu Oct 25 03:20:05 2007 -0400
[libata] Utilize new SCSI media event infrastructure
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
drivers/ata/libata-scsi.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
6ba2326c804e2d449c2f40a63ba0a9ea650bef47
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index f5d5420..65b6153 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -773,6 +773,9 @@ static void ata_scsi_dev_config(struct scsi_device *sdev,
blk_queue_max_hw_segments(q, q-max_hw_segments - 1);
}
+ if (dev-flags ATA_DFLAG_AN)
+ sdev-media_events = 1;
+
if (dev-flags ATA_DFLAG_NCQ) {
int depth;
@@ -3248,10 +3251,8 @@ static void ata_scsi_handle_link_detach(struct ata_link
*link)
*/
void ata_scsi_media_change_notify(struct ata_device *dev)
{
-#ifdef OTHER_AN_PATCHES_HAVE_BEEN_APPLIED
if (dev-sdev)
- scsi_device_event_notify(dev-sdev, SDEV_MEDIA_CHANGE);
-#endif
+ scsi_device_event_notify(dev-sdev, 1UL SDEV_MEDIA_CHANGE);
}
/**
Re: [PATCH 1/2] libata: backport ATA_FLAG_NO_SRST and ATA_FLAG_ASSUME_ATA
Jeff Garzik wrote: Tejun Heo wrote: Backport ATA_FLAG_NO_SRST and ATA_FLAG_ASSUME_ATA. These are originally link flags (ATA_LFLAG_*) but link abstraction doesn't exist on 2.6.23, so make it port flags. This is for the following workaround for ASUS P5W DH Deluxe. These new flags don't introduce any behavior change unless set and nobody sets them yet. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- This and the next patch are a bit large for -stable but they don't change anything for machines other than P5W DH and P5W DH users have been suffering long enough, so I think it'll be nice to include these patches in the next -stable release. However, feel free to NACK if you can see some danger in these patches. Jeff, what do you think? drivers/ata/libata-eh.c | 32 include/linux/libata.h |2 ++ 2 files changed, 26 insertions(+), 8 deletions(-) ACK from me, though I wonder if we shouldn't wait and get feedback once this hits upstream (my next push to Andrew and Linus), before applying to stable. No special reason, just being conservative... Agreed. Let's give the upstream changes a few weeks before updating -stable. I'll ping this thread after a few weeks. 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
[git patches] libata updates
A couple small cleanups, the rest fixes.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ahci.c| 144 +
drivers/ata/libata-core.c | 40 ++--
drivers/ata/libata-eh.c | 12 ++--
drivers/ata/pata_icside.c | 42 +++--
drivers/ata/sata_nv.c |6 +-
5 files changed, 195 insertions(+), 49 deletions(-)
Adrian Bunk (1):
libata-core.c: make 2 functions static
Al Viro (1):
Fix pata_icside build for recent libata API changes
Alan Cox (1):
libata-core: Be a bit more relaxed about early DMA zero devices
Jeff Garzik (1):
[libata] Create [and use -ed.] internal helper ata_dev_set_feature()
Kuan Luo (1):
[libata] sata_nv: SWNCQ should not apply to MCP61
Tejun Heo (2):
libata: cosmetic clean up in ata_eh_reset()
ahci: ahci: implement workaround for ASUS P5W-DH Deluxe
ahci_broken_hardreset(), take #2
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 95229e7..49cf4cf 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -41,6 +41,7 @@
#include linux/interrupt.h
#include linux/dma-mapping.h
#include linux/device.h
+#include linux/dmi.h
#include scsi/scsi_host.h
#include scsi/scsi_cmnd.h
#include linux/libata.h
@@ -241,6 +242,7 @@ static void ahci_pmp_attach(struct ata_port *ap);
static void ahci_pmp_detach(struct ata_port *ap);
static void ahci_error_handler(struct ata_port *ap);
static void ahci_vt8251_error_handler(struct ata_port *ap);
+static void ahci_p5wdh_error_handler(struct ata_port *ap);
static void ahci_post_internal_cmd(struct ata_queued_cmd *qc);
static int ahci_port_resume(struct ata_port *ap);
static unsigned int ahci_fill_sg(struct ata_queued_cmd *qc, void *cmd_tbl);
@@ -339,6 +341,40 @@ static const struct ata_port_operations ahci_vt8251_ops = {
.port_stop = ahci_port_stop,
};
+static const struct ata_port_operations ahci_p5wdh_ops = {
+ .check_status = ahci_check_status,
+ .check_altstatus= ahci_check_status,
+ .dev_select = ata_noop_dev_select,
+
+ .tf_read= ahci_tf_read,
+
+ .qc_defer = sata_pmp_qc_defer_cmd_switch,
+ .qc_prep= ahci_qc_prep,
+ .qc_issue = ahci_qc_issue,
+
+ .irq_clear = ahci_irq_clear,
+
+ .scr_read = ahci_scr_read,
+ .scr_write = ahci_scr_write,
+
+ .freeze = ahci_freeze,
+ .thaw = ahci_thaw,
+
+ .error_handler = ahci_p5wdh_error_handler,
+ .post_internal_cmd = ahci_post_internal_cmd,
+
+ .pmp_attach = ahci_pmp_attach,
+ .pmp_detach = ahci_pmp_detach,
+
+#ifdef CONFIG_PM
+ .port_suspend = ahci_port_suspend,
+ .port_resume= ahci_port_resume,
+#endif
+
+ .port_start = ahci_port_start,
+ .port_stop = ahci_port_stop,
+};
+
#define AHCI_HFLAGS(flags) .private_data = (void *)(flags)
static const struct ata_port_info ahci_port_info[] = {
@@ -1213,6 +1249,53 @@ static int ahci_vt8251_hardreset(struct ata_link *link,
unsigned int *class,
return rc ?: -EAGAIN;
}
+static int ahci_p5wdh_hardreset(struct ata_link *link, unsigned int *class,
+ unsigned long deadline)
+{
+ struct ata_port *ap = link-ap;
+ struct ahci_port_priv *pp = ap-private_data;
+ u8 *d2h_fis = pp-rx_fis + RX_FIS_D2H_REG;
+ struct ata_taskfile tf;
+ int rc;
+
+ ahci_stop_engine(ap);
+
+ /* clear D2H reception area to properly wait for D2H FIS */
+ ata_tf_init(link-device, tf);
+ tf.command = 0x80;
+ ata_tf_to_fis(tf, 0, 0, d2h_fis);
+
+ rc = sata_link_hardreset(link, sata_ehc_deb_timing(link-eh_context),
+deadline);
+
+ ahci_start_engine(ap);
+
+ if (rc || ata_link_offline(link))
+ return rc;
+
+ /* spec mandates = 2ms before checking status */
+ msleep(150);
+
+ /* The pseudo configuration device on SIMG4726 attached to
+* ASUS P5W-DH Deluxe doesn't send signature FIS after
+* hardreset if no device is attached to the first downstream
+* port the pseudo device locks up on SRST w/ PMP==0. To
+* work around this, wait for !BSY only briefly. If BSY isn't
+* cleared, perform CLO and proceed to IDENTIFY (achieved by
+* ATA_LFLAG_NO_SRST and ATA_LFLAG_ASSUME_ATA).
+*
+* Wait for two seconds. Devices attached to downstream port
+* which can't process the following IDENTIFY after this will
+* have to be reset again. For most cases, this should
+* suffice while making probing snappish
Re: [PATCH 4/4]: [PCI]: Add MSI INTX_DISABLE quirks for ATI SB700/800 SATA and IXP SB400 USB
From: Shane Huang [EMAIL PROTECTED] Date: Wed, 24 Oct 2007 14:43:21 +0800 This patch and the third one seems can make my SB700 SATA controller work under MSI(simply tested on 2.6.23-rc5). So you may withdraw the RS690/RD580/RX790 MSI disablement patches http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi t;h=4be8f906435a6af241821ab5b94b2b12cb7d57d8 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi t;h=aea6a433f50cd89b9cbd10850fd0b32f961f9883 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi t;h=f122392f679ebed39db08074f935d770504623eb after the commit of these MSI/INTx quirks. Thank you for testing! I will add this change to my patch set. - 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 0/4]: Resolve MSI vs. INTX_DISABLE quirks, V2.
Ok, I've respun the patches including all of the feedback I've obtained. Again, it's at: kernel.org:/pub/scm/linux/kernel/git/davem/msiquirk-2.6.git Greg, I think this stuff is ready to go so if you would pull them in I would really appreciate it. These changes clean up the handling of the common quirk wherein setting INTX_DISABLE will mistakedly disable MSI generation for some devices. For devices without that problem, we want to keep the pci_intx() calls in drivers/pci/msi.c because those help protect against devices with the opposite problem. Such devices always generate INTX interrupts even when MSI is enabled, unless INTX_DISABLE is set. In addition to the Tigon3 cases, I added quirk entries for the SB700/800 SATA chips and the IXP SB400 USB controllers. And as a result of the latter we can remove several AMD full-chipset MSI disable quirks which are no longer necessary. Signed-off-by: David S. Miller [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
[PATCH 1/5]: Revert PCI: disable MSI by default on systems with Serverworks HT1000 chips
This reverts commit e3008dedff4bdc96a5f67224cd3d8d12237082a0. The real bug was an INTX issue in the tg3 ethernet chip, and cured by commit c129d962a66c76964954a98b38586ada82cf9381 Signed-off-by: David S. Miller [EMAIL PROTECTED] --- drivers/pci/quirks.c|1 - include/linux/pci_ids.h |1 - 2 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index d0bb5b9..f5999f5 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1621,7 +1621,6 @@ static void __init quirk_disable_all_msi(struct pci_dev *dev) printk(KERN_WARNING PCI: MSI quirk detected. MSI deactivated.\n); } DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_GCNB_LE, quirk_disable_all_msi); -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_HT1000_PCIX, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS400_200, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS480, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RD580, quirk_disable_all_msi); diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 4e10a07..0571d6a 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -1433,7 +1433,6 @@ #define PCI_DEVICE_ID_SERVERWORKS_LE 0x0009 #define PCI_DEVICE_ID_SERVERWORKS_GCNB_LE 0x0017 #define PCI_DEVICE_ID_SERVERWORKS_EPB0x0103 -#define PCI_DEVICE_ID_SERVERWORKS_HT1000_PCIX 0x0104 #define PCI_DEVICE_ID_SERVERWORKS_HT2000_PCIE 0x0132 #define PCI_DEVICE_ID_SERVERWORKS_OSB4 0x0200 #define PCI_DEVICE_ID_SERVERWORKS_CSB5 0x0201 -- 1.5.2.5 - 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/5]: [PCI]: Add MSI quirk for ServerWorks HT1000 PCIX bridge.
This is the fix for the following problem: https://bugzilla.redhat.com/show_bug.cgi?id=227657 The bnx2 device 5706 complains about MSI not working behind a ServerWorks HT1000 PCIX bridge. An earlier commit to fix the problem: e3008dedff4bdc96a5f67224cd3d8d12237082a0: PCI: disable MSI by default on systems with Serverworks HT1000 chips was not entirely correct, and has been reverted. MSI does not work on the PCIX bus because the BIOS did not set the HT_MSI_FLAGS_ENABLE bit in the HyperTransport MSI capability on the bridge. We use the existing quirk_msi_ht_cap() to detect the problem and disable MSI in all buses behind it. Signed-off-by: Michael Chan [EMAIL PROTECTED] Cc: Anantha Subramanyam [EMAIL PROTECTED] Cc: Naren Sankar [EMAIL PROTECTED] Signed-off-by: David S. Miller [EMAIL PROTECTED] --- drivers/pci/quirks.c|3 +++ include/linux/pci_ids.h |1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index f5999f5..f975f7f 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1677,6 +1677,9 @@ static void __devinit quirk_msi_ht_cap(struct pci_dev *dev) } DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_HT2000_PCIE, quirk_msi_ht_cap); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, + PCI_DEVICE_ID_SERVERWORKS_HT1000_PXB, + quirk_msi_ht_cap); /* The nVidia CK804 chipset may have 2 HT MSI mappings. * MSI are supported if the MSI capability set in any of these mappings. diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 0571d6a..c64bb89 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -1432,6 +1432,7 @@ #define PCI_DEVICE_ID_SERVERWORKS_HE 0x0008 #define PCI_DEVICE_ID_SERVERWORKS_LE 0x0009 #define PCI_DEVICE_ID_SERVERWORKS_GCNB_LE 0x0017 +#define PCI_DEVICE_ID_SERVERWORKS_HT1000_PXB 0x0036 #define PCI_DEVICE_ID_SERVERWORKS_EPB0x0103 #define PCI_DEVICE_ID_SERVERWORKS_HT2000_PCIE 0x0132 #define PCI_DEVICE_ID_SERVERWORKS_OSB4 0x0200 -- 1.5.2.5 - 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/5]: [PCI]: Add quirk for devices which disable MSI when INTX_DISABLE is set.
A reasonably common problem with some devices is that they will
disable MSI generation when the INTX_DISABLE bit is set in the
PCI_COMMAND register.
Quirk this explicitly, guarding the pci_intx() calls in msi.c with
this quirk indication.
The first entries for this quirk are for 5714 and 5780 Tigon3 chips,
and thus we can remove the workaround code from the tg3.c driver.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
Acked-by: Michael Chan [EMAIL PROTECTED]
---
drivers/net/tg3.c|9 -
drivers/pci/msi.c| 18 --
drivers/pci/quirks.c | 24
include/linux/pci.h |9 +
4 files changed, 45 insertions(+), 15 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 09440d7..cad5199 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -7365,10 +7365,6 @@ static int tg3_open(struct net_device *dev)
} else if (pci_enable_msi(tp-pdev) == 0) {
u32 msi_mode;
- /* Hardware bug - MSI won't work if INTX disabled. */
- if (tp-tg3_flags2 TG3_FLG2_5780_CLASS)
- pci_intx(tp-pdev, 1);
-
msi_mode = tr32(MSGINT_MODE);
tw32(MSGINT_MODE, msi_mode | MSGINT_MODE_ENABLE);
tp-tg3_flags2 |= TG3_FLG2_USING_MSI;
@@ -12681,11 +12677,6 @@ static int tg3_resume(struct pci_dev *pdev)
if (err)
return err;
- /* Hardware bug - MSI won't work if INTX disabled. */
- if ((tp-tg3_flags2 TG3_FLG2_5780_CLASS)
- (tp-tg3_flags2 TG3_FLG2_USING_MSI))
- pci_intx(tp-pdev, 1);
-
netif_device_attach(dev);
tg3_full_lock(tp, 0);
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 87e0161..07c9f09 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -224,6 +224,12 @@ static struct msi_desc* alloc_msi_entry(void)
return entry;
}
+static void pci_intx_for_msi(struct pci_dev *dev, int enable)
+{
+ if (!(dev-dev_flags PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG))
+ pci_intx(dev, enable);
+}
+
#ifdef CONFIG_PM
static void __pci_restore_msi_state(struct pci_dev *dev)
{
@@ -237,7 +243,7 @@ static void __pci_restore_msi_state(struct pci_dev *dev)
entry = get_irq_msi(dev-irq);
pos = entry-msi_attrib.pos;
- pci_intx(dev, 0); /* disable intx */
+ pci_intx_for_msi(dev, 0);
msi_set_enable(dev, 0);
write_msi_msg(dev-irq, entry-msg);
if (entry-msi_attrib.maskbit)
@@ -260,7 +266,7 @@ static void __pci_restore_msix_state(struct pci_dev *dev)
return;
/* route the table */
- pci_intx(dev, 0); /* disable intx */
+ pci_intx_for_msi(dev, 0);
msix_set_enable(dev, 0);
list_for_each_entry(entry, dev-msi_list, list) {
@@ -343,7 +349,7 @@ static int msi_capability_init(struct pci_dev *dev)
}
/* Set MSI enabled bits */
- pci_intx(dev, 0); /* disable intx */
+ pci_intx_for_msi(dev, 0);
msi_set_enable(dev, 1);
dev-msi_enabled = 1;
@@ -433,7 +439,7 @@ static int msix_capability_init(struct pci_dev *dev,
i++;
}
/* Set MSI-X enabled bits */
- pci_intx(dev, 0); /* disable intx */
+ pci_intx_for_msi(dev, 0);
msix_set_enable(dev, 1);
dev-msix_enabled = 1;
@@ -528,7 +534,7 @@ void pci_disable_msi(struct pci_dev* dev)
return;
msi_set_enable(dev, 0);
- pci_intx(dev, 1); /* enable intx */
+ pci_intx_for_msi(dev, 1);
dev-msi_enabled = 0;
BUG_ON(list_empty(dev-msi_list));
@@ -640,7 +646,7 @@ void pci_disable_msix(struct pci_dev* dev)
return;
msix_set_enable(dev, 0);
- pci_intx(dev, 1); /* enable intx */
+ pci_intx_for_msi(dev, 1);
dev-msix_enabled = 0;
msix_free_all_irqs(dev);
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index f975f7f..9e8c7af 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1707,4 +1707,28 @@ static void __devinit
quirk_nvidia_ck804_msi_ht_cap(struct pci_dev *dev)
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_CK804_PCIE,
quirk_nvidia_ck804_msi_ht_cap);
+
+static void __devinit quirk_msi_intx_disable_bug(struct pci_dev *dev)
+{
+ dev-dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM,
+ PCI_DEVICE_ID_TIGON3_5780,
+ quirk_msi_intx_disable_bug);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM,
+ PCI_DEVICE_ID_TIGON3_5780S,
+ quirk_msi_intx_disable_bug);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM,
+ PCI_DEVICE_ID_TIGON3_5714,
+
[PATCH 4/5]: [PCI]: Add MSI INTX_DISABLE quirks for ATI SB700/800 SATA and IXP SB400 USB
Signed-off-by: David S. Miller [EMAIL PROTECTED] --- drivers/pci/quirks.c | 20 1 files changed, 20 insertions(+), 0 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 9e8c7af..d8f2d89 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1731,4 +1731,24 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5715S, quirk_msi_intx_disable_bug); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4390, + quirk_msi_intx_disable_bug); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4391, + quirk_msi_intx_disable_bug); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4392, + quirk_msi_intx_disable_bug); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4393, + quirk_msi_intx_disable_bug); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4394, + quirk_msi_intx_disable_bug); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4395, + quirk_msi_intx_disable_bug); + +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4373, + quirk_msi_intx_disable_bug); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4374, + quirk_msi_intx_disable_bug); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x4375, + quirk_msi_intx_disable_bug); + #endif /* CONFIG_PCI_MSI */ -- 1.5.2.5 - 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 5/5]: [PCI]: Remove 3 incorrect MSI quirks.
Now that we have dealt with the real issue, in that some ATI SATA and USB controllers needed the INTX_DISABLE quirk, we can remove these AMD chipset global MSI disabling quirks. This reverts three changesets: 4be8f906435a6af241821ab5b94b2b12cb7d57d8 (PCI: disable MSI on RS690) aea6a433f50cd89b9cbd10850fd0b32f961f9883 (PCI: disable MSI on RD580) f122392f679ebed39db08074f935d770504623eb (PCI: disable MSI on RX790) This is based upon testing and feedback from Shane Huang [EMAIL PROTECTED]. Signed-off-by: David S. Miller [EMAIL PROTECTED] --- drivers/pci/quirks.c|3 --- include/linux/pci_ids.h |3 --- 2 files changed, 0 insertions(+), 6 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index d8f2d89..26cc4dc 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1623,9 +1623,6 @@ static void __init quirk_disable_all_msi(struct pci_dev *dev) DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_GCNB_LE, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS400_200, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS480, quirk_disable_all_msi); -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RD580, quirk_disable_all_msi); -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RX790, quirk_disable_all_msi); -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS690, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VT3351, quirk_disable_all_msi); /* Disable MSI on chipsets that are known to not support it */ diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index c64bb89..e66af5d 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -360,9 +360,6 @@ #define PCI_DEVICE_ID_ATI_RS400_166 0x5a32 #define PCI_DEVICE_ID_ATI_RS400_200 0x5a33 #define PCI_DEVICE_ID_ATI_RS480 0x5950 -#define PCI_DEVICE_ID_ATI_RD5800x5952 -#define PCI_DEVICE_ID_ATI_RX7900x5957 -#define PCI_DEVICE_ID_ATI_RS6900x7910 /* ATI IXP Chipset */ #define PCI_DEVICE_ID_ATI_IXP200_IDE 0x4349 #define PCI_DEVICE_ID_ATI_IXP200_SMBUS 0x4353 -- 1.5.2.5 - 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] ata: ahci: Enable enclosure management via LED (resend)
On Thu, October 25, 2007 07:58, Jeff Garzik wrote: Kristen Carlson Accardi wrote: Enable enclosure management via LED As described in the AHCI spec, some AHCI controllers may support Enclosure management via a variety of protocols. This patch adds support for the LED message type that is specified in AHCI 1.1 and higher. Comments: ... 8) when is this actually used? do you have a sample user in userspace? does a userspace daemon watch disk activity and manage LEDs somehow? I'm a bit cloudy on the usage need of this. I think the idea is that if mdadm (for example) kicks out a faulty disk from an array, it could also activate a LED (usually a different LED than the disk activity LED) on the corresponding enclosure so that the admin knows when standing in front of the storage server which disk to pull out and replace. -- David Härdeman - 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 0/5]: Resolve MSI vs. INTX_DISABLE quirks, V2.
David Miller wrote: Ok, I've respun the patches including all of the feedback I've obtained. Again, it's at: kernel.org:/pub/scm/linux/kernel/git/davem/msiquirk-2.6.git Greg, I think this stuff is ready to go so if you would pull them in I would really appreciate it. These changes clean up the handling of the common quirk wherein setting INTX_DISABLE will mistakedly disable MSI generation for some devices. For devices without that problem, we want to keep the pci_intx() calls in drivers/pci/msi.c because those help protect against devices with the opposite problem. Such devices always generate INTX interrupts even when MSI is enabled, unless INTX_DISABLE is set. In addition to the Tigon3 cases, I added quirk entries for the SB700/800 SATA chips and the IXP SB400 USB controllers. And as a result of the latter we can remove several AMD full-chipset MSI disable quirks which are no longer necessary. Signed-off-by: David S. Miller [EMAIL PROTECTED] [corrected subject line s/4/5/. the actual patches are OK] Acked-by: Jeff Garzik [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: [PATCH] libata: Deal with ATA8-ACS proposed Trusted/Treacherous Computing features
Alan Cox wrote: - Make dword_io check the ATA version speaking of dword_io, it would be nice to add 32-bit functions for I/O rather than hand-rolling like pdc_data_xfer_vlb() does. 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
[PATCH #upstream] libata: relocate and fix post-command processing
Some commands need post-processing after successful completion. This
was done in ata_scsi_qc_complete() till now but this has the following
problems.
* Post-command processing gets executed when qc is completed from EH.
Some qc's are retried from EH with zero err_mask and thus triggers
unnecessary/incorrect post-command processing.
* Command post processing doesn't belong to SAT layer.
* Link-wide revalidation was scheduled where device revalidation
suffices.
This patch moves post-command processing to success completion path of
ata_qc_complete() which is travelled iff the command is going to be
completed without passing through EH and updates post-command
processing such that device-specific action is used. While at it,
restructure code a bit for readability.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/libata-core.c | 20
drivers/ata/libata-scsi.c | 23 ---
2 files changed, 20 insertions(+), 23 deletions(-)
Index: work/drivers/ata/libata-core.c
===
--- work.orig/drivers/ata/libata-core.c
+++ work/drivers/ata/libata-core.c
@@ -5594,6 +5594,9 @@ void ata_qc_complete(struct ata_queued_c
* taken care of.
*/
if (ap-ops-error_handler) {
+ struct ata_device *dev = qc-dev;
+ struct ata_eh_info *ehi = dev-link-eh_info;
+
WARN_ON(ap-pflags ATA_PFLAG_FROZEN);
if (unlikely(qc-err_mask))
@@ -5612,6 +5615,23 @@ void ata_qc_complete(struct ata_queued_c
if (qc-flags ATA_QCFLAG_RESULT_TF)
fill_result_tf(qc);
+ /* Some commands need post-processing after successful
+* completion.
+*/
+ switch (qc-tf.command) {
+ case ATA_CMD_SET_FEATURES:
+ if (qc-tf.feature != SETFEATURES_WC_ON
+ qc-tf.feature != SETFEATURES_WC_OFF)
+ break;
+ /* fall through */
+ case ATA_CMD_INIT_DEV_PARAMS: /* CHS translation changed */
+ case ATA_CMD_SET_MULTI: /* multi_count changed */
+ /* revalidate device */
+ ehi-dev_action[dev-devno] |= ATA_EH_REVALIDATE;
+ ata_port_schedule_eh(ap);
+ break;
+ }
+
__ata_qc_complete(qc);
} else {
if (qc-flags ATA_QCFLAG_EH_SCHEDULED)
Index: work/drivers/ata/libata-scsi.c
===
--- work.orig/drivers/ata/libata-scsi.c
+++ work/drivers/ata/libata-scsi.c
@@ -1361,33 +1361,10 @@ nothing_to_do:
static void ata_scsi_qc_complete(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc-ap;
- struct ata_eh_info *ehi = qc-dev-link-eh_info;
struct scsi_cmnd *cmd = qc-scsicmd;
u8 *cdb = cmd-cmnd;
int need_sense = (qc-err_mask != 0);
- /* We snoop the SET_FEATURES - Write Cache ON/OFF command, and
-* schedule EH_REVALIDATE operation to update the IDENTIFY DEVICE
-* cache
-*/
- if (ap-ops-error_handler !need_sense) {
- switch (qc-tf.command) {
- case ATA_CMD_SET_FEATURES:
- if ((qc-tf.feature == SETFEATURES_WC_ON) ||
- (qc-tf.feature == SETFEATURES_WC_OFF)) {
- ehi-action |= ATA_EH_REVALIDATE;
- ata_port_schedule_eh(ap);
- }
- break;
-
- case ATA_CMD_INIT_DEV_PARAMS: /* CHS translation changed */
- case ATA_CMD_SET_MULTI: /* multi_count changed */
- ehi-action |= ATA_EH_REVALIDATE;
- ata_port_schedule_eh(ap);
- break;
- }
- }
-
/* For ATA pass thru (SAT) commands, generate a sense block if
* user mandated it or if there's an error. Note that if we
* generate because the user forced us to, a check condition
-
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 #upstream] libata: relocate and fix post-command processing
Tejun Heo wrote: Some commands need post-processing after successful completion. This was done in ata_scsi_qc_complete() till now but this has the following problems. * Post-command processing gets executed when qc is completed from EH. Some qc's are retried from EH with zero err_mask and thus triggers unnecessary/incorrect post-command processing. * Command post processing doesn't belong to SAT layer. * Link-wide revalidation was scheduled where device revalidation suffices. This patch moves post-command processing to success completion path of ata_qc_complete() which is travelled iff the command is going to be completed without passing through EH and updates post-command processing such that device-specific action is used. While at it, restructure code a bit for readability. Signed-off-by: Tejun Heo [EMAIL PROTECTED] applied now if only I had a way for the SAT to issue CHECK POWER MODE (used in TEST UNIT READY translation), and inspect qc-err_mask before EH gets its hands on it... :) - 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 #upstream] libata: track SLEEP state and issue SRST to wake it up
Tejun Heo wrote: ATA devices in SLEEP mode don't respond to any commands. SRST is necessary to wake it up. Till now, when a command is issued to a device in SLEEP mode, the command times out, which makes EH reset the device and retry the command after that, causing a long delay. This patch makes libata track SLEEP state and issue SRST automatically if a command is about to be issued to a device in SLEEP. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Bruce Allen [EMAIL PROTECTED] Cc: Andrew Paprocki [EMAIL PROTECTED] --- This patch is against #upstream + relocate-and-fix-post-command-processing patch (http://article.gmane.org/gmane.linux.ide/24001) The infinite loop with the previous patch wasn't caused by bug in sleep state tracking. It was happening because post-command processing was being performed for commands which are being retried from EH, so what happened was. 1. device is flagged SLEEPING 2. SLEEP is issued, as device is sleeping, EH is rescheduled against the qc for SLEEP. 3. EH kicks in and wakes up the device and clears SLEEPING. 4. EH finishes up failed qc which triggers post-command processing and sets SLEEPING. 5. SCSI command is retried, go back to #2. relocate-and-fix-post-command-processing patch fixes the original bug in post-command processing and this patch doesn't cause infinite loop anymore. drivers/ata/libata-core.c | 12 drivers/ata/libata-eh.c |4 +++- include/linux/ata.h |1 + include/linux/libata.h|1 + 4 files changed, 17 insertions(+), 1 deletion(-) applied, both of these changes were nice improvements, as well as fixing problems - 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 #upstream] libata: relocate and fix post-command processing
Jeff Garzik wrote: Tejun Heo wrote: Some commands need post-processing after successful completion. This was done in ata_scsi_qc_complete() till now but this has the following problems. * Post-command processing gets executed when qc is completed from EH. Some qc's are retried from EH with zero err_mask and thus triggers unnecessary/incorrect post-command processing. * Command post processing doesn't belong to SAT layer. * Link-wide revalidation was scheduled where device revalidation suffices. This patch moves post-command processing to success completion path of ata_qc_complete() which is travelled iff the command is going to be completed without passing through EH and updates post-command processing such that device-specific action is used. While at it, restructure code a bit for readability. Signed-off-by: Tejun Heo [EMAIL PROTECTED] applied now if only I had a way for the SAT to issue CHECK POWER MODE (used in TEST UNIT READY translation), and inspect qc-err_mask before EH gets its hands on it... :) Yeah, yeah, SAT error pass-through is coming. :-) -- 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: track SLEEP state and issue SRST to wake it up
ATA devices in SLEEP mode don't respond to any commands. SRST is
necessary to wake it up. Till now, when a command is issued to a
device in SLEEP mode, the command times out, which makes EH reset the
device and retry the command after that, causing a long delay.
This patch makes libata track SLEEP state and issue SRST automatically
if a command is about to be issued to a device in SLEEP.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Bruce Allen [EMAIL PROTECTED]
Cc: Andrew Paprocki [EMAIL PROTECTED]
---
This patch is against
#upstream
+ relocate-and-fix-post-command-processing patch
(http://article.gmane.org/gmane.linux.ide/24001)
The infinite loop with the previous patch wasn't caused by bug in
sleep state tracking. It was happening because post-command
processing was being performed for commands which are being retried
from EH, so what happened was.
1. device is flagged SLEEPING
2. SLEEP is issued, as device is sleeping, EH is rescheduled against
the qc for SLEEP.
3. EH kicks in and wakes up the device and clears SLEEPING.
4. EH finishes up failed qc which triggers post-command processing and
sets SLEEPING.
5. SCSI command is retried, go back to #2.
relocate-and-fix-post-command-processing patch fixes the original bug
in post-command processing and this patch doesn't cause infinite loop
anymore.
drivers/ata/libata-core.c | 12
drivers/ata/libata-eh.c |4 +++-
include/linux/ata.h |1 +
include/linux/libata.h|1 +
4 files changed, 17 insertions(+), 1 deletion(-)
Index: work/include/linux/ata.h
===
--- work.orig/include/linux/ata.h
+++ work/include/linux/ata.h
@@ -180,6 +180,7 @@ enum {
ATA_CMD_VERIFY_EXT = 0x42,
ATA_CMD_STANDBYNOW1 = 0xE0,
ATA_CMD_IDLEIMMEDIATE = 0xE1,
+ ATA_CMD_SLEEP = 0xE6,
ATA_CMD_INIT_DEV_PARAMS = 0x91,
ATA_CMD_READ_NATIVE_MAX = 0xF8,
ATA_CMD_READ_NATIVE_MAX_EXT = 0x27,
Index: work/include/linux/libata.h
===
--- work.orig/include/linux/libata.h
+++ work/include/linux/libata.h
@@ -138,6 +138,7 @@ enum {
ATA_DFLAG_PIO = (1 12), /* device limited to PIO mode */
ATA_DFLAG_NCQ_OFF = (1 13), /* device limited to non-NCQ mode
*/
ATA_DFLAG_SPUNDOWN = (1 14), /* XXX: for spindown_compat */
+ ATA_DFLAG_SLEEPING = (1 15), /* device is sleeping */
ATA_DFLAG_INIT_MASK = (1 16) - 1,
ATA_DFLAG_DETACH= (1 16),
Index: work/drivers/ata/libata-core.c
===
--- work.orig/drivers/ata/libata-core.c
+++ work/drivers/ata/libata-core.c
@@ -5630,6 +5630,10 @@ void ata_qc_complete(struct ata_queued_c
ehi-dev_action[dev-devno] |= ATA_EH_REVALIDATE;
ata_port_schedule_eh(ap);
break;
+
+ case ATA_CMD_SLEEP:
+ dev-flags |= ATA_DFLAG_SLEEPING;
+ break;
}
__ata_qc_complete(qc);
@@ -5769,6 +5773,14 @@ void ata_qc_issue(struct ata_queued_cmd
qc-flags = ~ATA_QCFLAG_DMAMAP;
}
+ /* if device is sleeping, schedule softreset and abort the link */
+ if (unlikely(qc-dev-flags ATA_DFLAG_SLEEPING)) {
+ link-eh_info.action |= ATA_EH_SOFTRESET;
+ ata_ehi_push_desc(link-eh_info, waking up from sleep);
+ ata_link_abort(link);
+ return;
+ }
+
ap-ops-qc_prep(qc);
qc-err_mask |= ap-ops-qc_issue(qc);
Index: work/drivers/ata/libata-eh.c
===
--- work.orig/drivers/ata/libata-eh.c
+++ work/drivers/ata/libata-eh.c
@@ -2208,9 +2208,11 @@ int ata_eh_reset(struct ata_link *link,
ata_link_for_each_dev(dev, link) {
/* After the reset, the device state is PIO 0
* and the controller state is undefined.
-* Record the mode.
+* Reset also wakes up drives from sleeping
+* mode.
*/
dev-pio_mode = XFER_PIO_0;
+ dev-flags = ~ATA_DFLAG_SLEEPING;
if (ata_link_offline(link))
continue;
-
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
What's left in libata-dev.git?
This is a summary of items and issues that remain outstanding for libata. Whenever a git branch is mentioned, it is referring to a branch at git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git Current push just sent to Linus: http://marc.info/?l=linux-idem=119329974119307w=2 Changes in 'upstream' branch pending for 2.6.24-rc, but not included in the above push: Tejun Heo (2): libata: relocate and fix post-command processing libata: track SLEEP state and issue SRST to wake it up Active libata branches: ALL Superset branch for -mm testing alpm Link power management (2.6.24-rc hopefully) anAsync notify (2.6.24-rc hopefully) for-testing Interesting-but-not-ready stuff masterVanilla linux-2.6.git clone mv-ahci-pata Marvell 6141 PATA support (incomplete) mv-ncqsata_mv NCQ support (incomplete) new-ehsata_qstore, sata_sx4 new-EH conversions (TEST ME! they have been in -mm for a while) pmask proto_mask introduction sii-lbt sata_sil large block transfer enablement upstream pending for 2.6.24-rc upstream-linusjust pushed upstream for 2.6.24-rc Patches and tasks in mbox queue, not yet in git: 1) Axboe: kill sg_last(), libata is last remaining user 2) Bart points out bugs in Re: [git patches] libata update 3) Tejun: libata: implement ata_wait_after_reset() ^^^ Tejun, what case does this solve? Still needed? 4) Alan: [PATCH] libata: Deal with ATA8-ACS proposed Trusted/Treacherous Computing features 5) Need a pass through bz.kernel.org Please speak up if there is something missing. 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: What's left in libata-dev.git?
Jeff Garzik wrote: Active libata branches: ALLSuperset branch for -mm testing alpmLink power management (2.6.24-rc hopefully) anAsync notify (2.6.24-rc hopefully) for-testingInteresting-but-not-ready stuff masterVanilla linux-2.6.git clone mv-ahci-pataMarvell 6141 PATA support (incomplete) mv-ncqsata_mv NCQ support (incomplete) new-ehsata_qstore, sata_sx4 new-EH conversions (TEST ME! they have been in -mm for a while) pmaskproto_mask introduction sii-lbtsata_sil large block transfer enablement upstreampending for 2.6.24-rc upstream-linusjust pushed upstream for 2.6.24-rc FWIW, current contents of ALL meta-branch: upstream an alpm for-testing new-eh i.e. that is what akpm will get on his next pull for -mm. - 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 2/4] libata: implement ata_wait_after_reset()
[EMAIL PROTECTED] wrote: From: Tejun Heo [EMAIL PROTECTED] On certain device/controller combination, 0xff status is asserted after reset and doesn't get cleared during 150ms post-reset wait. As 0xff status is interpreted as no device (for good reasons), this can lead to misdetection on such cases. This patch implements ata_wait_after_reset() which replaces the 150ms sleep and waits upto ATA_TMOUT_FF_WAIT if status is 0xff. ATA_TMOUT_FF_WAIT is currently 800ms which is enough for HHD424020F7SV00 to get detected but not enough for Quantum GoVault drive which is known to take upto 2s. Without parallel probing, spending 2s on 0xff port would incur too much delay on ata_piix's which use 0xff to indicate empty port and doesn't have SCR register, so GoVault needs to wait till parallel probing. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/ata/ahci.c | 11 + drivers/ata/libata-core.c | 67 +++--- drivers/ata/pata_scc.c | 13 +- drivers/ata/sata_inic162x.c |2 - include/linux/libata.h |8 5 files changed, 67 insertions(+), 34 deletions(-) applied - 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
PMP device port link speed issues
While testing the sata_fsl driver with a Sil3726 based PMP, we had a specific configuration where the host port to PMP link speed was 1.5Gbps, while the PMP has configured it's device port(s) link speed to 3Gbps. This configuration causes NCQ hangs on certain Seagate drives, probably because of the link speed difference between host and PMP device PMP device ports and drives. Does it makes sense to limit the PMP device port link speeds to the host port link speed ? I believe currently sata_pmp_attach() is calling sata_link_init_spd() for each PMP device port and thus causing PMP device port link speeds being configured independent of host port link speed. Probably the PMP device port links should be limited to the host link speed. Thanks, Ashish Kalra. Freescale Semiconductor. - 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: PMP device port link speed issues
Kalra Ashish-B00888 wrote: While testing the sata_fsl driver with a Sil3726 based PMP, we had a specific configuration where the host port to PMP link speed was 1.5Gbps, while the PMP has configured it's device port(s) link speed to 3Gbps. This configuration causes NCQ hangs on certain Seagate drives, probably because of the link speed difference between host and PMP device PMP device ports and drives. Does it makes sense to limit the PMP device port link speeds to the host port link speed ? I believe currently sata_pmp_attach() is calling sata_link_init_spd() for each PMP device port and thus causing PMP device port link speeds being configured independent of host port link speed. Probably the PMP device port links should be limited to the host link speed. Interesting question. I'm sure Tejun will chime in, but I'm wondering if there is any real use -- even theoretical -- for running downstream links faster than the host-PMP link? 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
2.6.24-rc1, sata_nv: MCP51 is boned with SWNCQ too
Hi, I've noticed a thread reporting that SWNCQ can't be disabled on the sata_nv. Gerhard Dirschl * BUG: sata_nv swncq cannot be disabled and another with a patch switching MCP61 to GENERIC instead of SWNCQ Kuan Luo * [PATCH] ata: sata_nv MCP61 using GENERIC instead of SWNCQ I would like to to report that the MCP51 on my Asus A8NVM CSM mainboard is dead due to timeouts with SWNCQ. Reverting sata_nv.c to the version prior to git commit f140f0f12fc8dc7264d2f97cbe663564e7d24f6d works around the problem. My drives are all Seagate drives, ST3320620AS, ST3500630AS, ST3300831AS. Not subscribed, please CC. Andrew - 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: 2.6.24-rc1, sata_nv: MCP51 is boned with SWNCQ too
Andrew wrote: Hi, I've noticed a thread reporting that SWNCQ can't be disabled on the sata_nv. Gerhard Dirschl * BUG: sata_nv swncq cannot be disabled and another with a patch switching MCP61 to GENERIC instead of SWNCQ Kuan Luo * [PATCH] ata: sata_nv MCP61 using GENERIC instead of SWNCQ I would like to to report that the MCP51 on my Asus A8NVM CSM mainboard is dead due to timeouts with SWNCQ. Reverting sata_nv.c to the version prior to git commit f140f0f12fc8dc7264d2f97cbe663564e7d24f6d works around the problem. My drives are all Seagate drives, ST3320620AS, ST3500630AS, ST3300831AS. Really? That's a showstopper bug, as swncq is supposed to be disabled by default. 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: 2.6.24-rc1, sata_nv: MCP51 is boned with SWNCQ too
On Thu, October 25, 2007 11:48, Jeff Garzik wrote: Really? That's a showstopper bug, as swncq is supposed to be disabled by default. Jeff Well I have sata_nv compiled in rather than a module loaded by initrd (If thats even possible?) and passing sata_nv.swncq=0 or swncq=0 to the kernel did nothing (Gaah, my kernel params, they do nothing!) I will post again shortly with a netconsole log from a fresh 2.6.24-rc1 build. - 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: 2.6.24-rc1, sata_nv: MCP51 is boned with SWNCQ too
Hi,
On Thursday 25 October 2007, Jeff Garzik wrote:
Andrew wrote:
Hi,
I've noticed a thread reporting that SWNCQ can't be disabled
on the sata_nv.
Gerhard Dirschl
* BUG: sata_nv swncq cannot be disabled
and another with a patch switching MCP61 to GENERIC instead
of SWNCQ
Kuan Luo
* [PATCH] ata: sata_nv MCP61 using GENERIC instead of SWNCQ
I would like to to report that the MCP51 on my Asus A8NVM CSM
mainboard is dead due to timeouts with SWNCQ. Reverting sata_nv.c
to the version prior to git commit
f140f0f12fc8dc7264d2f97cbe663564e7d24f6d works around the problem.
My drives are all Seagate drives, ST3320620AS, ST3500630AS,
ST3300831AS.
Really? That's a showstopper bug, as swncq is supposed to be disabled
by default.
From the quick look:
static int nv_init_one (struct pci_dev *pdev, const struct pci_device_id *ent)
...
ppi[0] = nv_port_info[type];
...
if (type == ADMA) {
rc = nv_adma_host_init(host);
if (rc)
return rc;
} else if (type == SWNCQ swncq_enabled) {
-- this is the only place when swncq_enabled is read
dev_printk(KERN_NOTICE, pdev-dev, Using SWNCQ mode\n);
nv_swncq_host_init(host);
-- nw_swncq_host_init() controls only _hardware_ side of SWNCQ enable
}
pci_set_master(pdev);
return ata_host_activate(host, pdev-irq, ppi[0]-irq_handler,
IRQF_SHARED, ppi[0]-sht);
-- since ppi[0] _always_ points nv_port_info[SWNCQ], it could happen
that if SWNCQ has already been enabled by BIOS/firmware swncq_enabled
setting will be ignored
...
If this is the case the obvious fix will be to s/SWNCQ/GENERIC/ in
nv_pci_tbl[] and assign ppi[0] to nv_port_info[SWNCQ] in nv_init_one()
only if (type == GENERIC swncq_enabled).
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: Warnings on shutdown (Debian Etch and Kernel 2.6.22.9)
Tejun Heo wrote: Renato S. Yamane wrote: Jim Paris wrote: For Debian, I don't think there are any complete solutions yet. The related bug is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224 I think that we can fix this if someone can answer this: $ man halt -h flag: This is important for IDE drives, since the kernel doesn’t flush the write cache itself before power-off.. How can I know if kernel write cache itself? :-) Kernel has been flushing write cache for many many years now. Man page needs update. Also, flushing cache from halt is okay. What's hurting is spinning down the drive from halt. So, I think that halt script need know: - How many and who is IDE drives and SCSI/SATA drives. - Devices with manage_start_stop as 0 or without manage_start_stop need halt -h. - Devices with manage_start_stop as 1 need only halt. This is correct? Regards, Renato - 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: 2.6.24-rc1, sata_nv: MCP51 is boned with SWNCQ too
On Thu, October 25, 2007 12:43, Bartlomiej Zolnierkiewicz wrote:
From the quick look:
static int nv_init_one (struct pci_dev *pdev, const struct pci_device_id
*ent) ...
ppi[0] = nv_port_info[type]; ...
if (type == ADMA) { rc = nv_adma_host_init(host); if (rc) return rc; } else
if (type ==
SWNCQ
swncq_enabled) {
-- this is the only place when swncq_enabled is read
dev_printk(KERN_NOTICE, pdev-dev, Using SWNCQ mode\n);
nv_swncq_host_init(host);
-- nw_swncq_host_init() controls only _hardware_ side of SWNCQ enable
}
pci_set_master(pdev); return ata_host_activate(host, pdev-irq,
ppi[0]-irq_handler,
IRQF_SHARED, ppi[0]-sht);
-- since ppi[0] _always_ points nv_port_info[SWNCQ], it could happen
that if SWNCQ has already been enabled by BIOS/firmware swncq_enabled setting
will be ignored
...
If this is the case the obvious fix will be to s/SWNCQ/GENERIC/ in
nv_pci_tbl[] and assign ppi[0] to nv_port_info[SWNCQ] in nv_init_one() only
if (type == GENERIC
swncq_enabled).
Thanks,
Bart
Hi,
I think my netconsole log will confirm your analysis.
It's available here:
http://andotnet.nfshost.com/linux/2.6.24-rc1-swncq.txt
Notice that Using SWNCQ mode is not printed.
Andrew.
-
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] Fix build bug
CC drivers/ide/pci/generic.o
drivers/ide/pci/generic.c:52: error: __setup_str_ide_generic_all_on causes a
+section type conflict
This sort of build error is becoming a regular issue. Either all or non
of the elements that go into a particular section of a compilation unit
need to be const. Or an error may result such as in this case if
CONFIG_HOTPLUG is unset.
Maybe worth a check in checkpatch.pl - but certainly gcc's interolerance
is also being less than helpful here.
---
drivers/ide/pci/generic.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ide/pci/generic.c b/drivers/ide/pci/generic.c
index f44d708..0047684 100644
--- a/drivers/ide/pci/generic.c
+++ b/drivers/ide/pci/generic.c
@@ -67,7 +67,7 @@ MODULE_PARM_DESC(all_generic_ide, IDE generic will claim all
unknown PCI IDE st
.udma_mask = ATA_UDMA6, \
}
-static const struct ide_port_info generic_chipsets[] __devinitdata = {
+static struct ide_port_info generic_chipsets[] __devinitdata = {
/* 0 */ DECLARE_GENERIC_PCI_DEV(Unknown, 0),
{ /* 1 */
-
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] Add a global ide=off switch for drivers/ide
On Thursday 25 October 2007 23:07:23 Bartlomiej Zolnierkiewicz wrote: On Monday 15 October 2007, Andi Kleen wrote: Had a situation where drivers/ide was compiled in, but I wanted to turn it off to let the drivers/ata drivers take over. I ended up using ide*=noprobe, but that was somewhat clumpsy because I wasn't sure how many IDE interfaces the machine really had. Add a global ide=off switch to handle this situation better. Overall looks OK but I think we should limit it to IDE built-in case (when IDE is modular it is all up to the user-space anyway). Disagree. It's useful for the modular case too e.g. if you have the ide modules in your initrd and you want to not load them for some reason (e.g. debugging) Besides adding so many ifdefs would be ugly in my opinion. The patch is a little bigger because I tried to cover all modules. A few still needs to be covered: - drivers/scsi/ide-scsi.c (other directory) - drivers/ide/legacy/ide_platform.c (new driver) - drivers/ide/legacy/ide-cs.c (late_initcall) - drivers/ide/pci/sgiioc4.c (ditto, not a SFF-PCI driver) Thanks I'll fix those. I'm also not 100% sure ENODEV is the right error return for this case, but I didn't come up with a better one. -EPERM? IMO it would be more appropriate (and easy to distinguish from the real -ENODEV). Ok. +int ide_off; +EXPORT_SYMBOL(ide_off); + _GPL? Please cover it with #ifdef/#endif CONFIG_BLK_DEV_IDE as it should be valid only when IDE is built-in. This way we don't pollute device/host drivers with CONFIG_BLK_DEV_IDE #ifdefs. What CONFIG_BLK_DEV_IDE ifdefs? I added the check only to code that is already conditional to this I believe and there were no additional ifdefs at all. -Andi - 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/3] ide: remove IRQF_DISABLED from IRQ flags for IDE IRQ handler
IRQF_DISABLED is not needed because the first thing that ide_intr()
(IDE IRQ handler) does is calling spin_lock_irqsave() which disables
local IRQs (IRQ unmasking is later handled by drive-unmask).
kernel/irq/handle.c:
irqreturn_t handle_IRQ_event(unsigned int irq, struct irqaction *action)
...
if (!(action-flags IRQF_DISABLED))
local_irq_enable_in_hardirq();
do {
ret = action-handler(irq, action-dev_id);
if (ret == IRQ_HANDLED)
status |= action-flags;
retval |= ret;
action = action-next;
} while (action);
...
drivers/ide/ide-io.c:
irqreturn_t ide_intr (int irq, void *dev_id)
...
spin_lock_irqsave(ide_lock, flags);
...
spin_unlock(ide_lock);
...
if (drive-unmask)
local_irq_enable_in_hardirq();
...
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-probe.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
Index: b/drivers/ide/ide-probe.c
===
--- a/drivers/ide/ide-probe.c
+++ b/drivers/ide/ide-probe.c
@@ -974,11 +974,6 @@ static int ide_init_queue(ide_drive_t *d
* Much of the code is for correctly detecting/handling irq sharing
* and irq serialization situations. This is somewhat complex because
* it handles static as well as dynamic (PCMCIA) IDE interfaces.
- *
- * The IRQF_DISABLED in sa_flags means ide_intr() is always entered with
- * interrupts completely disabled. This can be bad for interrupt latency,
- * but anything else has led to problems on some machines. We re-enable
- * interrupts as much as we can safely do in most places.
*/
static int init_irq (ide_hwif_t *hwif)
{
@@ -1061,17 +1056,13 @@ static int init_irq (ide_hwif_t *hwif)
* Allocate the irq, if not already obtained for another hwif
*/
if (!match || match-irq != hwif-irq) {
- int sa = IRQF_DISABLED;
+ int sa = 0;
#if defined(__mc68000__) || defined(CONFIG_APUS)
sa = IRQF_SHARED;
#endif /* __mc68000__ || CONFIG_APUS */
- if (IDE_CHIPSET_IS_PCI(hwif-chipset)) {
+ if (IDE_CHIPSET_IS_PCI(hwif-chipset))
sa = IRQF_SHARED;
-#ifndef CONFIG_IDEPCI_SHARE_IRQ
- sa |= IRQF_DISABLED;
-#endif /* CONFIG_IDEPCI_SHARE_IRQ */
- }
if (hwif-io_ports[IDE_CONTROL_OFFSET])
/* clear nIEN */
-
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/3] ide: fix drive_is_ready() for non-PCI hosts and CONFIG_IDEPCI_SHARE_IRQ=y
Need to check if the host is a PCI one before reading IDE_ALTSTATUS_REG. Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] --- drivers/ide/ide-iops.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: b/drivers/ide/ide-iops.c === --- a/drivers/ide/ide-iops.c +++ b/drivers/ide/ide-iops.c @@ -455,7 +455,7 @@ int drive_is_ready (ide_drive_t *drive) * an interrupt with another pci card/device. We make no assumptions * about possible isa-pnp and pci-pnp issues yet. */ - if (IDE_CONTROL_REG) + if (hwif-pci_dev IDE_CONTROL_REG) stat = hwif-INB(IDE_ALTSTATUS_REG); else #endif /* CONFIG_IDEPCI_SHARE_IRQ */ - 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 2/3] ide: fix drive_is_ready() for non-PCI hosts and CONFIG_IDEPCI_SHARE_IRQ=y
On Friday 26 October 2007, Alan Cox wrote: On Fri, 26 Oct 2007 01:36:37 +0200 Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote: Need to check if the host is a PCI one before reading IDE_ALTSTATUS_REG. Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] Umm why ? The altstatus register goes back to ST-506 and the original IBM XT hard disk controller card ? Thought that there have to be some (non-obvious) reason behing the fact that IDE_ALTSTATUS_REG reading was covered by #ifdef CONFIG_IDEPCI_SHARE_IRQ. However if this is the case patch #2/3 can be dumped and we can go straight to patch #3/3. 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 2/3] drivers/ide/pci/sc1200.c: remove pointless hwif lookup loop
Bartlomiej Zolnierkiewicz wrote:
On Thursday 25 October 2007, Jeff Garzik wrote:
Store our hwif indices at probe time, in order to eliminate a needless
and ugly loop across all hwifs, searching for our pci device.
It seems that we can simplify it even further and remove knowledge about
hwifs altogether from suspend/resume methods.
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
---
drivers/ide/pci/sc1200.c | 76 +++---
1 files changed, 51 insertions(+), 25 deletions(-)
diff --git a/drivers/ide/pci/sc1200.c b/drivers/ide/pci/sc1200.c
index d2c8b55..17e58d6 100644
--- a/drivers/ide/pci/sc1200.c
+++ b/drivers/ide/pci/sc1200.c
@@ -41,6 +41,8 @@
#define PCI_CLK_66 0x02
#define PCI_CLK_33A0x03
+#define SC1200_IFS 4
+
static unsigned short sc1200_get_pci_clock (void)
{
unsigned char chip_id, silicon_revision;
@@ -261,31 +263,32 @@ static void sc1200_set_pio_mode(ide_drive_t *drive, const
u8 pio)
}
#ifdef CONFIG_PM
-static ide_hwif_t *lookup_pci_dev (ide_hwif_t *prev, struct pci_dev *dev)
-{
- int h;
-
- for (h = 0; h MAX_HWIFS; h++) {
- ide_hwif_t *hwif = ide_hwifs[h];
- if (prev) {
- if (hwif == prev)
- prev = NULL;// found previous, now look for
next match
- } else {
- if (hwif hwif-pci_dev == dev)
- return hwif;// found next match
- }
- }
- return NULL;// not found
-}
-
typedef struct sc1200_saved_state_s {
__u32 regs[4];
} sc1200_saved_state_t;
+static unsigned int pack_hwif_idx(u8 *idx)
+{
+ return (((unsigned int) idx[0]) 0) |
+ (((unsigned int) idx[1]) 8) |
+ (((unsigned int) idx[2]) 16) |
+ (((unsigned int) idx[3]) 24);
+}
+
+static ide_hwif_t *sc1200_hwif(struct pci_dev *pdev, unsigned int iface)
+{
+ unsigned int packed_hwifs, idx;
+
+ packed_hwifs = (unsigned long) pci_get_drvdata(pdev);
+ idx = (packed_hwifs (iface * 8)) 0xff;
+
+ return (idx == 0xff) ? NULL : ide_hwifs[idx];
+}
static int sc1200_suspend (struct pci_dev *dev, pm_message_t state)
{
- ide_hwif_t *hwif = NULL;
+ ide_hwif_t *hwif;
+ int i;
printk(SC1200: suspend(%u)\n, state.event);
@@ -295,9 +298,14 @@ static int sc1200_suspend (struct pci_dev *dev, pm_message_t state)
//
// Loop over all interfaces that are part of this PCI device:
//
- while ((hwif = lookup_pci_dev(hwif, dev)) != NULL) {
+ for (i = 0; i SC1200_IFS; i++) {
sc1200_saved_state_t*ss;
unsigned intbasereg, r;
+
+ hwif = sc1200_hwif(dev, i);
+ if (!hwif)
+ continue;
+
//
// allocate a permanent save area, if not already
allocated
//
@@ -310,7 +318,7 @@ static int sc1200_suspend (struct pci_dev *dev,
pm_message_t state)
}
ss = (sc1200_saved_state_t *)hwif-config_data;
//
- // Save timing registers: this may be unnecessary if
+ // Save timing registers: this may be unnecessary if
// BIOS also does it
//
basereg = hwif-channel ? 0x50 : 0x40;
Please take a close look at the line above and the next three lines:
for (r = 0; r 4; ++r) {
pci_read_config_dword (hwif-pci_dev, basereg + (r2), ss-regs[r]);
}
It is highly obfuscated but the sc1200_suspend() reads 16 bytes from
the offset 0x40 (for the primary port) and puts them in the corresponding
struct sc1200_saved_state_s buffer, then it reads another 16 bytes from the
offset 0x50 (for the secondary port) and puts it in the another buffer.
In summary sc1200_suspend() reads 32 continuous bytes from offset 0x40
and the exactly reverse operation happens in sc1200_resume().
Given that and the fact that struct sc1200_save_state_s buffers are used
_only_ by sc1200_{suspend,resume}() we may safely convert the code to use
one buffer for both ports (the whole PCI device). We just need to bump
the size of struct sc1200_saved_state_s (from 4 to 8 double-words) and use
pci_{get,set}_drvdata() instead of hwif-config_data. Then we can remove
looping over interfaces completely from sc1200_{suspend,resume}()! :)
May I assume you'll handle that task? :) It sounds like you have a far
better idea than mine, and my main goal -- fixing bugs and warning -- is
accomplished anyway with the merging of patch #3.
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More
Re: Re-enabling Serial ATA ports possible?
Mikael Pettersson wrote: On Wed, 17 Oct 2007 14:38:04 +0200, Marcin Juszkiewicz wrote: On my system (2.6.23-rc9) I have Serial-ATA DVD/RW drive connected to sata_sil controller. Sometimes when there is a problem with CD or DVD disk controller shutdowns drive: [53560.095573] cdrom: sr0: mrw address space DMA selected [53561.001946] ISO 9660 Extensions: Microsoft Joliet Level 3 [53561.002777] ISOFS: changing to secondary root [53621.380238] ata6.00: exception Emask 0x10 SAct 0x0 SErr 0x9 action 0x2 [53621.380249] ata6.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 [53621.380252] res 51/60:03:00:00:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error) [53621.380263] ata6: hard resetting port [53623.783961] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [53642.595278] ata6.00: qc timeout (cmd 0xa1) [53642.595285] ata6.00: failed to IDENTIFY (I/O error, err_mask=0x4) [53642.595288] ata6.00: revalidation failed (errno=-5) [53642.595292] ata6: failed to recover some devices, retrying in 5 secs [53645.092046] ata6: hard resetting port [53646.193870] ata6: SATA link down (SStatus 1 SControl 310) [53646.193881] ata6.00: limiting speed to UDMA/25:PIO3 [53646.193884] ata6: failed to recover some devices, retrying in 5 secs [53648.690501] ata6: hard resetting port [53649.792323] ata6: SATA link down (SStatus 1 SControl 310) [53649.792333] ata6.00: disabled Care to post full boot log and the result of hdparm -I /dev/sr0? Is there a way to re-enable ata6.00 in other way then power down/power up whole machine? Looks like reboot is not a way to get it working again. If the driver supports SATA hotplugging, then removing the cable, waiting for libata EH to complete, and then inserting it again, should do the trick. You don't have to wait till EH finishes. As long as PHY event is generated, EH should do the right thing. Also, you can trigger rescan by echo - - - /sys/class/scsi_host/hostX/scan. -- 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
Questions about SATA hotplug in linux 2.6
Greetings: I have some questions about SATA HDD/ODD hotplug support in linux. 1. If users unplug one SATA HDD(no-root partition) or SATA ODD when the system is running, then plug it back to the same SATA port, Should the system and SATA HDD/ODD still work well? 2. How about users plug the SATA HDD/ODD in a different SATA port? Should it still work? These questions come up when our QA test our SB700 SATA drivers, but I don't know the SATA hotplug support in linux 2.6. Is there any guy who can give some official confirmation? :-) Thanks Best Regards Shane - 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: seagate disks on sil3114 - slow?
Soeren Sonnenburg wrote: On Thu, 2007-10-18 at 01:07 -0400, Jeff Garzik wrote: Soeren Sonnenburg wrote: Dear all, I just now realize that all disk i.o. on my machine is quite slow compared with the pata disks I had before. Furthermore I recognized that I only have seagates (ST3400832AS,ST3400620AS,ST3750640AS,ST3750640AS) connected to a sil3114 controller. Being on kernel 2.6.23.1 and stumbling across http://home-tj.org/wiki/index.php/Sil_m15w I am now wondering if this patch made it already in kernel (or when it will make it if it is not yet in/why never). Are you sure you have a 3114? the mod15write isn't applied to that chip. Does your dmesg say applying Seagate errata fix (mod15write workaround) ? At least lspci / dmesg indicates I have a 3114 ... but maybe the problem is something else. Is there a raw device speed, readonly benchmark to check whether things are as expected? dd if=/dev/sdX of=/dev/null bs=1M? Also, does changing IO scheduler to deadline make any difference? -- 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: Questions about SATA hotplug in linux 2.6
Shane Huang wrote: 1. If users unplug one SATA HDD(no-root partition) or SATA ODD when the system is running, then plug it back to the same SATA port, Should the system and SATA HDD/ODD still work well? Yes. 2. How about users plug the SATA HDD/ODD in a different SATA port? Should it still work? Yes. For all hotplug-aware libata drivers, you should be able to unplug a SATA device _while_ it is actively reading or writing data, with no ill effects to the kernel. You might lose cached and in-flight data of course, and userspace applications may or may not handle the disappearance of their underlying filesystem with grace and aplomb :) But device hotplug should be reliable from a kernel standpoint [assuming driver support]. These questions come up when our QA test our SB700 SATA drivers, but I don't know the SATA hotplug support in linux 2.6. Is there any guy who can give some official confirmation? :-) The main thing of note with regards to hotplug is that the associated device (/dev/sdb, /dev/scd0, etc.) may change between plug and unplug. For example, if you unplug a SATA HDD then plug it back in, the user might see /dev/sdb disappear, and /dev/sdd appear -- even if it is the exact same HDD, on the exact same port. 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: Questions about SATA hotplug in linux 2.6
Jeff Garzik wrote: Shane Huang wrote: 1. If users unplug one SATA HDD(no-root partition) or SATA ODD when the system is running, then plug it back to the same SATA port, Should the system and SATA HDD/ODD still work well? Yes. To add a bit, libata hotplug has grace time of at least 15secs. If the same device is plugged out and then plugged in in that time, libata considers that the device and/or connection has suffered transient failure and assumes it's the same device and there's no modification to its content. This means that if you disconnect a harddrive, write to it and then connect it back in the grace period corruption will occur. It will be fun to have some sort of competition to actually do this. :-) These questions come up when our QA test our SB700 SATA drivers, but I don't know the SATA hotplug support in linux 2.6. Is there any guy who can give some official confirmation? :-) The main thing of note with regards to hotplug is that the associated device (/dev/sdb, /dev/scd0, etc.) may change between plug and unplug. For example, if you unplug a SATA HDD then plug it back in, the user might see /dev/sdb disappear, and /dev/sdd appear -- even if it is the exact same HDD, on the exact same port. Yeah, using LABEL and/or UUID is a good idea. In the future, it will be nice to have persistent block device name as netdevices do. -- 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: [git patches] libata update
Jeff Garzik wrote: Andrey Borzenkov wrote: Jeff Garzik wrote: * Asynchronous notification -- finally userspace CD-ROM polling can go away! (NOTE: waiting on James B to apply the piece that actually makes this work...) Does it depend on hardware offering suitable support? What are chances for it to work on 5 years old DVD-ROM? Correct -- it requires a new SATA CD-ROM with the AN capability. And some SATA CD-ROMs lie about AN capability and sends nothing when media event occurs. Do we need to start a blacklist or whitelist? :-) -- 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: marvell 88SX6081 and linux 2.6.23.1
jeffunit wrote: I built a kernel, 2.6.23.1 today. My motherboard is an intel stl2, dual pentium 933 motherboard, with about 3gb of ram. I also have a promise tx100 controller with an ata hard drive for the os, and a sony dvdrw drive. There is an intel gigabit ethernet card, and an ati pci video card. I have an 8 port supermicro sata II controller with the marvell 888SX6081 chipset. I have four 500gb sata II maxtor hard drives attached to it. All except /dev/sda1 seem to work fine. When I copy/modify files on /dev/sda1, I get the following dmesg errors: The machine is designed to be a fileserver, but I am happy to help debug this issue to the best of my abilities. When I boot windows xp, xp sees all 4 of the sata drives, and they work without any problems. Please advise, jeff ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: edma_err 0x0084, EDMA self-disable ata1.00: cmd c8/00:08:37:02:90/00:00:00:00:00/e5 tag 0 cdb 0x0 data 4096 in res 51/40:00:37:02:90/00:00:00:00:00/e5 Emask 0x9 (media error) Media errors which is usually localized to certain area of disk. Replace disk. The disk works fine under windows xp. I never got any errors with it and xp. I can swap the first and second hard drive. With the old kernel, the errors stayed with whatever drive was hooked up to the first port of the controller. I will report the results. 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: marvell 88SX6081 and linux 2.6.23.1
jeffunit wrote: jeffunit wrote: I built a kernel, 2.6.23.1 today. My motherboard is an intel stl2, dual pentium 933 motherboard, with about 3gb of ram. I also have a promise tx100 controller with an ata hard drive for the os, and a sony dvdrw drive. There is an intel gigabit ethernet card, and an ati pci video card. I have an 8 port supermicro sata II controller with the marvell 888SX6081 chipset. I have four 500gb sata II maxtor hard drives attached to it. All except /dev/sda1 seem to work fine. When I copy/modify files on /dev/sda1, I get the following dmesg errors: The machine is designed to be a fileserver, but I am happy to help debug this issue to the best of my abilities. When I boot windows xp, xp sees all 4 of the sata drives, and they work without any problems. Please advise, jeff ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: edma_err 0x0084, EDMA self-disable ata1.00: cmd c8/00:08:37:02:90/00:00:00:00:00/e5 tag 0 cdb 0x0 data 4096 in res 51/40:00:37:02:90/00:00:00:00:00/e5 Emask 0x9 (media error) Media errors which is usually localized to certain area of disk. Replace disk. The disk works fine under windows xp. I never got any errors with it and xp. And you were accessing the same region of the drive? I can swap the first and second hard drive. With the old kernel, the errors stayed with whatever drive was hooked up to the first port of the controller. I will report the results. Hmmm... Yes please. Also, please report the result of smartctl -a /dev/sda. -- 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: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
Tejun Heo wrote: [please don't drop cc. restored] Steen Eugen Poulsen wrote: Tejun Heo skrev: All these are caused by smartd. Updating should fix the problem. Okay, but there is no newer smartd than what I'm using. (5.37) Bruce? Original thread can be read from... http://thread.gmane.org/gmane.linux.kernel/588972 The fixes were added in smartmontools CVS, but there hasn't been a release since then. -jim - 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: marvell 88SX6081 and linux 2.6.23.1
At 08:23 PM 10/25/2007, Tejun Heo wrote: jeffunit wrote: jeffunit wrote: I built a kernel, 2.6.23.1 today. My motherboard is an intel stl2, dual pentium 933 motherboard, with about 3gb of ram. I also have a promise tx100 controller with an ata hard drive for the os, and a sony dvdrw drive. There is an intel gigabit ethernet card, and an ati pci video card. I have an 8 port supermicro sata II controller with the marvell 888SX6081 chipset. I have four 500gb sata II maxtor hard drives attached to it. All except /dev/sda1 seem to work fine. When I copy/modify files on /dev/sda1, I get the following dmesg errors: The machine is designed to be a fileserver, but I am happy to help debug this issue to the best of my abilities. When I boot windows xp, xp sees all 4 of the sata drives, and they work without any problems. Please advise, jeff ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: edma_err 0x0084, EDMA self-disable ata1.00: cmd c8/00:08:37:02:90/00:00:00:00:00/e5 tag 0 cdb 0x0 data 4096 in res 51/40:00:37:02:90/00:00:00:00:00/e5 Emask 0x9 (media error) Media errors which is usually localized to certain area of disk. Replace disk. The disk works fine under windows xp. I never got any errors with it and xp. And you were accessing the same region of the drive? I can swap the first and second hard drive. With the old kernel, the errors stayed with whatever drive was hooked up to the first port of the controller. I will report the results. Hmmm... Yes please. Also, please report the result of smartctl -a /dev/sda. Pardon the long post I swapped /dev/sda and /dev/sdb cables at the controller. Here is what smartctl -a said afterward: sda: smartctl version 5.37 [i586-mandriva-linux-gnu] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: MAXTOR STM3500630AS Serial Number:9QG1Y3R3 Firmware Version: 3.AAE User Capacity:500,107,862,016 bytes Device is:Not in smartctl database [for details use: -P showall] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is:Thu Oct 25 21:02:45 2007 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 430) seconds. Offline data collection capabilities:(0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities:(0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability:(0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time:( 1) minutes. Extended self-test routine recommended polling time:( 163) minutes. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 119 094 006Pre-fail Always - 218977613 3 Spin_Up_Time0x0003 093 093 000Pre-fail Always - 0 4 Start_Stop_Count0x0032 100 100 020Old_age Always - 28 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 23 7 Seek_Error_Rate 0x000f 066 060 030Pre-fail Always - 5082213 9 Power_On_Hours 0x0032 100 100 000Old_age Always - 74 10 Spin_Retry_Count0x0013 100 100 097Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020
Re: [stable] [PATCH 1/2] libata: backport ATA_FLAG_NO_SRST and ATA_FLAG_ASSUME_ATA
On Thu, Oct 25, 2007 at 04:36:01PM +0900, Tejun Heo wrote: Jeff Garzik wrote: Tejun Heo wrote: Backport ATA_FLAG_NO_SRST and ATA_FLAG_ASSUME_ATA. These are originally link flags (ATA_LFLAG_*) but link abstraction doesn't exist on 2.6.23, so make it port flags. This is for the following workaround for ASUS P5W DH Deluxe. These new flags don't introduce any behavior change unless set and nobody sets them yet. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- This and the next patch are a bit large for -stable but they don't change anything for machines other than P5W DH and P5W DH users have been suffering long enough, so I think it'll be nice to include these patches in the next -stable release. However, feel free to NACK if you can see some danger in these patches. Jeff, what do you think? drivers/ata/libata-eh.c | 32 include/linux/libata.h |2 ++ 2 files changed, 26 insertions(+), 8 deletions(-) ACK from me, though I wonder if we shouldn't wait and get feedback once this hits upstream (my next push to Andrew and Linus), before applying to stable. No special reason, just being conservative... Agreed. Let's give the upstream changes a few weeks before updating -stable. I'll ping this thread after a few weeks. Ok, thanks, I'll hold off until you respond. greg k-h - 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: 2.6.24-rc1, sata_nv: MCP51 is boned with SWNCQ too
Andrew wrote: On Thu, October 25, 2007 13:11, Bartlomiej Zolnierkiewicz wrote: a better version [PATCH] sata_nv: respect swncq_enabled setting SWNCQ is always used despite swncq_enabled setting (which is disabled by default). Fix it by using GENERIC nv_port_info[] entry for SWNCQ controllers if swncq_enabled is not enabled. This patch worked a treat, thanks. - Andrew I just reviewed your mails and simply analysed the message from http://andotnet.nfshost.com/linux/2.6.24-rc1-swncq.txt. I saw that the Using SWNCQ mode didn't appear, so the swncq should be equal to 0 and nv_swncq_host_init wasnt' called. From the message ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32) , i know the libata layer should use ncq protocol. Because the nv_port_info set ATA_FLAG_NCQ flag and the sata support ncq, ata_dev_config_ncq will set dev-flags |= ATA_DFLAG_NCQ and print (depth 31/32); When a ncq command is transferred to sata_nv, sata_nv with mcp51 in SWNCQ will handle it using ncq software flow whatever value the swncq is. The error maybe happens if sata_nv does ncq , but the nv_swncq_host_init isn't called and bios either doesn't initialize the ncq register. Best regards, Kuan Luo --- 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
