RE: Broadcom 9460 raid card takes too long at system resuming

Hi Chris - Most likely behavior you explained is associated with how much time FW takes to be activated. In case of actual init from fresh boot, FW is already started running once system is powered on, and user may not be aware of it. By the time OS boot reach driver load from fresh boot, there

RE: problem booting 5.10

> -Original Message- > From: John Garry [mailto:john.ga...@huawei.com] > Sent: Wednesday, December 9, 2020 9:22 PM > To: Julia Lawall ; Kashyap Desai > > Cc: Martin K. Petersen ; Linus Torvalds > ; James E.J. Bottomley > ; Linux Kernel Mailing List ker...@vger

RE: [PATCH v8 17/18] scsi: megaraid_sas: Added support for shared host tagset for cpuhotplug

> > > > v5.10-rc2 is also broken here. > > John, Kashyap, any update on this? If this is going to take a while to fix > it > proper, should I send a patch to revert this or at least disable the > feature by > default for megaraid_sas in the meantime, so it no longer breaks the > existing > systems

RE: [PATCH v8 17/18] scsi: megaraid_sas: Added support for shared host tagset for cpuhotplug

> On Wed, 2020-08-19 at 23:20 +0800, John Garry wrote: > > From: Kashyap Desai > > > > Fusion adapters can steer completions to individual queues, and we now > > have support for shared host-wide tags. > > So we can enable multiqueue support for fusion adapters.

RE: [PATCH v8 00/18] blk-mq/scsi: Provide hostwide shared tags for SCSI HBAs

> > John, > > > Have you had a chance to check these outstanding SCSI patches? > > > > scsi: megaraid_sas: Added support for shared host tagset for cpuhotplug > > scsi: scsi_debug: Support host tagset > > scsi: hisi_sas: Switch v3 hw to MQ > > scsi: core: Show nr_hw_queues in sysfs > > scsi: Add

RE: [PATCH 1/8] scsi: add a host / host template field for the virt boundary

ize aligned, and un-aligned max segment size has caused trouble on > mmc. I validated changes on latest and few older series controllers. Post changes, I noticed max_segment_size is updated. find /sys/ -name max_segment_size |grep sdb |xargs grep -r . /sys/devices/pci:3a/:3a:00.0/:3b:00.0/:3c:04.0/:40:00.0/:41:00.0/:42:00.0/host0/target0:2:12/0:2:12:0/block/sdb/queue/max_segment_size:4294967295 I verify that single SGE having 1MB transfer length is working fine. Acked-by: Kashyap Desai < kashyap.de...@broadcom.com> > > Thanks, > Ming Lei >

RE: [PATCH 10/13] megaraid_sas: set virt_boundary_mask in the scsi host

> > So before I respin this series, can you help with a way to figure out for > mpt3sas and megaraid if a given controller supports NVMe devices at all, so > that we don't have to set the virt boundary if not? In MegaRaid we have below enum -VENTURA_SERIES and AERO_SERIES supports NVME

RE: [RFC PATCH] irq/affinity: Mark the pre/post vectors as regular interrupts

> This is the wrong direction as it does not allow to do initial affinity > assignement for the non-managed interrupts on allocation time. And that's > what Kashyap and Sumit are looking for. > > The trivial fix for the possible breakage when irq_default_affinity != > cpu_possible_mask is to set

RE: [RFC PATCH] irq/affinity: Mark the pre/post vectors as regular interrupts

> This is the wrong direction as it does not allow to do initial affinity > assignement for the non-managed interrupts on allocation time. And that's > what Kashyap and Sumit are looking for. > > The trivial fix for the possible breakage when irq_default_affinity != > cpu_possible_mask is to set

RE: Affinity managed interrupts vs non-managed interrupts

> > The point I don't get here is why you need separate reply queues for > the interrupt coalesce setting. Shouldn't this just be a flag at > submission time that indicates the amount of coalescing that should > happen? > > What is the benefit of having different completion queues? Having

RE: Affinity managed interrupts vs non-managed interrupts

> > The point I don't get here is why you need separate reply queues for > the interrupt coalesce setting. Shouldn't this just be a flag at > submission time that indicates the amount of coalescing that should > happen? > > What is the benefit of having different completion queues? Having

RE: Affinity managed interrupts vs non-managed interrupts

> > > > It is not yet finalized, but it can be based on per sdev outstanding, > > shost_busy etc. > > We want to use special 16 reply queue for IO acceleration (these queues are > > working interrupt coalescing mode. This is a h/w feature) > > TBH, this does not make any sense whatsoever. Why are

RE: Affinity managed interrupts vs non-managed interrupts

> > > > It is not yet finalized, but it can be based on per sdev outstanding, > > shost_busy etc. > > We want to use special 16 reply queue for IO acceleration (these queues are > > working interrupt coalescing mode. This is a h/w feature) > > TBH, this does not make any sense whatsoever. Why are

RE: Affinity managed interrupts vs non-managed interrupts

ux-kernel@vger.kernel.org; Kashyap > Desai; Shivasharan Srikanteshwara > Subject: RE: Affinity managed interrupts vs non-managed interrupts > > > -Original Message- > > From: Ming Lei [mailto:ming@redhat.com] > > Sent: Wednesday, August 29, 2018 2:16 PM > >

RE: Affinity managed interrupts vs non-managed interrupts

ux-kernel@vger.kernel.org; Kashyap > Desai; Shivasharan Srikanteshwara > Subject: RE: Affinity managed interrupts vs non-managed interrupts > > > -Original Message- > > From: Ming Lei [mailto:ming@redhat.com] > > Sent: Wednesday, August 29, 2018 2:16 PM > >

RE: system hung up when offlining CPUs

> > On 09/12/2017 08:15 PM, YASUAKI ISHIMATSU wrote: > > + linux-scsi and maintainers of megasas > > > > When offlining CPU, I/O stops. Do you have any ideas? > > > > On 09/07/2017 04:23 PM, YASUAKI ISHIMATSU wrote: > >> Hi Mark and Christoph, > >> > >> Sorry for the late reply. I appreciated that

RE: system hung up when offlining CPUs

> > On 09/12/2017 08:15 PM, YASUAKI ISHIMATSU wrote: > > + linux-scsi and maintainers of megasas > > > > When offlining CPU, I/O stops. Do you have any ideas? > > > > On 09/07/2017 04:23 PM, YASUAKI ISHIMATSU wrote: > >> Hi Mark and Christoph, > >> > >> Sorry for the late reply. I appreciated that

RE: [PATCH v2 00/13] mpt3sas driver NVMe support:

> -Original Message- > From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] > Sent: Monday, August 07, 2017 7:48 PM > To: Kashyap Desai; Christoph Hellwig; Hannes Reinecke > Cc: Suganath Prabu Subramani; martin.peter...@oracle.com; linux- > s...@vger.

RE: [PATCH v2 00/13] mpt3sas driver NVMe support:

> -Original Message- > From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] > Sent: Monday, August 07, 2017 7:48 PM > To: Kashyap Desai; Christoph Hellwig; Hannes Reinecke > Cc: Suganath Prabu Subramani; martin.peter...@oracle.com; linux- > s...@vger.

RE: [PATCH v2 00/13] mpt3sas driver NVMe support:

> -Original Message- > From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] > Sent: Saturday, August 05, 2017 8:12 PM > To: Christoph Hellwig; Hannes Reinecke > Cc: Suganath Prabu S; martin.peter...@oracle.com; linux- > s...@vger.kernel.org; sathya.prak...@broadcom.com; >

RE: [PATCH v2 00/13] mpt3sas driver NVMe support:

> -Original Message- > From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] > Sent: Saturday, August 05, 2017 8:12 PM > To: Christoph Hellwig; Hannes Reinecke > Cc: Suganath Prabu S; martin.peter...@oracle.com; linux- > s...@vger.kernel.org; sathya.prak...@broadcom.com; >

RE: [RESEND][PATCH 07/10][SCSI]mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support

> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Martin K. Petersen > Sent: Thursday, April 27, 2017 3:55 AM > To: Sreekanth Reddy > Cc: Martin K. Petersen; j...@kernel.org; linux-s...@vger.kernel.org; linux- >

RE: [RESEND][PATCH 07/10][SCSI]mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support

> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Martin K. Petersen > Sent: Thursday, April 27, 2017 3:55 AM > To: Sreekanth Reddy > Cc: Martin K. Petersen; j...@kernel.org; linux-s...@vger.kernel.org; linux- >

RE: out of range LBA using sg_raw

> -Original Message- > From: Martin K. Petersen [mailto:martin.peter...@oracle.com] > Sent: Wednesday, March 08, 2017 10:03 PM > To: Kashyap Desai > Cc: Christoph Hellwig; linux-kernel@vger.kernel.org; linux- > s...@vger.kernel.org > Subject: Re: out of r

RE: out of range LBA using sg_raw

> -Original Message- > From: Martin K. Petersen [mailto:martin.peter...@oracle.com] > Sent: Wednesday, March 08, 2017 10:03 PM > To: Kashyap Desai > Cc: Christoph Hellwig; linux-kernel@vger.kernel.org; linux- > s...@vger.kernel.org > Subject: Re: out of r

RE: out of range LBA using sg_raw

> -Original Message- > From: Christoph Hellwig [mailto:h...@infradead.org] > Sent: Wednesday, March 08, 2017 9:37 PM > To: Kashyap Desai > Cc: Christoph Hellwig; linux-kernel@vger.kernel.org; linux- > s...@vger.kernel.org > Subject: Re: out of range LBA using sg_r

RE: out of range LBA using sg_raw

> -Original Message- > From: Christoph Hellwig [mailto:h...@infradead.org] > Sent: Wednesday, March 08, 2017 9:37 PM > To: Kashyap Desai > Cc: Christoph Hellwig; linux-kernel@vger.kernel.org; linux- > s...@vger.kernel.org > Subject: Re: out of range LBA using sg_r

RE: out of range LBA using sg_raw

e LBA using sg_raw > > On Wed, 2017-03-08 at 21:29 +0530, Kashyap Desai wrote: > > Also one more fault I can generate using below sg_raw command - > > > > "sg_raw -r 32k /dev/sdx 28 00 01 4f ff ff 00 00 08 00" > > > > Provide more scsi data length comp

RE: out of range LBA using sg_raw

e LBA using sg_raw > > On Wed, 2017-03-08 at 21:29 +0530, Kashyap Desai wrote: > > Also one more fault I can generate using below sg_raw command - > > > > "sg_raw -r 32k /dev/sdx 28 00 01 4f ff ff 00 00 08 00" > > > > Provide more scsi data length comp

RE: out of range LBA using sg_raw

> -Original Message- > From: Christoph Hellwig [mailto:h...@infradead.org] > Sent: Wednesday, March 08, 2017 8:41 PM > To: Kashyap Desai > Cc: linux-kernel@vger.kernel.org; linux-s...@vger.kernel.org > Subject: Re: out of range LBA using sg_raw > > Hi Kashyap, &

RE: out of range LBA using sg_raw

> -Original Message- > From: Christoph Hellwig [mailto:h...@infradead.org] > Sent: Wednesday, March 08, 2017 8:41 PM > To: Kashyap Desai > Cc: linux-kernel@vger.kernel.org; linux-s...@vger.kernel.org > Subject: Re: out of range LBA using sg_raw > > Hi Kashyap, &

out of range LBA using sg_raw

Hi - Need help to understand if below is something we should consider to be fixed in megaraid_sas driver or call as unreal exposure. I have created slice VD of size 10GB (raid 1) using 2 drives. Each Physical Drive size is 256GB. Last LBA of the VD and actual Physical disk associated with

out of range LBA using sg_raw

Hi - Need help to understand if below is something we should consider to be fixed in megaraid_sas driver or call as unreal exposure. I have created slice VD of size 10GB (raid 1) using 2 drives. Each Physical Drive size is 256GB. Last LBA of the VD and actual Physical disk associated with

RE: Device or HBA level QD throttling creates randomness in sequetial workload

dead.org; linux-bl...@vger.kernel.org; paolo.vale...@linaro.org > Subject: Re: Device or HBA level QD throttling creates randomness in > sequetial workload > > On 01/30/2017 09:30 AM, Bart Van Assche wrote: > > On Mon, 2017-01-30 at 19:22 +0530, Kashyap Desai wrote: > >&

RE: Device or HBA level QD throttling creates randomness in sequetial workload

dead.org; linux-bl...@vger.kernel.org; paolo.vale...@linaro.org > Subject: Re: Device or HBA level QD throttling creates randomness in > sequetial workload > > On 01/30/2017 09:30 AM, Bart Van Assche wrote: > > On Mon, 2017-01-30 at 19:22 +0530, Kashyap Desai wrote: > >&

RE: Device or HBA level QD throttling creates randomness in sequetial workload

cmd = megasas_get_cmd_fusion(instance, scmd->request->tag); ` Kashyap > -Original Message- > From: Kashyap Desai [mailto:kashyap.de...@broadcom.com] > Sent: Tuesday, November 01, 2016 11:11 AM > To: 'Jens Axboe'; 'Omar Sandoval' > Cc: 'linux-s...@vger.kernel.org'; 'linux

RE: Device or HBA level QD throttling creates randomness in sequetial workload

cmd = megasas_get_cmd_fusion(instance, scmd->request->tag); ` Kashyap > -Original Message- > From: Kashyap Desai [mailto:kashyap.de...@broadcom.com] > Sent: Tuesday, November 01, 2016 11:11 AM > To: 'Jens Axboe'; 'Omar Sandoval' > Cc: 'linux-s...@vger.kernel.org'; 'linux

RE: [PATCH][V2] scsi: megaraid-sas: fix spelling mistake of "outstanding"

> -Original Message- > From: Bart Van Assche [mailto:bart.vanass...@sandisk.com] > Sent: Wednesday, November 30, 2016 12:50 AM > To: Colin King; Kashyap Desai; Sumit Saxena; Shivasharan S; James E . J . > Bottomley; Martin K . Petersen; megaraidlinux@broadcom.

RE: [PATCH][V2] scsi: megaraid-sas: fix spelling mistake of "outstanding"

> -Original Message- > From: Bart Van Assche [mailto:bart.vanass...@sandisk.com] > Sent: Wednesday, November 30, 2016 12:50 AM > To: Colin King; Kashyap Desai; Sumit Saxena; Shivasharan S; James E . J . > Bottomley; Martin K . Petersen; megaraidlinux@broadcom.

RE: [GIT PULL] SCSI fixes for 4.9-rc3

rnel.org > Subject: Re: [GIT PULL] SCSI fixes for 4.9-rc3 > > > > On 11.11.2016 04:30, Gabriel C wrote: > > > > On 05.11.2016 14:29, James Bottomley wrote: > > > > > > ... > > > >> Kashyap Desai (1): > >> scsi: megaraid_s

RE: [GIT PULL] SCSI fixes for 4.9-rc3

rnel.org > Subject: Re: [GIT PULL] SCSI fixes for 4.9-rc3 > > > > On 11.11.2016 04:30, Gabriel C wrote: > > > > On 05.11.2016 14:29, James Bottomley wrote: > > > > > > ... > > > >> Kashyap Desai (1): > >> scsi: megaraid_s

RE: Device or HBA level QD throttling creates randomness in sequetial workload

Read depth: 0 Write depth: 5 IO unplugs:79 Timer unplugs: 0 ` Kashyap > -Original Message- > From: Jens Axboe [mailto:ax...@kernel.dk] > Sent: Monday, October 31, 2016 10:54 PM > To: Kashyap Desai; Omar

RE: Device or HBA level QD throttling creates randomness in sequetial workload

Read depth: 0 Write depth: 5 IO unplugs:79 Timer unplugs: 0 ` Kashyap > -Original Message- > From: Jens Axboe [mailto:ax...@kernel.dk] > Sent: Monday, October 31, 2016 10:54 PM > To: Kashyap Desai; Omar

RE: Device or HBA level QD throttling creates randomness in sequetial workload

> -Original Message- > From: Omar Sandoval [mailto:osan...@osandov.com] > Sent: Monday, October 24, 2016 9:11 PM > To: Kashyap Desai > Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > bl...@vger.kernel.org; ax...@kernel.dk; Christoph Hel

RE: Device or HBA level QD throttling creates randomness in sequetial workload

> -Original Message- > From: Omar Sandoval [mailto:osan...@osandov.com] > Sent: Monday, October 24, 2016 9:11 PM > To: Kashyap Desai > Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > bl...@vger.kernel.org; ax...@kernel.dk; Christoph Hel

RE: Device or HBA level QD throttling creates randomness in sequetial workload

> > On Fri, Oct 21, 2016 at 05:43:35PM +0530, Kashyap Desai wrote: > > Hi - > > > > I found below conversation and it is on the same line as I wanted some > > input from mailing list. > > > > http://marc.info/?l=linux-kernel=147569860526197=2 > &

RE: Device or HBA level QD throttling creates randomness in sequetial workload

> > On Fri, Oct 21, 2016 at 05:43:35PM +0530, Kashyap Desai wrote: > > Hi - > > > > I found below conversation and it is on the same line as I wanted some > > input from mailing list. > > > > http://marc.info/?l=linux-kernel=147569860526197=2 > &

RE: Device or HBA level QD throttling creates randomness in sequetial workload

workaround/alternative in latest upstream kernel, if user wants to see limited penalty for Sequential Work load on HDD ? ` Kashyap > -Original Message- > From: Kashyap Desai [mailto:kashyap.de...@broadcom.com] > Sent: Thursday, October 20, 2016 3:39 PM > To: linux-s...@vge

RE: Device or HBA level QD throttling creates randomness in sequetial workload

workaround/alternative in latest upstream kernel, if user wants to see limited penalty for Sequential Work load on HDD ? ` Kashyap > -Original Message- > From: Kashyap Desai [mailto:kashyap.de...@broadcom.com] > Sent: Thursday, October 20, 2016 3:39 PM > To: linux-s...@vge

RE: Observing Softlockup's while running heavy IOs

> -Original Message- > From: Elliott, Robert (Persistent Memory) [mailto:elli...@hpe.com] > Sent: Saturday, August 20, 2016 2:58 AM > To: Sreekanth Reddy > Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; > irqbala...@lists.infradead.org; Kashyap Des

RE: Observing Softlockup's while running heavy IOs

> -Original Message- > From: Elliott, Robert (Persistent Memory) [mailto:elli...@hpe.com] > Sent: Saturday, August 20, 2016 2:58 AM > To: Sreekanth Reddy > Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; > irqbala...@lists.infradead.org; Kashyap Des

RE: [PATCH] megaraid_sas: Fix probing cards without io port

> > index 1 is used as mask 1, so that pci_request_selected_regions() is > > trying to request BAR0 instead of BAR1. > > > Fix all related reference. Review patch and looks good. Thanks Yinghai for submitting patch. Acked-by: Kashyap Desai <kashyap.de...@broadcom.com> > > Kashyap? Sumit? > > -- > Martin K. PetersenOracle Linux Engineering

RE: [PATCH] megaraid_sas: Fix probing cards without io port

> > index 1 is used as mask 1, so that pci_request_selected_regions() is > > trying to request BAR0 instead of BAR1. > > > Fix all related reference. Review patch and looks good. Thanks Yinghai for submitting patch. Acked-by: Kashyap Desai > > Kashyap? Sumit? > > -- > Martin K. PetersenOracle Linux Engineering

RE: [PATCH] megaraid:Make various functions static in megaraid_sas_fusion.c

> -Original Message- > From: Nicholas Krause [mailto:xerofo...@gmail.com] > Sent: Monday, July 06, 2015 10:06 PM > To: kashyap.de...@avagotech.com > Cc: sumit.sax...@avagotech.com; uday.ling...@avagotech.com; > jbottom...@odin.com; megaraidlinux@avagotech.com; linux- >

RE: [PATCH] megaraid:Make the function megasas_alloc_cmd_fusion static

> -int > +static int > megasas_alloc_cmds_fusion(struct megasas_instance *instance) { > int i, j, count; Good catch. Let's not include patch to avoid further confusion on series of acked patch which are not making significant functional difference. NACK as not making any functional

RE: [PATCH] megaraid:Make various functions static in megaraid_sas_fusion.c

> -Original Message- > From: Nicholas Krause [mailto:xerofo...@gmail.com] > Sent: Monday, July 06, 2015 10:06 PM > To: kashyap.de...@avagotech.com > Cc: sumit.sax...@avagotech.com; uday.ling...@avagotech.com; > jbottom...@odin.com; megaraidlinux@avagotech.com; linux- >

RE: [PATCH] megaraid:Make the function megasas_alloc_cmd_fusion static

> -int > +static int > megasas_alloc_cmds_fusion(struct megasas_instance *instance) { > int i, j, count; Good catch. Let's not include patch to avoid further confusion on series of acked patch which are not making significant functional difference. NACK as not making any functional

RE: [PATCH RESEND 09/25] mpt3sas: Don't send PHYDISK_HIDDEN Raid Action request on SAS2 HBA's

> -Original Message- > From: Hannes Reinecke [mailto:h...@suse.de] > Sent: Wednesday, November 11, 2015 6:27 PM > To: Sreekanth Reddy; j...@kernel.org > Cc: martin.peter...@oracle.com; linux-s...@vger.kernel.org; > jbottom...@parallels.com; sathya.prak...@avagotech.com; >

RE: [PATCH RESEND 09/25] mpt3sas: Don't send PHYDISK_HIDDEN Raid Action request on SAS2 HBA's

> -Original Message- > From: Hannes Reinecke [mailto:h...@suse.de] > Sent: Wednesday, November 11, 2015 6:27 PM > To: Sreekanth Reddy; j...@kernel.org > Cc: martin.peter...@oracle.com; linux-s...@vger.kernel.org; > jbottom...@parallels.com; sathya.prak...@avagotech.com; >

RE: [patch 1/2] megaraid_sas: remove a stray tab

> -Original Message- > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > Sent: Saturday, November 07, 2015 9:46 PM > To: Kashyap Desai; Sumit Saxena > Cc: Uday Lingala; James E.J. Bottomley; megaraidlinux@avagotech.com; > linux-s...@vger.kernel.org; linux-kern

RE: [patch 1/2] megaraid_sas: remove a stray tab

> -Original Message- > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > Sent: Saturday, November 07, 2015 9:46 PM > To: Kashyap Desai; Sumit Saxena > Cc: Uday Lingala; James E.J. Bottomley; megaraidlinux@avagotech.com; > linux-s...@vger.kernel.org; linux-kern

RE: [PATCH 1/3] megaraid_sas: Convert dev_printk to dev_

> > + dev_dbg(>pdev->dev, "Error copying out > > cmd_status\n"); > > error = -EFAULT; > > } > > > > Reviewed-by: Johannes Thumshirn We will consider all three patches for future submission. As of now we have two patch set pending to be committed. We are working for few

RE: [PATCH 1/3] megaraid_sas: Convert dev_printk to dev_

> > + dev_dbg(>pdev->dev, "Error copying out > > cmd_status\n"); > > error = -EFAULT; > > } > > > > Reviewed-by: Johannes Thumshirn We will consider all three patches for future submission. As of now we have two patch set pending to be committed. We

RE: megaraid_sas: "FW in FAULT state!!", how to get more debug output? [BKO63661]

> > I am about to commit the patch that was successfully tested by the > customer on > SLES 12, but I'm a bit confused. The upstream patch you referred to is: > > https://git.kernel.org/cgit/linux/kernel/git/jejb/scsi.git/commit/?h=for- > next=6431f5d7c6025f8b007af06ea090de308f7e6881 > [SCSI]

RE: megaraid_sas: FW in FAULT state!!, how to get more debug output? [BKO63661]

I am about to commit the patch that was successfully tested by the customer on SLES 12, but I'm a bit confused. The upstream patch you referred to is: https://git.kernel.org/cgit/linux/kernel/git/jejb/scsi.git/commit/?h=for- nextid=6431f5d7c6025f8b007af06ea090de308f7e6881 [SCSI]

RE: megaraid_sas: "FW in FAULT state!!", how to get more debug output? [BKO63661]

> -Original Message- > From: Jean Delvare [mailto:jdelv...@suse.de] > Sent: Tuesday, July 07, 2015 2:14 PM > To: Kashyap Desai > Cc: Bjorn Helgaas; Robin H. Johnson; Adam Radford; Neela Syam Kolli; linux- > s...@vger.kernel.org; arkadiusz.bub...@open-e.com; Matthew Garre

RE: megaraid_sas: FW in FAULT state!!, how to get more debug output? [BKO63661]

-Original Message- From: Jean Delvare [mailto:jdelv...@suse.de] Sent: Tuesday, July 07, 2015 2:14 PM To: Kashyap Desai Cc: Bjorn Helgaas; Robin H. Johnson; Adam Radford; Neela Syam Kolli; linux- s...@vger.kernel.org; arkadiusz.bub...@open-e.com; Matthew Garrett; Sumit Saxena; Uday

RE: megaraid_sas: "FW in FAULT state!!", how to get more debug output? [BKO63661]

age- > From: Jean Delvare [mailto:jdelv...@suse.de] > Sent: Monday, June 29, 2015 6:55 PM > To: Kashyap Desai > Cc: Bjorn Helgaas; Robin H. Johnson; Adam Radford; Neela Syam Kolli; > linux- > s...@vger.kernel.org; arkadiusz.bub...@open-e.com; Matthew Garrett; Sumit > Saxena; Uday Li

RE: megaraid_sas: FW in FAULT state!!, how to get more debug output? [BKO63661]

: Jean Delvare [mailto:jdelv...@suse.de] Sent: Monday, June 29, 2015 6:55 PM To: Kashyap Desai Cc: Bjorn Helgaas; Robin H. Johnson; Adam Radford; Neela Syam Kolli; linux- s...@vger.kernel.org; arkadiusz.bub...@open-e.com; Matthew Garrett; Sumit Saxena; Uday Lingala; PDL,MEGARAIDLINUX; linux

RE: megaraid_sas: "FW in FAULT state!!", how to get more debug output? [BKO63661]

elgaas [mailto:bhelg...@google.com] > Sent: Thursday, May 28, 2015 5:55 PM > To: Robin H. Johnson > Cc: Adam Radford; Neela Syam Kolli; linux-s...@vger.kernel.org; > arkadiusz.bub...@open-e.com; Matthew Garrett; Kashyap Desai; Sumit Saxena; > Uday Lingala; megaraidlinux@avagotech.com; linu

RE: megaraid_sas: FW in FAULT state!!, how to get more debug output? [BKO63661]

[mailto:bhelg...@google.com] Sent: Thursday, May 28, 2015 5:55 PM To: Robin H. Johnson Cc: Adam Radford; Neela Syam Kolli; linux-s...@vger.kernel.org; arkadiusz.bub...@open-e.com; Matthew Garrett; Kashyap Desai; Sumit Saxena; Uday Lingala; megaraidlinux@avagotech.com; linux-...@vger.kernel.org

RE: [PATCH] scsi: megaraid_sas: Prevent future %p disaster

Acked-by: Kashyap Desai > -Original Message- > From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk] > Sent: Friday, February 06, 2015 8:04 PM > To: Kashyap Desai; Sumit Saxena; Uday Lingala; James E.J. Bottomley > Cc: Rasmus Villemoes; megaraidlinux@avagotech.

RE: [PATCH] scsi: megaraid_sas: Prevent future %p disaster

Acked-by: Kashyap Desai kashyap.de...@avagotech.com -Original Message- From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk] Sent: Friday, February 06, 2015 8:04 PM To: Kashyap Desai; Sumit Saxena; Uday Lingala; James E.J. Bottomley Cc: Rasmus Villemoes; megaraidlinux

Re: [PATCH 13/14] scsi: add support for a blk-mq based I/O path.

On Tue, Aug 19, 2014 at 9:36 PM, Christoph Hellwig wrote: > On Tue, Aug 19, 2014 at 03:51:42AM +0530, Kashyap Desai wrote: >> I read this comment and find that very few drivers are using this >> cmd_list. I think if we remove this cmd_list, performance will scale as I >

Re: [PATCH 13/14] scsi: add support for a blk-mq based I/O path.

On Tue, Aug 19, 2014 at 3:51 AM, Kashyap Desai wrote: > > > -Original Message- > > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > > ow...@vger.kernel.org] On Behalf Of Christoph Hellwig > > Sent: Friday, July 18, 2014 3:43 PM >

Re: [PATCH 13/14] scsi: add support for a blk-mq based I/O path.

On Tue, Aug 19, 2014 at 3:51 AM, Kashyap Desai kashyap.de...@avagotech.com wrote: -Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- ow...@vger.kernel.org] On Behalf Of Christoph Hellwig Sent: Friday, July 18, 2014 3:43 PM To: James Bottomley; linux-s

Re: [PATCH 13/14] scsi: add support for a blk-mq based I/O path.

On Tue, Aug 19, 2014 at 9:36 PM, Christoph Hellwig h...@lst.de wrote: On Tue, Aug 19, 2014 at 03:51:42AM +0530, Kashyap Desai wrote: I read this comment and find that very few drivers are using this cmd_list. I think if we remove this cmd_list, performance will scale as I am seeing major

RE: [PATCH 13/14] scsi: add support for a blk-mq based I/O path.

> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Christoph Hellwig > Sent: Friday, July 18, 2014 3:43 PM > To: James Bottomley; linux-s...@vger.kernel.org > Cc: Jens Axboe; Bart Van Assche; Mike Christie; Martin K.

RE: [PATCH 13/14] scsi: add support for a blk-mq based I/O path.

-Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- ow...@vger.kernel.org] On Behalf Of Christoph Hellwig Sent: Friday, July 18, 2014 3:43 PM To: James Bottomley; linux-s...@vger.kernel.org Cc: Jens Axboe; Bart Van Assche; Mike Christie; Martin K. Petersen;

RE: [PATCH v2 RESEND 14/23] megaraid: Use pci_enable_msix_range() instead of pci_enable_msix()

> -Original Message- > From: Alexander Gordeev [mailto:agord...@redhat.com] > Sent: Monday, August 11, 2014 1:40 PM > To: Kashyap Desai; Neela Syam Kolli > Cc: linux-s...@vger.kernel.org; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; Christoph Hellwig > S

RE: [PATCH v2 RESEND 13/23] megaraid: Fail resume if MSI-X re-initialization failed

lement > > failed. > > Hi Neela, > > Could you please review megaraid patches in this series? > > Thanks! Please consider this patch Acked by Me. Acked-by: Kashyap Desai > > > Signed-off-by: Alexander Gordeev > > --- > > drivers/scsi/megaraid

RE: [PATCH v2 RESEND 13/23] megaraid: Fail resume if MSI-X re-initialization failed

megaraid patches in this series? Thanks! Please consider this patch Acked by Me. Acked-by: Kashyap Desai kashyap.de...@avagotech.com Signed-off-by: Alexander Gordeev agord...@redhat.com --- drivers/scsi/megaraid/megaraid_sas_base.c |8 +--- 1 files changed, 5 insertions(+), 3