elgaas [mailto:bhelg...@google.com]
> Sent: Thursday, May 28, 2015 5:55 PM
> To: Robin H. Johnson
> Cc: Adam Radford; Neela Syam Kolli; linux-scsi@vger.kernel.org;
> arkadiusz.bub...@open-e.com; Matthew Garrett; Kashyap Desai; Sumit
Saxena;
> Uday Lingala; megaraidlinux@avagotech.com;
linu
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
> -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
>
> 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&id=6431f5d7c6025f8b007af06ea090de308f7e6881
> [SCSI] me
JBOD "canHandleSyncCache"
> > > > > > bit in scratch pad register(offset
> > > > > > 0x00B4) will be set.
> > > > > >
> > > > > > This behavior can be controlled via module parameter and user
>
Hi,
I am doing some performance tuning in MR driver to understand how sdev
queue depth and hba queue depth play role in IO submission from above
layer.
I have 24 JBOD connected to MR 12GB controller and I can see performance
for 4K Sequential work load as below.
HBA QD for MR controller is 4065
Reply to see if email reached to linux-scsi@vger.kernel.org.
On Thu, Oct 20, 2016 at 12:07 PM, Kashyap Desai
wrote:
> Hi,
>
> I am doing some performance tuning in MR driver to understand how sdev queue
> depth and hba queue depth play role in IO submission from above layer.
>
&g
[ Apologize, if this thread is reached to you multiple time ]
Hi,
I am doing some performance tuning in MR driver to understand how sdev
queue depth and hba queue depth play role in IO submission from above
layer. I have 24 JBOD connected to MR 12GB controller and I can see
performance for 4K Seq
> -Original Message-
> From: i...@itu.dk [mailto:i...@itu.dk]
> Sent: Monday, October 17, 2016 1:00 PM
> To: Jiri Kosina
> Cc: Kashyap Desai; Sumit Saxena; Uday Lingala; James E.J. Bottomley;
Martin K.
> Petersen; megaraidlinux@avagotech.com; linux-scsi@vger.kerne
[ Apologize, if you find more than one instance of my email.
Web based email client has some issue, so now trying git send mail.]
Hi,
I am doing some performance tuning in MR driver to understand how sdev queue
depth and hba queue depth play role in IO submission from above layer.
I have 24 JBOD
[ Apologize, if you find more than one instance of my email.
Web based email client has some issue, so now trying git send mail.]
Hi,
I am doing some performance tuning in MR driver to understand how sdev queue
depth and hba queue depth play role in IO submission from above layer.
I have 24 JBOD
river return SUCCESS for that command.
> >ENDIF
> > ENDIF
> > ENDIF
> >
> > CC: sta...@vger.kernel.org
>
> Can you please split this into two, so we can backport the bug fix without
> any of
> the feature addition junk?
James - I am sen
here any 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-
Changes in v3
two logical patches created for "Send SYNCHRONIZE_CACHE command to firmware"
- Send SYNCHRONIZE_CACHE for JBOD to firmware
- Send SYNCHRONIZE_CACHE for VD to firmware
Changes in v2:
1. Removed unconditional msleep and moved calls to atomic_read into
megasas_w
This patch fixes the issue of wrong PhysArm was sent to firmware for R1
VD downgrade.
Signed-off-by: Kiran Kumar Kasturi
Signed-off-by: Sumit Saxena
Reviewed-by: Hannes Reinecke
Reviewed-by: Tomas Henzl
---
drivers/scsi/megaraid/megaraid_sas_fp.c | 6 --
1 file changed, 4 insertions(+), 2
This patch addresses the issue of driver firing DCMDs in PCI
shutdown/detach path irrespective of firmware state.
Driver will check for whether firmware is operational state or not
before firing DCMDs. If firmware is in unrecoverbale
state or does not become operational within specfied time, driver
For SRIOV enabled firmware, if there is a OCR(online controller reset)
possibility driver set the convert flag to 1, which is not happening if
there are outstanding commands even after 180 seconds.
As driver does not set convert flag to 1 and still making the OCR to run,
VF(Virtual function) driver
.
CC: sta...@vger.kernel.org
Signed-off-by: Kashyap Desai
Signed-off-by: Sumit Saxena
---
drivers/scsi/megaraid/megaraid_sas_base.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
ind
FW returns SUCCESS
ELSE
Driver does not send SYNCH_CACHE command to the
FW.
Driver return SUCCESS for that command.
ENDIF
ENDIF
ENDIF
Signed-off-by: Kashyap Desai
Signed-off-by: Sumit Saxena
---
drivers/scsi/
@@ -7612,12 +7612,12 @@ S: Maintained
F: drivers/net/wireless/mediatek/mt7601u/
MEGARAID SCSI/SAS DRIVERS
-M: Kashyap Desai
-M: Sumit Saxena
-M: Uday Lingala
-L: megaraidlinux@avagotech.com
+M: Kashyap Desai
+M: Sumit Saxena
+M: Shivasharan S
+L
Signed-off-by: Sumit Saxena
---
drivers/scsi/megaraid/megaraid_sas.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
index 43fd14f..74c7b44 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/
CC: sta...@vger.kernel.org
Signed-off-by: Sumit Saxena
Reviewed-by: Hannes Reinecke
Reviewed-by: Tomas Henzl
---
drivers/scsi/megaraid/megaraid_sas_fusion.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/me
> > >
> > > Can you please split this into two, so we can backport the bug fix
> > > without any of the feature addition junk?
> >
> > James - I am sending new patch making two logical fix as you
> > requested. JBOD fix will be marked for CC:stable and for Virtual disk
> > I will post only for hea
>
> 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&m=147569860526197&w=
> -Original Message-
> From: Omar Sandoval [mailto:osan...@osandov.com]
> Sent: Monday, October 24, 2016 9:11 PM
> To: Kashyap Desai
> Cc: linux-scsi@vger.kernel.org; linux-ker...@vger.kernel.org; linux-
> bl...@vger.kernel.org; ax...@kernel.dk; Christoph Hel
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 San
> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Wednesday, November 09, 2016 4:45 AM
> To: Jens Axboe
> Cc: linux-scsi; Kashyap Desai; Martin K. Petersen
> Subject: Re: [REGRESSION] 4.9-rc4+ doesn't boot on my test box
&
> -Original Message-
> From: Jens Axboe [mailto:ax...@kernel.dk]
> Sent: Wednesday, November 09, 2016 6:50 AM
> To: Kashyap Desai; Martin K. Petersen
> Cc: linux-scsi
> Subject: Re: [REGRESSION] 4.9-rc4+ doesn't boot on my test box
>
> On 11/08/2016
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Paul Menzel
> Sent: Thursday, November 10, 2016 7:40 PM
> To: Martin K. Petersen
> Cc: linux-scsi@vger.kernel.org; James E.J. Bottomley
> Subject: Re: Delivery Status Noti
> -Original Message-
> From: i...@itu.dk [mailto:i...@itu.dk]
> Sent: Monday, October 17, 2016 1:00 PM
> To: Jiri Kosina
> Cc: Kashyap Desai; Sumit Saxena; Uday Lingala; James E.J. Bottomley;
Martin K.
> Petersen; megaraidlinux@avagotech.com; linux-scsi@vger.kerne
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Jens Axboe
> Sent: Thursday, November 10, 2016 10:18 PM
> To: Hannes Reinecke; Christoph Hellwig
> Cc: SCSI Mailing List; linux-bl...@vger.kernel.org
> Subject: Re: Reduce
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_sas
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Christoph Hellwig
> Sent: Sunday, November 13, 2016 5:29 PM
> To: Hannes Reinecke
> Cc: Christoph Hellwig; Hannes Reinecke; Christoph Hellwig; Martin K.
Petersen;
> James
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Hannes Reinecke
> Sent: Friday, November 11, 2016 3:15 PM
> To: Martin K. Petersen
> Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; linux-
> s...@vger.kernel.org; H
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Tomas Henzl
> Sent: Friday, November 18, 2016 9:23 PM
> To: Hannes Reinecke; Martin K. Petersen
> Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; linux-
> s...@vger.
> -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.
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Monday, November 21, 2016 9:27 PM
> To: Kashyap Desai; Hannes Reinecke; Martin K. Petersen
> Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; linux-
> s...@vger.kernel.org; Hannes Rein
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Martin K. Petersen
> Sent: Thursday, December 08, 2016 4:43 AM
> To: adam radford
> Cc: linux-scsi; Kashyap Desai
> Subject: Re: [PATCH] Upda
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Hannes Reinecke
> Sent: Wednesday, December 14, 2016 9:07 PM
> To: Sumit Saxena; linux-scsi
> Subject: Re: SCSI: usage of DID_REQUEUE vs DID_RESET for returning SCSI
> com
gned-off-by: Kashyap desai
---
diff --git a/block/blk-core.c b/block/blk-core.c
index 14d7c07..2e93d14 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -693,6 +693,7 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask,
int node_id)
{
struct request_queue *q;
> -Original Message-
> From: kbuild test robot [mailto:l...@intel.com]
> Sent: Thursday, January 12, 2017 1:18 AM
> To: Kashyap Desai
> Cc: kbuild-...@01.org; linux-scsi@vger.kernel.org;
linux-bl...@vger.kernel.org;
> ax...@kernel.dk; martin.peter...@oracle.com; j...@
> Hi, Kashyap,
>
> I'm CC-ing Kent, seeing how this is his code.
Hi Jeff and Kent, See my reply inline.
>
> Kashyap Desai writes:
>
> > Objective of this patch is -
> >
> > To move code used in bcache module in block layer which is used to
> > fin
n SCSI.MQ mode.
+*/
+ if (!is_nonrot)
+ udelay(100);
+ }
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: &
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:
> >> - if
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Tuesday, January 31, 2017 4:47 PM
> To: Christoph Hellwig
> Cc: Martin K. Petersen; James Bottomley; linux-scsi@vger.kernel.org;
Sathya
> Prakash; Kashyap Desai; mpt-fusionlinux@broadcom
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Wednesday, February 01, 2017 12:21 PM
> To: Kashyap Desai; Christoph Hellwig
> Cc: Martin K. Petersen; James Bottomley; linux-scsi@vger.kernel.org;
> Sathya
> Prakash Veerichetty; PDL-MPT-F
> >
> > /**
> > + * megasas_complete_r1_command -
> > + * completes R1 FP write commands which has valid peer smid
> > + * @instance: Adapter soft state
> > + * @cmd_fusion:MPT command frame
> > + *
> > + */
> > +static inline void
> > +megasas_complete_r1_
m;
> h...@suse.com
> Subject: Re: [PATCH 33/39] megaraid_sas: call flush_scheduled_work
during
> controller shutdown/detach
>
> On 6.2.2017 11:00, Shivasharan S wrote:
> > Signed-off-by: Kashyap Desai
> > Signed-off-by: Shivasharan S
>
> > ---
> > drivers/
> -Original Message-
> From: Kashyap Desai [mailto:kashyap.de...@broadcom.com]
> Sent: Monday, February 06, 2017 10:48 PM
> To: 'Tomas Henzl'; Shivasharan Srikanteshwara;
'linux-scsi@vger.kernel.org'
> Cc: 'martin.peter...@oracle.com';
> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Tuesday, February 07, 2017 5:22 AM
> To: Shivasharan S
> Cc: linux-scsi@vger.kernel.org; martin.peter...@oracle.com;
> the...@redhat.com; j...@linux.vnet.ibm.com;
> kashyap.de...@broadcom.com; sumit.
> > +static inline void
> > +megasas_complete_r1_command(struct megasas_instance *instance,
> > + struct megasas_cmd_fusion *cmd) {
> > + u8 *sense, status, ex_status;
> > + u32 data_length;
> > + u16 peer_smid;
> > + struct fusion_context *fusion;
> > + struct megas
> Signed-off-by: Shivasharan S
> Signed-off-by: Kashyap Desai
In this patch series, we are done with review but this particular patch
missed Review-by tag.
Kashyap
> +static inline void set_num_sge(struct RAID_CONTEXT_G35 rctx_g35,
> +u16 sge_count)
> +{
> + rctx_g35.u.bytes[0] = (u8)(sge_count & NUM_SGE_MASK_LOWER);
> + rctx_g35.u.bytes[1] |= (u8)((sge_count >> NUM_SGE_SHIFT_UPPER)
> +
00
Root cause is SCSI buffer length and DMA buffer length miss match for
WRITE SAME command.
Fix - return valid data buffer length in scsi_bufflen() API using
RQF_SPECIAL_PAYLOAD
Signed-off-by: Kashyap Desai
---
diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
index 9fc1aec
>
>
> Hannes,
>
> Result I have posted last time is with merge operation enabled in block
> layer. If I disable merge operation then I don't see much improvement
> with
> multiple hw request queues. Here is the result,
>
> fio results when nr_hw_queues=1,
> 4k read when numjobs=24: io=248387MB, bw=
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Wednesday, February 15, 2017 3:35 PM
> To: Kashyap Desai; Sreekanth Reddy
> Cc: Christoph Hellwig; Martin K. Petersen; James Bottomley; linux-
> s...@vger.kernel.org; Sathya Prakash Veerichetty; P
> > - Later we can explore if nr_hw_queue more than one really add benefit.
> > From current limited testing, I don't see major performance boost if
> > we have nr_hw_queue more than one.
> >
> Well, the _actual_ code to support mq is rather trivial, and really serves
> as a
> good testbed for scsi
- ParErr-
Stepping- SERR+ FastB2B- DisINTx+
Signed-off-by: Kashyap Desai
---
drivers/scsi/megaraid/megaraid_sas_base.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 7ac9a9e..82a8ec8
Peter:
We will check with Falcon MR controller and will get back to you. Can you
quickly check using stable kernel instead of upstream. (Just to check if
it is regression>) ?
~ Kashyap
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.o
> -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-scsi@vger.kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Christoph Hellwig
> S
> -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-scsi@vger.kernel.org
> Cc: Jens Axboe; Bart Van Assche; Mike Christie; Martin K. Peter
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
> >
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
>
> -Original Message-
> From: Bart Van Assche [mailto:bvanass...@acm.org]
> Sent: Wednesday, August 20, 2014 4:18 PM
> To: kashyap.de...@avagotech.com; linux-scsi@vger.kernel.org
> Cc: aacr...@adaptec.com; elli...@hp.com; jbottom...@parallels.com;
> h...@infradead.org
> Subject: Re: [PATCH]
> -Original Message-
> From: Christoph Hellwig [mailto:h...@infradead.org]
> Sent: Wednesday, August 20, 2014 6:11 PM
> To: Kashyap Desai
> Cc: Bart Van Assche; linux-scsi@vger.kernel.org; aacr...@adaptec.com;
> elli...@hp.com; jbottom...@parallels.com; h...@infradead
lock
> overhead.
> >
> > Signed-off-by: Sumit Saxena
> > Signed-off-by: Kashyap Desai
> > ---
> > drivers/scsi/megaraid/megaraid_sas_fusion.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/scsi/megaraid/megaraid
mplicity
customer might like this type of module parameter.
Kashyap
>
> Thanks,
> Tomas
>
>>
>> Signed-off-by: Sumit Saxena
>> Signed-off-by: Kashyap Desai
>> ---
>> drivers/scsi/megaraid/megaraid_sas_base.c | 60
>> +++
ny given time, driver will always have old or new Raid map.
> > So with this changes, driver can also work in host lock less mode. Please
> > see next patch which enable host lock less mode for megaraid_sas driver.
> >
> > Signed-off-by: Sumit Saxena
> > Signed-off-by: Kas
t;> will do MFI/MPT list corruption.
>>
>> Renamed the cmd_pool_lock which is used in instance as well as fusion with
>> below name.
>> mfi_pool_lock and mpt_pool_lock to add more code readability.
>>
>> Signed-off-by: Sumit Saxena
>> Signed-off-by: Kashyap Desai
&
ttom...@parallels.com; Kashyap Desai; aradf...@gmail.com; Michal
> Schmidt; am...@mellanox.com; Jens Axboe
> (ax...@kernel.dk); scame...@beardog.cce.hp.com
> Subject: Re: [PATCH 04/11] megaraid_sas : Firmware crash dump feature
> support
>
> On Wed, Sep 10, 2014 at 05:28:40PM +020
On Thu, Sep 11, 2014 at 4:50 PM, Tomas Henzl wrote:
> On 09/11/2014 11:02 AM, Kashyap Desai wrote:
>>> -Original Message-
>>> From: Vivek Goyal [mailto:vgo...@redhat.com]
>>> Sent: Wednesday, September 10, 2014 9:17 PM
>>> To: Tomas Henzl
>>
On Thu, Sep 11, 2014 at 5:53 PM, Tomas Henzl wrote:
> On 09/11/2014 04:48 AM, Kashyap Desai wrote:
>> On Wed, Sep 10, 2014 at 8:36 PM, Tomas Henzl wrote:
>>> On 09/06/2014 03:25 PM, sumit.sax...@avagotech.com wrote:
>>>> Problem statement:
>>>> MFI lin
On Fri, Sep 12, 2014 at 12:28 AM, Tomas Henzl wrote:
> On 09/11/2014 06:39 PM, Kashyap Desai wrote:
>> On Thu, Sep 11, 2014 at 4:50 PM, Tomas Henzl wrote:
>>> On 09/11/2014 11:02 AM, Kashyap Desai wrote:
>>>>> -Original Message-
>>>>
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Friday, September 12, 2014 12:50 AM
> To: Kashyap Desai
> Cc: Sumit Saxena; linux-scsi@vger.kernel.org; Martin K. Petersen;
> Christoph
> Hellwig; jbottom...@parallels.com; aradford
> S
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.
Hi Hannes,
I was going through one of the slide posted at below link.
http://events.linuxfoundation.org/sites/events/files/slides/SCSI-EH.pdf
Slide #59 has below data. I was trying to correlate with latest upstream
code, but do not understand few things. Does Linux handle blocking I/O to
the dev
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Thursday, March 26, 2015 9:28 PM
> To: Kashyap Desai; linux-scsi@vger.kernel.org
> Subject: Re: Scsi Error handling query
>
> On 03/26/2015 02:38 PM, Kashyap Desai wrote:
> > Hi Hannes,
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Friday, March 27, 2015 9:32 PM
> To: Kashyap Desai; linux-scsi@vger.kernel.org
> Subject: Re: Scsi Error handling query
>
> On 03/26/2015 07:43 PM, Kashyap Desai wrote:
> >> -O
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Monday, March 30, 2015 8:43 PM
> To: Kashyap Desai; linux-scsi@vger.kernel.org
> Subject: Re: Scsi Error handling query
>
> On 03/30/2015 01:45 PM, Kashyap Desai wrote:
> >> -O
> -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 differ
> -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-
> s...@vger.kernel.
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Friday, January 29, 2016 11:05 PM
> To: 'linux-scsi@vger.kernel.org'
> Cc: sumit.sax...@avagotech.com; Desai, Kashyap; Uday Lingala
> Subject: megaraid_sas: add an i/o barrier
>
> A barrier should be added to ensure
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Monday, February 01, 2016 6:23 PM
> To: Kashyap Desai; linux-scsi@vger.kernel.org
> Cc: Sumit Saxena; Uday Lingala
> Subject: Re: megaraid_sas: add an i/o barrier
>
> On 1.2.2016 05
el.org
> Subject: Re: [PATCH v2] megaraid_sas: add an i/o barrier
>
> >>>>> "Tomas" == Tomas Henzl writes:
>
> Tomas> A barrier should be added to ensure proper ordering of memory
> Tomas> mapped writes.
>
> Tomas> V2: - added the barrie
> > + dev_dbg(&instance->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
>
> > -Original Message-
> > From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> > Sent: Wednesday, October 28, 2015 8:03 AM
> > To: sumit.sax...@avagotech.com
> > Cc: linux-scsi@vger.kernel.org; the...@redhat.com;
> > martin.peter...@oracle.com; h...@infradead.org;
> > jbottom..
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Saturday, November 07, 2015 9:47 PM
> To: Kashyap Desai; Sumit Saxena
> Cc: Uday Lingala; James E.J. Bottomley; megaraidlinux@avagotech.com;
> linux-scsi@vger.kernel
> -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-scsi@vger.kernel.org; linux-ker.
> -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-scsi@vger.kernel.org;
> jbottom...@parallels.com; sathya.prak...@avagotech.com;
> kashyap.de...@avag
> -Original Message-
> From: Jens Axboe [mailto:ax...@kernel.dk]
> Sent: Tuesday, May 06, 2014 7:47 PM
> To: Desai, Kashyap
> Cc: linux-scsi@vger.kernel.org
> Subject: Re: How to get more sequential IO merged at elevator
>
> On 05/06/2014 04:06 AM, Desai, Kashyap wrote:
> > I got some clue
> -Original Message-
> From: Jens Axboe [mailto:ax...@kernel.dk]
> Sent: Tuesday, May 06, 2014 7:47 PM
> To: Desai, Kashyap
> Cc: linux-scsi@vger.kernel.org
> Subject: Re: How to get more sequential IO merged at elevator
>
> On 05/06/2014 04:06 AM, Desai, Kashyap wrote:
> > I got some clue
[mpt3sas]
Cc:
Signed-off-by: Kashyap Desai
Signed-off-by: Sreekanth Reddy
---
block/blk-mq.c | 4 +++-
block/blk-mq.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 6a75662..88d1e92 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@
> >
> > Other block drivers (e.g. ib_srp, skd) do not need this to work
> > reliably.
> > It has been explained to you that the bug that you reported can be
> > fixed by modifying the mpt3sas driver. So why to fix this by modifying
> > the block layer? Additionally, what prevents that a race condit
>
> On 12/18/18 10:08 AM, Kashyap Desai wrote:
> >>>
> >>> Other block drivers (e.g. ib_srp, skd) do not need this to work
> >>> reliably.
> >>> It has been explained to you that the bug that you reported can be
> >>> fixed by modif
> On 12/18/18 10:48 AM, Kashyap Desai wrote:
> >>
> >> On 12/18/18 10:08 AM, Kashyap Desai wrote:
> >>>>>
> >>>>> Other block drivers (e.g. ib_srp, skd) do not need this to work
> >>>>> reliably.
> >>>>>
> >
> > At the time of device removal, it requires reverse traversing. Find
> > out if each requests associated with sdev is part of hctx->tags->rqs()
> > and clear that entry.
> > Not sure about atomic traverse if more than one device removal is
> > happening in parallel. May be more error pron
>
> I actually took a look at scsi_host_find_tag() - what I think needs fixing
> here is
> that it should not return a tag that isn't allocated.
> You're just looking up random stuff, that is a recipe for disaster.
> But even with that, there's no guarantee that the tag isn't going away.
Got your
> Fusion adapters can steer completions to individual queues, so we can
enable
> blk-mq for those adapters.
> And in doing so we can rely on the interrupt affinity from the block
layer and
> drop the hand-crafted 'reply_map' construct.
Hannes, I understand the intend of this patch as we discussed
On Tue, Feb 26, 2019 at 8:23 PM Hannes Reinecke wrote:
>
> On 2/26/19 3:33 PM, Christoph Hellwig wrote:
> > On Tue, Feb 26, 2019 at 02:49:30PM +0100, Hannes Reinecke wrote:
> >> Attached is a patch to demonstrate my approach.
> >> I am aware that it'll only be useful for latest upstream where the
Hi Martin/Chris,
I was going through below discussion as well as going through linux
scsi code to know if linux scsi stack support NDOB. It looks like
current scsi stack does not have support of NDOB. From below thread,
it looks like NDOB is not good way to support considering lack of
device leve
1 - 100 of 180 matches
Mail list logo