Linux 2.6.24 sata_promise SATA300TX4 problems

2008-01-26 Thread Peter Favrholdt 

Hi Mikael & list,

I have previously reported problems with my setup:

SATA300TX4 + 4 Seagate Barracuda ES 500GB

I just tested with 2.6.24. After copying approx 25GB of each drive using
 dd if=/dev/sd[abcd] of=/dev/null bs=1M
sda failed with the following message:

[ 1060.069489] ata1: SError: { 10B8B Dispar BadCRC TrStaTrns }
[ 1060.069498] ata1.00: cmd 25/00:00:90:2c:e6/00:02:01:00:00/e0 tag 0 
dma 262144 in
[ 1060.069501]  res 40/00:28:00:00:00/00:00:00:00:00/40 Emask 
0x4 (timeout)


I have included lspci and dmesg output below.

My system is rock solid using 2.6.21-rc2 with Mikael Pettersons 1.5Gbps 
patch.


I will happily test any patch/suggestions thrown towards me :-)

Best regards,

Peter


lspci -v (only the promise card):

01:08.0 Mass storage controller: Promise Technology, Inc. PDC40718 (SATA 
300 TX4) (rev 02)

Subsystem: Promise Technology, Inc. PDC40718 (SATA 300 TX4)
Flags: bus master, 66MHz, medium devsel, latency 72, IRQ 19
I/O ports at a400 [size=128]
I/O ports at a800 [size=256]
Memory at e9024000 (32-bit, non-prefetchable) [size=4K]
Memory at e900 (32-bit, non-prefetchable) [size=128K]
[virtual] Expansion ROM at 300a [disabled] [size=32K]
Capabilities: [60] Power Management version 2
Kernel driver in use: sata_promise

lspci:

00:00.0 Host bridge: nVidia Corporation nForce2 IGP2 (rev c1)
00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1)
00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1)
00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1)
00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1)
00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1)
00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4)
00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet 
Controller (rev a1)
00:05.0 Multimedia audio controller: nVidia Corporation nForce Audio 
Processing Unit (rev a2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce2 AC97 
Audio Controler (MCP) (rev a1)

00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3)
00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2)
00:0d.0 FireWire (IEEE 1394): nVidia Corporation nForce2 FireWire (IEEE 
1394) Controller (rev a3)

00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1)
01:04.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 
Gigabit Ethernet Controller (rev 13)
01:08.0 Mass storage controller: Promise Technology, Inc. PDC40718 (SATA 
300 TX4) (rev 02)
01:0b.0 RAID bus controller: Silicon Image, Inc. SiI 3112 
[SATALink/SATARaid] Serial ATA Controller (rev 02)
03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP 
(rev 01)


Here is my complete dmesg:

[   24.897952] forcedeth: Reverse Engineered nForce ethernet driver. 
Version 0.61.

[   24.898267] ACPI: PCI Interrupt Link [APCH] enabled at IRQ 22
[   24.898317] ACPI: PCI Interrupt :00:04.0[A] -> Link [APCH] -> GSI 
22 (level, high) -> IRQ 18

[   24.898440] PCI: Setting latency timer of device :00:04.0 to 64
[   25.051795] Switched to high resolution mode on CPU 0
[   25.421997] forcedeth :00:04.0: ifname eth1, PHY OUI 0x20 @ 1, 
addr 00:11:2f:10:c1:c8

[   25.422057] forcedeth :00:04.0: timirq lnktim desc-v1
[   25.422118] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[   25.422169] ide: Assuming 33MHz system bus speed for PIO modes; 
override with idebus=xx
[   25.422284] NFORCE2: IDE controller (0x10de:0x0065 rev 0xa2) at  PCI 
slot :00:09.0

[   25.422355] NFORCE2: not 100% native mode: will probe irqs later
[   25.422405] NFORCE2: BIOS didn't set cable bits correctly. Enabling 
workaround.

[   25.422465] NFORCE2: :00:09.0 (rev a2) UDMA133 controller
[   25.422516] ide0: BM-DMA at 0xf000-0xf007, BIOS settings: 
hda:DMA, hdb:DMA
[   25.422642] ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: 
hdc:DMA, hdd:DMA

[   25.422798] Probing IDE interface ide0...
[   25.731527] hdb: ST380021A, ATA DISK drive
[   26.091338] hda: ST380021A, ATA DISK drive
[   26.091419] hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4
[   26.091509] hda: UDMA/100 mode selected
[   26.091635] hdb: host max PIO5 wanted PIO255(auto-tune) selected PIO4
[   26.091984] hdb: UDMA/100 mode selected
[   26.092132] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[   26.092294] Probing IDE interface ide1...
[   27.300704] hdc: HITACHI DVD-ROM GD-2500, ATAPI CD/DVD-ROM drive
[   27.300856] hdc: host max PIO5 wanted PIO255(auto-tune) selected PIO4
[   27.359737] hdc: MWDMA2 mode selected
[   27.360303] ide1

Re: [PATCH 02/14] sata_mv Mask transient IRQs.

2008-01-26 Thread Mark Lord 

Jeff Garzik wrote:

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.

..

Sure thing.  But the patch above does NOT remove any.

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: [PATCH 05/14] sata_mv Fix EDMA configuration

2008-01-26 Thread Mark Lord 

Jeff Garzik wrote:

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.

..

Sure it does.  It clears the *whole* register by default,
and then turns on only the bits we want.

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: [PATCH 07/14] sata_mv Use hqtag instead of ioid

2008-01-26 Thread Mark Lord 

Jeff Garzik wrote:

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

..

Okay.  Do you want to just nuke the first fragment of that patch
and keep the rest, then?

Or resubmit ?
-
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

2008-01-26 Thread Mark Lord 

Jeff Garzik wrote:

Mark Lord wrote:

..

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 this.

..

The waste amounts to perhaps half a page, per port.
The chips have either 4 or 8 ports.

But whatever.  I think libata should actually provide the pools anyway,
since most drivers need hardware aligned DMA memory of very similar 
requirements.

The pre-existing scheme in the driver is insufficient,
as it does not guarantee correct alignment.  Right now it does
appear to work by accident, but there's no alignment guarantee
in the interface unless pools are used.

When we allocate 32 SG tables *per port*, this becomes much more of
a bother, so pools are needed there to avoid waste.

Having the pools per-port rather than per-chip multiplies any waste
by factors of 4 or 8.  I prefer not wasting memory, myself.

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: [PATCH 10/14] sata_mv Use DMA memory pools for hardware memory tables

2008-01-26 Thread Mark Lord 

Jeff Garzik wrote:
..
The amount of memory used in the pre-existing configuration is small, it 
is already allocated on a per-device basis, and it is statically 
allocated -- meaning no worry about allocations failing inside of 
interrupts or similar nastiness.

..

Note that there's also "no worry about allocations failing inside of 
interrupts or similar nastiness" with the patch posted, either.


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: [PATCH 13/14] sata_mv No soft resets

2008-01-26 Thread Mark Lord 

Jeff Garzik wrote:

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?

..

When I hit the existing EH, the system locks up.

When I remove the ata_std_softreset from that line,
it no longer locks up.

It still does have other issues, though, so you could drop
that patch for now, and I'll reissue it when I get round to
fixing that particularly horribly broken part of the driver later.

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: [PATCH 10/14] sata_mv Use DMA memory pools for hardware memory tables

2008-01-26 Thread Mark Lord 

Mark Lord wrote:

Jeff Garzik wrote:

Mark Lord wrote:

..

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 this.

..

The waste amounts to perhaps half a page, per port.
The chips have either 4 or 8 ports.

But whatever.  I think libata should actually provide the pools anyway,
since most drivers need hardware aligned DMA memory of very similar 
requirements.


The pre-existing scheme in the driver is insufficient,
as it does not guarantee correct alignment.  Right now it does
appear to work by accident, but there's no alignment guarantee
in the interface unless pools are used.

When we allocate 32 SG tables *per port*, this becomes much more of
a bother, so pools are needed there to avoid waste.

Having the pools per-port rather than per-chip multiplies any waste
by factors of 4 or 8.  I prefer not wasting memory, myself.

..

Actually, it currently does one set of pools for the driver.

An only slightly worse solution might be to do one set of pools per chip,
as much of the time there's likely only a single chip anyway.

And per-chip means we'll have a struct device to pass to the pools interface.

So I'll change the driver to do it that way.

I can do this as a supplemental patch immediately, which will minimize
the need for retest/rebuild of other changes.

Or re-issue patches 10,11 as a single new patch, and possibly reissue
patches 12,13,14,15 but only if they no longer apply cleanly.

Just say exactly what you require here.
And keep in mind that any change I make incurs a 2-day wait
while the Marvell folks vet it again (not my choice).

Thanks
-
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

2008-01-26 Thread Jeff Garzik 

Mark Lord wrote:

Just say exactly what you require here.
And keep in mind that any change I make incurs a 2-day wait
while the Marvell folks vet it again (not my choice).



(about to go to sleep, so the rest must wait)

Bandwidth and mailing list archives are cheap, emailing is scriptable 
and its less confusion to simply discuss, revise, then repost the whole 
thing.  Keeping track of the latest revision of each of 15 patches is an 
exercise in complexity management :)


When its just one or two patches, replying with an updated
"[PATCH v2] ..."
generally works, but that doesn't scale well.

(and, more practically, I made a guess that the patch series would need 
some revisions somewhere, assumed it would be reposted post-discussion, 
and deleted it locally after review)


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

libata pm

2008-01-26 Thread [EMAIL PROTECTED] 
I'm currently running

Linux *** 2.6.23 #1 SMP PREEMPT Sat Jan 26 17:59:58 CET 2008 x86_64
Intel(R) Pentium(R) D CPU 3.20GHz GenuineIntel GNU/Linux
with the libata-tj-2.6.23-20071011 path for 2.6.23

and for testing purposes

linux-2.6.24-rc6-mm1


on a Asus P5WDG2-WS with two PCI-X Dawicontrol DC 4300 Controllers and two
Dawicontrol DC 6510 PM port multipliers to get 16 sata ports. (the linux
partition is on a ide drive)

the second raid array with 8 Samsung HD-LJ 501 works great without any
errors. but the first raid with 8 Maxtor 6V300F0 produces one error after
another after mounting the filesystem:

Filesystem "dm-0": Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-0
Ending clean XFS mount for filesystem: dm-0
Filesystem "dm-1": Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-1
Ending clean XFS mount for filesystem: dm-1
ata6.04: exception Emask 0x10 SAct 0x0 SErr 0x401 action 0xb
ata6: SError: { PHYRdyChg DevExch }
ata6.04: hard resetting link
ata6.04: SATA link down (SStatus 0 SControl 300)
ata6: failed to recover some devices, retrying in 5 secs
ata6.04: hard resetting link
ata6.04: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata6.04: configured for UDMA/100
ata6: EH complete
sd 5:0:0:0: [sdh] 586114704 512-byte hardware sectors (300091 MB)
sd 5:0:0:0: [sdh] Write Protect is off
sd 5:0:0:0: [sdh] Mode Sense: 00 3a 00 00
sd 5:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 5:1:0:0: [sdi] 586114704 512-byte hardware sectors (300091 MB)
sd 5:1:0:0: [sdi] Write Protect is off
sd 5:1:0:0: [sdi] Mode Sense: 00 3a 00 00
sd 5:1:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 5:2:0:0: [sdj] 586114704 512-byte hardware sectors (300091 MB)
sd 5:2:0:0: [sdj] Write Protect is off
sd 5:2:0:0: [sdj] Mode Sense: 00 3a 00 00
sd 5:2:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 5:3:0:0: [sdk] 586114704 512-byte hardware sectors (300091 MB)
sd 5:3:0:0: [sdk] Write Protect is off
sd 5:3:0:0: [sdk] Mode Sense: 00 3a 00 00
sd 5:3:0:0: [sdk] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 5:4:0:0: [sdl] 586114704 512-byte hardware sectors (300091 MB)
sd 5:4:0:0: [sdl] Write Protect is off
sd 5:4:0:0: [sdl] Mode Sense: 00 3a 00 00
sd 5:4:0:0: [sdl] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
ata6.00: failed to read SCR 1 (Emask=0x40)
ata6.01: failed to read SCR 1 (Emask=0x40)
ata6.02: failed to read SCR 1 (Emask=0x40)
ata6.03: failed to read SCR 1 (Emask=0x40)
ata6.04: failed to read SCR 1 (Emask=0x40)
ata6.05: failed to read SCR 1 (Emask=0x40)
ata6.00: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata6.01: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata6.01: cmd c8/00:10:97:26:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in
 res 50/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata6.01: status: { DRDY }
ata6.02: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata6.03: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata6.04: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata6.05: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata6.15: hard resetting link
ata6.15: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
ata6.00: hard resetting link
ata6.00: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata6.01: hard resetting link
ata6.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata6.02: hard resetting link
ata6.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata6.03: hard resetting link
ata6.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata6.04: hard resetting link
ata6.04: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata6.05: hard resetting link
ata6.05: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata6.00: configured for UDMA/100
ata6.01: configured for UDMA/100
ata6.02: configured for UDMA/100
ata6.03: configured for UDMA/100
ata6.04: configured for UDMA/100
ata6: EH complete
sd 5:0:0:0: [sdh] 586114704 512-byte hardware sectors (300091 MB)
sd 5:0:0:0: [sdh] Write Protect is off
sd 5:0:0:0: [sdh] Mode Sense: 00 3a 00 00
sd 5:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 5:1:0:0: [sdi] 586114704 512-byte hardware sectors (300091 MB)
sd 5:1:0:0: [sdi] Write Protect is off
sd 5:1:0:0: [sdi] Mode Sense: 00 3a 00 00
sd 5:1:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 5:2:0:0: [sdj] 586114704 512-byte hardware sectors (300091 MB)
sd 5:2:0:0: [sdj] Write Protect is off
sd 5:2:0:0: [sdj] Mode Sense: 00 3a 00 00
sd 5:2:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 5:3:0:0: [sdk] 586114704 512-byte hardware sectors (300091 MB)
sd 5:3:0:0: [sdk] Write Protect is off
sd 5:3:0:0: [sdk] Mode Sense: 00 3a 00 00
sd 5:3:0:0: [sdk] Write cache: enabled, read cache: enabled, do

Re: [PATCH 21/21] ide: make remaining built-in only IDE host drivers modular

2008-01-26 Thread Bartlomiej Zolnierkiewicz 

Hi,

On Friday 04 January 2008, Sergei Shtylyov wrote:
> Bartlomiej Zolnierkiewicz wrote:
> 
> > * Make remaining built-in only IDE host drivers modular, add ide-scan-pci.c
> >   file for probing PCI host drivers registered with IDE core (special case
> >   for built-in IDE and CONFIG_IDEPCI_PCIBUS_ORDER=y) and then take care of
> >   the ordering in which all IDE host drivers are probed when IDE is built-in
> >   during link time.
> 
> > * Move probing of gayle, falconide, macide, q40ide and buddha (m68k arch
> >   specific) host drivers, before PCI ones (no PCI on m68k), ide-cris (cris
> >   arch specific), cmd640 (x86 arch specific) and pmac (ppc arch specific).
> 
> > * Move probing of ide-cris (cris arch specific) host driver before cmd640
> >   (x86 arch specific).
> 
> > * Move probing of mpc8xx (ppc specific) host driver before ide-pnp (depends
> >   on ISA and none of ppc platform that use mpc8xx supports ISA) and 
> > ide-h8300
> >   (h8300 arch specific).
> 
> > * Add "probe_vlb" kernel parameter to cmd640 host driver and update
> >   Documentation/ide.txt accordingly.
> 
> > * Make IDE_ARM config option visible so it can also be disabled if needed.
> 
> > * Remove bogus comment from ide.c while at it.
> 
> > Cc: Mikael Starvik <[EMAIL PROTECTED]>
> > Cc: Geert Uytterhoeven <[EMAIL PROTECTED]>
> > Cc: Roman Zippel <[EMAIL PROTECTED]>
> > Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> 
> [...]
> 
> > Index: b/drivers/ide/h8300/ide-h8300.c
> > ===
> > --- a/drivers/ide/h8300/ide-h8300.c
> > +++ b/drivers/ide/h8300/ide-h8300.c
> [...]
> > @@ -104,7 +104,7 @@ void __init h8300_ide_init(void)
> > hwif = ide_find_port(hw.io_ports[IDE_DATA_OFFSET]);
> > if (hwif == NULL) {
> > printk(KERN_ERR "ide-h8300: IDE I/F register failed\n");
> > -   return;
> > +   return -ENOMEM;
> > }
> 
> ENOENT would seem more appropriate...

fixed in v2

> > Index: b/drivers/ide/pci/cmd640.c
> > ===
> > --- a/drivers/ide/pci/cmd640.c
> > +++ b/drivers/ide/pci/cmd640.c
> > @@ -706,9 +706,9 @@ static int pci_conf2(void)
> >  }
> >  
> >  /*
> > - * Probe for a cmd640 chipset, and initialize it if found.  Called from 
> > ide.c
> > + * Probe for a cmd640 chipset, and initialize it if found.
> >   */
> > -int __init ide_probe_for_cmd640x (void)
> > +static int __init cmd640x_init(void)
> >  {
> >  #ifdef CONFIG_BLK_DEV_CMD640_ENHANCED
> > int second_port_toggled = 0;
> > @@ -883,3 +883,7 @@ int __init ide_probe_for_cmd640x (void)
> > return 1;
> >  }
> >  
> > +module_param_named(probe_vlb, cmd640_vlb, bool, 0);
> > +MODULE_PARM_DESC(probe, "probe for VLB version of CMD640 chipset");
> 
> Shouldn't 'probe' be 'probe_vlb' here?

fixed in v2

interdiff between v1 and v2:

[...]
v2:
* Fix two issues spotted by Sergei:
  - replace ENOMEM error value by ENOENT in ide-h8300 host driver
  - fix MODULE_PARM_DESC() in cmd640 host driver

Cc: Sergei Shtylyov <[EMAIL PROTECTED]>
[...]

diff -u b/drivers/ide/h8300/ide-h8300.c b/drivers/ide/h8300/ide-h8300.c
--- b/drivers/ide/h8300/ide-h8300.c
+++ b/drivers/ide/h8300/ide-h8300.c
@@ -104,7 +104,7 @@
hwif = ide_find_port(hw.io_ports[IDE_DATA_OFFSET]);
if (hwif == NULL) {
printk(KERN_ERR "ide-h8300: IDE I/F register failed\n");
-   return -ENOMEM;
+   return -ENOENT;
}
 
index = hwif->index;
diff -u b/drivers/ide/pci/cmd640.c b/drivers/ide/pci/cmd640.c
--- b/drivers/ide/pci/cmd640.c
+++ b/drivers/ide/pci/cmd640.c
@@ -885,5 +885,5 @@
 
 module_param_named(probe_vlb, cmd640_vlb, bool, 0);
-MODULE_PARM_DESC(probe, "probe for VLB version of CMD640 chipset");
+MODULE_PARM_DESC(probe_vlb, "probe for VLB version of CMD640 chipset");
 
 module_init(cmd640x_init);

> > +
> > +module_init(cmd640x_init);
> 
> BTW, it's interesting why this driver still uses it's own home-grown PCI 
> config. space access code? 8-)

Lets stick to "you found it, you fix it" rule. 8)

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: libata pm

2008-01-26 Thread [EMAIL PROTECTED] 
I could solve the problem by ncq blacklisting the "Maxtor 6V300F0" devices
in libata-core.c


Am Sa, 26.01.2008, 18:03, schrieb [EMAIL PROTECTED]:
> I'm currently running
>
>
> Linux *** 2.6.23 #1 SMP PREEMPT Sat Jan 26 17:59:58 CET 2008 x86_64
> Intel(R) Pentium(R) D CPU 3.20GHz GenuineIntel GNU/Linux
> with the libata-tj-2.6.23-20071011 path for 2.6.23
>
> and for testing purposes
>
> linux-2.6.24-rc6-mm1
>
>
> on a Asus P5WDG2-WS with two PCI-X Dawicontrol DC 4300 Controllers and
> two Dawicontrol DC 6510 PM port multipliers to get 16 sata ports. (the
> linux partition is on a ide drive)
>
> the second raid array with 8 Samsung HD-LJ 501 works great without any
> errors. but the first raid with 8 Maxtor 6V300F0 produces one error after
>  another after mounting the filesystem:
>
> Filesystem "dm-0": Disabling barriers, not supported by the underlying
> device XFS mounting filesystem dm-0
> Ending clean XFS mount for filesystem: dm-0
> Filesystem "dm-1": Disabling barriers, not supported by the underlying
> device XFS mounting filesystem dm-1
> Ending clean XFS mount for filesystem: dm-1
> ata6.04: exception Emask 0x10 SAct 0x0 SErr 0x401 action 0xb
> ata6: SError: { PHYRdyChg DevExch }
> ata6.04: hard resetting link
> ata6.04: SATA link down (SStatus 0 SControl 300)
> ata6: failed to recover some devices, retrying in 5 secs
> ata6.04: hard resetting link
> ata6.04: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata6.04: configured for UDMA/100
> ata6: EH complete
> sd 5:0:0:0: [sdh] 586114704 512-byte hardware sectors (300091 MB) sd
> 5:0:0:0: [sdh] Write Protect is off
> sd 5:0:0:0: [sdh] Mode Sense: 00 3a 00 00 sd 5:0:0:0: [sdh] Write cache:
> enabled, read cache: enabled, doesn't support DPO or FUA sd 5:1:0:0: [sdi]
> 586114704 512-byte hardware sectors (300091 MB)
> sd 5:1:0:0: [sdi] Write Protect is off sd 5:1:0:0: [sdi] Mode Sense: 00 3a
> 00 00
> sd 5:1:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA sd 5:2:0:0: [sdj] 586114704 512-byte hardware sectors
> (300091 MB)
> sd 5:2:0:0: [sdj] Write Protect is off sd 5:2:0:0: [sdj] Mode Sense: 00 3a
> 00 00
> sd 5:2:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA sd 5:3:0:0: [sdk] 586114704 512-byte hardware sectors
> (300091 MB)
> sd 5:3:0:0: [sdk] Write Protect is off sd 5:3:0:0: [sdk] Mode Sense: 00 3a
> 00 00
> sd 5:3:0:0: [sdk] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA sd 5:4:0:0: [sdl] 586114704 512-byte hardware sectors
> (300091 MB)
> sd 5:4:0:0: [sdl] Write Protect is off sd 5:4:0:0: [sdl] Mode Sense: 00 3a
> 00 00
> sd 5:4:0:0: [sdl] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA ata6.00: failed to read SCR 1 (Emask=0x40)
> ata6.01: failed to read SCR 1 (Emask=0x40)
> ata6.02: failed to read SCR 1 (Emask=0x40)
> ata6.03: failed to read SCR 1 (Emask=0x40)
> ata6.04: failed to read SCR 1 (Emask=0x40)
> ata6.05: failed to read SCR 1 (Emask=0x40)
> ata6.00: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata6.01: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata6.01: cmd c8/00:10:97:26:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192
> in res 50/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata6.01:
> status: { DRDY }
> ata6.02: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata6.03: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata6.04: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata6.05: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata6.15: hard resetting link
> ata6.15: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
> ata6.00: hard resetting link
> ata6.00: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata6.01: hard resetting link
> ata6.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata6.02: hard resetting link
> ata6.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata6.03: hard resetting link
> ata6.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata6.04: hard resetting link
> ata6.04: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata6.05: hard resetting link
> ata6.05: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata6.00: configured for UDMA/100
> ata6.01: configured for UDMA/100
> ata6.02: configured for UDMA/100
> ata6.03: configured for UDMA/100
> ata6.04: configured for UDMA/100
> ata6: EH complete
> sd 5:0:0:0: [sdh] 586114704 512-byte hardware sectors (300091 MB) sd
> 5:0:0:0: [sdh] Write Protect is off
> sd 5:0:0:0: [sdh] Mode Sense: 00 3a 00 00 sd 5:0:0:0: [sdh] Write cache:
> enabled, read cache: enabled, doesn't support DPO or FUA sd 5:1:0:0: [sdi]
> 586114704 512-byte hardware sectors (300091 MB)
> sd 5:1:0:0: [sdi] Write Protect is off sd 5:1:0:0: [sdi] Mode Sense: 00 3a
> 00 00
> sd 5:1:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA sd 5:2:0:0: [sdj] 586114704 512-byte hardware sectors
> (300091 MB)
> sd 5:2:0:0: [sdj] Write Protect is off

Re: [PATCH 10/14] sata_mv Use DMA memory pools for hardware memory tables

2008-01-26 Thread Mark Lord 

Jeff Garzik wrote:

Mark Lord wrote:

Just say exactly what you require here.

..

.. repost the whole thing ..


..

Okay, will do in a couple of days.

-ml

-
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: From: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> (linux.* mail to news gateway)

2008-01-26 Thread Frans Pop 
>  config BLK_DEV_IDE_PMAC
> -   bool "Builtin PowerMac IDE support"
> +   tristate "Builtin PowerMac IDE support"

This does not seem to make sense: if the option is now tristate, it is no
longer "Builtin", so probably s/Builtin // in the description.

Cheers,
FJP
-
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: From: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> (linux.* mail to news gateway)

2008-01-26 Thread Jan Engelhardt 

On Jan 26 2008 21:31, Frans Pop wrote:
>>  config BLK_DEV_IDE_PMAC
>> -   bool "Builtin PowerMac IDE support"
>> +   tristate "Builtin PowerMac IDE support"
>
>This does not seem to make sense: if the option is now tristate, it is no
>longer "Builtin", so probably s/Builtin // in the description.

Or something like s/Builtin/Onboard/;
-
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: From: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> (linux.* mail to news gateway)

2008-01-26 Thread Bartlomiej Zolnierkiewicz 
On Saturday 26 January 2008, Jan Engelhardt wrote:
> 
> On Jan 26 2008 21:31, Frans Pop wrote:
> >>  config BLK_DEV_IDE_PMAC
> >> -   bool "Builtin PowerMac IDE support"
> >> +   tristate "Builtin PowerMac IDE support"

this change is no-op at the moment because the next Kconfig line is:

depends on PPC_PMAC && IDE=y && BLK_DEV_IDE=y

[ PPC-specific IDE host drivers are still a special case because they are
  using ppc_ide_md architecture hooks instead of doing proper host driver
  initialization sequence - to be fixed after adding warm-plug support... ]

> >This does not seem to make sense: if the option is now tristate, it is no
> >longer "Builtin", so probably s/Builtin // in the description.
> 
> Or something like s/Builtin/Onboard/;

Please send a patch.

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

[PATCH 01/13] sata_mv ncq EH fixes

2008-01-26 Thread Mark Lord 

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.c   2008-01-24 10:40:11.0 -0500
+++ new/drivers/ata/sata_mv.c   2008-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);

if (!err_mask) {
err_mask = AC_ERR_OTHER;
-
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 02/13] sata_mv ncq Mask transient IRQs

2008-01-26 Thread Mark Lord 

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.c   2008-01-24 11:11:26.0 -0500
+++ new/drivers/ata/sata_mv.c   2008-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 |
@@ -1716,18 +1735,19 @@
struct ata_host *host = dev_instance;
unsigned int hc, handled = 0, n_hcs;
void __iomem *mmio = host->iomap[MV_PRIMARY_BAR];
-   u32 irq_stat;
+   u32 irq_stat, irq_mask;

+   spin_lock(&host->lock);
irq_stat = readl(mmio + HC_MAIN_IRQ_CAUSE_OFS);
+   irq_mask = readl(mmio + HC_MAIN_IRQ_MASK_OFS);

/* check the cases where we either have nothing pending or have read
 * a bogus register value which can indicate HW removal or PCI fault
 */
-   if (!irq_stat || (0xU == irq_stat))
-   return IRQ_NONE;
+   if (!(irq_stat & irq_mask) || (0xU == irq_stat))
+   goto out_unlock;

n_hcs = mv_get_hc_count(host->ports[0]->flags);
-   spin_lock(&host->lock);

if (unlikely(irq_stat & PCI_ERR)) {
mv_pci_error(host, mmio);
@@ -2428,8 +2448,8 @@
writelfl(readl(port_mmio + serr_ofs), port_mmio + serr_ofs);
writelfl(0, port_mmio + EDMA_ERR_IRQ_CAUSE_OFS);

-   /* unmask all EDMA error interrupts */
-   writelfl(~0, port_mmio + EDMA_ERR_IRQ_MASK_OFS);
+   /* unmask all non-transient EDMA error interrupts */
+   writelfl(~EDMA_ERR_IRQ_TRANSIENT, port_mmio + EDMA_ERR_IRQ_MASK_OFS);

VPRINTK("EDMA cfg=0x%08x EDMA IRQ err cause/mask=0x%08x/0x%08x\n",
readl(port_mmio + EDMA_CFG_OFS),
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordom

[PATCH 03/13] sata_mv ncq Rename base to port mmio

2008-01-26 Thread Mark Lord 

Use naming consistent with elsewhere in this driver.
This will keep things less confusing when we later add "hc_mmio" in this 
function.

Signed-off-by: Mark Lord <[EMAIL PROTECTED]>

--- old/drivers/ata/sata_mv.c   2008-01-24 11:23:05.0 -0500
+++ new/drivers/ata/sata_mv.c   2008-01-24 11:26:33.0 -0500
@@ -834,19 +834,19 @@
 *  LOCKING:
 *  Inherited from caller.
 */
-static void mv_start_dma(void __iomem *base, struct mv_host_priv *hpriv,
+static void mv_start_dma(void __iomem *port_mmio, struct mv_host_priv *hpriv,
 struct mv_port_priv *pp)
{
if (!(pp->pp_flags & MV_PP_FLAG_EDMA_EN)) {
/* clear EDMA event indicators, if any */
-   writelfl(0, base + EDMA_ERR_IRQ_CAUSE_OFS);
+   writelfl(0, port_mmio + EDMA_ERR_IRQ_CAUSE_OFS);

-   mv_set_edma_ptrs(base, hpriv, pp);
+   mv_set_edma_ptrs(port_mmio, hpriv, pp);

-   writelfl(EDMA_EN, base + EDMA_CMD_OFS);
+   writelfl(EDMA_EN, port_mmio + EDMA_CMD_OFS);
pp->pp_flags |= MV_PP_FLAG_EDMA_EN;
}
-   WARN_ON(!(EDMA_EN & readl(base + EDMA_CMD_OFS)));
+   WARN_ON(!(EDMA_EN & readl(port_mmio + EDMA_CMD_OFS)));
}

/**
-
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 04/13] sata_mv ncq Fix EDMA configuration

2008-01-26 Thread Mark Lord 

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.c   2008-01-24 12:06:25.0 -0500
+++ new/drivers/ata/sata_mv.c   2008-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 */
-   }

-   else if (IS_GEN_II(hpriv)) {
-   cfg &= ~0x1f;   /* clear queue depth */
+   else if (IS_GEN_II(hpriv))
cfg |= EDMA_CFG_RD_BRST_EXT | EDMA_CFG_WR_BUFF_LEN;
-   cfg &= ~(EDMA_CFG_NCQ | EDMA_CFG_NCQ_GO_ON_ERR); /* clear NCQ */
-   }

else if (IS_GEN_IIE(hpriv)) {
cfg |= (1 << 23); /* do not mask PM field in rx'd FIS */
cfg |= (1 << 22); /* enab 4-entry host queue cache */
-   cfg &= ~(1 << 19);/* dis 128-entry queue (for now?) */
cfg |= (1 << 18); /* enab early completion */
cfg |= (1 << 17); /* enab cut-through (dis stor&forwrd) */
-   cfg &= ~(1 << 16);/* dis FIS-based switching (for now) */
-   cfg &= ~(EDMA_CFG_NCQ); /* clear NCQ */
}

writelfl(cfg, port_mmio + EDMA_CFG_OFS);
@@ -137

[PATCH 05/13] sata_mv ncq Add want ncq parameter for EDMA configuration

2008-01-26 Thread Mark Lord 

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]>

--- old/drivers/ata/sata_mv.c   2008-01-24 12:12:37.0 -0500
+++ new/drivers/ata/sata_mv.c   2008-01-24 12:07:16.0 -0500
@@ -331,6 +331,7 @@

/* Port private flags (pp_flags) */
MV_PP_FLAG_EDMA_EN  = (1 << 0),   /* is EDMA engine enabled? */
+   MV_PP_FLAG_NCQ_EN   = (1 << 1),   /* is EDMA set up for NCQ? */
MV_PP_FLAG_HAD_A_RESET  = (1 << 2),   /* 1st hard reset complete? */
};

@@ -471,8 +472,9 @@
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 void mv_edma_cfg(struct mv_port_priv *pp, struct mv_host_priv *hpriv,
+   void __iomem *port_mmio, int want_ncq);
+static int __mv_stop_dma(struct ata_port *ap);

static struct scsi_host_template mv5_sht = {
.module = THIS_MODULE,
@@ -838,8 +840,15 @@
 *  Inherited from caller.
 */
static void mv_start_dma(struct ata_port *ap, void __iomem *port_mmio,
-struct mv_port_priv *pp)
+struct mv_port_priv *pp, u8 protocol)
{
+   int want_ncq = (protocol == ATA_PROT_NCQ);
+
+   if (pp->pp_flags & MV_PP_FLAG_EDMA_EN) {
+   int using_ncq = ((pp->pp_flags & MV_PP_FLAG_NCQ_EN) != 0);
+   if (want_ncq != using_ncq)
+   __mv_stop_dma(ap);
+   }
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);
@@ -859,7 +868,7 @@
 hc_mmio + HC_IRQ_CAUSE_OFS);
}

-   mv_edma_cfg(ap, hpriv, port_mmio);
+   mv_edma_cfg(pp, hpriv, port_mmio, want_ncq);

/* clear FIS IRQ Cause */
writelfl(0, port_mmio + SATA_FIS_IRQ_CAUSE_OFS);
@@ -1045,8 +1054,8 @@
return -EINVAL;
}

-static void mv_edma_cfg(struct ata_port *ap, struct mv_host_priv *hpriv,
-   void __iomem *port_mmio)
+static void mv_edma_cfg(struct mv_port_priv *pp, struct mv_host_priv *hpriv,
+   void __iomem *port_mmio, int want_ncq)
{
u32 cfg;

@@ -1066,6 +1075,12 @@
cfg |= (1 << 17); /* enab cut-through (dis stor&forwrd) */
}

+   if (want_ncq) {
+   cfg |= EDMA_CFG_NCQ;
+   pp->pp_flags |=  MV_PP_FLAG_NCQ_EN;
+   } else
+   pp->pp_flags &= ~MV_PP_FLAG_NCQ_EN;
+
writelfl(cfg, port_mmio + EDMA_CFG_OFS);
}

@@ -1128,7 +1143,7 @@

spin_lock_irqsave(&ap->host->lock, flags);

-   mv_edma_cfg(ap, hpriv, port_mmio);
+   mv_edma_cfg(pp, hpriv, port_mmio, 0);

mv_set_edma_ptrs(port_mmio, hpriv, pp);

@@ -1396,7 +1411,7 @@
return ata_qc_issue_prot(qc);
}

-   mv_start_dma(ap, port_mmio, pp);
+   mv_start_dma(ap, port_mmio, pp, qc->tf.protocol);

in_index = pp->req_idx & MV_MAX_Q_DEPTH_MASK;

-
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 06/13] sata_mv ncq Use hqtag instead of ioid

2008-01-26 Thread Mark Lord 

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.c   2008-01-26 10:46:58.0 -0500
+++ new/drivers/ata/sata_mv.c   2008-01-26 10:47:35.0 -0500
@@ -1252,7 +1252,6 @@
flags |= CRQB_FLAG_READ;
WARN_ON(MV_MAX_Q_DEPTH <= qc->tag);
flags |= qc->tag << CRQB_TAG_SHIFT;
-   flags |= qc->tag << CRQB_IOID_SHIFT;   /* 50xx appears to ignore this*/

/* get current queue index from software */
in_index = pp->req_idx & MV_MAX_Q_DEPTH_MASK;
@@ -1345,8 +1344,7 @@

WARN_ON(MV_MAX_Q_DEPTH <= qc->tag);
flags |= qc->tag << CRQB_TAG_SHIFT;
-   flags |= qc->tag << CRQB_IOID_SHIFT;   /* "I/O Id" is -really-
-  what we use as our tag */
+   flags |= qc->tag << CRQB_HOSTQ_SHIFT;

/* get current queue index from software */
in_index = pp->req_idx & MV_MAX_Q_DEPTH_MASK;
@@ -1587,13 +1585,8 @@
 * support for queueing.  this works transparently for
 * queued and non-queued modes.
 */
-   else if (IS_GEN_II(hpriv))
-   tag = (le16_to_cpu(pp->crpb[out_index].id)
-   >> CRPB_IOID_SHIFT_6) & 0x3f;
-
-   else /* IS_GEN_IIE */
-   tag = (le16_to_cpu(pp->crpb[out_index].id)
-   >> CRPB_IOID_SHIFT_7) & 0x3f;
+   else
+   tag = le16_to_cpu(pp->crpb[out_index].id) & 0x1f;

qc = ata_qc_from_tag(ap, tag);

-
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 07/13] sata_mv ncq Ignore response status LSB on NCQ

2008-01-26 Thread Mark Lord 

The lower 8 bits of response status are not valid for NCQ.

Signed-off-by: Mark Lord <[EMAIL PROTECTED]>

--- old/drivers/ata/sata_mv.c   2008-01-24 12:35:14.0 -0500
+++ new/drivers/ata/sata_mv.c   2008-01-24 12:35:43.0 -0500
@@ -1587,13 +1587,12 @@

qc = ata_qc_from_tag(ap, tag);

-   /* lower 8 bits of status are EDMA_ERR_IRQ_CAUSE_OFS
-* bits (WARNING: might not necessarily be associated
-* with this command), which -should- be clear
-* if all is well
+   /* For non-NCQ mode, the lower 8 bits of status
+* are from EDMA_ERR_IRQ_CAUSE_OFS,
+* which should be zero if all went well.
 */
status = le16_to_cpu(pp->crpb[out_index].flags);
-   if (unlikely(status & 0xff)) {
+   if ((status & 0xff) && !(pp->pp_flags & MV_PP_FLAG_NCQ_EN)) {
mv_err_intr(ap, qc);
return;
}
-
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 08/13] sata_mv ncq Restrict max sectors to 8-bits on GenII NCQ

2008-01-26 Thread Mark Lord 

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.c   2008-01-24 12:35:43.0 -0500
+++ new/drivers/ata/sata_mv.c   2008-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)
{
-
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 09/13] sata_mv ncq Use DMA memory pools for hardware memory tables

2008-01-26 Thread Mark Lord 

Create host-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.c   2008-01-26 12:50:54.0 -0500
+++ new/drivers/ata/sata_mv.c   2008-01-26 13:01:56.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 */
@@ -421,6 +419,14 @@
u32 irq_cause_ofs;
u32 irq_mask_ofs;
u32 unmask_all_irqs;
+   /*
+* These consistent DMA memory pools give us guaranteed
+* alignment for hardware-accessed data structures,
+* and less memory waste in accomplishing the alignment.
+*/
+   struct dma_pool *crqb_pool;
+   struct dma_pool *crpb_pool;
+   struct dma_pool *sg_tbl_pool;
};

struct mv_hw_ops {
@@ -1097,6 +1103,25 @@
writelfl(cfg, port_mmio + EDMA_CFG_OFS);
}

+static void mv_port_free_dma_mem(struct ata_port *ap)
+{
+   struct mv_host_priv *hpriv = ap->host->private_data;
+   struct mv_port_priv *pp = ap->private_data;
+
+   if (pp->crqb) {
+   dma_pool_free(hpriv->crqb_pool, pp->crqb, pp->crqb_dma);
+   pp->crqb = NULL;
+   }
+   if (pp->crpb) {
+   dma_pool_free(hpriv->crpb_pool, pp->crpb, pp->crpb_dma);
+   pp->crpb = NULL;
+   }
+   if (pp->sg_tbl) {
+   dma_pool_free(hpriv->sg_tbl_pool, pp->sg_tbl, pp->sg_tbl_dma);
+   pp->sg_tbl = NULL;
+   }
+}
+
/**
 *  mv_port_start - Port specific init/start routine.
 *  @ap: ATA channel to manipulate
@@ -1113,51 +1138,36 @@
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;

pp = devm_kzalloc(dev, sizeof(*pp), GFP_KERNEL);
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);
+   ap->private_data = pp;

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;
+   pp->crqb = dma_pool_alloc(hpriv->crqb_pool, GFP_KERNEL, &pp->crqb_dma);
+   if (!pp->crqb)
+   return -ENOMEM;
+   memset(pp->crqb, 0, MV_CRQB_Q_SZ);

-   /* Third item:
-* Table of scatter-gather descriptors (ePRD), 16 bytes each
-*/
-   pp->sg_tbl = mem;
-   pp->sg_tbl_dma = mem_dma;
+   pp->crpb = dma_pool_alloc(hpriv->crpb_pool, GFP_KERNEL, &pp->crpb_dma);
+   if (!pp->crpb)
+   goto out_port_free_dma_mem;
+   memset(pp->crpb, 0, MV_CRPB_Q_SZ);
+
+   pp->sg_tbl = dma_pool_alloc(hpriv->sg_tbl_pool, GFP_KERNEL,
+ &pp->sg_tbl_dma);
+   if (!pp->sg_tbl)
+   goto out_port_free_dma_mem;

spin_lock_irqsave(&ap->host->lock, flags);

mv_edma_cfg(pp, hpriv, port_mmio, 0);
-
mv_set_edma_ptrs(port_mmio, hpriv, pp);

spin_unlock_irqrestore(&ap->host->lock, flags);
@@ -1166,8 +1176,11 @@
 * we'll be unable to send non-data, PIO, etc due to restricted access
 * to shadow regs.
 */
-   ap->private_data = pp;
return 0;
+
+out_port_free_dma_mem:
+   mv_port_free_dma_mem(ap);
+   return -ENOMEM;
}

/**
@@ -1182,6 +1195,7 @@
static void mv_port_stop(struct ata_port *ap)
{
mv

[PATCH 10/13] sata_mv ncq Introduce per-tag SG tables

2008-01-26 Thread Mark Lord 

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]>

--- old/drivers/ata/sata_mv.c   2008-01-26 14:18:05.0 -0500
+++ new/drivers/ata/sata_mv.c   2008-01-26 14:19:12.0 -0500
@@ -398,8 +398,8 @@
dma_addr_t  crqb_dma;
struct mv_crpb  *crpb;
dma_addr_t  crpb_dma;
-   struct mv_sg*sg_tbl;
-   dma_addr_t  sg_tbl_dma;
+   struct mv_sg*sg_tbl[MV_MAX_Q_DEPTH];
+   dma_addr_t  sg_tbl_dma[MV_MAX_Q_DEPTH];

unsigned intreq_idx;
unsigned intresp_idx;
@@ -483,6 +483,10 @@
void __iomem *port_mmio, int want_ncq);
static int __mv_stop_dma(struct ata_port *ap);

+/* .sg_tablesize is (MV_MAX_SG_CT / 2) in the structures below
+ * because we have to allow room for worst case splitting of
+ * PRDs for 64K boundaries in mv_fill_sg().
+ */
static struct scsi_host_template mv5_sht = {
.module = THIS_MODULE,
.name   = DRV_NAME,
@@ -1107,6 +,7 @@
{
struct mv_host_priv *hpriv = ap->host->private_data;
struct mv_port_priv *pp = ap->private_data;
+   int tag;

if (pp->crqb) {
dma_pool_free(hpriv->crqb_pool, pp->crqb, pp->crqb_dma);
@@ -1116,9 +1121,18 @@
dma_pool_free(hpriv->crpb_pool, pp->crpb, pp->crpb_dma);
pp->crpb = NULL;
}
-   if (pp->sg_tbl) {
-   dma_pool_free(hpriv->sg_tbl_pool, pp->sg_tbl, pp->sg_tbl_dma);
-   pp->sg_tbl = NULL;
+   /*
+* For GEN_I, there's no NCQ, so we have only a single sg_tbl.
+* For later hardware, we have one unique sg_tbl per NCQ tag.
+*/
+   for (tag = 0; tag < MV_MAX_Q_DEPTH; ++tag) {
+   if (pp->sg_tbl[tag]) {
+   if (tag == 0 || !IS_GEN_I(hpriv))
+   dma_pool_free(hpriv->sg_tbl_pool,
+ pp->sg_tbl[tag],
+ pp->sg_tbl_dma[tag]);
+   pp->sg_tbl[tag] = NULL;
+   }
}
}

@@ -1139,7 +1153,7 @@
struct mv_port_priv *pp;
void __iomem *port_mmio = mv_ap_base(ap);
unsigned long flags;
-   int rc;
+   int tag, rc;

pp = devm_kzalloc(dev, sizeof(*pp), GFP_KERNEL);
if (!pp)
@@ -1160,10 +1174,21 @@
goto out_port_free_dma_mem;
memset(pp->crpb, 0, MV_CRPB_Q_SZ);

-   pp->sg_tbl = dma_pool_alloc(hpriv->sg_tbl_pool, GFP_KERNEL,
- &pp->sg_tbl_dma);
-   if (!pp->sg_tbl)
-   goto out_port_free_dma_mem;
+   /*
+* For GEN_I, there's no NCQ, so we only allocate a single sg_tbl.
+* For later hardware, we need one unique sg_tbl per NCQ tag.
+*/
+   for (tag = 0; tag < MV_MAX_Q_DEPTH; ++tag) {
+   if (tag == 0 || !IS_GEN_I(hpriv)) {
+   pp->sg_tbl[tag] = dma_pool_alloc(hpriv->sg_tbl_pool,
+ GFP_KERNEL, &pp->sg_tbl_dma[tag]);
+   if (!pp->sg_tbl[tag])
+   goto out_port_free_dma_mem;
+   } else {
+   pp->sg_tbl[tag] = pp->sg_tbl[0];
+   pp->sg_tbl_dma[tag] = pp->sg_tbl_dma[0];
+   }
+   }

spin_lock_irqsave(&ap->host->lock, flags);

@@ -1213,7 +1238,7 @@
struct mv_sg *mv_sg, *last_sg = NULL;
unsigned int si;

-   mv_sg = pp->sg_tbl;
+   mv_sg = pp->sg_tbl[qc->tag];
for_each_sg(qc->sg, sg, qc->n_elem, si) {
dma_addr_t addr = sg_dma_address(sg);
u32 sg_len = sg_dma_len(sg);
@@ -1283,9 +1308,9 @@
in_index = pp->req_idx & MV_MAX_Q_DEPTH_MASK;

pp->crqb[in_index].sg_addr =
-   cpu_to_le32(pp->sg_tbl_dma & 0x);
+   cpu_to_le32(pp->sg_tbl_dma[qc->tag] & 0x);
pp->crqb[in_index].sg_addr_hi =
-   cpu_to_le32((pp->sg_tbl_dma >> 16) >> 16);
+   cpu_to_le32((pp->sg_tbl_dma[qc->tag] >> 16) >> 16);
pp->crqb[in_index].ctrl_flags = cpu_to_le16(flags);

cw = &pp->crqb[in_index].ata_cmd[0];
@@ -1376,8 +1401,8 @@
in_index = pp->req_idx & MV_MAX_Q_DEPTH_MASK;

crqb = (struct mv_crqb_iie *) &pp->crqb[in_index];
-   crqb->addr = cpu_to_le32(pp->sg_tbl_dma & 0x);
-   crqb->addr_hi = cpu_to_le32((pp->sg_tbl_dma >> 16) >> 16);
+   crqb->addr = cpu_to_le32(pp->sg_tbl_dma[qc->tag] & 0x

[PATCH 11/13] sata_mv ncq Enable NCQ operation

2008-01-26 Thread Mark Lord 

Final changes to actually turn on NCQ in the driver for GEN_II/IIE hardware.

Signed-off-by: Mark Lord <[EMAIL PROTECTED]>

--- old/drivers/ata/sata_mv.c   2008-01-26 12:41:01.0 -0500
+++ new/drivers/ata/sata_mv.c   2008-01-26 12:43:21.0 -0500
@@ -510,7 +510,8 @@
.name   = DRV_NAME,
.ioctl  = ata_scsi_ioctl,
.queuecommand   = ata_scsi_queuecmd,
-   .can_queue  = ATA_DEF_QUEUE,
+   .change_queue_depth = ata_scsi_change_queue_depth,
+   .can_queue  = MV_MAX_Q_DEPTH - 1,
.this_id= ATA_SHT_THIS_ID,
.sg_tablesize   = MV_MAX_SG_CT / 2,
.cmd_per_lun= ATA_SHT_CMD_PER_LUN,
@@ -572,6 +573,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,
@@ -600,6 +602,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,
@@ -628,26 +631,29 @@
.port_ops   = &mv5_ops,
},
{  /* chip_604x */
-   .flags  = MV_COMMON_FLAGS | MV_6XXX_FLAGS,
+   .flags  = MV_COMMON_FLAGS | MV_6XXX_FLAGS |
+ ATA_FLAG_NCQ,
.pio_mask   = 0x1f, /* pio0-4 */
.udma_mask  = ATA_UDMA6,
.port_ops   = &mv6_ops,
},
{  /* chip_608x */
.flags  = MV_COMMON_FLAGS | MV_6XXX_FLAGS |
- MV_FLAG_DUAL_HC,
+ ATA_FLAG_NCQ | MV_FLAG_DUAL_HC,
.pio_mask   = 0x1f, /* pio0-4 */
.udma_mask  = ATA_UDMA6,
.port_ops   = &mv6_ops,
},
{  /* chip_6042 */
-   .flags  = MV_COMMON_FLAGS | MV_6XXX_FLAGS,
+   .flags  = MV_COMMON_FLAGS | MV_6XXX_FLAGS |
+ ATA_FLAG_NCQ,
.pio_mask   = 0x1f, /* pio0-4 */
.udma_mask  = ATA_UDMA6,
.port_ops   = &mv_iie_ops,
},
{  /* chip_7042 */
-   .flags  = MV_COMMON_FLAGS | MV_6XXX_FLAGS,
+   .flags  = MV_COMMON_FLAGS | MV_6XXX_FLAGS |
+ ATA_FLAG_NCQ,
.pio_mask   = 0x1f, /* pio0-4 */
.udma_mask  = ATA_UDMA6,
.port_ops   = &mv_iie_ops,
@@ -1261,7 +1267,8 @@
u16 flags = 0;
unsigned in_index;

-   if (qc->tf.protocol != ATA_PROT_DMA)
+   if ((qc->tf.protocol != ATA_PROT_DMA) &&
+   (qc->tf.protocol != ATA_PROT_NCQ))
return;

/* Fill in command request block
@@ -1297,13 +1304,11 @@
case ATA_CMD_WRITE_FUA_EXT:
mv_crqb_pack_cmd(cw++, tf->hob_nsect, ATA_REG_NSECT, 0);
break;
-#ifdef LIBATA_NCQ  /* FIXME: remove this line when NCQ added */
case ATA_CMD_FPDMA_READ:
case ATA_CMD_FPDMA_WRITE:
mv_crqb_pack_cmd(cw++, tf->hob_feature, ATA_REG_FEATURE, 0);
mv_crqb_pack_cmd(cw++, tf->feature, ATA_REG_FEATURE, 0);
break;
-#endif /* FIXME: remove this line when NCQ added */
default:
/* The only other commands EDMA supports in non-queued and
 * non-NCQ mode are: [RW] STREAM DMA and W DMA FUA EXT, none
@@ -1352,7 +1357,8 @@
unsigned in_index;
u32 flags = 0;

-   if (qc->tf.protocol != ATA_PROT_DMA)
+   if ((qc->tf.protocol != ATA_PROT_DMA) &&
+   (qc->tf.protocol != ATA_PROT_NCQ))
return;

/* Fill in Gen IIE command request block
@@ -1418,7 +1424,8 @@
struct mv_port_priv *pp = ap->private_data;
u32 in_index;

-   if (qc->tf.protocol != ATA_PROT_DMA) {
+   if ((qc->tf.protocol != ATA_PROT_DMA) &&
+   (qc->tf.protocol != ATA_PROT_NCQ)) {
/* We're about to send a non-EDMA capable command to the
 * port.  Turn off EDMA so there won't be problems accessing
 * shadow block, etc registers.
@@ -1429,12 +1436,6 @@

mv_start_dma(ap, port_mmio, pp, qc->tf.protocol);

-   in_index = pp->req_idx & MV_MAX_Q_DEPTH_MASK;
-
-   /* until we do queuing, the queue should be empty at this point */
-   WARN_ON(in_index != ((readl(port_mmio + EDMA_REQ_Q_OUT_PTR_OFS)
-   >> EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK));
-
pp->re

[PATCH 12/13] sata_mv ncq Remove post internal cmd op

2008-01-26 Thread Mark Lord 

This driver currently has no need for the .post_internal_cmd op.
So get rid of it, to save unnecessary transitions between EDMA and non-EDMA 
modes.

Signed-off-by: Mark Lord <[EMAIL PROTECTED]>

--- old/drivers/ata/sata_mv.c   2008-01-26 18:11:17.0 -0500
+++ new/drivers/ata/sata_mv.c   2008-01-26 18:10:38.0 -0500
@@ -452,7 +452,6 @@
static void mv_qc_prep_iie(struct ata_queued_cmd *qc);
static unsigned int mv_qc_issue(struct ata_queued_cmd *qc);
static void mv_error_handler(struct ata_port *ap);
-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);
@@ -541,7 +540,6 @@
.irq_on = ata_irq_on,

.error_handler  = mv_error_handler,
-   .post_internal_cmd  = mv_post_int_cmd,
.freeze = mv_eh_freeze,
.thaw   = mv_eh_thaw,

@@ -570,7 +568,6 @@
.irq_on = ata_irq_on,

.error_handler  = mv_error_handler,
-   .post_internal_cmd  = mv_post_int_cmd,
.freeze = mv_eh_freeze,
.thaw   = mv_eh_thaw,
.qc_defer   = ata_std_qc_defer,
@@ -599,7 +596,6 @@
.irq_on = ata_irq_on,

.error_handler  = mv_error_handler,
-   .post_internal_cmd  = mv_post_int_cmd,
.freeze = mv_eh_freeze,
.thaw   = mv_eh_thaw,
.qc_defer   = ata_std_qc_defer,
@@ -2424,11 +2420,6 @@
  mv_hardreset, mv_postreset);
}

-static void mv_post_int_cmd(struct ata_queued_cmd *qc)
-{
-   mv_stop_dma(qc->ap);
-}
-
static void mv_eh_freeze(struct ata_port *ap)
{
void __iomem *mmio = ap->host->iomap[MV_PRIMARY_BAR];
-
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: libata pm

2008-01-26 Thread Tejun Heo 
[EMAIL PROTECTED] wrote:
> I could solve the problem by ncq blacklisting the "Maxtor 6V300F0" devices
> in libata-core.c

That's a strange story.  The reported error was PHY readiness changed
and Device exchanged, both of which point to hotplug event.  Maybe
something causes the firmware to reset?  What happen if you only leave
two drives on the port multiplier and remove the NCQ blacklist?  Also,
does the error ever occur on the drives which are connected directly to
the controller?


-- 
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 13/13] sata_mv ncq Comments and version bump

2008-01-26 Thread Mark Lord 

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-26 11:05:54.0 -0500
+++ new/drivers/ata/sata_mv.c   2008-01-26 11:12:32.0 -0500
@@ -29,7 +29,13 @@
  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)
+  2) Improve/fix IRQ and error handling sequences.
+
+  3) ATAPI support (Marvell claims the 60xx/70xx chips can do it).
+
+  4) Think about TCQ support here, and for libata in general
+  with controllers that suppport it via host-queuing hardware
+  (a software-only implementation could be a nightmare).

  5) Investigate problems with PCI Message Signalled Interrupts (MSI).

@@ -53,8 +59,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 +77,7 @@
#include 

#define DRV_NAME"sata_mv"
-#define DRV_VERSION"1.01"
+#define DRV_VERSION"1.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: Linux 2.6.24 sata_promise SATA300TX4 problems

2008-01-26 Thread Mikael Pettersson 
Peter Favrholdt writes:
 > Hi Mikael & list,
 > 
 > I have previously reported problems with my setup:
 > 
 > SATA300TX4 + 4 Seagate Barracuda ES 500GB
 > 
 > I just tested with 2.6.24. After copying approx 25GB of each drive using
 >   dd if=/dev/sd[abcd] of=/dev/null bs=1M
 > sda failed with the following message:
 > 
 > [ 1060.069489] ata1: SError: { 10B8B Dispar BadCRC TrStaTrns }
 > [ 1060.069498] ata1.00: cmd 25/00:00:90:2c:e6/00:02:01:00:00/e0 tag 0 
 > dma 262144 in
 > [ 1060.069501]  res 40/00:28:00:00:00/00:00:00:00:00/40 Emask 
 > 0x4 (timeout)
 > 
 > I have included lspci and dmesg output below.
 > 
 > My system is rock solid using 2.6.21-rc2 with Mikael Pettersons 1.5Gbps 
 > patch.
...
 > [ 1060.069478] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x138 
 > action 0x2 frozen
 > [ 1060.069489] ata1: SError: { 10B8B Dispar BadCRC TrStaTrns }
 > [ 1060.069498] ata1.00: cmd 25/00:00:90:2c:e6/00:02:01:00:00/e0 tag 0 
 > dma 262144 in
 > [ 1060.069501]  res 40/00:28:00:00:00/00:00:00:00:00/40 Emask 
 > 0x4 (timeout)
 > [ 1060.069505] ata1.00: status: { DRDY }
 > [ 1065.437567] ata1: port is slow to respond, please be patient (Status 
 > 0xff)
 > [ 1070.114210] ata1: device not ready (errno=-16), forcing hardreset
 > [ 1070.114219] ata1: hard resetting link
 > [ 1076.320932] ata1: port is slow to respond, please be patient (Status 
 > 0xff)
 > [ 1080.158924] ata1: COMRESET failed (errno=-16)

Mysterious. What you have there is a transmission error between the
controller and the disk, which is bad in and by itself, but then there's
a sequence of COMRESETs that fail to bring the port or disk back to life.

The original error is not a driver error but something caused by your
system, be it a dodgy cable, a poorly seated cable, or electrical
interference. But the failed COMRESETs is a concern as I've seen them
in other reports as well.

Me worried ...

So going back to 2.6.21-rc2 makes the system stable again? Can you do some
more testing to see at what point the system becomes less stable? I.e.,
2.6.21-rcI, 2.6.22, 2.6.22-rcJ, 2.6.23, or 2.6.24-rcJ?

FWIW, I just completed some testing of a 300 TX4 card with kernel 2.6.24,
including dd:s, fscks, mkfs:s, and copying about 400GB of data from one drive
(Samsung) to another (Seagate 7200.10) on that card, and I cannot seem to break 
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: Linux 2.6.24 sata_promise SATA300TX4 problems

2008-01-26 Thread Peter Favrholdt 

Hi Mikael,

Thanks for your reply :-)

Mikael Pettersson wrote:

Mysterious. What you have there is a transmission error between the
controller and the disk, which is bad in and by itself, but then there's
a sequence of COMRESETs that fail to bring the port or disk back to life.

The original error is not a driver error but something caused by your
system, be it a dodgy cable, a poorly seated cable, or electrical
interference. But the failed COMRESETs is a concern as I've seen them
in other reports as well.


Maybe I should try switching cables (again). Or it could be a 
motherboard issue (NFORCE2)?



Me worried ...

So going back to 2.6.21-rc2 makes the system stable again? Can you do some
more testing to see at what point the system becomes less stable? I.e.,
2.6.21-rcI, 2.6.22, 2.6.22-rcJ, 2.6.23, or 2.6.24-rcJ?


I believe the important part is your 1.5Gbps patch which I applied to 
2.6.21-rc2. Maybe the reason for being stable is that the transmission 
error will not show up at that speed - thus not having anything to do 
with the kernel version. I'm quite sure the problem is there using 
2.6.21-rc2 at 3Gbps.



FWIW, I just completed some testing of a 300 TX4 card with kernel 2.6.24,
including dd:s, fscks, mkfs:s, and copying about 400GB of data from one drive
(Samsung) to another (Seagate 7200.10) on that card, and I cannot seem to break 
it.


I believe it only happens if I stress all four drives simultanously. So 
maybe the transmission error is somehow related to the overall stress of 
the PCI bus/card/chip/whatever?


If it is not too much of a hassle, could you please make a 1.5Gbps patch 
for 2.6.24 for me to try out? If it solves the problem (without me ever 
touching the cables) we know for sure it is speed-related and not due to 
kernel version.


Still strange that the com resets does not help though (but maybe this 
is the drive which locks up?) :-/


Best regards,

Peter
-
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: libata pm

2008-01-26 Thread [EMAIL PROTECTED] 
Am Sa, 26.01.2008, 23:33, schrieb Tejun Heo:
> [EMAIL PROTECTED] wrote:
>> I could solve the problem by ncq blacklisting the "Maxtor 6V300F0"
>> devices in libata-core.c
>
> That's a strange story.  The reported error was PHY readiness changed
> and Device exchanged, both of which point to hotplug event.  Maybe
> something causes the firmware to reset?  What happen if you only leave two
> drives on the port multiplier and remove the NCQ blacklist?  Also, does
> the error ever occur on the drives which are connected directly to the
> controller?
>
>
> --
> tejun
>
>

No the error only occures on the drives on the pm. I can test the pm with
two Maxtor drives tomorrow (currently backing up the raid).



-
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: Linux 2.6.24 sata_promise SATA300TX4 problems

2008-01-26 Thread Mikael Pettersson 
Peter Favrholdt writes:
 > Hi Mikael,
 > 
 > Thanks for your reply :-)
 > 
 > Mikael Pettersson wrote:
 > > Mysterious. What you have there is a transmission error between the
 > > controller and the disk, which is bad in and by itself, but then there's
 > > a sequence of COMRESETs that fail to bring the port or disk back to life.
 > > 
 > > The original error is not a driver error but something caused by your
 > > system, be it a dodgy cable, a poorly seated cable, or electrical
 > > interference. But the failed COMRESETs is a concern as I've seen them
 > > in other reports as well.
 > 
 > Maybe I should try switching cables (again). Or it could be a 
 > motherboard issue (NFORCE2)?
 > 
 > > Me worried ...
 > > 
 > > So going back to 2.6.21-rc2 makes the system stable again? Can you do some
 > > more testing to see at what point the system becomes less stable? I.e.,
 > > 2.6.21-rcI, 2.6.22, 2.6.22-rcJ, 2.6.23, or 2.6.24-rcJ?
 > 
 > I believe the important part is your 1.5Gbps patch which I applied to 
 > 2.6.21-rc2. Maybe the reason for being stable is that the transmission 
 > error will not show up at that speed - thus not having anything to do 
 > with the kernel version. I'm quite sure the problem is there using 
 > 2.6.21-rc2 at 3Gbps.
 > 
 > > FWIW, I just completed some testing of a 300 TX4 card with kernel 2.6.24,
 > > including dd:s, fscks, mkfs:s, and copying about 400GB of data from one 
 > > drive
 > > (Samsung) to another (Seagate 7200.10) on that card, and I cannot seem to 
 > > break it.
 > 
 > I believe it only happens if I stress all four drives simultanously. So 
 > maybe the transmission error is somehow related to the overall stress of 
 > the PCI bus/card/chip/whatever?
 > 
 > If it is not too much of a hassle, could you please make a 1.5Gbps patch 
 > for 2.6.24 for me to try out? If it solves the problem (without me ever 
 > touching the cables) we know for sure it is speed-related and not due to 
 > kernel version.

No problem. I had intended to drop that patch after 2.6.24-rc8 as it
ought to be obsolete, but then again it might not be. It's available here:

-
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