MVSAS status

MVSAS status

[Orion Poplawski]

What's the status of the MVSAS patches posted in November '09?  I'm just trying
to get started with mvsas and running into the mvs_abort_task issue.  At least
one person has reported that stability improved, but it looks like there were
some other issues with the patches.  Any chance on seeing this in the mainline
kernel soon?  Are there updated versions?  A git tree to pull from?

Thanks!

- Orion Poplawski

Re: MVSAS status

[Audio Haven]

I'm still experiencing issues with this patched driver (using patches
posted in November '09), but I believe I'm hitting known issues in the
following Western Digital green drives.

WDC WD15EADS-00P8B0

I have five of those 00P8B0, some of them have a really high
Load_Cycle_Count, or they become slow during a raid rebuild, or they
just timeout when not using WDIDLE3.EXE (and using the default 8sec
Intellipark feature which is really bad design) ... they are reported
as BAD and "NOT RECOMMENDED" all over the internet. WD doesn't provide
a decent solution yet for these.

My three newer WD15EADS-00S2B0 are also running on the same Marvell
controller and were never kicked out of the raid. Stable and decent
speed. I didn't see any issue with those newer 00S2B0 drives, so I
believe this is actually a WD issue and not a Marvell issue. Maybe the
timeouts are not handled well by the Marvell driver and we're seeing
mvs_abort_task , but that looks more like a symptom.

I disabled the intellipark feature of the WD drives using WDIDLE3.EXE
via a DOS usb bootable stick, and instead of timing out, the
WD15EADS-00P8B0 just have become extremely slow now, iostat reports
1.5 MB/s writes to the  raid rebuild drive.

I believe the current MVSAS patches should be good enough if you avoid
WD Green drives;

Best regards,

Audio Haven

On Wed, Feb 10, 2010 at 12:32 AM, Orion Poplawski <orion@cora.nwra.com> wrote:
> What's the status of the MVSAS patches posted in November '09?  I'm just trying
> to get started with mvsas and running into the mvs_abort_task issue.  At least
> one person has reported that stability improved, but it looks like there were
> some other issues with the patches.  Any chance on seeing this in the mainline
> kernel soon?  Are there updated versions?  A git tree to pull from?
>
> Thanks!
>
> - Orion Poplawski
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MVSAS status

[Caspar Smit]

> I'm still experiencing issues with this patched driver (using patches
> posted in November '09), but I believe I'm hitting known issues in the
> following Western Digital green drives.
>
> WDC WD15EADS-00P8B0
>
> I have five of those 00P8B0, some of them have a really high
> Load_Cycle_Count, or they become slow during a raid rebuild, or they
> just timeout when not using WDIDLE3.EXE (and using the default 8sec
> Intellipark feature which is really bad design) ... they are reported
> as BAD and "NOT RECOMMENDED" all over the internet. WD doesn't provide
> a decent solution yet for these.
>
> My three newer WD15EADS-00S2B0 are also running on the same Marvell
> controller and were never kicked out of the raid. Stable and decent
> speed. I didn't see any issue with those newer 00S2B0 drives, so I
> believe this is actually a WD issue and not a Marvell issue. Maybe the
> timeouts are not handled well by the Marvell driver and we're seeing
> mvs_abort_task , but that looks more like a symptom.
>
> I disabled the intellipark feature of the WD drives using WDIDLE3.EXE
> via a DOS usb bootable stick, and instead of timing out, the
> WD15EADS-00P8B0 just have become extremely slow now, iostat reports
> 1.5 MB/s writes to the  raid rebuild drive.
>
> I believe the current MVSAS patches should be good enough if you avoid
> WD Green drives;

Well,

I am still experiencing very unstable SATA hotplugging, 9 out of 10
hotplugs end up in a kernel panic (only with SATA disks, SAS is fine).
Still problems with using 3 controllers in 1 machine using SATA disks is
instant kernel panic.

Using 2.6.32.2 kernel with the november (1-6/7) patches from Andy Yan.

Kind regards,
Caspar Smit

>
> Best regards,
>
> Audio Haven
>
> On Wed, Feb 10, 2010 at 12:32 AM, Orion Poplawski <orion@cora.nwra.com>
> wrote:
>> What's the status of the MVSAS patches posted in November '09?  I'm just
>> trying
>> to get started with mvsas and running into the mvs_abort_task issue.  At
>> least
>> one person has reported that stability improved, but it looks like there
>> were
>> some other issues with the patches.  Any chance on seeing this in the
>> mainline
>> kernel soon?  Are there updated versions?  A git tree to pull from?
>>
>> Thanks!
>>
>> - Orion Poplawski
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MVSAS status

[Mikael Abrahamsson]

On Wed, 10 Feb 2010, Audio Haven wrote:

> I believe the current MVSAS patches should be good enough if you avoid 
> WD Green drives;

WHen I used those patches I get panics when hotswapping drives and I think 
people say it won't work with SMART either? So they seem to need more work 
to be included in regular kernel?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re[2]: MVSAS status

[Erno Kovacs]

> WHen I used those patches I get panics when hotswapping drives and I think
> people say it won't work with SMART either? So they seem to need more work
> to be included in regular kernel?

Regular IO, raid5/6 and SMART works fine here but I have the same bad
experience when hotplugging SATA drives.

Erno

Re: MVSAS status

[Kristleifur Daðason]

On Tue, Feb 9, 2010 at 11:32 PM, Orion Poplawski <orion@cora.nwra.com> wrote:
>
> What's the status of the MVSAS patches posted in November '09?  I'm just trying
> to get started with mvsas and running into the mvs_abort_task issue.  At least
> one person has reported that stability improved, but it looks like there were
> some other issues with the patches.  Any chance on seeing this in the mainline
> kernel soon?  Are there updated versions?  A git tree to pull from?
>

As far as I know, the patches from November were rejected because the
patches themselves weren't solid enough - meaning there were some
cross-references between each of the seven patches, things like that.
The functionality was fine, at least a definite improvement. Ideally,
there would have been another set of patches to top things up and
really get everything running smoothly.

I haven't come across any patch traffic for the card after that November batch.

In the interests of getting these amazingly cheap and effective cards
running properly on Linux, it would be extremely good if someone
experienced with Linux patches would get involved in the matter with
Mr. Andy Yan from Marvell, straighten things out, get the ball rolling
and make the driver stick in mainline. When I emailed him, Mr. Yan was
very helpful and sent me the patches and some info. I tried to fix the
patches myself but was in over my head. And had no time. Etc.

These cards have been recommended for ZFS use on Solaris backed with
solid arguments, so the hardware is definitely fine [1].

I will PERSONALLY buy two of these cards to send to any reasonably
experienced Linux driver programmer willing to help finish these
drivers. My company will buy two more, and I'm sure there is enough
latent interest out there to get any number of development machines
packed with these cards. This is the perfect case for open-source
development, we just need a solid prospect that the driver issues can
be nailed.

-- Kristleifur


[1] - http://jmlittle.blogspot.com/2008/06/recommended-disk-controllers-for-zfs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MVSAS status

[Mikael Abrahamsson]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 483 bytes --]

On Thu, 11 Feb 2010, Kristleifur Daðason wrote:

> I will PERSONALLY buy two of these cards to send to any reasonably
> experienced Linux driver programmer willing to help finish these

If someone gets involved in fixing mvsas for (preferrably) 2.6.32 and 
makes it reliably work with hotswap and SMART, I'll personally donate $100 
to charity or Linux related organisation of that programmers choice (must 
accept paypal payments).

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: MVSAS status

[Kristleifur Daðason]

On Thu, Feb 11, 2010 at 11:20 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Thu, 11 Feb 2010, Kristleifur Dađason wrote:
>
>> I will PERSONALLY buy two of these cards to send to any reasonably
>> experienced Linux driver programmer willing to help finish these
>
> If someone gets involved in fixing mvsas for (preferrably) 2.6.32 and makes
> it reliably work with hotswap and SMART, I'll personally donate $100 to
> charity or Linux related organisation of that programmers choice (must
> accept paypal payments).
>

+1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MVSAS status

[Orion Poplawski]

Kristleifur Daðason <kristleifur <at> gmail.com> writes:
> These cards have been recommended for ZFS use on Solaris backed with
> solid arguments, so the hardware is definitely fine [1].
>
> [1] -
http://jmlittle.blogspot.com/2008/06/recommended-disk-controllers-for-zfs.html

That article seems to refer to the old PCI-X Marvell 88SX60XX controllers,
which I'm using under linux.  Having some trouble with the 88SX5081, but the
6081 is fine.

Just booted the opensolard 2009.06 live cd and I'm not sure it detected the
PCIe marvell card.  Very green with solaris, but I don't see anything promising
in dmesg.

- Orion

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MVSAS status

[James Bottomley]

On Thu, 2010-02-11 at 09:50 +0000, Kristleifur Daðason wrote:
> On Tue, Feb 9, 2010 at 11:32 PM, Orion Poplawski <orion@cora.nwra.com> wrote:
> >
> > What's the status of the MVSAS patches posted in November '09?  I'm just trying
> > to get started with mvsas and running into the mvs_abort_task issue.  At least
> > one person has reported that stability improved, but it looks like there were
> > some other issues with the patches.  Any chance on seeing this in the mainline
> > kernel soon?  Are there updated versions?  A git tree to pull from?
> >
> 
> As far as I know, the patches from November were rejected because the
> patches themselves weren't solid enough - meaning there were some
> cross-references between each of the seven patches, things like that.
> The functionality was fine, at least a definite improvement. Ideally,
> there would have been another set of patches to top things up and
> really get everything running smoothly.

There were two reasons for the reject.  The first was that the series
just wasn't bisectable.  This is annoying but not completely fatal, and
if it were a required bug fix I can just squash all the patches together
to apply to make a single commit.  I hate doing this but I've done it
before with problem vendor patch series.

The bigger problem was there were several reports of the rate of kernel
panics increasing with this patch series applied.  If the patch series
is going to decrease stability, it's not worth applying.

I can fix the first if someone can do a solid comparison and assure me
that the patch series does actually increase not decrease stability.

> I haven't come across any patch traffic for the card after that November batch.

Yes, Marvell has gone radio silent.

> In the interests of getting these amazingly cheap and effective cards
> running properly on Linux, it would be extremely good if someone
> experienced with Linux patches would get involved in the matter with
> Mr. Andy Yan from Marvell, straighten things out, get the ball rolling
> and make the driver stick in mainline. When I emailed him, Mr. Yan was
> very helpful and sent me the patches and some info. I tried to fix the
> patches myself but was in over my head. And had no time. Etc.

OK, I'll try 1:1 email with Marvell and Andy and see what comes out.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch for MVSAS

[Srinivas Naga Venkatasatya Pasagadugula - ERS, HCL Tech]

[-- Attachment #1: Type: text/plain, Size: 4116 bytes --]

Hi,
The attached patch contains the fixes for SATA hot plugging, hot plug in/out of drives (SAS/SATA) from Expander while IO is going on and tape issues. 
Try with attached patch and let me know the results. 
Note: I have tested with only 64xx chipset. 

Srinivas.

-----Original Message-----
From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of James Bottomley
Sent: Friday, February 12, 2010 12:26 AM
To: Kristleifur Daðason
Cc: Orion Poplawski; linux-scsi@vger.kernel.org
Subject: Re: MVSAS status

On Thu, 2010-02-11 at 09:50 +0000, Kristleifur Daðason wrote:
> On Tue, Feb 9, 2010 at 11:32 PM, Orion Poplawski <orion@cora.nwra.com> wrote:
> >
> > What's the status of the MVSAS patches posted in November '09?  I'm just trying
> > to get started with mvsas and running into the mvs_abort_task issue.  At least
> > one person has reported that stability improved, but it looks like there were
> > some other issues with the patches.  Any chance on seeing this in the mainline
> > kernel soon?  Are there updated versions?  A git tree to pull from?
> >
> 
> As far as I know, the patches from November were rejected because the
> patches themselves weren't solid enough - meaning there were some
> cross-references between each of the seven patches, things like that.
> The functionality was fine, at least a definite improvement. Ideally,
> there would have been another set of patches to top things up and
> really get everything running smoothly.

There were two reasons for the reject.  The first was that the series
just wasn't bisectable.  This is annoying but not completely fatal, and
if it were a required bug fix I can just squash all the patches together
to apply to make a single commit.  I hate doing this but I've done it
before with problem vendor patch series.

The bigger problem was there were several reports of the rate of kernel
panics increasing with this patch series applied.  If the patch series
is going to decrease stability, it's not worth applying.

I can fix the first if someone can do a solid comparison and assure me
that the patch series does actually increase not decrease stability.

> I haven't come across any patch traffic for the card after that November batch.

Yes, Marvell has gone radio silent.

> In the interests of getting these amazingly cheap and effective cards
> running properly on Linux, it would be extremely good if someone
> experienced with Linux patches would get involved in the matter with
> Mr. Andy Yan from Marvell, straighten things out, get the ball rolling
> and make the driver stick in mainline. When I emailed him, Mr. Yan was
> very helpful and sent me the patches and some info. I tried to fix the
> patches myself but was in over my head. And had no time. Etc.

OK, I'll try 1:1 email with Marvell and Andy and see what comes out.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. 
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. 
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have 
received this email in error please delete it and notify the sender immediately. Before opening any mail and 
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

[-- Attachment #2: mvsas.patch --]
[-- Type: application/octet-stream, Size: 22187 bytes --]

diff -uprN linux-2.6.32.7/drivers/scsi/mvsas_org/mv_64xx.c linux-2.6.32.7/drivers/scsi/mvsas/mv_64xx.c
--- linux-2.6.32.7/drivers/scsi/mvsas_org/mv_64xx.c	2010-02-12 00:25:26.000000000 +0530
+++ linux-2.6.32.7/drivers/scsi/mvsas/mv_64xx.c	2010-02-12 00:44:37.000000000 +0530
@@ -132,9 +132,9 @@ static void mvs_64xx_phy_reset(struct mv
 	tmp &= ~PHYEV_RDY_CH;
 	mvs_write_port_irq_stat(mvi, phy_id, tmp);
 	tmp = mvs_read_phy_ctl(mvi, phy_id);
-	if (hard)
+	if (hard == 1)
 		tmp |= PHY_RST_HARD;
-	else
+	else if (hard == 0)
 		tmp |= PHY_RST;
 	mvs_write_phy_ctl(mvi, phy_id, tmp);
 	if (hard) {
@@ -144,6 +144,27 @@ static void mvs_64xx_phy_reset(struct mv
 	}
 }
 
+void mvs_64xx_clear_srs_irq(struct mvs_info *mvi, u8 reg_set, u8 clear_all) {
+       void __iomem *regs = mvi->regs;
+       u32 tmp;
+       if (clear_all) {
+               tmp = mr32(MVS_INT_STAT_SRS_0);
+               if (tmp) {
+                       printk("check SRS 0 %08X.\n", tmp);
+                       mw32(MVS_INT_STAT_SRS_0, tmp);
+               }
+       } else {
+               tmp = mr32(MVS_INT_STAT_SRS_0);
+               if (tmp &  (1 << (reg_set % 32))) {
+                       printk("register set 0x%x was stopped.\n", reg_set);
+                       mw32(MVS_INT_STAT_SRS_0, 1 << (reg_set % 32));
+               }
+       }
+}
+
+
+
+
 static int __devinit mvs_64xx_chip_reset(struct mvs_info *mvi)
 {
 	void __iomem *regs = mvi->regs;
@@ -761,6 +782,7 @@ const struct mvs_dispatch mvs_64xx_dispa
 	mvs_write_port_irq_mask,
 	mvs_get_sas_addr,
 	mvs_64xx_command_active,
+	mvs_64xx_clear_srs_irq,
 	mvs_64xx_issue_stop,
 	mvs_start_delivery,
 	mvs_rx_update,
diff -uprN linux-2.6.32.7/drivers/scsi/mvsas_org/mv_init.c linux-2.6.32.7/drivers/scsi/mvsas/mv_init.c
--- linux-2.6.32.7/drivers/scsi/mvsas_org/mv_init.c	2010-02-12 00:25:26.000000000 +0530
+++ linux-2.6.32.7/drivers/scsi/mvsas/mv_init.c	2010-02-12 00:44:37.000000000 +0530
@@ -37,6 +37,7 @@ static const struct mvs_chip_info mvs_ch
 };
 
 #define SOC_SAS_NUM 2
+#define SG_MX 64
 
 static struct scsi_host_template mvs_sht = {
 	.module			= THIS_MODULE,
@@ -53,10 +54,10 @@ static struct scsi_host_template mvs_sht
 	.can_queue		= 1,
 	.cmd_per_lun		= 1,
 	.this_id		= -1,
-	.sg_tablesize		= SG_ALL,
+	.sg_tablesize		= SG_MX,
 	.max_sectors		= SCSI_DEFAULT_MAX_SECTORS,
 	.use_clustering		= ENABLE_CLUSTERING,
-	.eh_device_reset_handler	= sas_eh_device_reset_handler,
+	.eh_device_reset_handler= sas_eh_device_reset_handler,
 	.eh_bus_reset_handler	= sas_eh_bus_reset_handler,
 	.slave_alloc		= mvs_slave_alloc,
 	.target_destroy		= sas_target_destroy,
@@ -65,19 +66,17 @@ static struct scsi_host_template mvs_sht
 
 static struct sas_domain_function_template mvs_transport_ops = {
 	.lldd_dev_found 	= mvs_dev_found,
-	.lldd_dev_gone	= mvs_dev_gone,
-
+	.lldd_dev_gone		= mvs_dev_gone,
 	.lldd_execute_task	= mvs_queue_command,
 	.lldd_control_phy	= mvs_phy_control,
 
 	.lldd_abort_task	= mvs_abort_task,
 	.lldd_abort_task_set    = mvs_abort_task_set,
 	.lldd_clear_aca         = mvs_clear_aca,
-       .lldd_clear_task_set    = mvs_clear_task_set,
+    	.lldd_clear_task_set    = mvs_clear_task_set,
 	.lldd_I_T_nexus_reset	= mvs_I_T_nexus_reset,
 	.lldd_lu_reset 		= mvs_lu_reset,
 	.lldd_query_task	= mvs_query_task,
-
 	.lldd_port_formed	= mvs_port_formed,
 	.lldd_port_deformed     = mvs_port_deformed,
 
@@ -177,7 +176,7 @@ static void mvs_tasklet(unsigned long op
 		mvi = ((struct mvs_prv_info *)sha->lldd_ha)->mvi[i];
 		stat = MVS_CHIP_DISP->isr_status(mvi, mvi->irq);
 		if (stat)
-			MVS_CHIP_DISP->isr(mvi, mvi->irq, stat);
+			 MVS_CHIP_DISP->isr(mvi, mvi->irq, stat);
 	}
 
 }
@@ -213,7 +212,11 @@ static irqreturn_t mvs_interrupt(int irq
 
 static int __devinit mvs_alloc(struct mvs_info *mvi, struct Scsi_Host *shost)
 {
-	int i, slot_nr;
+	int i = 0, j = 0, slot_nr;
+	unsigned long buf_size;
+    void *buf;
+    dma_addr_t buf_dma;
+    struct mvs_slot_info *slot = 0;
 
 	if (mvi->flags & MVF_FLAG_SOC)
 		slot_nr = MVS_SOC_SLOTS;
@@ -232,6 +235,7 @@ static int __devinit mvs_alloc(struct mv
 		mvi->devices[i].dev_type = NO_DEVICE;
 		mvi->devices[i].device_id = i;
 		mvi->devices[i].dev_status = MVS_DEV_NORMAL;
+		init_timer(&mvi->devices[i].timer);
 	}
 
 	/*
@@ -437,6 +441,7 @@ static int __devinit mvs_prep_sas_ha_ini
 
 	sha->sas_phy = arr_phy;
 	sha->sas_port = arr_port;
+	sha->core.shost = shost;
 
 	sha->lldd_ha = kzalloc(sizeof(struct mvs_prv_info), GFP_KERNEL);
 	if (!sha->lldd_ha)
@@ -574,6 +579,10 @@ static int __devinit mvs_pci_init(struct
 		}
 		nhost++;
 	} while (nhost < chip->n_host);
+#ifdef MVS_USE_TASKLET
+       tasklet_init(&mv_tasklet, mvs_tasklet,
+               (unsigned long)SHOST_TO_SAS_HA(shost));
+#endif
 
 	mvs_post_sas_ha_init(shost, chip);
 
diff -uprN linux-2.6.32.7/drivers/scsi/mvsas_org/mv_sas.c linux-2.6.32.7/drivers/scsi/mvsas/mv_sas.c
--- linux-2.6.32.7/drivers/scsi/mvsas_org/mv_sas.c	2010-02-12 00:25:26.000000000 +0530
+++ linux-2.6.32.7/drivers/scsi/mvsas/mv_sas.c	2010-02-12 18:27:18.000000000 +0530
@@ -259,8 +259,6 @@ static inline void mvs_free_reg_set(stru
 		mv_printk("device has been free.\n");
 		return;
 	}
-	if (dev->runing_req != 0)
-		return;
 	if (dev->taskfileset == MVS_ID_NOT_MAPPED)
 		return;
 	MVS_CHIP_DISP->free_reg_set(mvi, &dev->taskfileset);
@@ -597,7 +595,7 @@ static int mvs_task_prep_ata(struct mvs_
 	struct mvs_slot_info *slot;
 	void *buf_prd;
 	u32 tag = tei->tag, hdr_tag;
-	u32 flags, del_q;
+	u32 flags, del_q, phy_mask;
 	void *buf_tmp;
 	u8 *buf_cmd, *buf_oaf;
 	dma_addr_t buf_tmp_dma;
@@ -762,8 +760,6 @@ static int mvs_task_prep_ssp(struct mvs_
 	}
 	if (is_tmf)
 		flags |= (MCH_SSP_FR_TASK << MCH_SSP_FR_TYPE_SHIFT);
-	else
-		flags |= (MCH_SSP_FR_CMD << MCH_SSP_FR_TYPE_SHIFT);
 	hdr->flags = cpu_to_le32(flags | (tei->n_elem << MCH_PRD_LEN_SHIFT));
 	hdr->tags = cpu_to_le32(tag);
 	hdr->data_len = cpu_to_le32(task->total_xfer_len);
@@ -878,14 +874,15 @@ static int mvs_task_exec(struct sas_task
 	struct mvs_slot_info *slot;
 	u32 tag = 0xdeadbeef, rc, n_elem = 0;
 	u32 n = num, pass = 0;
-	unsigned long flags = 0;
+	unsigned long flags = 0,  flags_libsas = 0;
 
 	if (!dev->port) {
 		struct task_status_struct *tsm = &t->task_status;
 
 		tsm->resp = SAS_TASK_UNDELIVERED;
 		tsm->stat = SAS_PHY_DOWN;
-		t->task_done(t);
+		if (dev->dev_type != SATA_DEV)
+			t->task_done(t);
 		return 0;
 	}
 
@@ -910,12 +907,23 @@ static int mvs_task_exec(struct sas_task
 		else
 			tei.port = &mvi->port[dev->port->id];
 
-		if (!tei.port->port_attached) {
+		if (tei.port && !tei.port->port_attached) {
 			if (sas_protocol_ata(t->task_proto)) {
 				mv_dprintk("port %d does not"
 					"attached device.\n", dev->port->id);
-				rc = SAS_PHY_DOWN;
-				goto out_done;
+			 	struct task_status_struct *ts = &t->task_status;
+                ts->stat = SAS_PROTO_RESPONSE;
+                ts->stat = SAS_PHY_DOWN;
+	            spin_unlock_irqrestore(dev->sata_dev.ap->lock,
+                                          flags_libsas);
+                spin_unlock_irqrestore(&mvi->lock, flags);
+                t->task_done(t);
+                spin_lock_irqsave(&mvi->lock, flags);
+                spin_lock_irqsave(dev->sata_dev.ap->lock,
+                                  flags_libsas);
+                if (n > 1)
+                	t = list_entry(t->list.next,struct sas_task, list);
+                    continue;
 			} else {
 				struct task_status_struct *ts = &t->task_status;
 				ts->resp = SAS_TASK_UNDELIVERED;
@@ -972,8 +980,7 @@ static int mvs_task_exec(struct sas_task
 			rc = mvs_task_prep_ata(mvi, &tei);
 			break;
 		default:
-			dev_printk(KERN_ERR, mvi->dev,
-				"unknown sas_task proto: 0x%x\n",
+			dev_printk(KERN_ERR, mvi->dev, "unknown sas_task proto: 0x%x\n",
 				t->task_proto);
 			rc = -EINVAL;
 			break;
@@ -993,11 +1000,16 @@ static int mvs_task_exec(struct sas_task
 		spin_unlock(&t->task_state_lock);
 
 		mvs_hba_memory_dump(mvi, tag, t->task_proto);
-		mvi_dev->runing_req++;
+		mvi_dev->running_req++;
 		++pass;
 		mvi->tx_prod = (mvi->tx_prod + 1) & (MVS_CHIP_SLOT_SZ - 1);
 		if (n > 1)
 			t = list_entry(t->list.next, struct sas_task, list);
+		if (likely(pass)) {
+       		        MVS_CHIP_DISP->start_delivery(mvi,(mvi->tx_prod - 1) & (MVS_CHIP_SLOT_SZ - 1));
+               }
+	
+
 	} while (--n);
 	rc = 0;
 	goto out_done;
@@ -1012,10 +1024,6 @@ err_out:
 			dma_unmap_sg(mvi->dev, t->scatter, n_elem,
 				     t->data_dir);
 out_done:
-	if (likely(pass)) {
-		MVS_CHIP_DISP->start_delivery(mvi,
-			(mvi->tx_prod - 1) & (MVS_CHIP_SLOT_SZ - 1));
-	}
 	spin_unlock_irqrestore(&mvi->lock, flags);
 	return rc;
 }
@@ -1187,7 +1195,7 @@ void mvs_update_phyinfo(struct mvs_info
 				MVS_CHIP_DISP->phy_reset(mvi, i, 0);
 				goto out_done;
 			}
-		}		else if (phy->phy_type & PORT_TYPE_SAS
+		}	else if (phy->phy_type & PORT_TYPE_SAS
 			|| phy->att_dev_info & PORT_SSP_INIT_MASK) {
 			phy->phy_attached = 1;
 			phy->identify.device_type =
@@ -1256,7 +1264,20 @@ static void mvs_port_notify_formed(struc
 
 static void mvs_port_notify_deformed(struct asd_sas_phy *sas_phy, int lock)
 {
-	/*Nothing*/
+       struct domain_device *dev;
+       struct mvs_phy *phy = sas_phy->lldd_phy;
+       struct mvs_info *mvi = phy->mvi;
+       struct asd_sas_port *port = sas_phy->port;
+       int phy_no = 0;
+
+       while (phy != &mvi->phy[phy_no]) {
+               phy_no++;
+               if (phy_no >= MVS_MAX_PHYS)
+                       return;
+       }
+       list_for_each_entry(dev, &port->dev_list, dev_list_node)
+               mvs_do_release_task(phy->mvi, phy_no, NULL);
+
 }
 
 
@@ -1316,6 +1337,7 @@ int mvs_dev_found_notify(struct domain_d
 		goto found_out;
 	}
 	dev->lldd_dev = mvi_device;
+	mvi_device->dev_status = MVS_DEV_NORMAL;
 	mvi_device->dev_type = dev->dev_type;
 	mvi_device->mvi_info = mvi;
 	if (parent_dev && DEV_IS_EXPANDER(parent_dev->dev_type)) {
@@ -1351,18 +1373,18 @@ int mvs_dev_found(struct domain_device *
 	return mvs_dev_found_notify(dev, 1);
 }
 
-void mvs_dev_gone_notify(struct domain_device *dev, int lock)
+void mvs_dev_gone_notify(struct domain_device *dev)
 {
 	unsigned long flags = 0;
 	struct mvs_device *mvi_dev = dev->lldd_dev;
 	struct mvs_info *mvi = mvi_dev->mvi_info;
 
-	if (lock)
-		spin_lock_irqsave(&mvi->lock, flags);
+	spin_lock_irqsave(&mvi->lock, flags);
 
 	if (mvi_dev) {
 		mv_dprintk("found dev[%d:%x] is gone.\n",
 			mvi_dev->device_id, mvi_dev->dev_type);
+		mvs_release_task(mvi, dev);
 		mvs_free_reg_set(mvi, mvi_dev);
 		mvs_free_dev(mvi_dev);
 	} else {
@@ -1370,14 +1392,13 @@ void mvs_dev_gone_notify(struct domain_d
 	}
 	dev->lldd_dev = NULL;
 
-	if (lock)
 		spin_unlock_irqrestore(&mvi->lock, flags);
 }
 
 
 void mvs_dev_gone(struct domain_device *dev)
 {
-	mvs_dev_gone_notify(dev, 1);
+	mvs_dev_gone_notify(dev);
 }
 
 static  struct sas_task *mvs_alloc_task(void)
@@ -1540,7 +1561,7 @@ int mvs_lu_reset(struct domain_device *d
 		num = mvs_find_dev_phyno(dev, phyno);
 		spin_lock_irqsave(&mvi->lock, flags);
 		for (i = 0; i < num; i++)
-			mvs_release_task(mvi, phyno[i], dev);
+			mvs_release_task(mvi, dev);
 		spin_unlock_irqrestore(&mvi->lock, flags);
 	}
 	/* If failed, fall-through I_T_Nexus reset */
@@ -1552,8 +1573,8 @@ int mvs_lu_reset(struct domain_device *d
 int mvs_I_T_nexus_reset(struct domain_device *dev)
 {
 	unsigned long flags;
-	int i, phyno[WIDE_PORT_MAX_PHY], num , rc = TMF_RESP_FUNC_FAILED;
-	struct mvs_device * mvi_dev = (struct mvs_device *)dev->lldd_dev;
+	int rc = TMF_RESP_FUNC_FAILED;
+    struct mvs_device * mvi_dev = (struct mvs_device *)dev->lldd_dev;
 	struct mvs_info *mvi = mvi_dev->mvi_info;
 
 	if (mvi_dev->dev_status != MVS_DEV_EH)
@@ -1563,10 +1584,8 @@ int mvs_I_T_nexus_reset(struct domain_de
 		__func__, mvi_dev->device_id, rc);
 
 	/* housekeeper */
-	num = mvs_find_dev_phyno(dev, phyno);
 	spin_lock_irqsave(&mvi->lock, flags);
-	for (i = 0; i < num; i++)
-		mvs_release_task(mvi, phyno[i], dev);
+	mvs_release_task(mvi, dev);
 	spin_unlock_irqrestore(&mvi->lock, flags);
 
 	return rc;
@@ -1603,6 +1622,9 @@ int mvs_query_task(struct sas_task *task
 		case TMF_RESP_FUNC_FAILED:
 		case TMF_RESP_FUNC_COMPLETE:
 			break;
+		default:
+			rc = TMF_RESP_FUNC_COMPLETE; 
+			break;
 		}
 	}
 	mv_printk("%s:rc= %d\n", __func__, rc);
@@ -1621,8 +1643,11 @@ int mvs_abort_task(struct sas_task *task
 	unsigned long flags;
 	u32 tag;
 
-	if (mvi->exp_req)
-		mvi->exp_req--;
+	if (!mvi_dev) {
+		mv_printk("%s:%d TMF_RESP_FUNC_FAILED\n", __func__, __LINE__);
+		rc = TMF_RESP_FUNC_FAILED;
+	}
+	
 	spin_lock_irqsave(&task->task_state_lock, flags);
 	if (task->task_state_flags & SAS_TASK_STATE_DONE) {
 		spin_unlock_irqrestore(&task->task_state_lock, flags);
@@ -1630,6 +1655,7 @@ int mvs_abort_task(struct sas_task *task
 		goto out;
 	}
 	spin_unlock_irqrestore(&task->task_state_lock, flags);
+	mvi_dev->dev_status = MVS_DEV_EH;
 	if (task->lldd_task && task->task_proto & SAS_PROTOCOL_SSP) {
 		struct scsi_cmnd * cmnd = (struct scsi_cmnd *)task->uldd_task;
 
@@ -1654,12 +1680,32 @@ int mvs_abort_task(struct sas_task *task
 			if (task->lldd_task) {
 				slot = task->lldd_task;
 				slot_no = (u32) (slot - mvi->slot_info);
+				spin_lock_irqsave(&mvi->lock, flags);
 				mvs_slot_complete(mvi, slot_no, 1);
+				spin_unlock_irqrestore(&mvi->lock, flags);
 			}
 		}
+	
 	} else if (task->task_proto & SAS_PROTOCOL_SATA ||
 		task->task_proto & SAS_PROTOCOL_STP) {
 		/* to do free register_set */
+		if (SATA_DEV == dev->dev_type) {
+        	struct mvs_slot_info *slot = task->lldd_task;
+			struct task_status_struct *tstat;
+	        tstat = &task->task_status;
+            u32    slot_idx =    (u32)(slot - mvi->slot_info);
+			mv_dprintk(KERN_DEBUG "mv_abort_task() mvi=%p task=%p \
+                               slot=%p slot_idx=x%x\n",
+                               mvi, task, slot, slot_idx);
+			tstat->stat = SAS_ABORTED_TASK;
+			if (mvi_dev)
+			if (mvi_dev && mvi_dev->running_req)
+				mvi_dev->running_req--;
+			if (sas_protocol_ata(task->task_proto))
+				mvs_free_reg_set(mvi, mvi_dev);
+			mvs_slot_task_free(mvi, task, slot, slot_idx);
+			return -1;
+		}
 	} else {
 		/* SMP */
 
@@ -1717,8 +1763,13 @@ static int mvs_sata_done(struct mvs_info
 	       SATA_RECEIVED_D2H_FIS(mvi_dev->taskfileset),
 	       sizeof(struct dev_to_host_fis));
 	tstat->buf_valid_size = sizeof(*resp);
-	if (unlikely(err))
-		stat = SAS_PROTO_RESPONSE;
+	if (unlikely(err)) {
+	      if (unlikely(err & CMD_ISS_STPD))
+                       stat = SAS_OPEN_REJECT;
+               else
+                       stat = SAS_PROTO_RESPONSE;
+       }
+
 	return stat;
 }
 
@@ -1728,6 +1779,7 @@ static int mvs_slot_err(struct mvs_info
 	struct mvs_slot_info *slot = &mvi->slot_info[slot_idx];
 	int stat;
 	u32 err_dw0 = le32_to_cpu(*(u32 *) (slot->response));
+	u32 err_dw1 = le32_to_cpu(*((u32 *)slot->response+1));
 	u32 tfs = 0;
 	enum mvs_port_type type = PORT_TYPE_SAS;
 
@@ -1753,9 +1805,7 @@ static int mvs_slot_err(struct mvs_info
 			mv_printk("find reserved error, why?\n");
 
 		task->ata_task.use_ncq = 0;
-		stat = SAS_PROTO_RESPONSE;
-		mvs_sata_done(mvi, task, slot_idx, 1);
-
+		mvs_sata_done(mvi, task, slot_idx, err_dw0);
 	}
 		break;
 	default:
@@ -1772,18 +1822,20 @@ int mvs_slot_complete(struct mvs_info *m
 	struct sas_task *task = slot->task;
 	struct mvs_device *mvi_dev = NULL;
 	struct task_status_struct *tstat;
+	struct domain_device *dev;	
+	u32 aborted;
 
-	bool aborted;
 	void *to;
 	enum exec_status sts;
 
 	if (mvi->exp_req)
-		mvi->exp_req--;
-	if (unlikely(!task || !task->lldd_task))
+		mvi->exp_req--; 
+	if (unlikely(!task || !task->lldd_task || !task->dev))
 		return -1;
 
 	tstat = &task->task_status;
-	mvi_dev = task->dev->lldd_dev;
+	dev = task->dev;
+	mvi_dev = dev->lldd_dev;
 
 	mvs_hba_cq_dump(mvi);
 
@@ -1801,7 +1853,8 @@ int mvs_slot_complete(struct mvs_info *m
 	if (unlikely(aborted)) {
 		tstat->stat = SAS_ABORTED_TASK;
 		if (mvi_dev)
-			mvi_dev->runing_req--;
+		if (mvi_dev && mvi_dev->running_req)
+			mvi_dev->running_req--;
 		if (sas_protocol_ata(task->task_proto))
 			mvs_free_reg_set(mvi, mvi_dev);
 
@@ -1809,24 +1862,17 @@ int mvs_slot_complete(struct mvs_info *m
 		return -1;
 	}
 
-	if (unlikely(!mvi_dev || !slot->port->port_attached || flags)) {
-		mv_dprintk("port has not device.\n");
+	if (unlikely(!mvi_dev || flags)) {
+		if (!mvi_dev)
+		    mv_dprintk("port has not device.\n");
 		tstat->stat = SAS_PHY_DOWN;
 		goto out;
 	}
 
-	/*
-	if (unlikely((rx_desc & RXQ_ERR) || (*(u64 *) slot->response))) {
-		 mv_dprintk("Find device[%016llx] RXQ_ERR %X,
-		 err info:%016llx\n",
-		 SAS_ADDR(task->dev->sas_addr),
-		 rx_desc, (u64)(*(u64 *) slot->response));
-	}
-	*/
-
 	/* error info record present */
 	if (unlikely((rx_desc & RXQ_ERR) && (*(u64 *) slot->response))) {
 		tstat->stat = mvs_slot_err(mvi, task, slot_idx);
+		tstat->resp = SAS_TASK_COMPLETE;
 		goto out;
 	}
 
@@ -1868,11 +1914,16 @@ int mvs_slot_complete(struct mvs_info *m
 		tstat->stat = SAM_CHECK_COND;
 		break;
 	}
+	if (!slot->port->port_attached) {
+	       	mv_dprintk("port %d has removed.\n", slot->port->sas_port.id);
+        	tstat->stat = SAS_PHY_DOWN;
+       }
+
 
 out:
-	if (mvi_dev) {
-		mvi_dev->runing_req--;
-		if (sas_protocol_ata(task->task_proto))
+	if (mvi_dev && mvi_dev->running_req) {
+		mvi_dev->running_req--;
+		if (sas_protocol_ata(task->task_proto) && !mvi_dev->running_req)
 			mvs_free_reg_set(mvi, mvi_dev);
 	}
 	mvs_slot_task_free(mvi, task, slot, slot_idx);
@@ -1888,10 +1939,10 @@ out:
 	return sts;
 }
 
-void mvs_release_task(struct mvs_info *mvi,
+void mvs_do_release_task(struct mvs_info *mvi,
 		int phy_no, struct domain_device *dev)
 {
-	int i = 0; u32 slot_idx;
+	u32 slot_idx;
 	struct mvs_phy *phy;
 	struct mvs_port *port;
 	struct mvs_slot_info *slot, *slot2;
@@ -1900,6 +1951,10 @@ void mvs_release_task(struct mvs_info *m
 	port = phy->port;
 	if (!port)
 		return;
+	/* clean cmpl queue in case request is already finished */
+ 	      mvs_int_rx(mvi, false);
+
+
 
 	list_for_each_entry_safe(slot, slot2, &port->list, entry) {
 		struct sas_task *task;
@@ -1911,18 +1966,22 @@ void mvs_release_task(struct mvs_info *m
 
 		mv_printk("Release slot [%x] tag[%x], task [%p]:\n",
 			slot_idx, slot->slot_tag, task);
-
-		if (task->task_proto & SAS_PROTOCOL_SSP) {
-			mv_printk("attached with SSP task CDB[");
-			for (i = 0; i < 16; i++)
-				mv_printk(" %02x", task->ssp_task.cdb[i]);
-			mv_printk(" ]\n");
-		}
+		MVS_CHIP_DISP->command_active(mvi, slot_idx);
 
 		mvs_slot_complete(mvi, slot_idx, 1);
 	}
 }
 
+void mvs_release_task(struct mvs_info *mvi,
+                       struct domain_device *dev)
+{
+       int i, phyno[WIDE_PORT_MAX_PHY], num;
+       /* housekeeper */
+       num = mvs_find_dev_phyno(dev, phyno);
+       for (i = 0; i < num; i++)
+               mvs_do_release_task(mvi, phyno[i], dev);
+}
+
 static void mvs_phy_disconnected(struct mvs_phy *phy)
 {
 	phy->phy_attached = 0;
@@ -2029,16 +2088,18 @@ void mvs_int_port(struct mvs_info *mvi,
 	* we need check the interrupt status which belongs to per port.
 	*/
 
-	if (phy->irq_status & PHYEV_DCDR_ERR)
+	if (phy->irq_status & PHYEV_DCDR_ERR) {
 		mv_dprintk("port %d STP decoding error.\n",
-		phy_no+mvi->id*mvi->chip->n_phy);
+		phy_no + mvi->id*mvi->chip->n_phy);
+	}
 
 	if (phy->irq_status & PHYEV_POOF) {
 		if (!(phy->phy_event & PHY_PLUG_OUT)) {
 			int dev_sata = phy->phy_type & PORT_TYPE_SATA;
 			int ready;
-			mvs_release_task(mvi, phy_no, NULL);
+			mvs_do_release_task(mvi, phy_no, NULL);
 			phy->phy_event |= PHY_PLUG_OUT;
+			MVS_CHIP_DISP->clear_srs_irq(mvi, 0, 1);
 			mvs_handle_event(mvi,
 				(void *)(unsigned long)phy_no,
 				PHY_PLUG_EVENT);
@@ -2085,6 +2146,11 @@ void mvs_int_port(struct mvs_info *mvi,
 							phy_no, tmp);
 			}
 			mvs_update_phyinfo(mvi, phy_no, 0);
+			 if (phy->phy_type & PORT_TYPE_SAS) {
+                               MVS_CHIP_DISP->phy_reset(mvi, phy_no, 2);
+                               mdelay(100);
+                       }
+
 			mvs_bytes_dmaed(mvi, phy_no);
 			/* whether driver is going to handle hot plug */
 			if (phy->phy_event & PHY_PLUG_OUT) {
diff -uprN linux-2.6.32.7/drivers/scsi/mvsas_org/mv_sas.h linux-2.6.32.7/drivers/scsi/mvsas/mv_sas.h
--- linux-2.6.32.7/drivers/scsi/mvsas_org/mv_sas.h	2010-02-12 00:25:26.000000000 +0530
+++ linux-2.6.32.7/drivers/scsi/mvsas/mv_sas.h	2010-02-12 00:44:37.000000000 +0530
@@ -38,6 +38,7 @@
 #include <linux/irq.h>
 #include <linux/vmalloc.h>
 #include <scsi/libsas.h>
+#include <scsi/scsi.h>
 #include <scsi/scsi_tcq.h>
 #include <scsi/sas_ata.h>
 #include <linux/version.h>
@@ -48,7 +49,7 @@
 #define _MV_DUMP		0
 #define MVS_ID_NOT_MAPPED	0x7f
 /* #define DISABLE_HOTPLUG_DMA_FIX */
-#define MAX_EXP_RUNNING_REQ	2
+// #define MAX_EXP_RUNNING_REQ	2
 #define WIDE_PORT_MAX_PHY		4
 #define	MV_DISABLE_NCQ	0
 #define mv_printk(fmt, arg ...)	\
@@ -128,6 +129,7 @@ struct mvs_dispatch {
 
 	void (*get_sas_addr)(void *buf, u32 buflen);
 	void (*command_active)(struct mvs_info *mvi, u32 slot_idx);
+	void (*clear_srs_irq)(struct mvs_info *mvi, u8 reg_set, u8 clear_all);
 	void (*issue_stop)(struct mvs_info *mvi, enum mvs_port_type type,
 				u32 tfs);
 	void (*start_delivery)(struct mvs_info *mvi, u32 tx);
@@ -235,9 +237,10 @@ struct mvs_device {
 	enum sas_dev_type dev_type;
 	struct mvs_info *mvi_info;
 	struct domain_device *sas_device;
+	struct timer_list timer;
 	u32 attached_phy;
 	u32 device_id;
-	u32 runing_req;
+	u32 running_req;
 	u8 taskfileset;
 	u8 dev_status;
 	u16 reserved;
@@ -396,7 +399,9 @@ int mvs_lu_reset(struct domain_device *d
 int mvs_slot_complete(struct mvs_info *mvi, u32 rx_desc, u32 flags);
 int mvs_I_T_nexus_reset(struct domain_device *dev);
 int mvs_query_task(struct sas_task *task);
-void mvs_release_task(struct mvs_info *mvi, int phy_no,
+void mvs_release_task(struct mvs_info *mvi,
+			struct domain_device *dev);
+void mvs_do_release_task(struct mvs_info *mvi, int phy_no,
 			struct domain_device *dev);
 void mvs_int_port(struct mvs_info *mvi, int phy_no, u32 events);
 void mvs_update_phyinfo(struct mvs_info *mvi, int i, int get_st);

Re: Patch for MVSAS

[Caspar Smit]

Thanks!

I will test this patch monday or tuesday with 3x 6480 controllers.
I'll let you know the results.

Kind regards,
Caspar


> Hi,
> The attached patch contains the fixes for SATA hot plugging, hot plug
> in/out of drives (SAS/SATA) from Expander while IO is going on and tape
> issues.
> Try with attached patch and let me know the results.
> Note: I have tested with only 64xx chipset.
>
> Srinivas.
>
> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org
> [mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of James Bottomley
> Sent: Friday, February 12, 2010 12:26 AM
> To: Kristleifur Daðason
> Cc: Orion Poplawski; linux-scsi@vger.kernel.org
> Subject: Re: MVSAS status
>
> On Thu, 2010-02-11 at 09:50 +0000, Kristleifur Daðason wrote:
>> On Tue, Feb 9, 2010 at 11:32 PM, Orion Poplawski <orion@cora.nwra.com>
>> wrote:
>> >
>> > What's the status of the MVSAS patches posted in November '09?  I'm
>> just trying
>> > to get started with mvsas and running into the mvs_abort_task issue.
>> At least
>> > one person has reported that stability improved, but it looks like
>> there were
>> > some other issues with the patches.  Any chance on seeing this in the
>> mainline
>> > kernel soon?  Are there updated versions?  A git tree to pull from?
>> >
>>
>> As far as I know, the patches from November were rejected because the
>> patches themselves weren't solid enough - meaning there were some
>> cross-references between each of the seven patches, things like that.
>> The functionality was fine, at least a definite improvement. Ideally,
>> there would have been another set of patches to top things up and
>> really get everything running smoothly.
>
> There were two reasons for the reject.  The first was that the series
> just wasn't bisectable.  This is annoying but not completely fatal, and
> if it were a required bug fix I can just squash all the patches together
> to apply to make a single commit.  I hate doing this but I've done it
> before with problem vendor patch series.
>
> The bigger problem was there were several reports of the rate of kernel
> panics increasing with this patch series applied.  If the patch series
> is going to decrease stability, it's not worth applying.
>
> I can fix the first if someone can do a solid comparison and assure me
> that the patch series does actually increase not decrease stability.
>
>> I haven't come across any patch traffic for the card after that November
>> batch.
>
> Yes, Marvell has gone radio silent.
>
>> In the interests of getting these amazingly cheap and effective cards
>> running properly on Linux, it would be extremely good if someone
>> experienced with Linux patches would get involved in the matter with
>> Mr. Andy Yan from Marvell, straighten things out, get the ball rolling
>> and make the driver stick in mainline. When I emailed him, Mr. Yan was
>> very helpful and sent me the patches and some info. I tried to fix the
>> patches myself but was in over my head. And had no time. Etc.
>
> OK, I'll try 1:1 email with Marvell and Andy and see what comes out.
>
> James
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> DISCLAIMER:
> -----------------------------------------------------------------------------------------------------------------------
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> It shall not attach any liability on the originator or HCL or its
> affiliates. Any views or opinions presented in
> this email are solely those of the author and may not necessarily reflect
> the opinions of HCL or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure,
> modification, distribution and / or publication of
> this message without the prior written consent of the author of this
> e-mail is strictly prohibited. If you have
> received this email in error please delete it and notify the sender
> immediately. Before opening any mail and
> attachments please check them for viruses and defect.
>
> -----------------------------------------------------------------------------------------------------------------------
>

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Patch for MVSAS

[Mikael Abrahamsson]

On Fri, 12 Feb 2010, Srinivas Naga Venkatasatya Pasagadugula - ERS, HCL Tech wrote:

> Hi,
> The attached patch contains the fixes for SATA hot plugging, hot plug in/out of drives (SAS/SATA) from Expander while IO is going on and tape issues.
> Try with attached patch and let me know the results.
> Note: I have tested with only 64xx chipset.

Hi, Srinivas!

First of all, all logs outputs I have put in 
<http://swm.pp.se/linux-scsi-feb14.txt>

I used the latest 2.6.32-13 ubuntu lucid 10.04 kernel and added your 
patches and booted the machine with no drives inserted. Then I 
hot-inserted drive after drive, where one drive gave me kernel errors in 
lib-ata (see above mentioned log). I then proceeded to do:

"mdadm --create /dev/md9 --chunk=128 --level=6 --raid-device=4 --size=2000000 --metadata=1.2 /dev/sd[bcde]"

That made mdadm go into D-state, accessing sdc (the oops:ed one). I 
unplugged sdc which made mdadm come out of D-state, ran the above line 
with "missing" instead of sdc, then my raid6 started sync:ing. I then put 
another drive in sdc slot which started without oops and then I as 
successfully able to add it to my test raid6. I then put that (I guess 
bad) drive in another drive slot (hotswapped) and the controller again 
gets the fits, so the error handling for whatever is wrong with that 
drive, could use some improvement.

Apart from that bad drive causing problems, the driver now seems to be in 
a much much better state. "smartctl -a" needs "-T permissive" on my 
WD20EADS drives, but it seems to be a bit coming and going, I don't really 
know the exact symptom. It seems to be initially, then after a while of 
trying it starts working without "-T permissive".

I rebooted the machine again (with only known good working disks but none 
plugged in) and hotplugged one drive, got the libata-core.c:5187 oops 
again. I now got the smartctl -a needing "-T permissive" on the WD20EADS 
drives again, but it cleared up after a few attempts.

I then rebooted again with all the drives plugged in and everything seemed 
to work fine. Tried some hot-remove and hot-plugging and didn't get any 
unexpected behaviour apart from more libata-core:5187 oops.

At no time did the machine crash or stopped responding (apart for 
processes in D-state that is). Great improvement! Good work!

I have the following hw (lspci -vvv)

02:00.0 SCSI storage controller: Marvell Technology Group Ltd. 
MV64460/64461/64462 System Controller, Revision B (rev 01)
 	Subsystem: Super Micro Computer Inc Device 0500
 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 	Latency: 0, Cache Line Size: 32 bytes
 	Interrupt: pin A routed to IRQ 16
 	Region 2: I/O ports at bc00 [size=128]
 	Region 4: Memory at fe7f0000 (64-bit, non-prefetchable) [size=64K]
 	Expansion ROM at fe780000 [disabled] [size=256K]
 	Capabilities: [48] Power Management version 2
 		Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0+,D1+,D2-,D3hot+,D3cold-)
 		Status: D0 PME-Enable- DSel=0 DScale=1 PME-
 	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
 		Address: 0000000000000000  Data: 0000
 	Capabilities: [e0] Express (v1) Legacy Endpoint, MSI 00
 		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
 			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
 		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
 			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
 			MaxPayload 128 bytes, MaxReadReq 2048 bytes
 		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
 		LnkCap:	Port #1, Speed 2.5GT/s, Width x4, ASPM L0s, Latency L0 <256ns, L1 unlimited
 			ClockPM- Suprise- LLActRep- BwNot-
 		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
 			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
 		LnkSta:	Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
 	Capabilities: [100] Advanced Error Reporting <?>
 	Kernel driver in use: mvsas
 	Kernel modules: mvsas

------------------------------------------------------------------------------------

Example of output where I need -T permissive:

root@swmike-test:/var/log# smartctl -a /dev/sde
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD20EADS-00S2B0
Serial Number:    WD-WCAVY0701443
Firmware Version: 04.05G04
User Capacity:    2,000,398,934,016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Sun Feb 14 10:27:57 2010 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Error SMART Status command failed
Please get assistance from http://smartmontools.sourceforge.net/
Values from ATA Return Descriptor are:
  00     09 0c 00 00 00 04 00 b0  00 3d 00 7e 40 40
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

----------------------------------------------------------------------------------

And here it works.


root@swmike-test:/var/log# smartctl -T permissive -a /dev/sde
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD20EADS-00S2B0
Serial Number:    WD-WCAVY0701443
Firmware Version: 04.05G04
User Capacity:    2,000,398,934,016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Sun Feb 14 10:28:21 2010 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Error SMART Status command failed
Please get assistance from http://smartmontools.sourceforge.net/
Values from ATA Return Descriptor are:
  00     09 0c 00 00 00 04 00 48  00 12 00 91 40 40
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x84)	Offline data collection activity
 					was suspended by an interrupting 
command from host.
 					Auto Offline Data Collection: 
Enabled.
Self-test execution status:      (   0)	The previous self-test routine 
completed
 					without error or no self-test has 
ever
 					been run.
Total time to complete Offline
data collection: 		 (43800) seconds.
Offline data collection
capabilities: 			 (0x7b) SMART execute Offline immediate.
 					Auto Offline data collection 
on/off support.
 					Suspend Offline collection upon 
new
 					command.
 					Offline surface scan supported.
 					Self-test supported.
 					Conveyance Self-test supported.
 					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
 					power-saving mode.
 					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
 					General Purpose Logging supported.
Short self-test routine
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 ( 255) minutes.
Conveyance self-test routine
recommended polling time: 	 (   5) minutes.
SCT capabilities: 	       (0x303f)	SCT Status supported.
 					SCT Feature Control supported.
 					SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED 
WHEN_FAILED RAW_VALUE
   1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always 
-       0
   3 Spin_Up_Time            0x0027   150   146   021    Pre-fail  Always 
-       9491
   4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always 
-       38
   5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always 
-       0
   7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always 
-       0
   9 Power_On_Hours          0x0032   100   100   000    Old_age   Always 
-       10
  10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always 
-       0
  11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always 
-       0
  12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always 
-       34
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always 
-       26
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always 
-       134
194 Temperature_Celsius     0x0022   122   115   000    Old_age   Always 
-       30
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always 
-       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always 
-       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline 
-       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always 
-       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline 
-       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]


SMART Selective self-test log data structure revision number 1
  SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
     1        0        0  Not_testing
     2        0        0  Not_testing
     3        0        0  Not_testing
     4        0        0  Not_testing
     5        0        0  Not_testing
Selective self-test flags (0x0):
   After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute 
delay.



-- 
Mikael Abrahamsson    email: swmike@swm.pp.se