Re: [PATCH 0/2] Two refactoring patches for the qla2xxx driver

qla_target.c | 14 ++--- >  2 files changed, 51 insertions(+), 52 deletions(-) > These look fine to me and the switch change makes it much cleaner. Reviewed-by: Laurence Oberman

Re: [PATCH V2 RESEND] Timeouts occur on surprise removal of QLogic adapter

On Mon, 2018-11-05 at 11:32 -0500, Laurence Oberman wrote: > On Mon, 2018-11-05 at 11:23 -0500, Bill Kuzeja wrote: > > When doing a surprise removal of an adapter, some in flight I/Os > > can > > get  > > stuck and take a while to complete (they actually timeou

Re: [PATCH V2 RESEND] Timeouts occur on surprise removal of QLogic adapter

On Mon, 2018-11-05 at 11:23 -0500, Bill Kuzeja wrote: > When doing a surprise removal of an adapter, some in flight I/Os can > get  > stuck and take a while to complete (they actually timeout and are  > retried). We are not handling an early error exit from  > qla2xxx_eh_abort properly. > >

Re: [PATCH 0/3] sd: Rely on the driver core for asynchronous probing

e SRP test bed here. Multiple disconnects/reconnects during heavy IO activity on 32 SRP 64 LUNS/ 32 mpaths with no issues seen with probes and reconnects. For the series. Tested-by: Laurence Oberman

Re: SCSI qla2xxx: tcm_qla2xxx target server code regession

On Wed, 2018-10-17 at 16:42 -0400, Laurence Oberman wrote: > On Mon, 2018-10-15 at 08:51 -0400, Laurence Oberman wrote: > > On Sat, 2018-10-13 at 10:42 -0400, Laurence Oberman wrote: > > > On Fri, 2018-10-12 at 17:51 -0700, Bart Van Assche wrote: > > > > On 10/12/18 1

Re: SCSI qla2xxx: tcm_qla2xxx target server code regession

On Mon, 2018-10-15 at 08:51 -0400, Laurence Oberman wrote: > On Sat, 2018-10-13 at 10:42 -0400, Laurence Oberman wrote: > > On Fri, 2018-10-12 at 17:51 -0700, Bart Van Assche wrote: > > > On 10/12/18 1:36 PM, Laurence Oberman wrote: > > >  > While I have for the l

[PATCH] scsi_error: Remove scsi_block_when_processing_errors: message

This message floods the log when enabling mask 0x7 for  /proc/sys/dev/scsi/logging_level  kernel: scsi_block_when_processing_errors: rtn: 1  Its not needed and makes tracing just scsi_eh* messages way too verbose so get rid of it Signed-off-by: Laurence Oberman ---  drivers/scsi

SCSI qla2xxx: tcm_qla2xxx target server code regession

On Sat, 2018-10-13 at 10:42 -0400, Laurence Oberman wrote: > On Fri, 2018-10-12 at 17:51 -0700, Bart Van Assche wrote: > > On 10/12/18 1:36 PM, Laurence Oberman wrote: > >  > While I have for the longest time used 4.5 as a base for my F/C > > jammer > >  > that

Re: SCSI qla2xxx: tcm_qla2xxx server code seems to have regressed quite badly with latest testing

On Fri, 2018-10-12 at 17:51 -0700, Bart Van Assche wrote: > On 10/12/18 1:36 PM, Laurence Oberman wrote: >  > While I have for the longest time used 4.5 as a base for my F/C > jammer >  > that I use every day here in our lab I recently added more jammer > code >  > so

SCSI qla2xxx: tcm_qla2xxx server code seems to have regressed quite badly with latest testing

Hello While I have for the longest time used 4.5 as a base for my F/C jammer that I use every day here in our lab I recently added more jammer code so I decided to test this all on latest upstream. Booting the target server on my 4.5 kernel with jammer code is flawless and serves LUNS with no

Re: [PATCH 0/4] libfc/fcoe: disc_mutex fixes

drivers/scsi/fcoe/fcoe_ctlr.c | 12 >  drivers/scsi/libfc/fc_disc.c  | 10 -- >  drivers/scsi/libfc/fc_rport.c |  3 ++- >  3 files changed, 10 insertions(+), 15 deletions(-) > Hannes Series looks fine to me, I will try get this tested as well. Reviewed-by Laurence Oberman

Re: Possible race in completion with SRP after abort with latest upstream kernel 4.17.0+

On Thu, 2018-06-07 at 15:21 +, Bart Van Assche wrote: > On Thu, 2018-06-07 at 09:23 -0400, Laurence Oberman wrote: > > Have you seen this before, let me know what else you want from the > > dump > > while I look further. > > Hello Laurence, > > I hav

Possible race in completion with SRP after abort with latest upstream kernel 4.17.0+

Hello Bart Have not seen this more than twice but during testing of latest upstream kernel with SRP I have had two of these completion races. 4.17.0+ [49945.984133] sd 2:0:0:29: alua: transition timeout set to 60 seconds [49945.984136] sd 2:0:0:29: alua: port group 00 state A non-preferred

Re: [PATCH] scsi: qla2xxx: remove the unused tcm_qla2xxx_cmd_wq

rget_unregister_template(_qla2xxx_ops); When I first saw this I thought, no way, it must be used, but when I had a closer look and checked its indeed not used or even made external. This looks OK to me. Reviewed-by: Laurence Oberman <lober...@redhat.com>

Re: [PATCH 0/3] scsi: scsi-mq: don't hold host_busy in IO path

On Fri, 2018-04-27 at 15:48 +, Bart Van Assche wrote: > On Fri, 2018-04-27 at 09:39 -0600, Jens Axboe wrote: > > blk_mq_tagset_busy_iter(>tag_set, scsi_host_check_in_flight, > > _flight); > > return in_flight.cnt + atomic_read(>host_busy); > > > > The atomic read is

Re: [PATCH 13/25] tcm_qla2xxx: Do not allow aborted cmd to advance.

On Sun, 2017-05-21 at 21:45 -0700, Nicholas A. Bellinger wrote: > On Fri, 2017-05-19 at 14:53 -0700, Himanshu Madhani wrote: > > From: Quinn Tran > > > > In case of hardware queue full, commands can loop between > > TCM stack and tcm_qla2xx shim layers for retry. While

Re: [PATCH v4 1/7] scsi: hpsa: Eliminate duplicate barriers on weakly-ordered archs

>commands_outstanding); >   } This looks like it would work for the x86_64 and arm because of how its defined architecture specific for the x86_64 and the arm64 I guess its up to Don and the driver folks and if its worth the change. I am generally not a fan of messing with these barrier things though. Reviewed-by: Laurence Oberman <lober...@redhat.com>

Re: [PATCH] scsi: scsi_dh_alua: Correct comment for alua_alloc_pg()

>   * @sdev: scsi device > - * @h: alua device_handler data >   * @group_id: port group id > + * @tpgs: target port group settings >   * >   * Allocate a new port_group structure for a given >   * device. Looks good to me, Thanks Reviewed-by Laurence Oberman <lober...@redhat.com>

Re: [PATCH] scsi: sd: Remember that READ CAPACITY(16) succeeded

/* Remember that READ CAPACITY(16) succeeded > */ > + sdp->try_rc_10_first = 0; >   } >   } >   Looks fine to me. Reviewed-by: Laurence Oberman <lober...@redhat.com>

Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

On Thu, 2018-03-08 at 21:42 +0800, Ming Lei wrote: > On Wed, Mar 07, 2018 at 09:11:37AM -0500, Laurence Oberman wrote: > > On Tue, 2018-03-06 at 14:24 -0500, Martin K. Petersen wrote: > > > Ming, > > > > > > > Given both Don and Laurence have verified that p

Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

1/8 from the V3 series. No issues running workload and no issues booting on the DL380G7. Don can you ack this so we can at least get this one in. Against: 4.16.0-rc4.v31of8+ on an x86_64 Tested-by: Laurence Oberman <lober...@redhat.com> Thanks Laurence

Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

On Fri, 2018-03-02 at 15:03 +, Don Brace wrote: > > -Original Message- > > From: Laurence Oberman [mailto:lober...@redhat.com] > > Sent: Friday, March 02, 2018 8:09 AM > > To: Ming Lei <ming@redhat.com> > > Cc: Don Brace <don.br...@microsemi

Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

On Fri, 2018-03-02 at 10:16 +0800, Ming Lei wrote: > On Thu, Mar 01, 2018 at 04:19:34PM -0500, Laurence Oberman wrote: > > On Thu, 2018-03-01 at 14:01 -0500, Laurence Oberman wrote: > > > On Thu, 2018-03-01 at 16:18 +, Don Brace wrote: > > > > > -Original

Re: [PATCH V3 0/8] blk-mq & scsi: fix reply queue selection and improve host wide tagset

sts passed with multiple concurrent fio runs. Original HPSA booting issue is also resolved and its important or we will have to revert original genirq commit commit 84676c1f21e8ff54befe985f4f14dc1edc10046b Tested-by: Laurence Oberman <lober...@redhat.com> Thanks Laurence

Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

On Thu, 2018-03-01 at 14:01 -0500, Laurence Oberman wrote: > On Thu, 2018-03-01 at 16:18 +, Don Brace wrote: > > > -Original Message- > > > From: Ming Lei [mailto:ming@redhat.com] > > > Sent: Tuesday, February 27, 2018 4:08 AM > > > To:

Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

martin.peter...@oracle.com>; James Bottomley > > <james.bottom...@hansenpartnership.com>; Christoph Hellwig <hch@lst > > .de>; > > Don Brace <don.br...@microsemi.com>; Kashyap Desai > > <kashyap.de...@broadcom.com>; Peter Rivera <peter.rivera@broadcom

Re: [PATCH V3 8/8] scsi: megaraid: improve scsi_mq performance via .host_tagset

On Wed, 2018-02-28 at 23:21 +0800, Ming Lei wrote: > On Wed, Feb 28, 2018 at 08:28:48PM +0530, Kashyap Desai wrote: > > Ming - > > > > Quick testing on my setup -  Performance slightly degraded (4-5% > > drop)for > > megaraid_sas driver with this patch. (From 1610K IOPS it goes to > > 1544K) > >

Re: Fwd: All scsi_debug devices in the scsi_debug driver share the same RAM space

On Tue, 2018-02-13 at 21:14 -0500, Martin K. Petersen wrote: > Lukas, > > > I like the idea to have an option to separate the memory area for > > different LUNs, while keeping the current behavior as default. > > As the name implies, scsi_debug is mostly a tool for debugging the > SCSI > stack.

Re: [PATCH V2 8/8] scsi: hpsa: use blk_mq to solve irq affinity issue

v...@broadcom.com> > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: Mike Snitzer <snit...@redhat.com> > Tested-by: Laurence Oberman <lober...@redhat.com> > Signed-off-by: Ming Lei <ming@redhat.com> > --- >  drivers/scsi/hpsa.c | 51 +

Re: All scsi_debug devices in the scsi_debug driver share the same RAM space

On Sat, 2018-02-03 at 14:43 -0500, Laurence Oberman wrote: > Hello Doug > > I had emailed you earlier about this issue forgetting to copy others. > > All test devices in the scsi_debug driver share the same ram space so > we cannot really have individual devices for testing stu

All scsi_debug devices in the scsi_debug driver share the same RAM space

Hello Doug I had emailed you earlier about this issue forgetting to copy others. All test devices in the scsi_debug driver share the same ram space so we cannot really have individual devices for testing stuff like md- raid. I bumped into this a few times already and I think it would be useful

[PATCH] scsi_debug: Add two new parameters to scsi_debug driver

of OPT_MEDIUM_ERR_ADDR, but use that set value. If medium_error_count is set we use that value otherwise default to OPT_MEDIUM_ERR_NUM. Signed-off-by: Laurence Oberman <lober...@redhat.com> Tested-by: Laurence Oberman <lober...@redhat.com> drivers/scsi/scsi_debug.c | 10 -- 1 fil

Request for input on new options for scsi_debug driver

is set we use that value otherwise default to OPT_MEDIUM_ERR_NUM. Should I send a patch for this, wanted to find out if this would be acceptable before I waste anybody's time having to review. Regards Laurence Oberman

Re: [dm-devel] [PATCH v5] blk-mq: introduce BLK_STS_DEV_RESOURCE

On Tue, 2018-01-30 at 09:52 -0800, Bart Van Assche wrote: > On 01/30/18 06:24, Mike Snitzer wrote: > > +  * > > +  * If driver returns BLK_STS_RESOURCE and > > SCHED_RESTART > > +  * bit is set, run queue after a delay to avoid IO > > stalls > > +  * that

Re: [PATCH V3] blk-mq: introduce BLK_STS_DEV_RESOURCE

On Sun, 2018-01-28 at 16:57 +, Bart Van Assche wrote: > On Sat, 2018-01-27 at 23:58 -0500, Mike Snitzer wrote: > > On Sat, Jan 27 2018 at 10:00pm -0500, > > Bart Van Assche wrote: > > > > > On Sat, 2018-01-27 at 21:03 -0500, Mike Snitzer wrote: > > > > You cannot even

Re: [PATCH] qla2xxx: Avoid triggering undefined behavior in qla2x00_mbx_completion()

mboxes = (1 << ha->mbx_count) - 1; > + WARN_ON_ONCE(ha->mbx_count > 32); > + mboxes = (1ULL << ha->mbx_count) - 1; >   if (!ha->mcp) >   ql_dbg(ql_dbg_async, vha, 0x504e, "MBX pointer > ERROR.\n"); >   else This looks fine to me and I tested the earlier patch suggestion supplied by Meelis. Reviewed-by: Laurence Oberman <lober...@redhat.com>

Re: [PATCH] bnx2fc: Fix check in SCSI completion handler when reqeust has already timed out.

 "this scsi cmd\n"); > + return; >   } >   >   /* Cancel the timeout_work, as we received IO completion */ Hello This was added after the race showed up for the first issue we fixed. Its been running stable in our lab and at the customer. Reviewed-by: Laurence Oberman <lober...@redhat.com> Tested-by: Laurence Oberman <lober...@redhat.com> Thanks Laurence

Re: HP ProLiant DL360p Gen8 hangs with Linux 4.13+.

On Mon, 2018-01-15 at 07:01 -0800, Hellwig, Christoph wrote: > Laurence, I'm a little confused.  Is this the same issue we just > fixed, > or is this an issue showing up with the fix? > > E.g. what kernel versions or trees are affected? Hello Christoph This showed up on a combined tree of

Re: HP ProLiant DL360p Gen8 hangs with Linux 4.13+.

On Mon, 2018-01-15 at 20:17 +0800, Ming Lei wrote: > On Sun, Jan 14, 2018 at 06:40:40PM -0500, Laurence Oberman wrote: > > On Thu, 2018-01-04 at 14:32 -0800, Vinson Lee wrote: > > > Hi. > > > > > > HP ProLiant DL360p Gen8 with Smart Array P420i boots to the log

Re: HP ProLiant DL360p Gen8 hangs with Linux 4.13+.

On Thu, 2018-01-04 at 14:32 -0800, Vinson Lee wrote: > Hi. > > HP ProLiant DL360p Gen8 with Smart Array P420i boots to the login > prompt and hangs with Linux 4.13 or later. I cannot log in on console > or SSH into the machine. Linux 4.12 and older boot fine. > > ... ... This issue bit me for

Re: HP ProLiant DL360p Gen8 hangs with Linux 4.13+.

On Fri, 2018-01-05 at 16:32 +, Bart Van Assche wrote: > On Thu, 2018-01-04 at 14:32 -0800, Vinson Lee wrote: > > HP ProLiant DL360p Gen8 with Smart Array P420i boots to the login > > prompt and hangs with Linux 4.13 or later. I cannot log in on > > console > > or SSH into the machine. Linux

Re: [PATCH] bnx2fc: Fix hung task messages when a cleanup response is not received during abort.

q); > - goto out; > + goto done; >   } else { >   /* >    * We come here even when there was a race condition > @@ -1249,7 +1274,6 @@ int bnx2fc_eh_abort(struct scsi_cmnd *sc_cmd) >  done: >   /* release the reference taken in eh_abort */ >   kref_put(_req->refcount, bnx2fc_cmd_release); > -out: >   spin_unlock_bh(>tgt_lock); >   return rc; >  } We experienced this at a major customer and provided this patch after working with Chad and backported to RHEL as a test kernel. Its been stable while running a test kernel and the changes look good ate least to me. Reviewed-by: Laurence Oberman <lober...@redhat.com> Tested-by: Laurence Oberman <lober...@redhat.com> Thanks Laurence

Re: [PATCH] SCSI: don't get target/host busy_count in scsi_mq_get_budget()

On Wed, 2017-11-08 at 10:57 -0700, Jens Axboe wrote: > On 11/08/2017 09:41 AM, Bart Van Assche wrote: > > On Tue, 2017-11-07 at 20:06 -0700, Jens Axboe wrote: > > > At this point, I have no idea what Bart's setup looks like. Bart, > > > it > > > would be REALLY helpful if you could tell us how you

[PATCH] Added notes to scsi-parameters.txt to show how to pass parameters on kernel line

--- Documentation/scsi/scsi-parameters.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/scsi/scsi-parameters.txt b/Documentation/scsi/scsi-parameters.txt index 8477655..5b87a11 100644 --- a/Documentation/scsi/scsi-parameters.txt +++

Re: Patch: add to Documentation/scsi for scsi_dev_flags and command line passing

Indeed it was Evolution and then linux-scsi rejected my fix. Trying again, for some reason it thought I had html Signed-off-by: Laurence Oberman <lober...@redhat.com> --- a/Documentation/scsi/scsi-parameters.txt +++ b/Documentation/scsi/scsi-parameters.txt @@ -116,3 +116,11 @@ paramete

Patch: add to Documentation/scsi for scsi_dev_flags and command line passing

Tired of forgetting about this so documented it for others so they also don't spend unnecessary time figuring this out. Signed-off-by: Laurence Oberman <lober...@redhat.com> diff --git a/Documentation/scsi/scsi-parameters.txt b/Documentation/scsi/scsi-parameters.txt index 8477655..c9e9ce8

Re: [PATCH] scsi: sd: Implement blacklist option for WRITE SAME w/ UNMAP

On Tue, 2017-10-17 at 10:26 -0400, Laurence Oberman wrote: > On Fri, 2017-09-29 at 10:01 -0400, Laurence Oberman wrote: > > On Fri, 2017-09-29 at 09:21 -0400, Martin K. Petersen wrote: > > > Laurence, > > > > > > > I am testing this but it

Re: [PATCH] scsi: sd: Implement blacklist option for WRITE SAME w/ UNMAP

On Fri, 2017-09-29 at 10:01 -0400, Laurence Oberman wrote: > On Fri, 2017-09-29 at 09:21 -0400, Martin K. Petersen wrote: > > Laurence, > > > > > I am testing this but its not being picked up so I want to know > > > if > > > I >

Re: [PATCH] scsi: sd: Implement blacklist option for WRITE SAME w/ UNMAP

; parameters despite lbpu being 0). > OK, Thanks, that is working now and I pick up the correct size now. Its going to be very useful for these corner case array inconsistencies. Tested-by: Laurence Oberman <lober...@redhat.com> Sep 29 09:56:11 localhost kernel: scsi 1:0:0:50: Di

Re: [PATCH] scsi: sd: Implement blacklist option for WRITE SAME w/ UNMAP

On Wed, 2017-09-27 at 21:35 -0400, Martin K. Petersen wrote: > SBC-4 states: > >   "A MAXIMUM UNMAP LBA COUNT field set to a non-zero value indicates > the >    maximum number of LBAs that may be unmapped by an UNMAP command" > >   "A MAXIMUM WRITE SAME LENGTH field set to a non-zero value >

Re: Sniffing FC traffic

On Fri, Aug 18, 2017 at 8:37 AM, Thomas Glanzmann wrote: > Hello, > I would like to create a setup that allows me to sniff FC traffic. Is it > possible with Linux or can someone recommend a setup that works. I want > to avoid buying a 120kUSD fabric analyzer. > > Cheers, >

Re: HBA recommended as FC target

On Fri, Aug 18, 2017 at 8:36 AM, Thomas Glanzmann wrote: > Hello, > I look for a FC HBA that works with the Linux target. Can somone > recommend a HBA type to me? > > Cheers, > Thomas Hello Any of the Qlogic qla24xx or qla25xx and higher that allow you to disable

Re: [v4.13-rc BUG] system lockup when running big buffered write(4M) to IB SRP via mpath

On 08/08/2017 10:28 PM, Laurence Oberman wrote: On Tue, 2017-08-08 at 20:11 -0400, Laurence Oberman wrote: On Tue, 2017-08-08 at 22:17 +0800, Ming Lei wrote: Hi Guys, Laurence and I see a system lockup issue when running concurrent big buffered write(4M bytes) to IB SRP on v4.13-rc3

Re: [v4.13-rc BUG] system lockup when running big buffered write(4M) to IB SRP via mpath

On Tue, 2017-08-08 at 20:11 -0400, Laurence Oberman wrote: > > On Tue, 2017-08-08 at 22:17 +0800, Ming Lei wrote: > > > > Hi Guys, > > > >  > > > > Laurence and I see a system lockup issue when running > > concurrent > > > > big buffere

Re: [v4.13-rc BUG] system lockup when running big buffered write(4M) to IB SRP via mpath

On Tue, 2017-08-08 at 22:17 +0800, Ming Lei wrote: > Hi Guys, > > Laurence and I see a system lockup issue when running concurrent > big buffered write(4M bytes) to IB SRP on v4.13-rc3. > > 1 how to reproduce > > 1) setup IB_SRR & multi path > > #./start_opensm.sh > #./start_srp.sh 

Re: device support in hpsa, was: Re: OOPS from cciss_ioctl in 4.12+git

On 07/07/2017 02:08 PM, Christoph Hellwig wrote: On Fri, Jul 07, 2017 at 11:42:38AM -0400, Laurence Oberman wrote: What happens when hpsa_allow_any=1 with the Smart Array 64xx It should probe. But only if it has a HP vendor ID as far as I can tell. We'd still need to add the compaq ids so

Re: device support in hpasa, was: Re: OOPS from cciss_ioctl in 4.12+git

On 07/07/2017 11:03 AM, Jens Axboe wrote: On 07/07/2017 09:00 AM, Christoph Hellwig wrote: On Thu, Jul 06, 2017 at 12:55:04PM +0300, Meelis Roos wrote: Also we're trying to move people away from the cciss driver, can you check if the hpsa SCSI driver works for you as well? I have older

Re: [PATCH RESEND] scsi: Add STARGET_CREATED_REMOVE state to scsi_target_state

+ STARGET_CREATED_REMOVE, STARGET_DEL, }; This patch (similar patch modified for RHEL) has been tested and validated here for multiple customers. Reviewed-by: Laurence Oberman <lober...@redhat.com> Tested-by: Laurence Oberman <lober...@redhat.com> Thanks Laurence

Re: [PATCH v2] lpfc: Fix panic on BFS configuration.

- Original Message - > From: jsmart2...@gmail.com > To: linux-scsi@vger.kernel.org, sta...@vger.kernel.org > Cc: jthumsh...@suse.de, linux-n...@lists.infradead.org, emi...@redhat.com, > "James Smart" , > "Dick Kennedy" , "James Smart" >

tcm_qla2xxx and target mode not stable at all on 4.10+

Hello I have had issues with the target mode working since moving to 4.10+. I am using a qla25xx card at 8Gbit Latest testing with 4.11 RC6 sees the same issue. Going back to 4.10.4 I can map targets but when I use my jammer I get into other issues. Its rock solid on 4.9 with the jammer. I

Re: [PATCH] sd: Consider max_xfer_blocks if opt_xfer_blocks is unusable

rw_max = BLK_DEF_MAX_SECTORS; > + rw_max = min_not_zero(rw_max, dev_max); > > /* Combine with controller limits */ > q->limits.max_sectors = min(rw_max, queue_max_hw_sectors(q)); > -- > 2.9.3 > > Looks good to me and addresses the issue we faced. FInal confirmation this change is OK to come from Martin or James. Reviewed-by: Laurence Oberman <lober...@redhat.com>

Re: 4.10+ qla2xxx driver wont load for qla2xxx (ISP2532-based 8Gb) with BAR 3 error, work fine on 4.9

- Original Message - > From: "Laurence Oberman" <lober...@redhat.com> > To: "Himanshu Madhani" <himanshu.madh...@cavium.com> > Cc: "Chad Dupuis" <chad.dup...@cavium.com>, "Linux SCSI List" > <linux-scsi@vger.ke

Re: 4.10+ qla2xxx driver wont load for qla2xxx (ISP2532-based 8Gb) with BAR 3 error, work fine on 4.9

- Original Message - > From: "Himanshu Madhani" <himanshu.madh...@cavium.com> > To: "Laurence Oberman" <lober...@redhat.com> > Cc: "Chad Dupuis" <chad.dup...@cavium.com>, "Linux SCSI List" > <linux-scsi@vger.k

Re: 4.10+ qla2xxx driver wont load for qla2xxx (ISP2532-based 8Gb) with BAR 3 error, work fine on 4.9

- Original Message - > From: "Laurence Oberman" <lober...@redhat.com> > To: "Himanshu Madhani" <himanshu.madh...@cavium.com> > Cc: "Chad Dupuis" <chad.dup...@cavium.com>, "Linux SCSI List" > <linux-scsi@vger.k

Re: 4.10+ qla2xxx driver wont load for qla2xxx (ISP2532-based 8Gb) with BAR 3 error, work fine on 4.9

- Original Message - > From: "Himanshu Madhani" <himanshu.madh...@cavium.com> > To: "Laurence Oberman" <lober...@redhat.com> > Cc: "Chad Dupuis" <chad.dup...@cavium.com>, "Linux SCSI List" > <linux-scsi@vger.k

Re: 4.10+ qla2xxx driver wont load for qla2xxx (ISP2532-based 8Gb) with BAR 3 error, work fine on 4.9

- Original Message - > From: "Laurence Oberman" <lober...@redhat.com> > To: "Himanshu Madhani" <himanshu.madh...@cavium.com> > Cc: "Chad Dupuis" <chad.dup...@cavium.com>, "Linux SCSI List" > <linux-scsi@vger.

Re: 4.10+ qla2xxx driver wont load for qla2xxx (ISP2532-based 8Gb) with BAR 3 error, work fine on 4.9

- Original Message - > From: "Laurence Oberman" <lober...@redhat.com> > To: "Himanshu Madhani" <himanshu.madh...@cavium.com> > Cc: "Chad Dupuis" <chad.dup...@cavium.com>, "Linux SCSI List" > <linux-scsi@vger.k

Re: 4.10+ qla2xxx driver wont load for qla2xxx (ISP2532-based 8Gb) with BAR 3 error, work fine on 4.9

- Original Message - > From: "Himanshu Madhani" <himanshu.madh...@cavium.com> > To: "Laurence Oberman" <lober...@redhat.com>, "Chad Dupuis" > <chad.dup...@cavium.com> > Cc: "Linux SCSI List" <linux-scsi@vger.k

Re: 4.10+ qla2xxx driver wont load for qla2xxx (ISP2532-based 8Gb) with BAR 3 error, work fine on 4.9

- Original Message - > From: "Laurence Oberman" <lober...@redhat.com> > To: "Chad Dupuis" <chad.dup...@cavium.com>, "Himanshu Madhani" > <himanshu.madh...@cavium.com> > Cc: "Linux SCSI List" <linux-scsi@vger.kerne

4.10+ qla2xxx driver wont load for qla2xxx (ISP2532-based 8Gb) with BAR 3 error, work fine on 4.9

Chad, Himanshu Before I bisect or go chase changes, wanted to reach out because the driver seems to be the same version. Perhaps this is a PCIE change in the kernel for 4.10 affecting the load. Its the same targetLIO server I have been using for a long time with 4.9 27:00.0 Fibre Channel:

Chasing possible Intel driver issue on Intel Soft FCOE CNA card

Hello Nicholas I am chasing the possibility of an OX_ID being prematurely re-used in the ixgbe and software fcoe stack when we have congestion. We have a situation where we have F/C traces showing this happening and in trying to track this down using LIO target as the array. I bumped into this

Re: [PATCH 11/20] lpfc: Fix eh_deadline setting for sli3 adapters.

.track_queue_depth = 0, > }; > > -struct scsi_host_template lpfc_template_s3 = { > +struct scsi_host_template lpfc_template_no_hr = { > .module = THIS_MODULE, > .name = LPFC_DRIVER_NAME, > .proc_name = LPFC_DRIVER_NAME, > @@ -6015,7 +6015,6 @@ struct scsi_host_template lpfc_vport_template = { > .eh_abort_handler = lpfc_abort_handler, > .eh_device_reset_handler = lpfc_device_reset_handler, > .eh_target_reset_handler = lpfc_target_reset_handler, > - .eh_bus_reset_handler = lpfc_bus_reset_handler, > .slave_alloc= lpfc_slave_alloc, > .slave_configure= lpfc_slave_configure, > .slave_destroy = lpfc_slave_destroy, > -- > 2.5.0 > > This patch was implemented and tested in the Red Hat lab and validated for a customer requiring eh_deadline. Reviewed-by: Laurence Oberman <lober...@redhat.com> Tested-by: Laurence Oberman <lober...@redhat.com>

Re: sg driver, sg_io and sg tablesize

- Original Message - > From: "Laurence Oberman" <lober...@redhat.com> > To: dgilb...@interlog.com, "Linux SCSI List" <linux-scsi@vger.kernel.org> > Sent: Wednesday, March 1, 2017 10:44:32 AM > Subject: sg driver, sg_io and sg tablesize

sg driver, sg_io and sg tablesize

Hi Doug I have a quick question here regarding the sg tablesize and retrieval of the supported size via a userspace ioctl. lpfc defaults to lpfc_sg_seg_cnt:Max Scatter Gather Segment Count (uint) = 64 For sg_io sent from qemu if we exceed 512K I/O we fail, qlogic allows 128 by default.

Re: [PATCH] scsi_error: count medium access timeout only once per EH run

0x2008 > #define FAST_IO_FAIL 0x2009 > +#define NEEDS_RESET 0x2010 > > /* > * Midlevel queue return values. > -- > 1.8.5.6 > > Hello Hannes This makes sense to me what you are doing here. I will also wait for Ewan to weigh in but I wonder if we should make a simple change. Maybe good to clarify the RESET here by simply changing the name. Change +#define NEEDS_RESET 0x2010 to +#define MAX_MEDIUM_ERROR_NEEDS_RESET Of course then also change + if (eh_disp == NEEDS_RESET) { to + if (eh_disp == MAX_MEDIUM_ERROR_NEEDS_RESET) { Reviewed-by: Laurence Oberman <lober...@redhat.com

Re: Patch: lpfc: Modify Emulex lpfc LPFC_DEFAULT_SG_SEG_CNT to 128 for default larger sg_io capability

- Original Message - > From: "Laurence Oberman" <lober...@redhat.com> > To: "Linux SCSI List" <linux-scsi@vger.kernel.org> > Sent: Wednesday, February 8, 2017 3:07:12 PM > Subject: Patch: lpfc: Modify Emulex lpfc LPFC_DEFAULT_SG_SEG_CNT t

Patch: lpfc: Modify Emulex lpfc LPFC_DEFAULT_SG_SEG_CNT to 128 for default larger sg_io capability

like to avoid having to set this in the module parameters to 128. Tested-by: Laurence Oberman <lober...@redhat.com> Signed-off-by: Laurence Oberman <lober...@redhat.com> >From 23996dcbdd9b505d18d59ecde961c87f76fc9c2e Mon Sep 17 00:00:00 2001 From: Laurence Oberman <lober...@r

Re: iscsi_trx going into D state

- Original Message - > From: "Robert LeBlanc" <rob...@leblancnet.us> > To: "Laurence Oberman" <lober...@redhat.com> > Cc: "Doug Ledford" <dledf...@redhat.com>, "Nicholas A. Bellinger" > <n...@linux-iscsi.org>,

Re: iscsi_trx going into D state

- Original Message - > From: "Robert LeBlanc" <rob...@leblancnet.us> > To: "Laurence Oberman" <lober...@redhat.com> > Cc: "Doug Ledford" <dledf...@redhat.com>, "Nicholas A. Bellinger" > <n...@linux-iscsi.org>,

Re: iscsi_trx going into D state

- Original Message - > From: "Robert LeBlanc" > To: "Doug Ledford" > Cc: "Nicholas A. Bellinger" , "Zhu Lingshan" > , "linux-rdma" > , linux-scsi@vger.kernel.org, "Sagi

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

- Original Message - > From: "Laurence Oberman" <lober...@redhat.com> > To: "Jan Kara" <j...@suse.cz> > Cc: "Johannes Weiner" <han...@cmpxchg.org>, "Hugh Dickins" > <hu...@google.com>, "Linus Torvalds

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

- Original Message - > From: "Jan Kara" > To: "Johannes Weiner" > Cc: "Hugh Dickins" , "Linus Torvalds" > , "Dave Chinner" > , "Chris Leech" , "Linux Kernel >

Re: scsi: qla2xxx: Fix apparent cut-n-paste error.

lock, flags); > qla2x00_free_rsp_que(ha, rsp); > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Hi

Re: [PATCH] qla2xxx: Get mutex lock before checking optrom_state

- Original Message - > From: "Milan P. Gandhi" <mgan...@redhat.com> > To: linux-scsi@vger.kernel.org > Cc: "Laurence Oberman" <lober...@redhat.com>, "chad dupuis" > <chad.dup...@cavium.com> > Sent: Saturday, December 24, 201

Re: [PATCH ] tcm_qla2xxx - Enhancements to the tcm_debug jammer code to jam only data movement commands

ember 22, 2016 4:54:30 PM > Subject: Re: [PATCH ] tcm_qla2xxx - Enhancements to the tcm_debug jammer code > to jam only data movement commands > > On Thu, 2016-12-22 at 16:46 -0500, Laurence Oberman wrote: > > Added the possibility of blocking only specific SCSI data movement commands > &

[PATCH ] tcm_qla2xxx - Enhancements to the tcm_debug jammer code to jam only data movement commands

TUR'S to pass. This has been helpful for debugging many driver/array interoperabilty issues. Folded documentation and code into single patch now Tested by: Laurence Oberman <lober...@redhat.com> Signed-off-by: Laurence Oberman <lober...@redhat.com> Documentation/scsi/tcm_qla2

Re: Testing latest linux-next 4.9 ib_srp and ib_srpt sees I/O capped at 1MB and no merging

- Original Message - > From: "Christoph Hellwig" <h...@infradead.org> > To: "Laurence Oberman" <lober...@redhat.com> > Cc: "Christoph Hellwig" <h...@infradead.org>, "Bart Van Assche" > <bart.vanass...@sandisk.com>

Re: Testing latest linux-next 4.9 ib_srp and ib_srpt sees I/O capped at 1MB and no merging

Hello Christoph, apologies, here is a clear summary of the issue. During testing of the latest linux-next with rc-10 block layer changes I noticed that I/O was being capped at 1MB size and no merging was seen. The issue was not apparent on 4.8.0-rc8 or earlier. dd if=/dev/sdw bs=4096k

Re: Testing latest linux-next 4.9 ib_srp and ib_srpt

- Original Message - > From: "Laurence Oberman" <lober...@redhat.com> > To: "Bart Van Assche" <bart.vanass...@sandisk.com> > Cc: linux-r...@vger.kernel.org > Sent: Wednesday, December 21, 2016 1:34:01 AM > Subject: Re: T

Re: SG does not ignore dxferp (direct io + mmap)

- Original Message - > From: "Hannes Reinecke" <h...@suse.de> > To: emi...@redhat.com, "Christoph Hellwig" <h...@infradead.org> > Cc: "Martin K. Petersen" <martin.peter...@oracle.com>, "Johannes Thumshirn" > <j

Re: [PATCH] bnx2fc: shift wrapping bug in bnx2fc_process_unsol_compl()

} > -- > 2.9.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Looks fine to me. Reviewed-by: Laurence Oberman <lober...@redhat.com> -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: SG does not ignore dxferp (direct io + mmap)

- Original Message - > From: "Ewan Milne" <emi...@redhat.com> > To: "Johannes Thumshirn" <jthumsh...@suse.de> > Cc: "Laurence Oberman" <lober...@redhat.com>, "Eyal Ben David" > <bde...@gmail.com>, dgilb...@int

Re: SG does not ignore dxferp (direct io + mmap)

- Original Message - > From: "Eyal Ben David" <bde...@gmail.com> > To: "Johannes Thumshirn" <jthumsh...@suse.de> > Cc: "Ewan D. Milne" <emi...@redhat.com>, "Laurence Oberman" > <lober...@redhat.com>, dgilb...@in

Re: SG does not ignore dxferp (direct io + mmap)

- Original Message - > From: "Eyal Ben David" <bde...@gmail.com> > To: "Ewan D. Milne" <emi...@redhat.com> > Cc: "Johannes Thumshirn" <jthumsh...@suse.de>, dgilb...@interlog.com, > "Laurence Oberman" <lober...@red

Re: SG does not ignore dxferp (direct io + mmap)

- Original Message - > From: "Ewan D. Milne" <emi...@redhat.com> > To: "Johannes Thumshirn" <jthumsh...@suse.de> > Cc: dgilb...@interlog.com, "Eyal Ben David" <bde...@gmail.com>, "Laurence > Oberman" <lober...@red

Re: SG does not ignore dxferp (direct io + mmap)

- Original Message - > From: "Eyal Ben David" <bde...@gmail.com> > To: "Johannes Thumshirn" <jthumsh...@suse.de> > Cc: "Ewan D. Milne" <emi...@redhat.com>, dgilb...@interlog.com, "Laurence > Oberman" <lober...@red

Re: SG does not ignore dxferp (direct io + mmap)

- Original Message - > From: "Eyal Ben David" <bde...@gmail.com> > To: emi...@redhat.com > Cc: "Laurence Oberman" <lober...@redhat.com>, dgilb...@interlog.com, > linux-scsi@vger.kernel.org > Sent: Monday, November 21, 2016 9:55:29 AM >

Re: SG does not ignore dxferp (direct io + mmap)

- Original Message - > From: "Ewan D. Milne" <emi...@redhat.com> > To: "Eyal Ben David" <bde...@gmail.com> > Cc: "Laurence Oberman" <lober...@redhat.com>, dgilb...@interlog.com, > linux-scsi@vger.kernel.org > Sent: Monday,

Re: SG does not ignore dxferp (direct io + mmap)

- Original Message - > From: "Eyal Ben David" > To: linux-scsi@vger.kernel.org > Sent: Sunday, November 20, 2016 11:02:49 AM > Subject: SG does not ignore dxferp (direct io + mmap) > > Hi all, > > We have some IO utility that perform the IOs using sg and direct io

Re: [PATCH] scsi: mpt3sas: fix some spelling mistakes in message and comments

- Original Message - > From: "Alexander Alemayhu" > To: "Colin King" > Cc: "Sathya Prakash" , "Chaitra P B" > , "Suganath Prabu > Subramani"

  1   2   3   >