Re: ata error codes
I saw in Jeff Garzik the link to http://www.t13.org/ for the ata 's documentation. Unfortunately , I do seem to be able to correlate the errors in the specs to the errors appear in dmesg. If you would be kind to direct me a little, I would write a code that dumps more information, something like ata_error err = error code utility. thank you On Jan 21, 2008 10:04 AM, Tejun Heo [EMAIL PROTECTED] wrote: Raz wrote: Mr Garzik Hello ata errors are some times cryptic. I am refering to this line, in the ata_qc_timeout which holds lots of information. printk(KERN_ERR ata%u: command 0x%x timeout, stat 0x%x host_stat 0x%x\n, ap-id, qc-tf.command, drv_stat, host_stat) These errors varries , and many times SMART cannot help. Is there a repository for these error codes, ( ata_dump_status isn't enough ). Is there an API to get these error codes translated to human readable format ? thank you Those values are directly from hardware registers and can be decoded with information from ATA and SFF specs. It could be nice to have decoded strings but I'm not too sure. Even when decoded, they're pretty cryptic and don't carry too much information by themselves. -- tejun -- Raz - 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] Palmchip BK3710 IDE driver
This is Palmchip BK3710 IDE controller support for kernel version 2.6.24.
The IDE controller logic supports PIO, multiword DMA and ultra-DMA modes.
Supports interface to compact Flash (CF) configured in True-IDE mode.
Signed-off-by: Anton Salnikov [EMAIL PROTECTED]
---
drivers/ide/Kconfig |8
drivers/ide/arm/Makefile |1
drivers/ide/arm/palm_bk3710.c | 424 ++
drivers/ide/ide-proc.c|1
include/linux/ide.h |2
5 files changed, 435 insertions(+), 1 deletion(-)
Index: 2.6.24.ide/drivers/ide/Kconfig
===
--- 2.6.24.ide.orig/drivers/ide/Kconfig
+++ 2.6.24.ide/drivers/ide/Kconfig
@@ -1008,6 +1008,14 @@ config BLK_DEV_Q40IDE
normally be on; disable it only if you are running a custom hard
drive subsystem through an expansion card.
+config BLK_DEV_PALMCHIP_BK3710
+ bool Palmchip bk3710 IDE controller support
+ depends on ARCH_DAVINCI
+ select BLK_DEV_IDEDMA_PCI
+ help
+ Say Y here if you want to support the onchip IDE controller on the
+ TI DaVinci SoC
+
config BLK_DEV_MPC8xx_IDE
bool MPC8xx IDE support
depends on 8xx (LWMON || IVMS8 || IVML24 || TQM8xxL) IDE=y
BLK_DEV_IDE=y !PPC_MERGE
Index: 2.6.24.ide/drivers/ide/arm/Makefile
===
--- 2.6.24.ide.orig/drivers/ide/arm/Makefile
+++ 2.6.24.ide/drivers/ide/arm/Makefile
@@ -2,5 +2,6 @@
obj-$(CONFIG_BLK_DEV_IDE_ICSIDE) += icside.o
obj-$(CONFIG_BLK_DEV_IDE_RAPIDE) += rapide.o
obj-$(CONFIG_BLK_DEV_IDE_BAST) += bast-ide.o
+obj-$(CONFIG_BLK_DEV_PALMCHIP_BK3710) += palm_bk3710.o
EXTRA_CFLAGS := -Idrivers/ide
Index: 2.6.24.ide/drivers/ide/arm/palm_bk3710.c
===
--- /dev/null
+++ 2.6.24.ide/drivers/ide/arm/palm_bk3710.c
@@ -0,0 +1,424 @@
+/*
+ * Palmchip bk3710 IDE controller
+ *
+ * Copyright (C) 2006 Texas Instruments.
+ * Copyright (C) 2007 MontaVista Software, Inc., [EMAIL PROTECTED]
+ *
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ *
+ */
+
+#include linux/types.h
+#include linux/module.h
+#include linux/kernel.h
+#include linux/ioport.h
+#include linux/hdreg.h
+#include linux/ide.h
+#include linux/delay.h
+#include linux/init.h
+#include linux/clk.h
+#include linux/platform_device.h
+
+/* Offset of the primary interface registers */
+#define IDE_PALM_ATA_PRI_REG_OFFSET 0x1F0
+
+/* Primary Control Offset */
+#define IDE_PALM_ATA_PRI_CTL_OFFSET 0x3F6
+
+/*
+ * PalmChip 3710 IDE Controller UDMA timing structure Definition
+ */
+struct palm_bk3710_udmatiming {
+ unsigned int rptime;/* Ready to pause time */
+ unsigned int cycletime; /* Cycle Time */
+};
+
+#define BK3710_BMICP 0x00
+#define BK3710_BMISP 0x02
+#define BK3710_BMIDTP 0x04
+#define BK3710_BMICS 0x08
+#define BK3710_BMISS 0x0A
+#define BK3710_BMIDTS 0x0C
+#define BK3710_IDETIMP 0x40
+#define BK3710_IDETIMS 0x42
+#define BK3710_SIDETIM 0x44
+#define BK3710_SLEWCTL 0x45
+#define BK3710_IDESTATUS 0x47
+#define BK3710_UDMACTL 0x48
+#define BK3710_UDMATIM 0x4A
+#define BK3710_MISCCTL 0x50
+#define BK3710_REGSTB 0x54
+#define BK3710_REGRCVR 0x58
+#define BK3710_DATSTB 0x5C
+#define BK3710_DATRCVR 0x60
+#define BK3710_DMASTB 0x64
+#define BK3710_DMARCVR 0x68
+#define BK3710_UDMASTB 0x6C
+#define BK3710_UDMATRP 0x70
+#define BK3710_UDMAENV 0x74
+#define BK3710_IORDYTMP0x78
+#define BK3710_IORDYTMS0x7C
+
+#include ../ide-timing.h
+
+static long ide_palm_clk;
+
+static const struct palm_bk3710_udmatiming palm_bk3710_udmatimings[6] = {
+ {160, 240}, /* UDMA Mode 0 */
+ {125, 160}, /* UDMA Mode 1 */
+ {100, 120}, /* UDMA Mode 2 */
+ {100, 90}, /* UDMA Mode 3 */
+ {85, 60},
re: [PATCH 14/14] sata_mv Comments and version bump (v.2)
Mark Lord wrote:
sata_mv Comments and version bump.
Remove some obsolete comments, and bump up the driver version number.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
..
Mmm.. something weird happened with that original patch,
in that it somehow also had this:
-int want_ncq = ata_is_ncq(protocol);
+int want_ncq = (protocol == ATA_PROT_NCQ);
..
Reposting it again here, without that extra fragment:
* * * * *
sata_mv Comments and version bump.
Remove some obsolete comments, and bump up the driver version number.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
--- old/drivers/ata/sata_mv.c 2008-01-24 15:09:31.0 -0500
+++ new/drivers/ata/sata_mv.c 2008-01-24 15:41:17.0 -0500
@@ -29,8 +29,6 @@
I distinctly remember a couple workarounds (one related to PCI-X)
are still needed.
- 4) Add NCQ support (easy to intermediate, once new-EH support appears)
-
5) Investigate problems with PCI Message Signalled Interrupts (MSI).
6) Add port multiplier support (intermediate)
@@ -53,8 +51,6 @@
Target mode, for those without docs, is the ability to directly
connect two SATA controllers.
- 13) Verify that 7042 is fully supported. I only have a 6042.
-
*/
@@ -73,7 +69,7 @@
#include linux/libata.h
#define DRV_NAMEsata_mv
-#define DRV_VERSION1.01
+#define DRV_VERSION1.20
enum {
/* BAR's are enumerated in terms of pci_resource_start() terms */
-
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: About forcing 32bit DMA patch for AMD690G(SB600)
Konstantin A. Lepikhov wrote: Hi Tejun! Friday 25, at 02:50:06 PM you wrote: Andrew Paprocki wrote: I have an SB600/RS690 here with SATA drives connected. I haven't been following this thread, but I can help test something if it would help. We're trying to determine whether SB600 ahci controller can do 64bit DMA or not. Srihari's couldn't but Shane's test result tells a different story. Do you have memory mapped over 4G (if you have 4G some of them will be over 4G, you can know this by looking at the e820 map printed during boot)? $ lspci -nn 00:00.0 Host bridge [0600]: ATI Technologies Inc RD580 [CrossFire Xpress 3200] Chipset Host Bridge [1002:5952] 00:02.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI-X Root Port [1002:5a34] 00:05.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a37] 00:12.0 SATA controller [0106]: ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380] ... Is this hardware enough for testing? I can add 2G to existing 4G of RAM and post dmesg. greater than 4G would be a highly useful configuration... 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: ata error codes
Raz wrote: I saw in Jeff Garzik the link to http://www.t13.org/ for the ata 's documentation. Unfortunately , I do seem to be able to correlate the errors in the specs to the errors appear in dmesg. If you would be kind to direct me a little, I would write a code that dumps more information, something like ata_error err = error code utility. What do you mean by 'utility'? A separate program to interpret kernel error message? -- 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: Firmware on SATA PMP Sil3726 - Sil3124
Lars Michael Jogbäck wrote: Hello, I've got a couple of older PMP's with Sil3726. I wonder if it's possible from Linux to check which firmware version it is on the Sil3726 and on the Sil3124? Is it possible to upgrade the firmware/bios on Sil3726 and Sil3124 from Linux? That is done via the scary config device which linux detects alright but needs more quirking to get the SIMG admin software to work. So, currently, not. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/14] sata_mv Add want_ncq parameter for EDMA configuration
Mark Lord wrote: sata_mv Add want_ncq parameter for EDMA configuration. An extra EDMA config bit is required for NCQ operation. So set/clear it as needed, and cache current setting in port_priv. For now though, it will always be off (0). Signed-off-by: Mark Lord [EMAIL PROTECTED] ACK, though from a personal taste perspective, I would probably have combined this with other NCQ changes further down the line Not a complaint... just an observation - 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 09/14] sata_mv Restrict max_sectors to 8-bits on GenII NCQ
Mark Lord wrote:
sata_mv Restrict max_sectors to 8-bits on GenII NCQ.
The GenII chips have only 8-bits for the sector_count field when
performing NCQ.
Add a dev_config method to restrict this when necessary, taking care not to
override any other restriction already in place (likely none, but
someday.. ?).
Signed-off-by: Mark Lord [EMAIL PROTECTED]
--- old/drivers/ata/sata_mv.c2008-01-24 12:35:43.0 -0500
+++ new/drivers/ata/sata_mv.c2008-01-24 12:40:10.0 -0500
@@ -446,6 +446,7 @@
static void mv_post_int_cmd(struct ata_queued_cmd *qc);
static void mv_eh_freeze(struct ata_port *ap);
static void mv_eh_thaw(struct ata_port *ap);
+static void mv6_dev_config(struct ata_device *dev);
static int mv_init_one(struct pci_dev *pdev, const struct pci_device_id
*ent);
static void mv5_phy_errata(struct mv_host_priv *hpriv, void __iomem *mmio,
@@ -538,6 +539,7 @@
};
static const struct ata_port_operations mv6_ops = {
+.dev_config = mv6_dev_config,
.tf_load= ata_tf_load,
.tf_read= ata_tf_read,
.check_status= ata_check_status,
@@ -1051,6 +1053,17 @@
return -EINVAL;
}
+static void mv6_dev_config(struct ata_device *adev)
+{
+/*
+ * We don't have hob_nsect when doing NCQ commands on Gen-II.
+ * See mv_qc_prep() for more info.
+ */
+if (adev-flags ATA_DFLAG_NCQ)
+if (adev-max_sectors ATA_MAX_SECTORS)
+adev-max_sectors = ATA_MAX_SECTORS;
+}
+
static void mv_edma_cfg(struct mv_port_priv *pp, struct mv_host_priv
*hpriv,
void __iomem *port_mmio, int want_ncq)
{
ACK patches 8-9
-
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 10/14] sata_mv Use DMA memory pools for hardware memory tables
Mark Lord wrote:
sata_mv Use DMA memory pools for hardware memory tables.
Create module-owned DMA memory pools, for use in allocating/freeing
per-port
command/response queues and SG tables. This gives us a way to guarantee we
meet the hardware address alignment requirements, and also reduces
memory that
might otherwise be wasted on alignment gaps.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
--- old/drivers/ata/sata_mv.c2008-01-24 12:40:10.0 -0500
+++ new/drivers/ata/sata_mv.c2008-01-24 14:17:39.0 -0500
@@ -107,14 +107,12 @@
/* CRQB needs alignment on a 1KB boundary. Size == 1KB
* CRPB needs alignment on a 256B boundary. Size == 256B
- * SG count of 176 leads to MV_PORT_PRIV_DMA_SZ == 4KB
* ePRD (SG) entries need alignment on a 16B boundary. Size == 16B
*/
MV_CRQB_Q_SZ= (32 * MV_MAX_Q_DEPTH),
MV_CRPB_Q_SZ= (8 * MV_MAX_Q_DEPTH),
-MV_MAX_SG_CT= 176,
+MV_MAX_SG_CT= 256,
MV_SG_TBL_SZ= (16 * MV_MAX_SG_CT),
-MV_PORT_PRIV_DMA_SZ= (MV_CRQB_Q_SZ + MV_CRPB_Q_SZ + MV_SG_TBL_SZ),
MV_PORTS_PER_HC= 4,
/* == (port / MV_PORTS_PER_HC) to determine HC from 0-7 port */
@@ -701,6 +699,33 @@
*/
static int msi; /* Use PCI msi; either zero (off, default) or
non-zero */
+/*
+ * These consistent DMA memory pools are owned by this module,
+ * and shared among all device instances. This gives us guaranteed
+ * alignment for hardware-accessed data structures, and low memory
+ * waste in accomplishing the alignment.
+ */
+static struct dma_pool *mv_crpb_pool;
+static struct dma_pool *mv_crqb_pool;
+static struct dma_pool *mv_sg_tbl_pool;
+
+static void mv_free_pool_items(struct ata_port *ap)
+{
+struct mv_port_priv *pp = ap-private_data;
+
+if (pp-sg_tbl) {
+dma_pool_free(mv_sg_tbl_pool, pp-sg_tbl, pp-sg_tbl_dma);
+pp-sg_tbl = NULL;
+}
+if (pp-crqb) {
+dma_pool_free(mv_crqb_pool, pp-crqb, pp-crqb_dma);
+pp-crpb = NULL;
+}
+if (pp-crqb) {
+dma_pool_free(mv_crqb_pool, pp-crqb, pp-crqb_dma);
+pp-crqb = NULL;
+}
+}
/* move to PCI layer or libata core? */
static int pci_go_64(struct pci_dev *pdev)
@@ -1110,8 +1135,6 @@
struct mv_host_priv *hpriv = ap-host-private_data;
struct mv_port_priv *pp;
void __iomem *port_mmio = mv_ap_base(ap);
-void *mem;
-dma_addr_t mem_dma;
unsigned long flags;
int rc;
@@ -1119,37 +1142,21 @@
if (!pp)
return -ENOMEM;
-mem = dmam_alloc_coherent(dev, MV_PORT_PRIV_DMA_SZ, mem_dma,
- GFP_KERNEL);
-if (!mem)
-return -ENOMEM;
-memset(mem, 0, MV_PORT_PRIV_DMA_SZ);
-
rc = ata_pad_alloc(ap, dev);
if (rc)
return rc;
-/* First item in chunk of DMA memory:
- * 32-slot command request table (CRQB), 32 bytes each in size
- */
-pp-crqb = mem;
-pp-crqb_dma = mem_dma;
-mem += MV_CRQB_Q_SZ;
-mem_dma += MV_CRQB_Q_SZ;
-
-/* Second item:
- * 32-slot command response table (CRPB), 8 bytes each in size
- */
-pp-crpb = mem;
-pp-crpb_dma = mem_dma;
-mem += MV_CRPB_Q_SZ;
-mem_dma += MV_CRPB_Q_SZ;
-
-/* Third item:
- * Table of scatter-gather descriptors (ePRD), 16 bytes each
- */
-pp-sg_tbl = mem;
-pp-sg_tbl_dma = mem_dma;
+pp-crqb = dma_pool_alloc(mv_crqb_pool, GFP_KERNEL, pp-crqb_dma);
+if (!pp-crqb)
+goto out_alloc_failed;
+
+pp-crpb = dma_pool_alloc(mv_crpb_pool, GFP_KERNEL, pp-crpb_dma);
+if (!pp-crpb)
+goto out_alloc_failed;
+
+pp-sg_tbl = dma_pool_alloc(mv_sg_tbl_pool, GFP_KERNEL,
pp-sg_tbl_dma);
+if (!pp-sg_tbl)
+goto out_alloc_failed;
spin_lock_irqsave(ap-host-lock, flags);
@@ -1165,6 +1172,10 @@
*/
ap-private_data = pp;
return 0;
+
+out_alloc_failed:
+mv_free_pool_items(ap);
+return -ENOMEM;
}
/**
@@ -1179,6 +1190,7 @@
static void mv_port_stop(struct ata_port *ap)
{
mv_stop_dma(ap);
+mv_free_pool_items(ap);
}
/**
@@ -2825,14 +2837,39 @@
IS_GEN_I(hpriv) ? mv5_sht : mv6_sht);
}
+static void mv_destroy_pools(void)
+{
+if (mv_sg_tbl_pool)
+dma_pool_destroy(mv_sg_tbl_pool);
+if (mv_crpb_pool)
+dma_pool_destroy(mv_crpb_pool);
+if (mv_crqb_pool)
+dma_pool_destroy(mv_crqb_pool);
+}
+
static int __init mv_init(void)
{
+/* Ideally, a device (second parameter) would own these pools.
+ * But for maximum memory efficiency, we really need one global
+ * set of each, shared among all like devices. As below.
+ */
+mv_crqb_pool = dma_pool_create(mv_crqb_q, NULL, MV_CRQB_Q_SZ,
+MV_CRQB_Q_SZ, 0);
+mv_crpb_pool = dma_pool_create(mv_crpb_q, NULL, MV_CRPB_Q_SZ,
+MV_CRPB_Q_SZ, 0);
+mv_sg_tbl_pool = dma_pool_create(mv_sg_tbl, NULL, MV_SG_TBL_SZ,
+ MV_SG_TBL_SZ, 0);
Sorry, I would far rather waste a tiny bit of memory than
Re: [PATCH 12/14] sata_mv Enable NCQ operation
Mark Lord wrote: sata_mv Enable NCQ operation. Final changes to actually turn on NCQ in the driver for GEN II/IIE hardware. Signed-off-by: Mark Lord [EMAIL PROTECTED] ACK though personally I would merge the -dev_config() patch into this one - 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 13/14] sata_mv No soft resets
Mark Lord wrote:
sata_mv No soft resets.
Soft resets rarely have significant effect with these chips,
so always do a hard reset instead.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
--- old/drivers/ata/sata_mv.c2008-01-24 14:49:28.0 -0500
+++ new/drivers/ata/sata_mv.c2008-01-24 14:51:53.0 -0500
@@ -2414,8 +2414,7 @@
static void mv_error_handler(struct ata_port *ap)
{
-ata_do_eh(ap, mv_prereset, ata_std_softreset,
- mv_hardreset, mv_postreset);
+ata_do_eh(ap, mv_prereset, NULL, mv_hardreset, mv_postreset);
}
Can you give a bit more explanation?
In general I agree, but SRST delivery does seem to work as intended from
a device perspective, so I would like to narrow down the conditions
where SRST must be avoided
-
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 11/12] sata_mv Introduce per-tag SG tables
Mark Lord wrote: sata_mv Introduce per-tag SG tables. In preparation for supporting NCQ, we must allocate separate SG tables for each command tag, rather than just a single table per port as before. Gen-I hardware cannot do NCQ, though, so we still allocate just a single table for that, but populate it in all 32 slots to avoid special-cases elsewhere in hotter paths of the code. Signed-off-by: Mark Lord [EMAIL PROTECTED] ACK (though it obviously must be revised per comments on patch #10) - 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 07/14] sata_mv Use hqtag instead of ioid
Mark Lord wrote: sata_mv Use hqtag instead of ioid. Simplify tag handling by using the cid/hqtag field instead of ioid, as recommended by Marvell. Signed-off-by: Mark Lord [EMAIL PROTECTED] --- old/drivers/ata/sata_mv.c2008-01-24 12:07:16.0 -0500 +++ new/drivers/ata/sata_mv.c2008-01-24 12:35:14.0 -0500 @@ -132,15 +132,12 @@ CRQB_FLAG_READ= (1 0), CRQB_TAG_SHIFT= 1, -CRQB_IOID_SHIFT= 6,/* CRQB Gen-II/IIE IO Id shift */ CRQB_HOSTQ_SHIFT= 17,/* CRQB Gen-II/IIE HostQueTag shift */ CRQB_CMD_ADDR_SHIFT= 8, CRQB_CMD_CS= (0x2 11), CRQB_CMD_LAST= (1 15), CRPB_FLAG_STATUS_SHIFT= 8, -CRPB_IOID_SHIFT_6= 5,/* CRPB Gen-II IO Id shift */ -CRPB_IOID_SHIFT_7= 7,/* CRPB Gen-IIE IO Id shift */ EPRD_FLAG_END_OF_TBL= (1 31), don't delete details of otherwise undocumented [publicly] hardware everything else OK - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] sata_mv NCQ support
Mark Lord wrote: Here is a set of 12 patches that gradually add working NCQ support to sata_mv. The driver still has issues afterwards, but nothing new that wasn't broken already. I am working on additional patches to correct the interrupt and error handling problems that still exist in the driver, as well as PMP and ATAPI support (later). Patches are against Jeff's #upstream git from this morning. Patch process note: Please don't duplicate the one-line summary found in the email subject line, in the email body. That causes all standard automated tools to copy that line twice into the permanent kernel changelog -- provided I don't go back and hand-edit each of the 15 patches. - 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 01/14] sata_mv EH fixes
Mark Lord wrote:
sata_mv EH fixes.
A hard reset is necessary after hotplug events.
Only clear the error irq bits that were set on entry.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
--- old/drivers/ata/sata_mv.c2008-01-24 10:40:11.0 -0500
+++ new/drivers/ata/sata_mv.c2008-01-24 11:11:26.0 -0500
@@ -1437,6 +1437,7 @@
ata_ehi_hotplugged(ehi);
ata_ehi_push_desc(ehi, edma_err_cause EDMA_ERR_DEV_DCON ?
dev disconnect : dev connect);
+action |= ATA_EH_HARDRESET;
}
if (IS_GEN_I(hpriv)) {
@@ -1465,7 +1466,7 @@
}
/* Clear EDMA now that SERR cleanup done */
-writelfl(0, port_mmio + EDMA_ERR_IRQ_CAUSE_OFS);
+writelfl(~edma_err_cause, port_mmio + EDMA_ERR_IRQ_CAUSE_OFS);
ACK
-
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 15/14] sata_mv NCQ support
Mark Lord wrote: sata_mv Add missing qc_defer op. This is necessary now that we support NCQ in the driver. Signed-off-by: Mark Lord [EMAIL PROTECTED] --- Who says a 14-patch series cannot have a 15th patch? :) --- old/drivers/ata/sata_mv.c2008-01-24 18:55:12.0 -0500 +++ new/drivers/ata/sata_mv.c2008-01-24 18:57:21.0 -0500 @@ -558,6 +558,7 @@ .post_internal_cmd= mv_post_int_cmd, .freeze= mv_eh_freeze, .thaw= mv_eh_thaw, +.qc_defer= ata_std_qc_defer, .scr_read= mv_scr_read, .scr_write= mv_scr_write, @@ -586,6 +587,7 @@ .post_internal_cmd= mv_post_int_cmd, .freeze= mv_eh_freeze, .thaw= mv_eh_thaw, +.qc_defer= ata_std_qc_defer, .scr_read= mv_scr_read, .scr_write= mv_scr_write, ACK; I would combine this with the NCQ-enable patch near the end of the series (patch #12 in this series) - 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 05/14] sata_mv Fix EDMA configuration
Mark Lord wrote:
sata_mv Fix EDMA configuration.
Simplify and fix EDMA configuration setup to match Marvell specificiations.
The chip documentation gives a specific (re)init sequence, which we now
follow.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
--- old/drivers/ata/sata_mv.c2008-01-24 12:06:25.0 -0500
+++ new/drivers/ata/sata_mv.c2008-01-24 12:12:37.0 -0500
@@ -210,6 +210,7 @@
/* SATA registers */
SATA_STATUS_OFS= 0x300, /* ctrl, err regs follow status */
SATA_ACTIVE_OFS= 0x350,
+SATA_FIS_IRQ_CAUSE_OFS= 0x364,
PHY_MODE3= 0x310,
PHY_MODE4= 0x314,
PHY_MODE2= 0x330,
@@ -222,11 +223,11 @@
/* Port registers */
EDMA_CFG_OFS= 0,
-EDMA_CFG_Q_DEPTH= 0,/* queueing disabled */
-EDMA_CFG_NCQ= (1 5),
-EDMA_CFG_NCQ_GO_ON_ERR= (1 14),/* continue on error */
-EDMA_CFG_RD_BRST_EXT= (1 11),/* read burst 512B */
-EDMA_CFG_WR_BUFF_LEN= (1 13),/* write buffer 512B */
+EDMA_CFG_Q_DEPTH= 0x1f,/* max device queue depth */
+EDMA_CFG_NCQ= (1 5),/* for R/W FPDMA queued */
+EDMA_CFG_NCQ_GO_ON_ERR= (1 14),/* continue on error */
+EDMA_CFG_RD_BRST_EXT= (1 11),/* read burst 512B */
+EDMA_CFG_WR_BUFF_LEN= (1 13),/* write buffer 512B */
EDMA_ERR_IRQ_CAUSE_OFS= 0x8,
EDMA_ERR_IRQ_MASK_OFS= 0xc,
@@ -470,6 +471,8 @@
static void mv_reset_pci_bus(struct pci_dev *pdev, void __iomem *mmio);
static void mv_channel_reset(struct mv_host_priv *hpriv, void __iomem
*mmio,
unsigned int port_no);
+static void mv_edma_cfg(struct ata_port *ap, struct mv_host_priv *hpriv,
+void __iomem *port_mmio);
static struct scsi_host_template mv5_sht = {
.module= THIS_MODULE,
@@ -834,13 +837,33 @@
* LOCKING:
* Inherited from caller.
*/
-static void mv_start_dma(void __iomem *port_mmio, struct mv_host_priv
*hpriv,
+static void mv_start_dma(struct ata_port *ap, void __iomem *port_mmio,
struct mv_port_priv *pp)
{
if (!(pp-pp_flags MV_PP_FLAG_EDMA_EN)) {
+struct mv_host_priv *hpriv = ap-host-private_data;
+int hard_port = mv_hardport_from_port(ap-port_no);
+void __iomem *hc_mmio = mv_hc_base_from_port(
+ap-host-iomap[MV_PRIMARY_BAR], hard_port);
+u32 hc_irq_cause, ipending;
+
/* clear EDMA event indicators, if any */
writelfl(0, port_mmio + EDMA_ERR_IRQ_CAUSE_OFS);
+/* clear EDMA interrupt indicator, if any */
+hc_irq_cause = readl(hc_mmio + HC_IRQ_CAUSE_OFS);
+ipending = (DEV_IRQ hard_port) |
+(CRPB_DMA_DONE hard_port);
+if (hc_irq_cause ipending) {
+writelfl(hc_irq_cause ~ipending,
+ hc_mmio + HC_IRQ_CAUSE_OFS);
+}
+
+mv_edma_cfg(ap, hpriv, port_mmio);
+
+/* clear FIS IRQ Cause */
+writelfl(0, port_mmio + SATA_FIS_IRQ_CAUSE_OFS);
+
mv_set_edma_ptrs(port_mmio, hpriv, pp);
writelfl(EDMA_EN, port_mmio + EDMA_CMD_OFS);
@@ -1025,30 +1048,22 @@
static void mv_edma_cfg(struct ata_port *ap, struct mv_host_priv *hpriv,
void __iomem *port_mmio)
{
-u32 cfg = readl(port_mmio + EDMA_CFG_OFS);
+u32 cfg;
/* set up non-NCQ EDMA configuration */
-cfg = ~(1 9);/* disable eQue */
+cfg = EDMA_CFG_Q_DEPTH;/* always 0x1f for *all* chips */
-if (IS_GEN_I(hpriv)) {
-cfg = ~0x1f;/* clear queue depth */
+if (IS_GEN_I(hpriv))
cfg |= (1 8);/* enab config burst size mask */
You no longer clear bit 9 for Gen-I, which looks wrong.
everything else looks OK
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About forcing 32bit DMA patch for AMD690G(SB600)
Hello, Konstantin. Konstantin A. Lepikhov wrote: $ lspci -nn 00:00.0 Host bridge [0600]: ATI Technologies Inc RD580 [CrossFire Xpress 3200] Chipset Host Bridge [1002:5952] 00:02.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI-X Root Port [1002:5a34] 00:05.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a37] 00:12.0 SATA controller [0106]: ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380] ... Is this hardware enough for testing? I can add 2G to existing 4G of RAM and post dmesg. Srihari's system which couldn't do 64bit DMA was ASUS M2A-VM. I'm including the result of lspci below. Shane verified 64bit works on a configuration which has SB600 and different bridge, RS690, but Shane's test result wasn't perfect either. AHCI triggers SERR_INTERNAL if quirk_disable_all_msi is not used. quirk_disable_all_msi removes the problem but specifying pci=nomsi doesn't. It's unknown whether the difference between Srihari's and Shane's is on the AHCI controller itself (different revisions?) or stemming from the differences in the rest of the system (host/pci bridges). The test results point to varied kinds and degrees of problems. At the moment. To avoid turning off anything fancy on systems involving SB600/700, we definitely need more info. Shane, can you please summarize chipset product lines and revisions and how they're configured together (e.g. SB600 Axx goes together with RSxxx kind of stuff)? Currently the following issues have been discovered and we need to find out what's caused by which. * MSI doesn't work at all. Possibly host or PCI bridge issue. Should be worked around by quirk_disable_all_msi. Shane has verified some systems do have this problem. It's still not clear which configurations have the problem and in such configurations which part. Currently quirk is applied if the system contains RS400_200 or RS480 (these are host bridges, right?). * Disabling INTx disables MSI too. Should be worked around with quirk_msi_intx_disable_bug. This one seems to be mostly taken care of. New revs of SB700 and all SB800s will have this fixed and Shane recently submitted patch to apply quirk to only affected machines. Let's wait and see if anything blows. * 64bit DMA doesn't work. Should be worked around by adding AHCI_HFLAG_32BIT_ONLY in ahci driver. Srihari's system showed failures firmly pointing to this problem. Shane tested different system with SB600 and 64bit DMA itself seemed to work although there were some issues. As written above, it's unclear what causes the difference. * Shane's test with RS690 + SB600 triggered a weird SERR_INTERNAL error condition if pci=nomsi is used insted of quirk_disable_all_msi. This is super-weird. Maybe difference in memory layout and 64bit DMA acutally didn't work? Shane, can you please do some data write/read/verify test on the setup? Thanks. -[:00]-+-00.0 ATI Technologies Inc Unknown device [1002:7910] +-02.0-[:01]--+-00.0 ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] [1002:5b60] | \-00.1 ATI Technologies Inc RV370 [Radeon X300SE] [1002:5b70] +-07.0-[:02]00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] +-12.0 ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380] +-13.0 ATI Technologies Inc SB600 USB (OHCI0) [1002:4387] +-13.1 ATI Technologies Inc SB600 USB (OHCI1) [1002:4388] +-13.2 ATI Technologies Inc SB600 USB (OHCI2) [1002:4389] +-13.3 ATI Technologies Inc SB600 USB (OHCI3) [1002:438a] +-13.4 ATI Technologies Inc SB600 USB (OHCI4) [1002:438b] +-13.5 ATI Technologies Inc SB600 USB Controller (EHCI) [1002:4386] +-14.0 ATI Technologies Inc SB600 SMBus [1002:4385] +-14.1 ATI Technologies Inc SB600 IDE [1002:438c] +-14.2 ATI Technologies Inc SB600 Azalia [1002:4383] +-14.3 ATI Technologies Inc SB600 PCI to LPC Bridge [1002:438d] +-14.4-[:03]-- +-18.0 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] +-18.1 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] +-18.2 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] \-18.3 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] 00:14.1 IDE interface: ATI Technologies Inc SB600 IDE (prog-if 82 [Master PriP]) Subsystem: ASUSTeK Computer Inc. Unknown device 81ef Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort - MAbort- SERR- PERR- Latency: 64 Interrupt: pin A routed to IRQ 16 Region 0: I/O ports at 01f0
Re: [PATCH 02/14] sata_mv Mask transient IRQs.
Mark Lord wrote: sata_mv Mask transient IRQs. The chips can handle many transient errors internally without a software IRQ. We now mask/ignore those interrupts here. This is necessary for NCQ, later on. Signed-off-by: Mark Lord [EMAIL PROTECTED] --- old/drivers/ata/sata_mv.c2008-01-24 11:11:26.0 -0500 +++ new/drivers/ata/sata_mv.c2008-01-24 11:17:42.0 -0500 @@ -170,7 +170,7 @@ PCIE_IRQ_CAUSE_OFS= 0x1900, PCIE_IRQ_MASK_OFS= 0x1910, -PCIE_UNMASK_ALL_IRQS= 0x70a,/* assorted bits */ +PCIE_UNMASK_ALL_IRQS= 0x40a,/* assorted bits */ HC_MAIN_IRQ_CAUSE_OFS= 0x1d60, HC_MAIN_IRQ_MASK_OFS= 0x1d64, @@ -241,17 +241,36 @@ EDMA_ERR_BIST_ASYNC= (1 8),/* BIST FIS or Async Notify */ EDMA_ERR_TRANS_IRQ_7= (1 8),/* Gen IIE transprt layer irq */ EDMA_ERR_CRQB_PAR= (1 9),/* CRQB parity error */ -EDMA_ERR_CRPB_PAR= (1 10),/* CRPB parity error */ -EDMA_ERR_INTRL_PAR= (1 11),/* internal parity error */ -EDMA_ERR_IORDY= (1 12),/* IORdy timeout */ -EDMA_ERR_LNK_CTRL_RX= (0xf 13),/* link ctrl rx error */ -EDMA_ERR_LNK_CTRL_RX_2= (1 15), -EDMA_ERR_LNK_DATA_RX= (0xf 17),/* link data rx error */ -EDMA_ERR_LNK_CTRL_TX= (0x1f 21),/* link ctrl tx error */ -EDMA_ERR_LNK_DATA_TX= (0x1f 26),/* link data tx error */ -EDMA_ERR_TRANS_PROTO= (1 31),/* transport protocol error */ -EDMA_ERR_OVERRUN_5= (1 5), -EDMA_ERR_UNDERRUN_5= (1 6), +EDMA_ERR_CRPB_PAR= (1 10),/* CRPB parity error */ +EDMA_ERR_INTRL_PAR= (1 11),/* internal parity error */ +EDMA_ERR_IORDY= (1 12),/* IORdy timeout */ + +EDMA_ERR_LNK_CTRL_RX= (0xf 13),/* link ctrl rx error */ +EDMA_ERR_LNK_CTRL_RX_0= (1 13),/* transient: CRC err */ +EDMA_ERR_LNK_CTRL_RX_1= (1 14),/* transient: FIFO err */ +EDMA_ERR_LNK_CTRL_RX_2= (1 15),/* fatal: caught SYNC */ +EDMA_ERR_LNK_CTRL_RX_3= (1 16),/* transient: FIS rx err */ + +EDMA_ERR_LNK_DATA_RX= (0xf 17),/* link data rx error */ + +EDMA_ERR_LNK_CTRL_TX= (0x1f 21),/* link ctrl tx error */ +EDMA_ERR_LNK_CTRL_TX_0= (1 21),/* transient: CRC err */ +EDMA_ERR_LNK_CTRL_TX_1= (1 22),/* transient: FIFO err */ +EDMA_ERR_LNK_CTRL_TX_2= (1 23),/* transient: caught SYNC */ +EDMA_ERR_LNK_CTRL_TX_3= (1 24),/* transient: caught DMAT */ +EDMA_ERR_LNK_CTRL_TX_4= (1 25),/* transient: FIS collision */ + +EDMA_ERR_LNK_DATA_TX= (0x1f 26),/* link data tx error */ + +EDMA_ERR_TRANS_PROTO= (1 31),/* transport protocol error */ +EDMA_ERR_OVERRUN_5= (1 5), +EDMA_ERR_UNDERRUN_5= (1 6), + +EDMA_ERR_IRQ_TRANSIENT = EDMA_ERR_LNK_CTRL_RX_0 | + EDMA_ERR_LNK_CTRL_RX_1 | + EDMA_ERR_LNK_CTRL_RX_3 | + EDMA_ERR_LNK_CTRL_TX, + EDMA_EH_FREEZE= EDMA_ERR_D_PAR | EDMA_ERR_PRD_PAR | EDMA_ERR_DEV_DCON | Overall operational changes -- ACK However, I do not want to remove definitions for unchecked hardware bits, because the documentation is not public. 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: About forcing 32bit DMA patch for AMD690G(SB600)
I'll try to get that configuration together.. right now I only have 2 1gb sticks installed on the board, so I would need to track down 2gb ones. If I can find some laying around, I'll let you know. Thanks, -Andrew On Jan 25, 2008 12:50 AM, Tejun Heo [EMAIL PROTECTED] wrote: Andrew Paprocki wrote: I have an SB600/RS690 here with SATA drives connected. I haven't been following this thread, but I can help test something if it would help. We're trying to determine whether SB600 ahci controller can do 64bit DMA or not. Srihari's couldn't but Shane's test result tells a different story. Do you have memory mapped over 4G (if you have 4G some of them will be over 4G, you can know this by looking at the e820 map printed during boot)? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] enable FSL SATA driver config for Freescale SoCs
On Fri, 25 Jan 2008 10:04:08 -0600 Kumar Gala [EMAIL PROTECTED] wrote: On Jan 24, 2008, at 8:46 PM, Kim Phillips wrote: The mpc8315 shares the same SATA controller as the mpc837x, and likelihood is that future SoCs from Freescale will also. Signed-off-by: Jerry Huang [EMAIL PROTECTED] Signed-off-by: Kim Phillips [EMAIL PROTECTED] --- Kumar, let me know if you want me to post this to the ata list (I'm assuming it's not necessary). It is necessary so they are aware. CC jgarizk, but we'll take it via powerpc. - k ok, cc'ing Jeff, linux-ide here: From: Kim Phillips [EMAIL PROTECTED] Date: Thu, 24 Jan 2008 01:49:24 -0600 Subject: [PATCH] enable FSL SATA driver config for Freescale SoCs The mpc8315 shares the same SATA controller as the mpc837x, and likelihood is that future SoCs from Freescale will also. Signed-off-by: Jerry Huang [EMAIL PROTECTED] Signed-off-by: Kim Phillips [EMAIL PROTECTED] --- drivers/ata/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 64b4964..75939dd 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -184,7 +184,7 @@ config PATA_ACPI config SATA_FSL tristate Freescale 3.0Gbps SATA support - depends on PPC_MPC837x + depends on FSL_SOC help This option enables support for Freescale 3.0Gbps SATA controller. It can be found on MPC837x and MPC8315. -- 1.5.2.2 - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ide-io: set REQ_FAILED when drive is dead
On Thursday 24 January 2008, Aristeu Rozanski wrote:
Currently it's possible to ide-cd to set an incorrect blocksize by
reading garbage if the drive is dead:
ide_cd_probe()
- cdrom_read_toc()
- cdrom_read_capacity()
- cdrom_queue_packet_command()
- ide_do_drive_cmd()
- ide_do_request()
- start_request()
on start_request():
/* bail early if we've exceeded max_failures */
if (drive-max_failures (drive-failures drive-max_failures)) {
goto kill_rq;
}
(...)
kill_rq:
ide_kill_rq(drive, rq);
return ide_stopped;
ide_kill_rq() and the next calls won't set REQ_FAILED on rq-cmd_flags and
thus
cdrom_queue_packet_command() won't return an error. then:
stat = cdrom_queue_packet_command(drive, req);
if (stat == 0) {
*capacity = 1 + be32_to_cpu(capbuf.lba);
*sectors_per_frame =
be32_to_cpu(capbuf.blocklen) SECTOR_BITS;
}
cdrom_read_capacity() ends believing capbuf is valid but in fact it's just
uninitialized data. back to cdrom_read_toc():
/* Try to get the total cdrom capacity and sector size. */
stat = cdrom_read_capacity(drive, toc-capacity, sectors_per_frame,
sense);
if (stat)
toc-capacity = 0x1f;
set_capacity(info-disk, toc-capacity * sectors_per_frame);
/* Save a private copy of te TOC capacity for error handling */
drive-probed_capacity = toc-capacity * sectors_per_frame;
blk_queue_hardsect_size(drive-queue,
sectors_per_frame SECTOR_BITS);
that will set drive-queue-hardsect_size to be the random value.
hardsect_size is used to calculate inode-i_blkbits. later on, on a read
path:
void create_empty_buffers(struct page *page,
unsigned long blocksize, unsigned long b_state)
{
struct buffer_head *bh, *head, *tail;
head = alloc_page_buffers(page, blocksize, 1);
bh = head;
do {
bh-b_state |= b_state;
tail = bh;
bh = bh-b_this_page;
} while (bh);
tail-b_this_page = head;
alloc_page_buffers() will return NULL if blocksize 4096. blocksize is
calculed based on inode-i_blkbits. that will trigger a null
dereference on create_empty_buffers().
Signed-off-by: Aristeu Rozanski [EMAIL PROTECTED]
thanks, applied
---
drivers/ide/ide-io.c |1 +
1 file changed, 1 insertion(+)
--- linus-2.6.orig/drivers/ide/ide-io.c 2007-12-18 07:54:59.0
-0500
+++ linus-2.6/drivers/ide/ide-io.c2008-01-24 14:48:29.0 -0500
@@ -1003,6 +1003,7 @@ static ide_startstop_t start_request (id
/* bail early if we've exceeded max_failures */
if (drive-max_failures (drive-failures drive-max_failures)) {
+ rq-cmd_flags |= REQ_FAILED;
goto kill_rq;
}
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] enable FSL SATA driver config for Freescale SoCs
On Thu, 24 Jan 2008, Kim Phillips wrote: The mpc8315 shares the same SATA controller as the mpc837x, and likelihood is that future SoCs from Freescale will also. Signed-off-by: Jerry Huang [EMAIL PROTECTED] Signed-off-by: Kim Phillips [EMAIL PROTECTED] --- Kumar, let me know if you want me to post this to the ata list (I'm assuming it's not necessary). drivers/ata/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied. - k - 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: About forcing 32bit DMA patch for AMD690G(SB600)
Hi Tejun! Friday 25, at 02:50:06 PM you wrote: Andrew Paprocki wrote: I have an SB600/RS690 here with SATA drives connected. I haven't been following this thread, but I can help test something if it would help. We're trying to determine whether SB600 ahci controller can do 64bit DMA or not. Srihari's couldn't but Shane's test result tells a different story. Do you have memory mapped over 4G (if you have 4G some of them will be over 4G, you can know this by looking at the e820 map printed during boot)? $ lspci -nn 00:00.0 Host bridge [0600]: ATI Technologies Inc RD580 [CrossFire Xpress 3200] Chipset Host Bridge [1002:5952] 00:02.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI-X Root Port [1002:5a34] 00:05.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a37] 00:12.0 SATA controller [0106]: ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380] ... Is this hardware enough for testing? I can add 2G to existing 4G of RAM and post dmesg. -- WBR et al. - 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
Firmware on SATA PMP Sil3726 - Sil3124
Hello, I've got a couple of older PMP's with Sil3726. I wonder if it's possible from Linux to check which firmware version it is on the Sil3726 and on the Sil3124? Is it possible to upgrade the firmware/bios on Sil3726 and Sil3124 from Linux? Best Regards, /LM - 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: WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
On Thu, 2008-01-24 at 23:29 -0500, Mark Lord wrote: Tejun Heo wrote: Mark Lord wrote: .. Super! You've done a great job with this stuff, Tejun! Thanks but I can't really say nice things about how sata_sil24's qc_defer() is implemented or how we generally handle command deferring. We really need the control at the higher level - request_queue group. Oh well... I guess you guys will be talking about it over beer again soon. :-) .. You too? Another one for those beers, is a way to tell the IOMMU code about physical segment limitations -- so we can stop having to allocate PRD tables 2X as big as necessary in drivers like sata_mv. If the IOMMU would observe the queue dma_boundary parameter, is that enough? (it is for the 64k PRD limit). If so, there are already patches in the works to solve this permanently. If not, could we get the requirements to see how it might be done? James - 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: WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
James Bottomley wrote: On Thu, 2008-01-24 at 23:29 -0500, Mark Lord wrote: Tejun Heo wrote: Mark Lord wrote: .. Super! You've done a great job with this stuff, Tejun! Thanks but I can't really say nice things about how sata_sil24's qc_defer() is implemented or how we generally handle command deferring. We really need the control at the higher level - request_queue group. Oh well... I guess you guys will be talking about it over beer again soon. :-) .. You too? Another one for those beers, is a way to tell the IOMMU code about physical segment limitations -- so we can stop having to allocate PRD tables 2X as big as necessary in drivers like sata_mv. If the IOMMU would observe the queue dma_boundary parameter, is that enough? (it is for the 64k PRD limit). If so, there are already patches in the works to solve this permanently. If not, could we get the requirements to see how it might be done? .. That sounds like the right thing. We just have ensure that: 1. single SG/PRD entries never cross a 64KB address boundary. and these two then naturally follow for free: 2. single SG/PRD entries never exceed 64KB. 3. single SG/PRD entries never cross a 32-bit address boundary. Are the patches going into 2.6.25 ? How do we take advantage of them ? Cheers - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
On Fri, 2008-01-25 at 10:18 -0500, Mark Lord wrote: James Bottomley wrote: On Thu, 2008-01-24 at 23:29 -0500, Mark Lord wrote: Tejun Heo wrote: Mark Lord wrote: .. Super! You've done a great job with this stuff, Tejun! Thanks but I can't really say nice things about how sata_sil24's qc_defer() is implemented or how we generally handle command deferring. We really need the control at the higher level - request_queue group. Oh well... I guess you guys will be talking about it over beer again soon. :-) .. You too? Another one for those beers, is a way to tell the IOMMU code about physical segment limitations -- so we can stop having to allocate PRD tables 2X as big as necessary in drivers like sata_mv. If the IOMMU would observe the queue dma_boundary parameter, is that enough? (it is for the 64k PRD limit). If so, there are already patches in the works to solve this permanently. If not, could we get the requirements to see how it might be done? .. That sounds like the right thing. We just have ensure that: 1. single SG/PRD entries never cross a 64KB address boundary. and these two then naturally follow for free: 2. single SG/PRD entries never exceed 64KB. 3. single SG/PRD entries never cross a 32-bit address boundary. Are the patches going into 2.6.25 ? Tomo can answer that one ... they're in his patch series How do we take advantage of them ? you need to set the dma_boundary in the host template for the driver. ATA already provides a ATA_DMA_BOUNDARY constant for the 64k case. James - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_sil24 / Alpha / 4726 PMP issue ..
added some more printk's based on what I saw - maybe some issue with the dma port? ...tom Thomas Evans wrote: Tejun (and all) - I've attached a log from my machine marked up with a few extra printk's. I did add the ssleep() you suggested off line - made no difference. I'll be happy to add more prinks in places that I did not ... kobject sata_sil24: registering. parent: NULL, set: module kobject holders: registering. parent: sata_sil24, set: NULL kobject_uevent_env kobject filter function caused the event to drop! kobject_uevent_env fill_kobj_path: path = '/module/sata_sil24' kobject notes: registering. parent: sata_sil24, set: NULL kobject_uevent_env kobject filter function caused the event to drop! bus pci: add driver sata_sil24 kobject sata_sil24: registering. parent: NULL, set: drivers kobject_uevent_env fill_kobj_path: path = '/bus/pci/drivers/sata_sil24' pci: Matched Device :00:07.0 with Driver sata_sil24 pci: Probing driver sata_sil24 with device :00:07.0 sata_sil24 :00:07.0: version 1.1 sata_sil24 :00:07.0: init_one -pcim_enable_device sata_sil24 :00:07.0: init_one -pcim_iomap_regions sata_sil24 :00:07.0: init_one -pcim_iomap_regions sata_sil24 :00:07.0: init_one - IRQ-loss PCI-X Errata. sata_sil24 :00:07.0: readl(iomap[SIL24_HOST_BAR] + HOST_CTRL) = 011F sata_sil24 :00:07.0: Clearing completion IRQ loss on PCI-X errata fix sata_sil24 :00:07.0: init_one - allocate and fill host ata4294967295: init_one ata4294967295: init_one ata4294967295: init_one ata4294967295: init_one sata_sil24 :00:07.0: init_one - setting 64 bit DMA sata_sil24 :00:07.0: init_one - sil24_init_controller ata4294967295: sil24_config_port - STD WOC ata4294967295: sil24_config_port - STD WOC ata4294967295: sil24_config_port - STD WOC ata4294967295: sil24_config_port - STD WOC sata_sil24 :00:07.0: init_one - setting master PCI: Enabling bus mastering for device :00:07.0 sata_sil24 :00:07.0: init_one - ata_host_activate scsi54 : sata_sil24 DEV: registering device: ID = 'host54' kobject host54: registering. parent: :00:07.0, set: devices kobject_uevent_env kobject filter function caused the event to drop! CLASS: registering class device: ID = 'host54' kobject host54: registering. parent: scsi_host, set: class_obj kobject_uevent_env fill_kobj_path: path = '/class/scsi_host/host54' class_uevent - name = host54 fill_kobj_path: path = '/devices/pci:00/:00:07.0/host54' scsi55 : sata_sil24 DEV: registering device: ID = 'host55' kobject host55: registering. parent: :00:07.0, set: devices kobject_uevent_env kobject filter function caused the event to drop! CLASS: registering class device: ID = 'host55' kobject host55: registering. parent: scsi_host, set: class_obj kobject_uevent_env fill_kobj_path: path = '/class/scsi_host/host55' class_uevent - name = host55 fill_kobj_path: path = '/devices/pci:00/:00:07.0/host55' scsi56 : sata_sil24 DEV: registering device: ID = 'host56' kobject host56: registering. parent: :00:07.0, set: devices kobject_uevent_env kobject filter function caused the event to drop! CLASS: registering class device: ID = 'host56' kobject host56: registering. parent: scsi_host, set: class_obj kobject_uevent_env fill_kobj_path: path = '/class/scsi_host/host56' class_uevent - name = host56 fill_kobj_path: path = '/devices/pci:00/:00:07.0/host56' scsi57 : sata_sil24 DEV: registering device: ID = 'host57' kobject host57: registering. parent: :00:07.0, set: devices kobject_uevent_env kobject filter function caused the event to drop! CLASS: registering class device: ID = 'host57' kobject host57: registering. parent: scsi_host, set: class_obj kobject_uevent_env fill_kobj_path: path = '/class/scsi_host/host57' class_uevent - name = host57 fill_kobj_path: path = '/devices/pci:00/:00:07.0/host57' ata5: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa irq 31 ata6: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa2000 irq 31 ata7: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa4000 irq 31 ata8: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa6000 irq 31 ata5: sil24_init_port - no PMP? ata5: ata_eh_recover - 1 ata5: ata_eh_recover - 2 re-enable link? ata5.00: ata_eh_recover - 3 ata5.00: ata_eh_recover - 5 ata5.00: ata_eh_recover - 6 ata5.00: ata_eh_recover - ata_dev_init 7 ata_eh_recover - 8 - retry ata5: ata_eh_recover - 8a prep for EH ata5: ata_eh_recover - reset ata5: ata_eh_recover - ATA_DEV_UNKNOWN ata_eh_recover - 9 - reset is true ata_eh_recover - freezing port - nr_pmp_links == 0 ata5: ata_eh_recover - ata_eh_reset ata5: hard resetting link ata5: hardreset - 1! ata5: hardreset - 2! ata5: hardreset - 3! ata5: hardreset - 4! ata5: hardreset - 4a! ata5: hardreset - 5! ata5: hardreset - 6! ata5: hardreset - 7 - ret -EAGAIN! ata5: PHYS - something is attached. ata5: sil24_init_port - no PMP? ata5: sil24_exec_polled_cmd irq_enabled = ata5: sil24_exec_polled_cmd paddr HI: LO:81A0
Re: sata_sil24 / Alpha / 4726 PMP issue ..
Saw something that caught my attention might be nothing ... When initialized, the port address is a 64 bit address: sil24_init_one init_one: port:FD00:09AA sil24_init_one init_one: port:FD00:09AA2000 sil24_init_one init_one: port:FD00:09AA4000 sil24_init_one init_one: port:FD00:09AA6000 When the description from ata_port_pbar_desc comes out, it shows: ata13: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa irq 31 ata14: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa2000 irq 31 ata15: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa4000 irq 31 ata16: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa6000 irq 31 I don't think the output is being truncated? Is there some issue with the address? ...tom Thomas Evans wrote: added some more printk's based on what I saw - maybe some issue with the dma port? ...tom - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_sil24 / Alpha / 4726 PMP issue ..
Thomas Evans wrote: Saw something that caught my attention might be nothing ... When initialized, the port address is a 64 bit address: sil24_init_one init_one: port:FD00:09AA sil24_init_one init_one: port:FD00:09AA2000 sil24_init_one init_one: port:FD00:09AA4000 sil24_init_one init_one: port:FD00:09AA6000 These are KSEG addresses used for getting at the memory/registers on the card, and were created by doing ioremap(physaddr). When the description from ata_port_pbar_desc comes out, it shows: ata13: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa irq 31 ata14: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa2000 irq 31 ata15: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa4000 irq 31 ata16: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9aa6000 irq 31 These are the physical addresses of the memory/registers of the card on the PCI bus. I don't think the output is being truncated? Nope, not truncated, just diff between physical and KSEG Is there some issue with the address? Don't think so, at this time. ...tom Thomas Evans wrote: added some more printk's based on what I saw - maybe some issue with the dma port? ...tom - 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
