* MVSAS status @ 2010-02-09 23:32 Orion Poplawski 2010-02-10 9:22 ` Audio Haven 2010-02-11 9:50 ` Kristleifur Daðason 0 siblings, 2 replies; 13+ messages in thread From: Orion Poplawski @ 2010-02-09 23:32 UTC (permalink / raw) To: linux-scsi 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MVSAS status 2010-02-09 23:32 MVSAS status Orion Poplawski @ 2010-02-10 9:22 ` Audio Haven 2010-02-10 9:36 ` Caspar Smit 2010-02-10 9:39 ` Mikael Abrahamsson 2010-02-11 9:50 ` Kristleifur Daðason 1 sibling, 2 replies; 13+ messages in thread From: Audio Haven @ 2010-02-10 9:22 UTC (permalink / raw) To: linux-scsi 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MVSAS status 2010-02-10 9:22 ` Audio Haven @ 2010-02-10 9:36 ` Caspar Smit 2010-02-10 9:39 ` Mikael Abrahamsson 1 sibling, 0 replies; 13+ messages in thread From: Caspar Smit @ 2010-02-10 9:36 UTC (permalink / raw) To: Audio Haven; +Cc: linux-scsi > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MVSAS status 2010-02-10 9:22 ` Audio Haven 2010-02-10 9:36 ` Caspar Smit @ 2010-02-10 9:39 ` Mikael Abrahamsson 2010-02-10 9:53 ` Re[2]: " Erno Kovacs 1 sibling, 1 reply; 13+ messages in thread From: Mikael Abrahamsson @ 2010-02-10 9:39 UTC (permalink / raw) To: linux-scsi 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re[2]: MVSAS status 2010-02-10 9:39 ` Mikael Abrahamsson @ 2010-02-10 9:53 ` Erno Kovacs 0 siblings, 0 replies; 13+ messages in thread From: Erno Kovacs @ 2010-02-10 9:53 UTC (permalink / raw) To: linux-scsi > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MVSAS status 2010-02-09 23:32 MVSAS status Orion Poplawski 2010-02-10 9:22 ` Audio Haven @ 2010-02-11 9:50 ` Kristleifur Daðason 2010-02-11 11:20 ` Mikael Abrahamsson ` (2 more replies) 1 sibling, 3 replies; 13+ messages in thread From: Kristleifur Daðason @ 2010-02-11 9:50 UTC (permalink / raw) To: Orion Poplawski; +Cc: linux-scsi 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MVSAS status 2010-02-11 9:50 ` Kristleifur Daðason @ 2010-02-11 11:20 ` Mikael Abrahamsson 2010-02-11 11:21 ` Kristleifur Daðason 2010-02-11 18:30 ` Orion Poplawski 2010-02-11 18:55 ` James Bottomley 2 siblings, 1 reply; 13+ messages in thread From: Mikael Abrahamsson @ 2010-02-11 11:20 UTC (permalink / raw) To: linux-scsi [-- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MVSAS status 2010-02-11 11:20 ` Mikael Abrahamsson @ 2010-02-11 11:21 ` Kristleifur Daðason 0 siblings, 0 replies; 13+ messages in thread From: Kristleifur Daðason @ 2010-02-11 11:21 UTC (permalink / raw) To: Mikael Abrahamsson; +Cc: linux-scsi 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MVSAS status 2010-02-11 9:50 ` Kristleifur Daðason 2010-02-11 11:20 ` Mikael Abrahamsson @ 2010-02-11 18:30 ` Orion Poplawski 2010-02-11 18:55 ` James Bottomley 2 siblings, 0 replies; 13+ messages in thread From: Orion Poplawski @ 2010-02-11 18:30 UTC (permalink / raw) To: linux-scsi 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MVSAS status 2010-02-11 9:50 ` Kristleifur Daðason 2010-02-11 11:20 ` Mikael Abrahamsson 2010-02-11 18:30 ` Orion Poplawski @ 2010-02-11 18:55 ` James Bottomley 2010-02-12 12:12 ` Patch for MVSAS Srinivas Naga Venkatasatya Pasagadugula - ERS, HCL Tech 2 siblings, 1 reply; 13+ messages in thread From: James Bottomley @ 2010-02-11 18:55 UTC (permalink / raw) To: Kristleifur Daðason; +Cc: Orion Poplawski, linux-scsi 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Patch for MVSAS 2010-02-11 18:55 ` James Bottomley @ 2010-02-12 12:12 ` Srinivas Naga Venkatasatya Pasagadugula - ERS, HCL Tech [not found] ` <6B62480106F2B34D8404CF2FDAA4D9EF71F637D6DB@CHN-HCLT-EVS06.HCLT.CORP.H CL.IN-99D05D88-A0F3-0C58-BFB2-2F138E38F61D> 2010-02-14 10:00 ` Mikael Abrahamsson 0 siblings, 2 replies; 13+ messages in thread From: Srinivas Naga Venkatasatya Pasagadugula - ERS, HCL Tech @ 2010-02-12 12:12 UTC (permalink / raw) To: James Bottomley, linux-scsi Cc: Orion Poplawski, swmike, Kristleifur Daðason, caspar [-- 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); ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <6B62480106F2B34D8404CF2FDAA4D9EF71F637D6DB@CHN-HCLT-EVS06.HCLT.CORP.H CL.IN-99D05D88-A0F3-0C58-BFB2-2F138E38F61D>]
* Re: Patch for MVSAS [not found] ` <6B62480106F2B34D8404CF2FDAA4D9EF71F637D6DB@CHN-HCLT-EVS06.HCLT.CORP.H CL.IN-99D05D88-A0F3-0C58-BFB2-2F138E38F61D> @ 2010-02-13 9:17 ` Caspar Smit 0 siblings, 0 replies; 13+ messages in thread From: Caspar Smit @ 2010-02-13 9:17 UTC (permalink / raw) To: Srinivas Naga Venkatasatya Pasagadugula - ERS, HCL Tech; +Cc: linux-scsi 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Patch for MVSAS 2010-02-12 12:12 ` Patch for MVSAS Srinivas Naga Venkatasatya Pasagadugula - ERS, HCL Tech [not found] ` <6B62480106F2B34D8404CF2FDAA4D9EF71F637D6DB@CHN-HCLT-EVS06.HCLT.CORP.H CL.IN-99D05D88-A0F3-0C58-BFB2-2F138E38F61D> @ 2010-02-14 10:00 ` Mikael Abrahamsson 1 sibling, 0 replies; 13+ messages in thread From: Mikael Abrahamsson @ 2010-02-14 10:00 UTC (permalink / raw) To: Srinivas Naga Venkatasatya Pasagadugula - ERS, HCL Tech Cc: James Bottomley, linux-scsi, Orion Poplawski, Kristleifur Daðason, caspar 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2010-02-14 10:00 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-02-09 23:32 MVSAS status Orion Poplawski
2010-02-10 9:22 ` Audio Haven
2010-02-10 9:36 ` Caspar Smit
2010-02-10 9:39 ` Mikael Abrahamsson
2010-02-10 9:53 ` Re[2]: " Erno Kovacs
2010-02-11 9:50 ` Kristleifur Daðason
2010-02-11 11:20 ` Mikael Abrahamsson
2010-02-11 11:21 ` Kristleifur Daðason
2010-02-11 18:30 ` Orion Poplawski
2010-02-11 18:55 ` James Bottomley
2010-02-12 12:12 ` Patch for MVSAS Srinivas Naga Venkatasatya Pasagadugula - ERS, HCL Tech
[not found] ` <6B62480106F2B34D8404CF2FDAA4D9EF71F637D6DB@CHN-HCLT-EVS06.HCLT.CORP.H CL.IN-99D05D88-A0F3-0C58-BFB2-2F138E38F61D>
2010-02-13 9:17 ` Caspar Smit
2010-02-14 10:00 ` Mikael Abrahamsson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.