Re: Testing latest linux-next 4.9 ib_srp and ib_srpt

[Christoph Hellwig]

I just got CC'ed to a massive chain of full quotes.  If you want an
answer from me please write a readable mail, thanks.
--
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: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

[Dave Chinner]

On Wed, Dec 21, 2016 at 09:46:37PM -0800, Linus Torvalds wrote:
> On Wed, Dec 21, 2016 at 9:13 PM, Dave Chinner  wrote:
> >
> > There may be deeper issues. I just started running scalability tests
> > (e.g. 16-way fsmark create tests) and about a minute in I got a
> > directory corruption reported - something I hadn't seen in the dev
> > cycle at all.
> 
> By "in the dev cycle", do you mean your XFS changes, or have you been
> tracking the merge cycle at least for some testing?

I mean the three months leading up to the 4.10 merge, when all the
XFS changes were being tested against 4.9-rc kernels.

The iscsi problem showed up when I updated the base kernel from
4.9 to 4.10-current last week to test the pullreq I was going to
send you. I've been bust with other stuff until now, so I didn't
upgrade my working trees again until today in the hope the iscsi
problem had already been found and fixed.

> > I unmounted the fs, mkfs'd it again, ran the
> > workload again and about a minute in this fired:
> >
> > [628867.607417] [ cut here ]
> > [628867.608603] WARNING: CPU: 2 PID: 16925 at mm/workingset.c:461 
> > shadow_lru_isolate+0x171/0x220
> 
> Well, part of the changes during the merge window were the shadow
> entry tracking changes that came in through Andrew's tree. Adding
> Johannes Weiner to the participants.
> 
> > Now, this workload does not touch the page cache at all - it's
> > entirely an XFS metadata workload, so it should not really be
> > affecting the working set code.
> 
> Well, I suspect that anything that creates memory pressure will end up
> triggering the working set code, so ..
> 
> That said, obviously memory corruption could be involved and result in
> random issues too, but I wouldn't really expect that in this code.
> 
> It would probably be really useful to get more data points - is the
> problem reliably in this area, or is it going to be random and all
> over the place.

The iscsi problem is 100% reproducable. create a pair of iscsi luns,
mkfs, run xfstests on them. iscsi fails a second after xfstests mounts
the filesystems.

The test machine I'm having all these other problems on? stable and
steady as a rock using PMEM devices. Moment I go to use /dev/vdc
(i.e. run load/perf benchmarks) it starts falling over left, right
and center.

And I just smacked into this in the bulkstat phase of the benchmark
(mkfs, fsmark, xfs_repair, mount, bulkstat, find, grep, rm):

[ 2729.750563] BUG: Bad page state in process bstat  pfn:14945
[ 2729.751863] page:ea525140 count:-1 mapcount:0 mapping:  
(null) index:0x0
[ 2729.753763] flags: 0x4000()
[ 2729.754671] raw: 4000   

[ 2729.756469] raw: dead0100 dead0200  

[ 2729.758276] page dumped because: nonzero _refcount
[ 2729.759393] Modules linked in:
[ 2729.760137] CPU: 7 PID: 25902 Comm: bstat Tainted: GB   
4.9.0-dgc #18
[ 2729.761888] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[ 2729.763943] Call Trace:
[ 2729.764523]  
[ 2729.765004]  dump_stack+0x63/0x83
[ 2729.765784]  bad_page+0xc4/0x130
[ 2729.766552]  free_pages_check_bad+0x4f/0x70
[ 2729.767531]  free_pcppages_bulk+0x3c5/0x3d0
[ 2729.768513]  ? page_alloc_cpu_dead+0x30/0x30
[ 2729.769510]  drain_pages_zone+0x41/0x60
[ 2729.770417]  drain_pages+0x3e/0x60
[ 2729.771215]  drain_local_pages+0x24/0x30
[ 2729.772138]  flush_smp_call_function_queue+0x88/0x160
[ 2729.773317]  generic_smp_call_function_single_interrupt+0x13/0x30
[ 2729.774742]  smp_call_function_single_interrupt+0x27/0x40
[ 2729.776000]  smp_call_function_interrupt+0xe/0x10
[ 2729.777102]  call_function_interrupt+0x8e/0xa0
[ 2729.778147] RIP: 0010:delay_tsc+0x41/0x90
[ 2729.779085] RSP: 0018:c9000f0cf500 EFLAGS: 0202 ORIG_RAX: 
ff03
[ 2729.780852] RAX: 77541291 RBX: 88008b5efe40 RCX: 002e
[ 2729.782514] RDX: 0577 RSI: 05541291 RDI: 0001
[ 2729.784167] RBP: c9000f0cf500 R08: 0007 R09: c9000f0cf678
[ 2729.785818] R10: 0006 R11: 1000 R12: 0061
[ 2729.787480] R13: 0001 R14: 83214e30 R15: 0080
[ 2729.789124]  
[ 2729.789626]  __delay+0xf/0x20
[ 2729.790333]  do_raw_spin_lock+0x8c/0x160
[ 2729.791255]  _raw_spin_lock+0x15/0x20
[ 2729.792112]  list_lru_add+0x1a/0x70
[ 2729.792932]  xfs_buf_rele+0x3e7/0x410
[ 2729.793792]  xfs_buftarg_shrink_scan+0x6b/0x80
[ 2729.794841]  shrink_slab.part.65.constprop.86+0x1dc/0x410
[ 2729.796099]  shrink_node+0x57/0x90
[ 2729.796905]  do_try_to_free_pages+0xdd/0x230
[ 2729.797914]  try_to_free_pages+0xce/0x1a0
[ 2729.798852]  __alloc_pages_slowpath+0x2df/0x960
[ 2729.799908]  __alloc_pages_nodemask+0x24b/0x290
[ 2729.800963]  new_slab+0x2ac/0x380
[ 2729.801743]  ___slab_alloc.constprop.82+0x336/0x440
[ 

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

[Christoph Hellwig]

On Thu, Dec 22, 2016 at 05:30:46PM +1100, Dave Chinner wrote:
> > For "normal" bios the for_each_segment loop iterates over bi_vcnt,
> > so it will be ignored anyway.  That being said both I and the lists
> > got CCed halfway through the thread and I haven't seen the original
> > report, so I'm not really sure what's going on here anyway.
> 
> http://www.gossamer-threads.com/lists/linux/kernel/2587485

This doesn't look like the discard changes, but if Chris wants to test
without them f9d03f96b988 reverts cleanly.
--
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: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

[Dave Chinner]

On Thu, Dec 22, 2016 at 07:18:27AM +0100, Christoph Hellwig wrote:
> On Wed, Dec 21, 2016 at 03:19:15PM -0800, Linus Torvalds wrote:
> > Looking around a bit, the only even halfway suspicious scatterlist
> > initialization thing I see is commit f9d03f96b988 ("block: improve
> > handling of the magic discard payload") which used to have a magic
> > hack wrt !bio->bi_vcnt, and that got removed. See __blk_bios_map_sg(),
> > now it does __blk_bvec_map_sg() instead.
> 
> But that check was only for discard (and discard-like) bios which
> had the maic single page that sometimes was unused attached.
> 
> For "normal" bios the for_each_segment loop iterates over bi_vcnt,
> so it will be ignored anyway.  That being said both I and the lists
> got CCed halfway through the thread and I haven't seen the original
> report, so I'm not really sure what's going on here anyway.

http://www.gossamer-threads.com/lists/linux/kernel/2587485

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.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: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

[Dave Chinner]

On Thu, Dec 22, 2016 at 04:13:22PM +1100, Dave Chinner wrote:
> On Wed, Dec 21, 2016 at 04:13:03PM -0800, Chris Leech wrote:
> > On Wed, Dec 21, 2016 at 03:19:15PM -0800, Linus Torvalds wrote:
> > > Hi,
> > > 
> > > On Wed, Dec 21, 2016 at 2:16 PM, Dave Chinner  wrote:
> > > > On Fri, Dec 16, 2016 at 10:59:06AM -0800, Chris Leech wrote:
> > > >> Thanks Dave,
> > > >>
> > > >> I'm hitting a bug at scatterlist.h:140 before I even get any iSCSI
> > > >> modules loaded (virtio block) so there's something else going on in the
> > > >> current merge window.  I'll keep an eye on it and make sure there's
> > > >> nothing iSCSI needs fixing for.
> > > >
> > > > OK, so before this slips through the cracks.
> > > >
> > > > Linus - your tree as of a few minutes ago still panics immediately
> > > > when starting xfstests on iscsi devices. It appears to be a
> > > > scatterlist corruption and not an iscsi problem, so the iscsi guys
> > > > seem to have bounced it and no-one is looking at it.
> > > 
> > > Hmm. There's not much to go by.
> > > 
> > > Can somebody in iscsi-land please try to just bisect it - I'm not
> > > seeing a lot of clues to where this comes from otherwise.
> > 
> > Yeah, my hopes of this being quickly resolved by someone else didn't
> > work out and whatever is going on in that test VM is looking like a
> > different kind of odd.  I'm saving that off for later, and seeing if I
> > can't be a bisect on the iSCSI issue.
> 
> There may be deeper issues. I just started running scalability tests
> (e.g. 16-way fsmark create tests) and about a minute in I got a
> directory corruption reported - something I hadn't seen in the dev
> cycle at all. I unmounted the fs, mkfs'd it again, ran the
> workload again and about a minute in this fired:
> 
> [628867.607417] [ cut here ]
> [628867.608603] WARNING: CPU: 2 PID: 16925 at mm/workingset.c:461 
> shadow_lru_isolate+0x171/0x220
> [628867.610702] Modules linked in:
> [628867.611375] CPU: 2 PID: 16925 Comm: kworker/2:97 Tainted: GW  
>  4.9.0-dgc #18
> [628867.613382] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> Debian-1.8.2-1 04/01/2014
> [628867.616179] Workqueue: events rht_deferred_worker
> [628867.632422] Call Trace:
> [628867.634691]  dump_stack+0x63/0x83
> [628867.637937]  __warn+0xcb/0xf0
> [628867.641359]  warn_slowpath_null+0x1d/0x20
> [628867.643362]  shadow_lru_isolate+0x171/0x220
> [628867.644627]  __list_lru_walk_one.isra.11+0x79/0x110
> [628867.645780]  ? __list_lru_init+0x70/0x70
> [628867.646628]  list_lru_walk_one+0x17/0x20
> [628867.647488]  scan_shadow_nodes+0x34/0x50
> [628867.648358]  shrink_slab.part.65.constprop.86+0x1dc/0x410
> [628867.649506]  shrink_node+0x57/0x90
> [628867.650233]  do_try_to_free_pages+0xdd/0x230
> [628867.651157]  try_to_free_pages+0xce/0x1a0
> [628867.652342]  __alloc_pages_slowpath+0x2df/0x960
> [628867.653332]  ? __might_sleep+0x4a/0x80
> [628867.654148]  __alloc_pages_nodemask+0x24b/0x290
> [628867.655237]  kmalloc_order+0x21/0x50
> [628867.656016]  kmalloc_order_trace+0x24/0xc0
> [628867.656878]  __kmalloc+0x17d/0x1d0
> [628867.657644]  bucket_table_alloc+0x195/0x1d0
> [628867.658564]  ? __might_sleep+0x4a/0x80
> [628867.659449]  rht_deferred_worker+0x287/0x3c0
> [628867.660366]  ? _raw_spin_unlock_irq+0xe/0x30
> [628867.661294]  process_one_work+0x1de/0x4d0
> [628867.662208]  worker_thread+0x4b/0x4f0
> [628867.662990]  kthread+0x10c/0x140
> [628867.663687]  ? process_one_work+0x4d0/0x4d0
> [628867.664564]  ? kthread_create_on_node+0x40/0x40
> [628867.665523]  ret_from_fork+0x25/0x30
> [628867.666317] ---[ end trace 7c38634006a9955e ]---
> 
> Now, this workload does not touch the page cache at all - it's
> entirely an XFS metadata workload, so it should not really be
> affecting the working set code.

The system back up, and I haven't reproduced this problem yet.
However, benchmark results are way off where they should be, and at
times the performance is utterly abysmal. The XFS for-next tree
based on the 4.9 kernel shows none of these problems, so I don't
think there's an XFS problem here. Workload is the same 16-way
fsmark workload that I've been using for years as a performance
regression test.

The workload normally averages around 230k files/s - i'm seeing
and average of ~175k files/s on you current kernel. And there are
periods where performance just completely tanks:

#  ./fs_mark  -D  1  -S0  -n  10  -s  0  -L  32  -d  /mnt/scratch/0  -d 
 /mnt/scratch/1  -d  /mnt/scratch/2  -d  /mnt/scratch/3  -d  /mnt/scratch/4  -d 
 /mnt/scratch/5  -d  /mnt/scratch/6  -d  /mnt/scratch/7  -d  /mnt/scratch/8  -d 
 /mnt/scratch/9  -d  /mnt/scratch/10  -d  /mnt/scratch/11  -d  /mnt/scratch/12  
-d  /mnt/scratch/13  -d  /mnt/scratch/14  -d  /mnt/scratch/15
#   Version 3.3, 16 thread(s) starting at Thu Dec 22 16:29:20 2016
#   Sync method: NO SYNC: Test does not issue sync() or fsync() calls.
#   Directories:  Time based hash 

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

[Christoph Hellwig]

On Wed, Dec 21, 2016 at 03:19:15PM -0800, Linus Torvalds wrote:
> Looking around a bit, the only even halfway suspicious scatterlist
> initialization thing I see is commit f9d03f96b988 ("block: improve
> handling of the magic discard payload") which used to have a magic
> hack wrt !bio->bi_vcnt, and that got removed. See __blk_bios_map_sg(),
> now it does __blk_bvec_map_sg() instead.

But that check was only for discard (and discard-like) bios which
had the maic single page that sometimes was unused attached.

For "normal" bios the for_each_segment loop iterates over bi_vcnt,
so it will be ignored anyway.  That being said both I and the lists
got CCed halfway through the thread and I haven't seen the original
report, so I'm not really sure what's going on here anyway.
--
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: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

[Linus Torvalds]

On Wed, Dec 21, 2016 at 9:13 PM, Dave Chinner  wrote:
>
> There may be deeper issues. I just started running scalability tests
> (e.g. 16-way fsmark create tests) and about a minute in I got a
> directory corruption reported - something I hadn't seen in the dev
> cycle at all.

By "in the dev cycle", do you mean your XFS changes, or have you been
tracking the merge cycle at least for some testing?

> I unmounted the fs, mkfs'd it again, ran the
> workload again and about a minute in this fired:
>
> [628867.607417] [ cut here ]
> [628867.608603] WARNING: CPU: 2 PID: 16925 at mm/workingset.c:461 
> shadow_lru_isolate+0x171/0x220

Well, part of the changes during the merge window were the shadow
entry tracking changes that came in through Andrew's tree. Adding
Johannes Weiner to the participants.

> Now, this workload does not touch the page cache at all - it's
> entirely an XFS metadata workload, so it should not really be
> affecting the working set code.

Well, I suspect that anything that creates memory pressure will end up
triggering the working set code, so ..

That said, obviously memory corruption could be involved and result in
random issues too, but I wouldn't really expect that in this code.

It would probably be really useful to get more data points - is the
problem reliably in this area, or is it going to be random and all
over the place.

That said:

> And worse, on that last error, the /host/ is now going into meltdown
> (running 4.7.5) with 32 CPUs all burning down in ACPI code:

The obvious question here is how much you trust the environment if the
host ends up also showing problems. Maybe you do end up having hw
issues pop up too.

The primary suspect would presumably be the development kernel you're
testing triggering something, but it has to be asked..

 Linus
--
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: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

[Dave Chinner]

On Wed, Dec 21, 2016 at 04:13:03PM -0800, Chris Leech wrote:
> On Wed, Dec 21, 2016 at 03:19:15PM -0800, Linus Torvalds wrote:
> > Hi,
> > 
> > On Wed, Dec 21, 2016 at 2:16 PM, Dave Chinner  wrote:
> > > On Fri, Dec 16, 2016 at 10:59:06AM -0800, Chris Leech wrote:
> > >> Thanks Dave,
> > >>
> > >> I'm hitting a bug at scatterlist.h:140 before I even get any iSCSI
> > >> modules loaded (virtio block) so there's something else going on in the
> > >> current merge window.  I'll keep an eye on it and make sure there's
> > >> nothing iSCSI needs fixing for.
> > >
> > > OK, so before this slips through the cracks.
> > >
> > > Linus - your tree as of a few minutes ago still panics immediately
> > > when starting xfstests on iscsi devices. It appears to be a
> > > scatterlist corruption and not an iscsi problem, so the iscsi guys
> > > seem to have bounced it and no-one is looking at it.
> > 
> > Hmm. There's not much to go by.
> > 
> > Can somebody in iscsi-land please try to just bisect it - I'm not
> > seeing a lot of clues to where this comes from otherwise.
> 
> Yeah, my hopes of this being quickly resolved by someone else didn't
> work out and whatever is going on in that test VM is looking like a
> different kind of odd.  I'm saving that off for later, and seeing if I
> can't be a bisect on the iSCSI issue.

There may be deeper issues. I just started running scalability tests
(e.g. 16-way fsmark create tests) and about a minute in I got a
directory corruption reported - something I hadn't seen in the dev
cycle at all. I unmounted the fs, mkfs'd it again, ran the
workload again and about a minute in this fired:

[628867.607417] [ cut here ]
[628867.608603] WARNING: CPU: 2 PID: 16925 at mm/workingset.c:461 
shadow_lru_isolate+0x171/0x220
[628867.610702] Modules linked in:
[628867.611375] CPU: 2 PID: 16925 Comm: kworker/2:97 Tainted: GW   
4.9.0-dgc #18
[628867.613382] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[628867.616179] Workqueue: events rht_deferred_worker
[628867.632422] Call Trace:
[628867.634691]  dump_stack+0x63/0x83
[628867.637937]  __warn+0xcb/0xf0
[628867.641359]  warn_slowpath_null+0x1d/0x20
[628867.643362]  shadow_lru_isolate+0x171/0x220
[628867.644627]  __list_lru_walk_one.isra.11+0x79/0x110
[628867.645780]  ? __list_lru_init+0x70/0x70
[628867.646628]  list_lru_walk_one+0x17/0x20
[628867.647488]  scan_shadow_nodes+0x34/0x50
[628867.648358]  shrink_slab.part.65.constprop.86+0x1dc/0x410
[628867.649506]  shrink_node+0x57/0x90
[628867.650233]  do_try_to_free_pages+0xdd/0x230
[628867.651157]  try_to_free_pages+0xce/0x1a0
[628867.652342]  __alloc_pages_slowpath+0x2df/0x960
[628867.653332]  ? __might_sleep+0x4a/0x80
[628867.654148]  __alloc_pages_nodemask+0x24b/0x290
[628867.655237]  kmalloc_order+0x21/0x50
[628867.656016]  kmalloc_order_trace+0x24/0xc0
[628867.656878]  __kmalloc+0x17d/0x1d0
[628867.657644]  bucket_table_alloc+0x195/0x1d0
[628867.658564]  ? __might_sleep+0x4a/0x80
[628867.659449]  rht_deferred_worker+0x287/0x3c0
[628867.660366]  ? _raw_spin_unlock_irq+0xe/0x30
[628867.661294]  process_one_work+0x1de/0x4d0
[628867.662208]  worker_thread+0x4b/0x4f0
[628867.662990]  kthread+0x10c/0x140
[628867.663687]  ? process_one_work+0x4d0/0x4d0
[628867.664564]  ? kthread_create_on_node+0x40/0x40
[628867.665523]  ret_from_fork+0x25/0x30
[628867.666317] ---[ end trace 7c38634006a9955e ]---

Now, this workload does not touch the page cache at all - it's
entirely an XFS metadata workload, so it should not really be
affecting the working set code.

And worse, on that last error, the /host/ is now going into meltdown
(running 4.7.5) with 32 CPUs all burning down in ACPI code:

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
35074 root  -2   0   0  0  0 R  99.0  0.0  12:38.92 acpi_pad/12
35079 root  -2   0   0  0  0 R  99.0  0.0  12:39.40 acpi_pad/16
35080 root  -2   0   0  0  0 R  99.0  0.0  12:39.29 acpi_pad/17
35085 root  -2   0   0  0  0 R  99.0  0.0  12:39.35 acpi_pad/22
35087 root  -2   0   0  0  0 R  99.0  0.0  12:39.13 acpi_pad/24
35090 root  -2   0   0  0  0 R  99.0  0.0  12:38.89 acpi_pad/27
35093 root  -2   0   0  0  0 R  99.0  0.0  12:38.88 acpi_pad/30
35063 root  -2   0   0  0  0 R  98.1  0.0  12:40.64 acpi_pad/1
35065 root  -2   0   0  0  0 R  98.1  0.0  12:40.38 acpi_pad/3
35066 root  -2   0   0  0  0 R  98.1  0.0  12:40.30 acpi_pad/4
35067 root  -2   0   0  0  0 R  98.1  0.0  12:40.82 acpi_pad/5
35077 root  -2   0   0  0  0 R  98.1  0.0  12:39.65 acpi_pad/14
35078 root  -2   0   0  0  0 R  98.1  0.0  12:39.58 acpi_pad/15
35081 root  -2   0   0  0  0 R  98.1  0.0  12:39.32 acpi_pad/18
35072 root  -2   0   0  0  0 R  96.2  

Re: Testing latest linux-next 4.9 ib_srp and ib_srpt

[Laurence Oberman]

- Original Message -
> From: "Laurence Oberman" 
> To: "Bart Van Assche" 
> Cc: linux-r...@vger.kernel.org
> Sent: Wednesday, December 21, 2016 1:34:01 AM
> Subject: Re: Testing latest linux-next 4.9 ib_srp and ib_srpt
> 
> 
> 
> - Original Message -
> > From: "Laurence Oberman" 
> > To: "Bart Van Assche" 
> > Cc: linux-r...@vger.kernel.org
> > Sent: Tuesday, December 20, 2016 10:31:34 PM
> > Subject: Re: Testing latest linux-next 4.9 ib_srp and ib_srpt
> > 
> > 
> > 
> > - Original Message -
> > > From: "Laurence Oberman" 
> > > To: "Bart Van Assche" 
> > > Cc: linux-r...@vger.kernel.org
> > > Sent: Tuesday, December 20, 2016 3:44:42 PM
> > > Subject: Re: Testing latest linux-next 4.9 ib_srp and ib_srpt
> > > 
> > > 
> > > 
> > > - Original Message -
> > > > From: "Laurence Oberman" 
> > > > To: "Bart Van Assche" 
> > > > Cc: linux-r...@vger.kernel.org
> > > > Sent: Tuesday, December 20, 2016 2:43:48 PM
> > > > Subject: Re: Testing latest linux-next 4.9 ib_srp and ib_srpt
> > > > 
> > > > 
> > > > 
> > > > - Original Message -
> > > > > From: "Laurence Oberman" 
> > > > > To: "Bart Van Assche" 
> > > > > Cc: linux-r...@vger.kernel.org
> > > > > Sent: Tuesday, December 20, 2016 2:33:26 PM
> > > > > Subject: Re: Testing latest linux-next 4.9 ib_srp and ib_srpt
> > > > > 
> > > > > Hello Bart
> > > > > 
> > > > > I pulled the latest linux-next and built kernels for both server and
> > > > > client
> > > > > to rerun all my EDR tests for srp.
> > > > > 
> > > > > For some reason the I/O size is being capped again to 1MB in my
> > > > > testing.
> > > > > Using my same testbed.
> > > > > Remember we spent a lot of time making sure we could do 4MB I/O :)
> > > > > 
> > > > > Its working fine in the RHEL 7.3 kernel so before I start going back
> > > > > testing
> > > > > upstream kernels decided to ask.
> > > > > 
> > > > > Have you tested large I/O with latest linux-next
> > > > > 
> > > > > Server Configuration
> > > > > -
> > > > > Linux fedstorage.bos.redhat.com 4.9.0+
> > > > > 
> > > > > [root@fedstorage modprobe.d]# cat ib_srp.conf
> > > > > options ib_srp cmd_sg_entries=64 indirect_sg_entries=2048
> > > > > 
> > > > > [root@fedstorage modprobe.d]# cat ib_srpt.conf
> > > > > options ib_srpt srp_max_req_size=8296
> > > > > 
> > > > > Also Using
> > > > > 
> > > > > # Set the srp_sq_size
> > > > > for i in
> > > > > /sys/kernel/config/target/srpt/0xfe807cfe900300726e4e
> > > > > /sys/kernel/config/target/srpt/0xfe807cfe900300726e4f
> > > > > do
> > > > >   echo 16384 > $i/tpgt_1/attrib/srp_sq_size
> > > > > done
> > > > > 
> > > > > Client Configuration
> > > > > 
> > > > > Linux ibclient 4.9.0+
> > > > > 
> > > > > [root@ibclient modprobe.d]# cat ib_srp.conf
> > > > > options ib_srp cmd_sg_entries=255 indirect_sg_entries=2048
> > > > > 
> > > > > dd if=/dev/sdw bs=4096k of=/dev/null iflag=direct
> > > > > 
> > > > > ### RECORD4 >>> ibclient <<< (1482261733.001) (Tue Dec 20
> > > > > 14:22:13
> > > > > 2016)
> > > > > ###
> > > > > # DISK STATISTICS (/sec)
> > > > > #
> > > > > <-reads---><-writes-->
> > > > > Pct
> > > > > #Time Name   KBytes Merged  IOs Size  Wait  KBytes Merged
> > > > > IOs
> > > > > Size
> > > > > Wait  RWSize  QLen  Wait SvcTim Util
> > > > > 14:22:13 sdw 1373184  0 1341 1024 2   0  0
> > > > > 0
> > > > > 0
> > > > > 01024 3 2  0   97
> > > > > 
> > > > > 
> > > > > If I reboot into my 7.3 kernel its back to what I expect
> > > > > 
> > > > >  dd if=/dev/sdw bs=4096k of=/dev/null iflag=direct
> > > > > 
> > > > > 
> > > > > ### RECORD3 >>> ibclient <<< (1482262254.001) (Tue Dec 20
> > > > > 14:30:54
> > > > > 2016)
> > > > > ###
> > > > > # DISK STATISTICS (/sec)
> > > > > #
> > > > > <-reads---><-writes-->
> > > > > Pct
> > > > > #Time Name   KBytes Merged  IOs Size  Wait  KBytes Merged
> > > > > IOs
> > > > > Size
> > > > > Wait  RWSize  QLen  Wait SvcTim Util
> > > > > 14:30:54 sdw 172032129   42 4096 3   0  0
> > > > > 0
> > > > > 0
> > > > > 04096 1 3  3   130
> > > > > 
> > > > > --
> > > > > To unsubscribe from this list: send the line "unsubscribe linux-rdma"
> > > > > in
> > > > > the body of a message to majord...@vger.kernel.org
> > > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > > > 
> > > > 
> > > > Hi Bart,
> > > > 
> > > > Just FYI
> > > > 
> > > > That dd snap was just as I had stopped the dd.
> > > > 
> > > > Here is a stable dd snap with the RHEL kernel, 

Re: JMS56x not working reliably with uas driver

[George Cherian]

Hi Oliver,

I will try it out and update you!!


Regards,

-George

On Wednesday 21 December 2016 08:09 PM, Oliver Neukum wrote:

On Wed, 2016-12-21 at 18:17 +0530, George Cherian wrote:

[  843.149653] scsi host5: uas_post_reset: alloc streams error -19
after
reset

That would mean the endpoints are gone. Which is odd.


[  843.157268] sd 5:0:0:0: [sdb] Synchronizing SCSI cache

Could you try the attached patch and do a SCSI log of the enumeration?

Regards
Oliver



--
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: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

[Chris Leech]

On Wed, Dec 21, 2016 at 03:19:15PM -0800, Linus Torvalds wrote:
> Hi,
> 
> On Wed, Dec 21, 2016 at 2:16 PM, Dave Chinner  wrote:
> > On Fri, Dec 16, 2016 at 10:59:06AM -0800, Chris Leech wrote:
> >> Thanks Dave,
> >>
> >> I'm hitting a bug at scatterlist.h:140 before I even get any iSCSI
> >> modules loaded (virtio block) so there's something else going on in the
> >> current merge window.  I'll keep an eye on it and make sure there's
> >> nothing iSCSI needs fixing for.
> >
> > OK, so before this slips through the cracks.
> >
> > Linus - your tree as of a few minutes ago still panics immediately
> > when starting xfstests on iscsi devices. It appears to be a
> > scatterlist corruption and not an iscsi problem, so the iscsi guys
> > seem to have bounced it and no-one is looking at it.
> 
> Hmm. There's not much to go by.
> 
> Can somebody in iscsi-land please try to just bisect it - I'm not
> seeing a lot of clues to where this comes from otherwise.

Yeah, my hopes of this being quickly resolved by someone else didn't
work out and whatever is going on in that test VM is looking like a
different kind of odd.  I'm saving that off for later, and seeing if I
can't be a bisect on the iSCSI issue.

Chris
--
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: iscsi_trx going into D state

[Robert LeBlanc]

I hit a new backtrace today, hopefully it adds something.

# cat /proc/19659/stack
[] iscsit_stop_session+0x1b1/0x1c0
[] iscsi_check_for_session_reinstatement+0x1e2/0x270
[] iscsi_target_check_for_existing_instances+0x30/0x40
[] iscsi_target_do_login+0x138/0x630
[] iscsi_target_start_negotiation+0x4e/0xa0
[] __iscsi_target_login_thread+0x83e/0xf20
[] iscsi_target_login_thread+0x24/0x30
[] kthread+0xd9/0xf0
[] ret_from_fork+0x25/0x30
[] 0x

# cat /proc/21342/stack
[] __ib_drain_sq+0x190/0x1c0 [ib_core]
[] ib_drain_sq+0x25/0x30 [ib_core]
[] ib_drain_qp+0x12/0x30 [ib_core]
[] isert_wait_conn+0x5f/0x2d0 [ib_isert]
[] iscsit_close_connection+0x157/0x860
[] iscsit_take_action_for_connection_exit+0x7b/0xf0
[] iscsi_target_rx_thread+0x95/0xa0
[] kthread+0xd9/0xf0
[] ret_from_fork+0x25/0x30
[] 0x

# ps aux | grep iscsi | grep D
root 19659  0.0  0.0  0 0 ?D16:12   0:00 [iscsi_np]
root 21342  0.0  0.0  0 0 ?D16:29   0:00 [iscsi_trx]

Robert LeBlanc
PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1


On Thu, Dec 15, 2016 at 1:38 PM, Robert LeBlanc  wrote:
> Nicholas,
>
> I've found that the kernels I used were not able to be inspected using
> crash and I could not build the debug info for them. So I built a new
> 4.9 kernel and verified that I could inspect the crash. It is located
> at [1].
>
> [1] http://mirrors.betterservers.com/trace/crash2.tar.xz
> 
> Robert LeBlanc
> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1
>
>
> On Mon, Dec 12, 2016 at 4:57 PM, Robert LeBlanc  wrote:
>> Nicholas,
>>
>> After lots of set backs and having to give up trying to get kernel
>> dumps on our "production" systems, I've been able to work out the
>> issues we had with kdump and replicate the issue on my dev boxes. I
>> have dumps from 4.4.30 and 4.9-rc8 (makedumpfile would not dump, so it
>> is a straight copy of /proc/vmcore from the crash kernel). In each
>> crash directory, I put a details.txt file that has the process IDs
>> that were having problems and a brief description of the set-up at the
>> time. This was mostly replicated by starting fio and pulling the
>> Infiniband cable until fio gave up. This hardware also has Mellanox
>> ConnectX4-LX cards and I also replicated the issue over RoCE using 4.9
>> since it has the drivers in-box. Please let me know if you need more
>> info, I can test much faster now. The cores/kernels/modules are
>> located at [1].
>>
>> [1] http://mirrors.betterservers.com/trace/crash.tar.xz
>>
>> Thanks,
>> Robert
>> 
>> Robert LeBlanc
>> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1
>>
>>
>> On Fri, Nov 4, 2016 at 3:57 PM, Robert LeBlanc  wrote:
>>> We hit this yesterday, this time it was on the tx thread (the other
>>> ones before seem to be on the rx thread). We weren't able to get a
>>> kernel dump on this. We'll try to get one next time.
>>>
>>> # ps axuw | grep "D.*iscs[i]"
>>> root 12383  0.0  0.0  0 0 ?DNov03   0:04 [iscsi_np]
>>> root 23016  0.0  0.0  0 0 ?DNov03   0:00 [iscsi_ttx]
>>> root 23018  0.0  0.0  0 0 ?DNov03   0:00 [iscsi_ttx]
>>> # cat /proc/12383/stack
>>> [] iscsit_stop_session+0x19f/0x1d0
>>> [] iscsi_check_for_session_reinstatement+0x1e6/0x270
>>> [] iscsi_target_check_for_existing_instances+0x30/0x40
>>> [] iscsi_target_do_login+0x140/0x640
>>> [] iscsi_target_start_negotiation+0x1c/0xb0
>>> [] iscsi_target_login_thread+0xa9b/0xfc0
>>> [] kthread+0xd8/0xf0
>>> [] ret_from_fork+0x3f/0x70
>>> [] 0x
>>> # cat /proc/23016/stack
>>> [] target_wait_for_sess_cmds+0x49/0x1a0
>>> [] isert_wait_conn+0x1ab/0x2f0 [ib_isert]
>>> [] iscsit_close_connection+0x162/0x870
>>> [] iscsit_take_action_for_connection_exit+0x7f/0x100
>>> [] iscsi_target_tx_thread+0x1aa/0x1d0
>>> [] kthread+0xd8/0xf0
>>> [] ret_from_fork+0x3f/0x70
>>> [] 0x
>>> # cat /proc/23018/stack
>>> [] target_wait_for_sess_cmds+0x49/0x1a0
>>> [] isert_wait_conn+0x1ab/0x2f0 [ib_isert]
>>> [] iscsit_close_connection+0x162/0x870
>>> [] iscsit_take_action_for_connection_exit+0x7f/0x100
>>> [] iscsi_target_tx_thread+0x1aa/0x1d0
>>> [] kthread+0xd8/0xf0
>>> [] ret_from_fork+0x3f/0x70
>>> [] 0x
>>>
>>> From dmesg:
>>> [  394.476332] INFO: rcu_sched self-detected stall on CPU
>>> [  394.476334]  20-...: (23976 ticks this GP)
>>> idle=edd/141/0 softirq=292/292 fqs=18788
>>> [  394.476336]   (t=24003 jiffies g=3146 c=3145 q=0)
>>> [  394.476337] Task dump for CPU 20:
>>> [  394.476338] kworker/u68:2   R  running task0 12906  2 
>>> 0x0008
>>> [  394.476345] Workqueue: isert_comp_wq isert_cq_work [ib_isert]
>>> [  394.476346]  883f2fe38000 f805705e 883f7fd03da8
>>> 810ac8ff
>>> [  394.476347]  0014 

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

[Linus Torvalds]

Hi,

On Wed, Dec 21, 2016 at 2:16 PM, Dave Chinner  wrote:
> On Fri, Dec 16, 2016 at 10:59:06AM -0800, Chris Leech wrote:
>> Thanks Dave,
>>
>> I'm hitting a bug at scatterlist.h:140 before I even get any iSCSI
>> modules loaded (virtio block) so there's something else going on in the
>> current merge window.  I'll keep an eye on it and make sure there's
>> nothing iSCSI needs fixing for.
>
> OK, so before this slips through the cracks.
>
> Linus - your tree as of a few minutes ago still panics immediately
> when starting xfstests on iscsi devices. It appears to be a
> scatterlist corruption and not an iscsi problem, so the iscsi guys
> seem to have bounced it and no-one is looking at it.

Hmm. There's not much to go by.

Can somebody in iscsi-land please try to just bisect it - I'm not
seeing a lot of clues to where this comes from otherwise.

There clearly hasn't been anything done to drivers/scsi/*iscsi* since
4.9, so it's coming from elsewhere, presumably the block layer changes
as you say.

But I think we need iscsi people to pinpoint it a bit more, since
nobody else seems to be complaining.

Looking around a bit, the only even halfway suspicious scatterlist
initialization thing I see is commit f9d03f96b988 ("block: improve
handling of the magic discard payload") which used to have a magic
hack wrt !bio->bi_vcnt, and that got removed. See __blk_bios_map_sg(),
now it does __blk_bvec_map_sg() instead.

Maybe __blk_bvec_map_sg() would want that same

if (!bio->bi_vcnt)
return 0;

adding Christoph explicitly so that he can tell me why I'm a clueless
weenie. Although I suspect he's already on the scsi and block lists
and would have done so anyway.

> I'm disappearing for several months at the end of tomorrow, so I
> thought I better make sure you know about it.  I've also added
> linux-scsi, linux-block to the cc list

Thanks,

Linus
--
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: [PATCH] scsi: do not requeue requests unaligned with device sector size

[Mauricio Faria de Oliveira]

On 12/21/2016 05:50 AM, Christoph Hellwig wrote:
> How do you even get an unaligned residual count?  Except for SES
> processor devices (which will only issue BLOCK_PC commands) this is
> not allowed by SPC:
>
> "The residual count shall be reported in bytes if the peripheral device
>  type in the destination target descriptor is 03h (i.e., processor 
device),

>  and in destination device blocks for all other device type codes.

On 12/21/2016 06:09 AM, Hannes Reinecke wrote:
> Which actually would be pretty much my objection, too.
>
> This would only be applicable for 512e drives, where we _might_ end up
> with a residual smaller than the physical sector size.
> But that should be handled by firmware; after all, that's what the 'e'
> implies, right?

On 12/21/2016 12:01 PM, Martin K. Petersen wrote:

I agree with Christoph and Hannes. Some of this falls into the gray area
that's outside of the T10 spec (HBA programming interface guarantees)
but it seems like a deficiency in the HBA to report a byte count that's
not a multiple of the logical block size. A block can't be partially
written. Either it made it or it didn't. Regardless of how the I/O is
being broken up into frames at the transport level and at which offset
the transfer was interrupted.


Christoph, Hannes, Martin,

Thank you all for your comments and pointers to the documentation/spec.
I'll carry it on with the HBA and storage folks.

cheers,

--
Mauricio Faria de Oliveira
IBM Linux Technology Center

--
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: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

[Dave Chinner]

On Fri, Dec 16, 2016 at 10:59:06AM -0800, Chris Leech wrote:
> Thanks Dave,
> 
> I'm hitting a bug at scatterlist.h:140 before I even get any iSCSI
> modules loaded (virtio block) so there's something else going on in the
> current merge window.  I'll keep an eye on it and make sure there's
> nothing iSCSI needs fixing for.

OK, so before this slips through the cracks.

Linus - your tree as of a few minutes ago still panics immediately
when starting xfstests on iscsi devices. It appears to be a
scatterlist corruption and not an iscsi problem, so the iscsi guys
seem to have bounced it and no-one is looking at it.

I'm disappearing for several months at the end of tomorrow, so I
thought I better make sure you know about it.  I've also added
linux-scsi, linux-block to the cc list

Cheers,

Dave.

> On Thu, Dec 15, 2016 at 09:29:53AM +1100, Dave Chinner wrote:
> > On Thu, Dec 15, 2016 at 09:24:11AM +1100, Dave Chinner wrote:
> > > Hi folks,
> > > 
> > > Just updated my test boxes from 4.9 to a current Linus 4.10 merge
> > > window kernel to test the XFS merge I am preparing for Linus.
> > > Unfortunately, all my test VMs using iscsi failed pretty much
> > > instantly on the first mount of an iscsi device:
> > > 
> > > [  159.372704] XFS (sdb): EXPERIMENTAL reverse mapping btree feature 
> > > enabled. Use at your own risk!
> > > [  159.374612] XFS (sdb): Mounting V5 Filesystem
> > > [  159.425710] XFS (sdb): Ending clean mount
> > > [  160.274438] BUG: unable to handle kernel NULL pointer dereference at 
> > > 000c
> > > [  160.275851] IP: iscsi_tcp_segment_done+0x20d/0x2e0
> > 
> > FYI, crash is here:
> > 
> > (gdb) l *(iscsi_tcp_segment_done+0x20d)
> > 0x81b950bd is in iscsi_tcp_segment_done 
> > (drivers/scsi/libiscsi_tcp.c:102).
> > 97  iscsi_tcp_segment_init_sg(struct iscsi_segment *segment,
> > 98struct scatterlist *sg, unsigned int offset)
> > 99  {
> > 100 segment->sg = sg;
> > 101 segment->sg_offset = offset;
> > 102 segment->size = min(sg->length - offset,
> > 103 segment->total_size - 
> > segment->total_copied);
> > 104 segment->data = NULL;
> > 105 }
> > 106 
> > 
> > So it looks to be sg = NULL, which means there's probably an issue
> > with the scatterlist...
> > 
> > -Dave.
> > 
> > > [  160.276565] PGD 336ed067 [  160.276885] PUD 31b0d067
> > > PMD 0 [  160.277309]
> > > [  160.277523] Oops:  [#1] PREEMPT SMP
> > > [  160.278004] Modules linked in:
> > > [  160.278407] CPU: 0 PID: 16 Comm: kworker/u2:1 Not tainted 4.9.0-dgc #18
> > > [  160.279224] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
> > > BIOS Debian-1.8.2-1 04/01/2014
> > > [  160.280314] Workqueue: iscsi_q_2 iscsi_xmitworker
> > > [  160.280919] task: 88003e28 task.stack: c908
> > > [  160.281647] RIP: 0010:iscsi_tcp_segment_done+0x20d/0x2e0
> > > [  160.282312] RSP: 0018:c9083c38 EFLAGS: 00010206
> > > [  160.282980] RAX:  RBX: 880039061730 RCX: 
> > > 
> > > [  160.283854] RDX: 1e00 RSI:  RDI: 
> > > 880039061730
> > > [  160.284738] RBP: c9083c90 R08: 0200 R09: 
> > > 05a8
> > > [  160.285627] R10: 9835607d R11:  R12: 
> > > 0200
> > > [  160.286495] R13:  R14: 8800390615a0 R15: 
> > > 880039061730
> > > [  160.287362] FS:  () GS:88003fc0() 
> > > knlGS:
> > > [  160.288340] CS:  0010 DS:  ES:  CR0: 80050033
> > > [  160.289113] CR2: 000c CR3: 31a8d000 CR4: 
> > > 06f0
> > > [  160.290084] Call Trace:
> > > [  160.290429]  ? inet_sendpage+0x4d/0x140
> > > [  160.290957]  iscsi_sw_tcp_xmit_segment+0x89/0x110
> > > [  160.291597]  iscsi_sw_tcp_pdu_xmit+0x56/0x180
> > > [  160.292190]  iscsi_tcp_task_xmit+0xb8/0x280
> > > [  160.292771]  iscsi_xmit_task+0x53/0xc0
> > > [  160.293282]  iscsi_xmitworker+0x274/0x310
> > > [  160.293835]  process_one_work+0x1de/0x4d0
> > > [  160.294388]  worker_thread+0x4b/0x4f0
> > > [  160.294889]  kthread+0x10c/0x140
> > > [  160.295333]  ? process_one_work+0x4d0/0x4d0
> > > [  160.295898]  ? kthread_create_on_node+0x40/0x40
> > > [  160.296525]  ret_from_fork+0x25/0x30
> > > [  160.297015] Code: 43 18 00 00 00 00 e9 ad fe ff ff 48 8b 7b 30 e8 da 
> > > e7 ca ff 8b 53 10 44 89 ee 48 89 df 2b 53 14 48 89 43 30 c7 43 40 00 00 
> > > 00 00 <8b
> > > [  160.300674] RIP: iscsi_tcp_segment_done+0x20d/0x2e0 RSP: 
> > > c9083c38
> > > [  160.301584] CR2: 000c
> > > 
> > > 
> > > Known problem, or something new?
> > > 
> > > Cheers,
> > > 
> > > Dave.
> > > -- 
> > > Dave Chinner
> > > da...@fromorbit.com
> > > 
> > 
> > -- 
> > Dave Chinner
> > da...@fromorbit.com
> 

-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in

[PATCH v2 08/10] qla2xxx: Reduce exess wait during chip reset

[Himanshu Madhani]

From: Quinn Tran 

Soft reset and Risc reset should take 100uS to complete.
This change pad the timeout up to 400uS, which should be
plenty.

Signed-off-by: Quinn Tran 
Signed-off-by: Himanshu Madhani 
---
 drivers/scsi/qla2xxx/qla_init.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 632d5f3..7b6317c 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -1191,7 +1191,7 @@ static int qla2x00_fabric_dev_login(scsi_qla_host_t *, 
fc_port_t *,
 
/* Wait for soft-reset to complete. */
RD_REG_DWORD(>ctrl_status);
-   for (cnt = 0; cnt < 600; cnt++) {
+   for (cnt = 0; cnt < 60; cnt++) {
barrier();
if ((RD_REG_DWORD(>ctrl_status) &
CSRX_ISP_SOFT_RESET) == 0)
@@ -1234,7 +1234,7 @@ static int qla2x00_fabric_dev_login(scsi_qla_host_t *, 
fc_port_t *,
RD_REG_DWORD(>hccr);
 
RD_REG_WORD(>mailbox0);
-   for (cnt = 600; RD_REG_WORD(>mailbox0) != 0 &&
+   for (cnt = 60; RD_REG_WORD(>mailbox0) != 0 &&
rval == QLA_SUCCESS; cnt--) {
barrier();
if (cnt)
-- 
1.8.3.1

--
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

[PATCH v2 10/10] qla2xxx: Disable Out-of-order processing by default in Firmware

[Himanshu Madhani]

From: Quinn Tran 

Out of order(OOO) processing requires initiator, switch
and target to support OOO. In today¹s environment, none
of the switches support OOO. OOO requires extra buffer
space which affect performance. By turning ON this feature
in QLogic's FW, it delays error recovery because droped
frame is treated as out of order frame. We¹re turning OFF
this option of speed up error recovery,

Signed-off-by: Quinn Tran 
Signed-off-by: Himanshu Madhani 
---
 drivers/scsi/qla2xxx/qla_target.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_target.c 
b/drivers/scsi/qla2xxx/qla_target.c
index c02f31a..6ab191a 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -6578,9 +6578,6 @@ static void qlt_disable_vha(struct scsi_qla_host *vha)
return;
}
 
-   /* out-of-order frames reassembly */
-   nv->firmware_options_3 |= BIT_6|BIT_9;
-
if (ha->tgt.enable_class_2) {
if (vha->flags.init_done)
fc_host_supported_classes(vha->host) =
@@ -6683,9 +6680,6 @@ static void qlt_disable_vha(struct scsi_qla_host *vha)
return;
}
 
-   /* out-of-order frames reassembly */
-   nv->firmware_options_3 |= BIT_6|BIT_9;
-
if (ha->tgt.enable_class_2) {
if (vha->flags.init_done)
fc_host_supported_classes(vha->host) =
-- 
1.8.3.1

--
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

[PATCH v2 05/10] qla2xxx: Collect additional information to debug fw dump.

[Himanshu Madhani]

From: Quinn Tran 

Signed-off-by: Quinn Tran 
Signed-off-by: Himanshu Madhani 
---
 drivers/scsi/qla2xxx/qla_mbx.c | 27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_mbx.c b/drivers/scsi/qla2xxx/qla_mbx.c
index 2819ceb..b4386fc 100644
--- a/drivers/scsi/qla2xxx/qla_mbx.c
+++ b/drivers/scsi/qla2xxx/qla_mbx.c
@@ -323,20 +323,33 @@ static int is_rom_cmd(uint16_t cmd)
}
} else {
 
-   uint16_t mb0;
-   uint32_t ictrl;
+   uint16_t mb[8];
+   uint32_t ictrl, host_status, hccr;
uint16_tw;
 
if (IS_FWI2_CAPABLE(ha)) {
-   mb0 = RD_REG_WORD(>isp24.mailbox0);
+   mb[0] = RD_REG_WORD(>isp24.mailbox0);
+   mb[1] = RD_REG_WORD(>isp24.mailbox1);
+   mb[2] = RD_REG_WORD(>isp24.mailbox2);
+   mb[3] = RD_REG_WORD(>isp24.mailbox3);
+   mb[7] = RD_REG_WORD(>isp24.mailbox7);
ictrl = RD_REG_DWORD(>isp24.ictrl);
+   host_status = RD_REG_DWORD(>isp24.host_status);
+   hccr = RD_REG_DWORD(>isp24.hccr);
+
+   ql_log(ql_log_warn, vha, 0x1119,
+   "MBX Command timeout for cmd %x, iocontrol=%x 
jiffies=%lx "
+   "mb[0-3]=[0x%x 0x%x 0x%x 0x%x] mb7 0x%x host_status 
0x%x hccr 0x%x\n",
+   command, ictrl, jiffies, mb[0], mb[1], mb[2], mb[3],
+   mb[7], host_status, hccr);
+
} else {
-   mb0 = RD_MAILBOX_REG(ha, >isp, 0);
+   mb[0] = RD_MAILBOX_REG(ha, >isp, 0);
ictrl = RD_REG_WORD(>isp.ictrl);
+   ql_dbg(ql_dbg_mbx + ql_dbg_buffer, vha, 0x1119,
+   "MBX Command timeout for cmd %x, iocontrol=%x 
jiffies=%lx "
+   "mb[0]=0x%x\n", command, ictrl, jiffies, mb[0]);
}
-   ql_dbg(ql_dbg_mbx + ql_dbg_buffer, vha, 0x1119,
-   "MBX Command timeout for cmd %x, iocontrol=%x jiffies=%lx "
-   "mb[0]=0x%x\n", command, ictrl, jiffies, mb0);
ql_dump_regs(ql_dbg_mbx + ql_dbg_buffer, vha, 0x1019);
 
/* Capture FW dump only, if PCI device active */
-- 
1.8.3.1

--
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

[PATCH v2 09/10] qla2xxx: Fix invalid handle erroneous message.

[Himanshu Madhani]

From: Quinn Tran 

Termination of Immediate Notify IOCB was using wrong
IOCB handle. IOCB completion code was unable to find
appropriate code path due to wrong handle.

Following message is seen in the logs.

"Error entry - invalid handle/queue ()."

Signed-off-by: Quinn Tran 
Signed-off-by: Himanshu Madhani 
---
 drivers/scsi/qla2xxx/qla_isr.c| 4 
 drivers/scsi/qla2xxx/qla_target.c | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index af840bf..eefcf2f 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -2495,6 +2495,10 @@ struct scsi_dif_tuple {
if (pkt->entry_status & RF_BUSY)
res = DID_BUS_BUSY << 16;
 
+   if (pkt->entry_type == NOTIFY_ACK_TYPE &&
+   pkt->handle == QLA_TGT_SKIP_HANDLE)
+   return;
+
sp = qla2x00_get_sp_from_handle(vha, func, req, pkt);
if (sp) {
sp->done(ha, sp, res);
diff --git a/drivers/scsi/qla2xxx/qla_target.c 
b/drivers/scsi/qla2xxx/qla_target.c
index 9252694..c02f31a 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -3061,7 +3061,7 @@ static int __qlt_send_term_imm_notif(struct scsi_qla_host 
*vha,
 
pkt->entry_type = NOTIFY_ACK_TYPE;
pkt->entry_count = 1;
-   pkt->handle = QLA_TGT_SKIP_HANDLE | CTIO_COMPLETION_HANDLE_MARK;
+   pkt->handle = QLA_TGT_SKIP_HANDLE;
 
nack = (struct nack_to_isp *)pkt;
nack->ox_id = ntfy->ox_id;
-- 
1.8.3.1

--
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

[PATCH v2 07/10] qla2xxx: Terminate exchange if corrputed.

[Himanshu Madhani]

From: Quinn Tran 

Corrupted ATIO is defined as length of fcp_header & fcp_cmd
payload is less than 0x38. It's the minimum size for a frame to
carry 8..16 bytes SCSI CDB. The exchange will be dropped or
terminated if corrupted.

Signed-off-by: Quinn Tran 
Signed-off-by: Himanshu Madhani 
---
 drivers/scsi/qla2xxx/qla_def.h|  3 ++-
 drivers/scsi/qla2xxx/qla_target.c | 22 +++---
 drivers/scsi/qla2xxx/qla_target.h | 22 +-
 3 files changed, 42 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
index f7df01b..b14455e 100644
--- a/drivers/scsi/qla2xxx/qla_def.h
+++ b/drivers/scsi/qla2xxx/qla_def.h
@@ -1556,7 +1556,8 @@ struct link_statistics {
 struct atio {
uint8_t entry_type; /* Entry type. */
uint8_t entry_count;/* Entry count. */
-   uint8_t data[58];
+   uint16_tattr_n_length;
+   uint8_t data[56];
uint32_tsignature;
 #define ATIO_PROCESSED 0xDEADDEAD  /* Signature */
 };
diff --git a/drivers/scsi/qla2xxx/qla_target.c 
b/drivers/scsi/qla2xxx/qla_target.c
index 5037b51..9252694 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -6451,12 +6451,28 @@ static void qlt_disable_vha(struct scsi_qla_host *vha)
if (!vha->flags.online)
return;
 
-   while (ha->tgt.atio_ring_ptr->signature != ATIO_PROCESSED) {
+   while ((ha->tgt.atio_ring_ptr->signature != ATIO_PROCESSED) ||
+   fcpcmd_is_corrupted(ha->tgt.atio_ring_ptr)) {
pkt = (struct atio_from_isp *)ha->tgt.atio_ring_ptr;
cnt = pkt->u.raw.entry_count;
 
-   qlt_24xx_atio_pkt_all_vps(vha, (struct atio_from_isp *)pkt,
-   ha_locked);
+   if (unlikely(fcpcmd_is_corrupted(ha->tgt.atio_ring_ptr))) {
+   /* This packet is corrupted. The header + payload
+* can not be trusted. There is no point in passing
+* it further up.
+*/
+   ql_log(ql_log_warn, vha, 0x,
+   "corrupted fcp frame SID[%3phN] OXID[%04x] EXCG[%x] 
%64phN\n",
+   pkt->u.isp24.fcp_hdr.s_id,
+   be16_to_cpu(pkt->u.isp24.fcp_hdr.ox_id),
+   le32_to_cpu(pkt->u.isp24.exchange_addr), pkt);
+
+   adjust_corrupted_atio(pkt);
+   qlt_send_term_exchange(vha, NULL, pkt, ha_locked, 0);
+   } else {
+   qlt_24xx_atio_pkt_all_vps(vha,
+   (struct atio_from_isp *)pkt, ha_locked);
+   }
 
for (i = 0; i < cnt; i++) {
ha->tgt.atio_ring_index++;
diff --git a/drivers/scsi/qla2xxx/qla_target.h 
b/drivers/scsi/qla2xxx/qla_target.h
index f26c5f6..f31d343 100644
--- a/drivers/scsi/qla2xxx/qla_target.h
+++ b/drivers/scsi/qla2xxx/qla_target.h
@@ -427,13 +427,33 @@ struct atio_from_isp {
struct {
uint8_t  entry_type;/* Entry type. */
uint8_t  entry_count;   /* Entry count. */
-   uint8_t  data[58];
+   uint16_t attr_n_length;
+#define FCP_CMD_LENGTH_MASK 0x0fff
+#define FCP_CMD_LENGTH_MIN  0x38
+   uint8_t  data[56];
uint32_t signature;
 #define ATIO_PROCESSED 0xDEADDEAD  /* Signature */
} raw;
} u;
 } __packed;
 
+static inline int fcpcmd_is_corrupted(struct atio *atio)
+{
+   if (atio->entry_type == ATIO_TYPE7 &&
+   (le16_to_cpu(atio->attr_n_length & FCP_CMD_LENGTH_MASK) <
+   FCP_CMD_LENGTH_MIN))
+   return 1;
+   else
+   return 0;
+}
+
+/* adjust corrupted atio so we won't trip over the same entry again. */
+static inline void adjust_corrupted_atio(struct atio_from_isp *atio)
+{
+   atio->u.raw.attr_n_length = cpu_to_le16(FCP_CMD_LENGTH_MIN);
+   atio->u.isp24.fcp_cmnd.add_cdb_len = 0;
+}
+
 #define CTIO_TYPE7 0x12 /* Continue target I/O entry (for 24xx) */
 
 /*
-- 
1.8.3.1

--
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

[PATCH v2 06/10] qla2xxx: Fix crash due to null pointer access.

[Himanshu Madhani]

From: Quinn Tran 

This patch fixes crash due to NULL pointer access.

Following stack trace will be seen.

[1469877.797315] Call Trace:
[1469877.799940]  [] qla2x00_mem_alloc+0xb09/0x10c0 [qla2xxx]
[1469877.806980]  [] qla2x00_probe_one+0x86a/0x1b50 [qla2xxx]
[1469877.814013]  [] ? __pm_runtime_resume+0x51/0xa0
[1469877.820265]  [] ? _raw_spin_lock_irqsave+0x25/0x90
[1469877.826776]  [] ? _raw_spin_unlock_irqrestore+0x6d/0x80
[1469877.833720]  [] ? preempt_count_sub+0xb1/0x100
[1469877.839885]  [] ? _raw_spin_unlock_irqrestore+0x4c/0x80
[1469877.846830]  [] local_pci_probe+0x4c/0xb0
[1469877.852562]  [] ? preempt_count_sub+0xb1/0x100
[1469877.858727]  [] pci_call_probe+0x89/0xb0

Cc: 
Signed-off-by: Quinn Tran 
Signed-off-by: Himanshu Madhani 
---
 drivers/scsi/qla2xxx/qla_os.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index 8521cfe..df57fb3 100644
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -3662,7 +3662,7 @@ void qla2x00_mark_device_lost(scsi_qla_host_t *vha, 
fc_port_t *fcport,
sizeof(struct ct6_dsd), 0,
SLAB_HWCACHE_ALIGN, NULL);
if (!ctx_cachep)
-   goto fail_free_gid_list;
+   goto fail_free_srb_mempool;
}
ha->ctx_mempool = mempool_create_slab_pool(SRB_MIN_REQ,
ctx_cachep);
@@ -3815,7 +3815,7 @@ void qla2x00_mark_device_lost(scsi_qla_host_t *vha, 
fc_port_t *fcport,
ha->loop_id_map = kzalloc(BITS_TO_LONGS(LOOPID_MAP_SIZE) * sizeof(long),
GFP_KERNEL);
if (!ha->loop_id_map)
-   goto fail_async_pd;
+   goto fail_loop_id_map;
else {
qla2x00_set_reserved_loop_ids(ha);
ql_dbg_pci(ql_dbg_init, ha->pdev, 0x0123,
@@ -3824,10 +3824,15 @@ void qla2x00_mark_device_lost(scsi_qla_host_t *vha, 
fc_port_t *fcport,
 
return 0;
 
+fail_loop_id_map:
+   dma_pool_free(ha->s_dma_pool, ha->async_pd, ha->async_pd_dma);
+   ha->async_pd = NULL;
 fail_async_pd:
dma_pool_free(ha->s_dma_pool, ha->ex_init_cb, ha->ex_init_cb_dma);
+   ha->ex_init_cb = NULL;
 fail_ex_init_cb:
kfree(ha->npiv_info);
+   ha->npiv_info = NULL;
 fail_npiv_info:
dma_free_coherent(>pdev->dev, ((*rsp)->length + 1) *
sizeof(response_t), (*rsp)->ring, (*rsp)->dma);
@@ -3851,6 +3856,14 @@ void qla2x00_mark_device_lost(scsi_qla_host_t *vha, 
fc_port_t *fcport,
dma_pool_free(ha->s_dma_pool, ha->ms_iocb, ha->ms_iocb_dma);
ha->ms_iocb = NULL;
ha->ms_iocb_dma = 0;
+
+   if (ha->sns_cmd) {
+   dma_free_coherent(>pdev->dev, sizeof(struct sns_cmd_pkt),
+   ha->sns_cmd, ha->sns_cmd_dma);
+   ha->sns_cmd_dma = 0;
+   ha->sns_cmd = NULL;
+   }
+
 fail_dma_pool:
if (IS_QLA82XX(ha) || ql2xenabledif) {
dma_pool_destroy(ha->fcp_cmnd_dma_pool);
@@ -3868,10 +3881,12 @@ void qla2x00_mark_device_lost(scsi_qla_host_t *vha, 
fc_port_t *fcport,
kfree(ha->nvram);
ha->nvram = NULL;
 fail_free_ctx_mempool:
-   mempool_destroy(ha->ctx_mempool);
+   if (ha->ctx_mempool)
+   mempool_destroy(ha->ctx_mempool);
ha->ctx_mempool = NULL;
 fail_free_srb_mempool:
-   mempool_destroy(ha->srb_mempool);
+   if (ha->srb_mempool)
+   mempool_destroy(ha->srb_mempool);
ha->srb_mempool = NULL;
 fail_free_gid_list:
dma_free_coherent(>pdev->dev, qla2x00_gid_list_size(ha),
-- 
1.8.3.1

--
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

[PATCH v2 04/10] qla2xxx: Reset reserved field in firmware options to 0.

[Himanshu Madhani]

During NVRAM initialization in target mode, reset reserved
fields in firmware options to Zero (BIT 15)

Signed-off-by: Himanshu Madhani 
Signed-off-by: Giridhar Malavali 
---
 drivers/scsi/qla2xxx/qla_target.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/qla2xxx/qla_target.c 
b/drivers/scsi/qla2xxx/qla_target.c
index b9c559c..5037b51 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -6539,6 +6539,14 @@ static void qlt_disable_vha(struct scsi_qla_host *vha)
 
/* Disable Full Login after LIP */
nv->host_p &= cpu_to_le32(~BIT_10);
+
+   /*
+* clear BIT 15 explicitly as we have seen at least
+* a couple of instances where this was set and this
+* was causing the firmware to not be initialized.
+*/
+   nv->firmware_options_1 &=
+   __constant_cpu_to_le32(~BIT_15);
/* Enable target PRLI control */
nv->firmware_options_2 |= cpu_to_le32(BIT_14);
} else {
@@ -6623,11 +6631,18 @@ static void qlt_disable_vha(struct scsi_qla_host *vha)
/* Disable ini mode, if requested */
if (!qla_ini_mode_enabled(vha))
nv->firmware_options_1 |= cpu_to_le32(BIT_5);
-
/* Disable Full Login after LIP */
nv->firmware_options_1 &= cpu_to_le32(~BIT_13);
/* Enable initial LIP */
nv->firmware_options_1 &= cpu_to_le32(~BIT_9);
+   /*
+* clear BIT 15 explicitly as we have seen at
+* least a couple of instances where this was set
+* and this was causing the firmware to not be
+* initialized.
+*/
+   nv->firmware_options_1 &=
+   __constant_cpu_to_le32(~BIT_15);
if (ql2xtgt_tape_enable)
/* Enable FC tape support */
nv->firmware_options_2 |= cpu_to_le32(BIT_12);
-- 
1.8.3.1

--
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

[PATCH v2 00/10] qla2xxx: Bug fixes for driver.

[Himanshu Madhani]

Hi Christoph, Bart,

Here's updated series of bug fixes for target code in the driver.
Please consider this for target-pending.

Changes from v1 --> v2

o Updated patches to remove braces. 
o Added description for the patch reqeusted.

Thanks,
Himanshu

Himanshu Madhani (3):
  qla2xxx: Include ATIO queue in firmware dump when in target mode
  qla2xxx: Set tcm_qla2xxx version to automatically track qla2xxx
version.
  qla2xxx: Reset reserved field in firmware options to 0.

Quinn Tran (7):
  qla2xxx: Fix wrong IOCB type assumption.
  qla2xxx: Collect additional information to debug fw dump.
  qla2xxx: Fix crash due to null pointer access.
  qla2xxx: Terminate exchange if corrputed.
  qla2xxx: Reduce exess wait during chip reset
  qla2xxx: Fix invalid handle erroneous message.
  qla2xxx: Disable Out-of-order processing by default in Firmware

 drivers/scsi/qla2xxx/qla_def.h |  3 ++-
 drivers/scsi/qla2xxx/qla_init.c|  4 +--
 drivers/scsi/qla2xxx/qla_isr.c |  4 +++
 drivers/scsi/qla2xxx/qla_mbx.c | 27 ++-
 drivers/scsi/qla2xxx/qla_os.c  | 23 +---
 drivers/scsi/qla2xxx/qla_target.c  | 55 +-
 drivers/scsi/qla2xxx/qla_target.h  | 22 ++-
 drivers/scsi/qla2xxx/qla_tmpl.c| 24 +
 drivers/scsi/qla2xxx/tcm_qla2xxx.c |  4 +--
 drivers/scsi/qla2xxx/tcm_qla2xxx.h |  1 -
 10 files changed, 131 insertions(+), 36 deletions(-)

-- 
1.8.3.1

--
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

[PATCH v2 02/10] qla2xxx: Include ATIO queue in firmware dump when in target mode

[Himanshu Madhani]

Include ATIO queue for ISP27XX when firmware dump is collected
for target mode.

Signed-off-by: Himanshu Madhani 
Signed-off-by: Giridhar Malavali 
---
 drivers/scsi/qla2xxx/qla_tmpl.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/scsi/qla2xxx/qla_tmpl.c b/drivers/scsi/qla2xxx/qla_tmpl.c
index 36935c9..d356ed0 100644
--- a/drivers/scsi/qla2xxx/qla_tmpl.c
+++ b/drivers/scsi/qla2xxx/qla_tmpl.c
@@ -433,6 +433,18 @@ static inline void (*qla27xx_read_vector(uint width))(void 
__iomem*, void *, ulo
count++;
}
}
+   } else if (QLA_TGT_MODE_ENABLED() &&
+   ent->t263.queue_type == T263_QUEUE_TYPE_ATIO) {
+   struct qla_hw_data *ha = vha->hw;
+   struct atio *atr = ha->tgt.atio_ring;
+
+   if (atr || !buf) {
+   length = ha->tgt.atio_q_length;
+   qla27xx_insert16(0, buf, len);
+   qla27xx_insert16(length, buf, len);
+   qla27xx_insertbuf(atr, length * sizeof(*atr), buf, len);
+   count++;
+   }
} else {
ql_dbg(ql_dbg_misc, vha, 0xd026,
"%s: unknown queue %x\n", __func__, ent->t263.queue_type);
@@ -676,6 +688,18 @@ static inline void (*qla27xx_read_vector(uint width))(void 
__iomem*, void *, ulo
count++;
}
}
+   } else if (QLA_TGT_MODE_ENABLED() &&
+   ent->t274.queue_type == T274_QUEUE_TYPE_ATIO_SHAD) {
+   struct qla_hw_data *ha = vha->hw;
+   struct atio *atr = ha->tgt.atio_ring_ptr;
+
+   if (atr || !buf) {
+   qla27xx_insert16(0, buf, len);
+   qla27xx_insert16(1, buf, len);
+   qla27xx_insert32(ha->tgt.atio_q_in ?
+   *ha->tgt.atio_q_in : 0, buf, len);
+   count++;
+   }
} else {
ql_dbg(ql_dbg_misc, vha, 0xd02f,
"%s: unknown queue %x\n", __func__, ent->t274.queue_type);
-- 
1.8.3.1

--
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

[PATCH v2 01/10] qla2xxx: Fix wrong IOCB type assumption.

[Himanshu Madhani]

From: Quinn Tran 

qlt_reset is called with Immedidate Notify IOCB only.
Current code wrongly cast it as ATIO IOCB.

Signed-off-by: Quinn Tran 
Signed-off-by: Himanshu Madhani 
---
 drivers/scsi/qla2xxx/qla_target.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_target.c 
b/drivers/scsi/qla2xxx/qla_target.c
index bff9689..b9c559c 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -668,11 +668,9 @@ static int qlt_reset(struct scsi_qla_host *vha, void 
*iocb, int mcmd)
 {
struct qla_hw_data *ha = vha->hw;
struct qla_tgt_sess *sess = NULL;
-   uint32_t unpacked_lun, lun = 0;
uint16_t loop_id;
int res = 0;
struct imm_ntfy_from_isp *n = (struct imm_ntfy_from_isp *)iocb;
-   struct atio_from_isp *a = (struct atio_from_isp *)iocb;
unsigned long flags;
 
loop_id = le16_to_cpu(n->u.isp24.nport_handle);
@@ -725,11 +723,7 @@ static int qlt_reset(struct scsi_qla_host *vha, void 
*iocb, int mcmd)
"loop_id %d)\n", vha->host_no, sess, sess->port_name,
mcmd, loop_id);
 
-   lun = a->u.isp24.fcp_cmnd.lun;
-   unpacked_lun = scsilun_to_int((struct scsi_lun *));
-
-   return qlt_issue_task_mgmt(sess, unpacked_lun, mcmd,
-   iocb, QLA24XX_MGMT_SEND_NACK);
+   return qlt_issue_task_mgmt(sess, 0, mcmd, iocb, QLA24XX_MGMT_SEND_NACK);
 }
 
 /* ha->tgt.sess_lock supposed to be held on entry */
-- 
1.8.3.1

--
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

[PATCH v2 03/10] qla2xxx: Set tcm_qla2xxx version to automatically track qla2xxx version.

[Himanshu Madhani]

Signed-off-by: Himanshu Madhani 
Signed-off-by: Giridhar Malavali 
---
 drivers/scsi/qla2xxx/tcm_qla2xxx.c | 4 ++--
 drivers/scsi/qla2xxx/tcm_qla2xxx.h | 1 -
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/qla2xxx/tcm_qla2xxx.c 
b/drivers/scsi/qla2xxx/tcm_qla2xxx.c
index 6643f6f..d925910 100644
--- a/drivers/scsi/qla2xxx/tcm_qla2xxx.c
+++ b/drivers/scsi/qla2xxx/tcm_qla2xxx.c
@@ -1800,7 +1800,7 @@ static ssize_t tcm_qla2xxx_wwn_version_show(struct 
config_item *item,
 {
return sprintf(page,
"TCM QLOGIC QLA2XXX NPIV capable fabric module %s on %s/%s on "
-   UTS_RELEASE"\n", TCM_QLA2XXX_VERSION, utsname()->sysname,
+   UTS_RELEASE"\n", QLA2XXX_VERSION, utsname()->sysname,
utsname()->machine);
 }
 
@@ -1906,7 +1906,7 @@ static int tcm_qla2xxx_register_configfs(void)
int ret;
 
pr_debug("TCM QLOGIC QLA2XXX fabric module %s on %s/%s on "
-   UTS_RELEASE"\n", TCM_QLA2XXX_VERSION, utsname()->sysname,
+   UTS_RELEASE"\n", QLA2XXX_VERSION, utsname()->sysname,
utsname()->machine);
 
ret = target_register_template(_qla2xxx_ops);
diff --git a/drivers/scsi/qla2xxx/tcm_qla2xxx.h 
b/drivers/scsi/qla2xxx/tcm_qla2xxx.h
index 37e026a..cf8430b 100644
--- a/drivers/scsi/qla2xxx/tcm_qla2xxx.h
+++ b/drivers/scsi/qla2xxx/tcm_qla2xxx.h
@@ -1,7 +1,6 @@
 #include 
 #include 
 
-#define TCM_QLA2XXX_VERSION"v0.1"
 /* length of ASCII WWPNs including pad */
 #define TCM_QLA2XXX_NAMELEN32
 /*
-- 
1.8.3.1

--
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

[patch 04/10] scsi/bnx2i: Convert to hotplug state machine

[Thomas Gleixner]

From: Sebastian Andrzej Siewior 

Install the callbacks via the state machine. No functional change.

This is the minimal fixup so we can remove the hotplug notifier mess
completely.

The real rework of this driver to use work queues is still stuck in
review/testing on the SCSI mailing list.

Signed-off-by: Sebastian Andrzej Siewior 
Cc: Martin K. Petersen 
Cc: James E.J. Bottomley 
Cc: linux-scsi@vger.kernel.org
Cc: Chad Dupuis 
Cc: qlogic-storage-upstr...@qlogic.com
Cc: Johannes Thumshirn 
Cc: Christoph Hellwig 
Signed-off-by: Thomas Gleixner 

---
 drivers/scsi/bnx2i/bnx2i_init.c |   80 +++-
 include/linux/cpuhotplug.h  |1 
 2 files changed, 32 insertions(+), 49 deletions(-)

--- a/drivers/scsi/bnx2i/bnx2i_init.c
+++ b/drivers/scsi/bnx2i/bnx2i_init.c
@@ -70,14 +70,6 @@ u64 iscsi_error_mask = 0x00;
 
 DEFINE_PER_CPU(struct bnx2i_percpu_s, bnx2i_percpu);
 
-static int bnx2i_cpu_callback(struct notifier_block *nfb,
- unsigned long action, void *hcpu);
-/* notification function for CPU hotplug events */
-static struct notifier_block bnx2i_cpu_notifier = {
-   .notifier_call = bnx2i_cpu_callback,
-};
-
-
 /**
  * bnx2i_identify_device - identifies NetXtreme II device type
  * @hba:   Adapter structure pointer
@@ -461,41 +453,21 @@ static void bnx2i_percpu_thread_destroy(
kthread_stop(thread);
 }
 
-
-/**
- * bnx2i_cpu_callback - Handler for CPU hotplug events
- *
- * @nfb:   The callback data block
- * @action:The event triggering the callback
- * @hcpu:  The index of the CPU that the event is for
- *
- * This creates or destroys per-CPU data for iSCSI
- *
- * Returns NOTIFY_OK always.
- */
-static int bnx2i_cpu_callback(struct notifier_block *nfb,
- unsigned long action, void *hcpu)
+static int bnx2i_cpu_online(unsigned int cpu)
 {
-   unsigned cpu = (unsigned long)hcpu;
+   pr_info("bnx2i: CPU %x online: Create Rx thread\n", cpu);
+   bnx2i_percpu_thread_create(cpu);
+   return 0;
+}
 
-   switch (action) {
-   case CPU_ONLINE:
-   case CPU_ONLINE_FROZEN:
-   printk(KERN_INFO "bnx2i: CPU %x online: Create Rx thread\n",
-   cpu);
-   bnx2i_percpu_thread_create(cpu);
-   break;
-   case CPU_DEAD:
-   case CPU_DEAD_FROZEN:
-   printk(KERN_INFO "CPU %x offline: Remove Rx thread\n", cpu);
-   bnx2i_percpu_thread_destroy(cpu);
-   break;
-   default:
-   break;
-   }
-   return NOTIFY_OK;
+static int bnx2i_cpu_dead(unsigned int cpu)
+{
+   pr_info("CPU %x offline: Remove Rx thread\n", cpu);
+   bnx2i_percpu_thread_destroy(cpu);
+   return 0;
 }
 
+static enum cpuhp_state bnx2i_online_state;
 
 /**
  * bnx2i_mod_init - module init entry point
@@ -539,18 +511,28 @@ static int __init bnx2i_mod_init(void)
p->iothread = NULL;
}
 
-   cpu_notifier_register_begin();
+   get_online_cpus();
 
for_each_online_cpu(cpu)
bnx2i_percpu_thread_create(cpu);
 
-   /* Initialize per CPU interrupt thread */
-   __register_hotcpu_notifier(_cpu_notifier);
-
-   cpu_notifier_register_done();
-
+   err = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
+  "scsi/bnx2i:online",
+  bnx2i_cpu_online, NULL);
+   if (err < 0)
+   goto remove_threads;
+   bnx2i_online_state = err;
+
+   cpuhp_setup_state_nocalls(CPUHP_SCSI_BNX2I_DEAD, "scsi/bnx2i:dead",
+ NULL, bnx2i_cpu_dead);
+   put_online_cpus();
return 0;
 
+remove_threads:
+   for_each_online_cpu(cpu)
+   bnx2i_percpu_thread_destroy(cpu);
+   put_online_cpus();
+   cnic_unregister_driver(CNIC_ULP_ISCSI);
 unreg_xport:
iscsi_unregister_transport(_iscsi_transport);
 out:
@@ -587,14 +569,14 @@ static void __exit bnx2i_mod_exit(void)
}
mutex_unlock(_dev_lock);
 
-   cpu_notifier_register_begin();
+   get_online_cpus();
 
for_each_online_cpu(cpu)
bnx2i_percpu_thread_destroy(cpu);
 
-   __unregister_hotcpu_notifier(_cpu_notifier);
-
-   cpu_notifier_register_done();
+   cpuhp_remove_state_nocalls(bnx2i_online_state);
+   cpuhp_remove_state_nocalls(CPUHP_SCSI_BNX2I_DEAD);
+   put_online_cpus();
 
iscsi_unregister_transport(_iscsi_transport);
cnic_unregister_driver(CNIC_ULP_ISCSI);
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -42,6 +42,7 @@ enum cpuhp_state {
CPUHP_PCI_XGENE_DEAD,
CPUHP_IOMMU_INTEL_DEAD,
CPUHP_SCSI_BNX2FC_DEAD,
+   

[patch 03/10] scsi/bnx2fc: Convert to hotplug state machine

[Thomas Gleixner]

From: Sebastian Andrzej Siewior 

Install the callbacks via the state machine. No functional change.

This is the minimal fixup so we can remove the hotplug notifier mess
completely.

The real rework of this driver to use work queues is still stuck in
review/testing on the SCSI mailing list.

Signed-off-by: Sebastian Andrzej Siewior 
Cc: Martin K. Petersen 
Cc: James E.J. Bottomley 
Cc: linux-scsi@vger.kernel.org
Cc: Chad Dupuis 
Cc: qlogic-storage-upstr...@qlogic.com
Cc: Johannes Thumshirn 
Cc: Christoph Hellwig 
Signed-off-by: Thomas Gleixner 

---
 drivers/scsi/bnx2fc/bnx2fc_fcoe.c |   81 +++---
 include/linux/cpuhotplug.h|1 
 2 files changed, 35 insertions(+), 47 deletions(-)

--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -127,13 +127,6 @@ module_param_named(log_fka, bnx2fc_log_f
 MODULE_PARM_DESC(log_fka, " Print message to kernel log when fcoe is "
"initiating a FIP keep alive when debug logging is enabled.");
 
-static int bnx2fc_cpu_callback(struct notifier_block *nfb,
-unsigned long action, void *hcpu);
-/* notification function for CPU hotplug events */
-static struct notifier_block bnx2fc_cpu_notifier = {
-   .notifier_call = bnx2fc_cpu_callback,
-};
-
 static inline struct net_device *bnx2fc_netdev(const struct fc_lport *lport)
 {
return ((struct bnx2fc_interface *)
@@ -2622,37 +2615,19 @@ static void bnx2fc_percpu_thread_destroy
kthread_stop(thread);
 }
 
-/**
- * bnx2fc_cpu_callback - Handler for CPU hotplug events
- *
- * @nfb:The callback data block
- * @action: The event triggering the callback
- * @hcpu:   The index of the CPU that the event is for
- *
- * This creates or destroys per-CPU data for fcoe
- *
- * Returns NOTIFY_OK always.
- */
-static int bnx2fc_cpu_callback(struct notifier_block *nfb,
-unsigned long action, void *hcpu)
+
+static int bnx2fc_cpu_online(unsigned int cpu)
 {
-   unsigned cpu = (unsigned long)hcpu;
+   printk(PFX "CPU %x online: Create Rx thread\n", cpu);
+   bnx2fc_percpu_thread_create(cpu);
+   return 0;
+}
 
-   switch (action) {
-   case CPU_ONLINE:
-   case CPU_ONLINE_FROZEN:
-   printk(PFX "CPU %x online: Create Rx thread\n", cpu);
-   bnx2fc_percpu_thread_create(cpu);
-   break;
-   case CPU_DEAD:
-   case CPU_DEAD_FROZEN:
-   printk(PFX "CPU %x offline: Remove Rx thread\n", cpu);
-   bnx2fc_percpu_thread_destroy(cpu);
-   break;
-   default:
-   break;
-   }
-   return NOTIFY_OK;
+static int bnx2fc_cpu_dead(unsigned int cpu)
+{
+   printk(PFX "CPU %x offline: Remove Rx thread\n", cpu);
+   bnx2fc_percpu_thread_destroy(cpu);
+   return 0;
 }
 
 static int bnx2fc_slave_configure(struct scsi_device *sdev)
@@ -2664,6 +2639,8 @@ static int bnx2fc_slave_configure(struct
return 0;
 }
 
+static enum cpuhp_state bnx2fc_online_state;
+
 /**
  * bnx2fc_mod_init - module init entry point
  *
@@ -2724,21 +2701,31 @@ static int __init bnx2fc_mod_init(void)
spin_lock_init(>fp_work_lock);
}
 
-   cpu_notifier_register_begin();
+   get_online_cpus();
 
-   for_each_online_cpu(cpu) {
+   for_each_online_cpu(cpu)
bnx2fc_percpu_thread_create(cpu);
-   }
 
-   /* Initialize per CPU interrupt thread */
-   __register_hotcpu_notifier(_cpu_notifier);
-
-   cpu_notifier_register_done();
+   rc = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
+  "scsi/bnx2fc:online",
+  bnx2fc_cpu_online, NULL);
+   if (rc < 0)
+   goto stop_threads;
+   bnx2fc_online_state = rc;
+
+   cpuhp_setup_state_nocalls(CPUHP_SCSI_BNX2FC_DEAD, "scsi/bnx2fc:dead",
+ NULL, bnx2fc_cpu_dead);
+   put_online_cpus();
 
cnic_register_driver(CNIC_ULP_FCOE, _cnic_cb);
 
return 0;
 
+stop_threads:
+   for_each_online_cpu(cpu)
+   bnx2fc_percpu_thread_destroy(cpu);
+   put_online_cpus();
+   kthread_stop(l2_thread);
 free_wq:
destroy_workqueue(bnx2fc_wq);
 release_bt:
@@ -2797,16 +2784,16 @@ static void __exit bnx2fc_mod_exit(void)
if (l2_thread)
kthread_stop(l2_thread);
 
-   cpu_notifier_register_begin();
-
+   get_online_cpus();
/* Destroy per cpu threads */
for_each_online_cpu(cpu) {
bnx2fc_percpu_thread_destroy(cpu);
}
 
-   __unregister_hotcpu_notifier(_cpu_notifier);
+   cpuhp_remove_state_nocalls(bnx2fc_online_state);
+   cpuhp_remove_state_nocalls(CPUHP_SCSI_BNX2FC_DEAD);
 
-  

Re: [PATCH] ibmvscsi: add write memory barrier to CRQ processing

[Tyrel Datwyler]

On 12/09/2016 01:20 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2016-12-07 at 17:31 -0600, Tyrel Datwyler wrote:
>> The first byte of each CRQ entry is used to indicate whether an entry is
>> a valid response or free for the VIOS to use. After processing a
>> response the driver sets the valid byte to zero to indicate the entry is
>> now free to be reused. Add a memory barrier after this write to ensure
>> no other stores are reordered when updating the valid byte.
> 
> Which "other stores" specifically ? This smells fishy without that
> precision. It's important to always understand what exactly barriers
> order with.

So, this patch initially came about while chasing a data integrity issue
based on the observation that we were already doing this same write
barrier in the virtual fibre channel driver.

However, the more I stare at it I agree it does seem fishy and I can't
see any other stores that we need to order with here. In terms of the
16byte CRQ entries we only ever write to the first byte as a sort of
doorbell to tell the VIOS that we have processed the data and the entry
is free to be re-used. The remainder of the CRQ is only ever read from.

The wmb() in the ibmvfc driver was part of a commit from Brian that also
involved a necessary rmb() that prevented stale data from load
re-ordering by ensuring that a read from the first byte completed and
contained a valid value prior to doing any other reads of the CRQ entry.

I'd have to defer to Brian as to whether he remembers a legitimate
reason for the wmb().

-Tyrel

> 
> Cheers,
> Ben.
> 
>> Signed-off-by: Tyrel Datwyler 
>> ---
>>  drivers/scsi/ibmvscsi/ibmvscsi.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c 
>> b/drivers/scsi/ibmvscsi/ibmvscsi.c
>> index d9534ee..2f5b07e 100644
>> --- a/drivers/scsi/ibmvscsi/ibmvscsi.c
>> +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
>> @@ -232,6 +232,7 @@ static void ibmvscsi_task(void *data)
>>> while ((crq = crq_queue_next_crq(>queue)) != NULL) {
>>> ibmvscsi_handle_crq(crq, hostdata);
>>> crq->valid = VIOSRP_CRQ_FREE;
>>> +   wmb();
>>> }
>>  
>>> vio_enable_interrupts(vdev);
>> @@ -240,6 +241,7 @@ static void ibmvscsi_task(void *data)
>>> vio_disable_interrupts(vdev);
>>> ibmvscsi_handle_crq(crq, hostdata);
>>> crq->valid = VIOSRP_CRQ_FREE;
>>> +   wmb();
>>> } else {
>>> done = 1;
>>> }
> 
> --
> 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
> 

--
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: [PATCH] snic: Return error code on memory allocation failure

[Ewan D. Milne]

On Wed, 2016-12-21 at 14:45 +0100, Burak Ok wrote:
> If a call to mempool_create_slab_pool() in snic_probe() returns NULL,
> return -ENOMEM to indicate failure. mempool_creat_slab_pool() only fails if
> it cannot allocate memory.
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=189061
> 
> Reported-by: bianpan2...@ruc.edu.cn
> Signed-off-by: Burak Ok 
> Signed-off-by: Andreas Schaertl 
> ---
>  drivers/scsi/snic/snic_main.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/scsi/snic/snic_main.c b/drivers/scsi/snic/snic_main.c
> index 396b32d..7cf70aa 100644
> --- a/drivers/scsi/snic/snic_main.c
> +++ b/drivers/scsi/snic/snic_main.c
> @@ -591,6 +591,7 @@ snic_probe(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
>   if (!pool) {
>   SNIC_HOST_ERR(shost, "dflt sgl pool creation failed\n");
>  
> + ret = -ENOMEM;
>   goto err_free_res;
>   }
>  
> @@ -601,6 +602,7 @@ snic_probe(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
>   if (!pool) {
>   SNIC_HOST_ERR(shost, "max sgl pool creation failed\n");
>  
> + ret = -ENOMEM;
>   goto err_free_dflt_sgl_pool;
>   }
>  
> @@ -611,6 +613,7 @@ snic_probe(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
>   if (!pool) {
>   SNIC_HOST_ERR(shost, "snic tmreq info pool creation failed.\n");
>  
> + ret = -ENOMEM;
>   goto err_free_max_sgl_pool;
>   }
>  

Reviewed-by: Ewan D. Milne 


--
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: [PATCH] snic: Return error code on memory allocation failure

[Narsimhulu Musini (nmusini)]

On 21/12/16 7:15 pm, "Burak Ok"  wrote:

>If a call to mempool_create_slab_pool() in snic_probe() returns NULL,
>return -ENOMEM to indicate failure. mempool_creat_slab_pool() only fails
>if
>it cannot allocate memory.
>
>https://bugzilla.kernel.org/show_bug.cgi?id=189061
>
>Reported-by: bianpan2...@ruc.edu.cn
>Signed-off-by: Burak Ok 
>Signed-off-by: Andreas Schaertl 
Acked-by: Narsimhulu Musini 
>---
> drivers/scsi/snic/snic_main.c | 3 +++
> 1 file changed, 3 insertions(+)
>
>diff --git a/drivers/scsi/snic/snic_main.c b/drivers/scsi/snic/snic_main.c
>index 396b32d..7cf70aa 100644
>--- a/drivers/scsi/snic/snic_main.c
>+++ b/drivers/scsi/snic/snic_main.c
>@@ -591,6 +591,7 @@ snic_probe(struct pci_dev *pdev, const struct
>pci_device_id *ent)
>   if (!pool) {
>   SNIC_HOST_ERR(shost, "dflt sgl pool creation failed\n");
> 
>+  ret = -ENOMEM;
>   goto err_free_res;
>   }
> 
>@@ -601,6 +602,7 @@ snic_probe(struct pci_dev *pdev, const struct
>pci_device_id *ent)
>   if (!pool) {
>   SNIC_HOST_ERR(shost, "max sgl pool creation failed\n");
> 
>+  ret = -ENOMEM;
>   goto err_free_dflt_sgl_pool;
>   }
> 
>@@ -611,6 +613,7 @@ snic_probe(struct pci_dev *pdev, const struct
>pci_device_id *ent)
>   if (!pool) {
>   SNIC_HOST_ERR(shost, "snic tmreq info pool creation failed.\n");
> 
>+  ret = -ENOMEM;
>   goto err_free_max_sgl_pool;
>   }
> 
>-- 
>2.7.4
>

--
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: JMS56x not working reliably with uas driver

[Oliver Neukum]

On Wed, 2016-12-21 at 18:17 +0530, George Cherian wrote:
> [  843.149653] scsi host5: uas_post_reset: alloc streams error -19
> after 
> reset

That would mean the endpoints are gone. Which is odd.

> [  843.157268] sd 5:0:0:0: [sdb] Synchronizing SCSI cache

Could you try the attached patch and do a SCSI log of the enumeration?

Regards
Oliver

From d4ddac88bbf9cb15e7d8638582f96d31e245f15b Mon Sep 17 00:00:00 2001
From: Oliver Neukum 
Date: Wed, 21 Dec 2016 15:34:54 +0100
Subject: [PATCH] uas: device crashes on reset

We avoid resetting it.

Signed-off-by: Oliver Neukum 
---
 drivers/usb/core/quirks.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index d2e50a2..52483fb 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -194,6 +194,8 @@ static const struct usb_device_id usb_quirk_list[] = {
 	{ USB_DEVICE(0x1532, 0x0116), .driver_info =
 			USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
 
+	{ USB_DEVICE(0x152d, 0x9561), .driver_info = USB_QUIRK_RESET },
+
 	/* BUILDWIN Photo Frame */
 	{ USB_DEVICE(0x1908, 0x1315), .driver_info =
 			USB_QUIRK_HONOR_BNUMINTERFACES },
-- 
2.1.4

Re: JMS56x not working reliably with uas driver

[George Cherian]

On 12/21/2016 05:12 PM, Oliver Neukum wrote:

On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote:

Hi Oliver,

I was working with this JMicron device and using the uas driver.
I am seeing the following 2 issues.

1) On connect I see the following messages.


Thanks. Do you want to submit it to Greg?
The patch is fine.

Yes please!!!




2) On disconnect I am seeing the following issue

   scsi host4: uas_post_reset: alloc streams error -19 after reset
   sd 4:0:0:0: [sdb] Synchronizing SCSI cache

This is more fatal because after these messages the USB port becomes
unusable. Even an lsusb invocation hangs for ever.


Ouch. That points to a logic error. We should not reset if
a device is gone.
Could you send dmesg of such a case?

here is the dmesg!!
[  203.475382] usb 4-1.3: new SuperSpeed USB device number 3 using xhci_hcd
[  203.496172] usb 4-1.3: New USB device found, idVendor=152d, 
idProduct=9561
[  203.503037] usb 4-1.3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=5

[  203.510352] usb 4-1.3: Product: JMS56x Series
[  203.514698] usb 4-1.3: Manufacturer: JMicron
[  203.518966] usb 4-1.3: SerialNumber: 
[  203.594383] usbcore: registered new interface driver usb-storage
[  203.612425] scsi host4: uas
[  203.615418] usbcore: registered new interface driver uas
[  203.620979] scsi 4:0:0:0: Direct-Access ST4000NM 0033-9ZM170 
 0001 PQ: 0 ANSI: 6

[  203.630240] sd 4:0:0:0: Attached scsi generic sg1 type 0
[  203.630382] sd 4:0:0:0: [sdb] 7814037168 512-byte logical blocks: 
(4.00 TB/3.63 TiB)

[  203.631338] sd 4:0:0:0: [sdb] Write Protect is off
[  203.631342] sd 4:0:0:0: [sdb] Mode Sense: 67 00 10 08
[  203.631734] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: 
enabled, supports DPO and FUA
[  203.631899] xhci_hcd :00:11.0: ERROR Transfer event for disabled 
endpoint or incorrect stream ring
[  203.631904] xhci_hcd :00:11.0: @001f610a1c10  
 1b00 03078001 state 14 ep_info 9403

[  203.631906] xhci_hcd :00:11.0: No epring
[  203.674546]  sdb: sdb1
[  203.676639] sd 4:0:0:0: [sdb] Attached SCSI disk
[  213.222913] scsi host4: uas_post_reset: alloc streams error -19 after 
reset

[  213.230548] sd 4:0:0:0: [sdb] Synchronizing SCSI cache

Above is the dmesg without the unusual_uas patch applied.
Do you need me to enable any specific dev_dbg and then the dmesg output?



Regards
Oliver



--
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: [PATCH] scsi: do not requeue requests unaligned with device sector size

[Martin K. Petersen]

> "Mauricio" == Mauricio Faria de Oliveira  
> writes:

Mauricio,

Mauricio> When a SCSI command (e.g., read operation) is partially
Mauricio> completed with good status and residual bytes (i.e., not all
Mauricio> the bytes from the specified transfer length were transferred)
Mauricio> the SCSI midlayer will update the request/bios with the
Mauricio> completed bytes and requeue the request in order to complete
Mauricio> the remainder/pending bytes.

I agree with Christoph and Hannes. Some of this falls into the gray area
that's outside of the T10 spec (HBA programming interface guarantees)
but it seems like a deficiency in the HBA to report a byte count that's
not a multiple of the logical block size. A block can't be partially
written. Either it made it or it didn't. Regardless of how the I/O is
being broken up into frames at the transport level and at which offset
the transfer was interrupted.

I am also not a fan of the delayed retry stuff which seems somewhat
orthogonal to the problem you're describing.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
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

[PATCH] snic: Return error code on memory allocation failure

[Burak Ok]

If a call to mempool_create_slab_pool() in snic_probe() returns NULL,
return -ENOMEM to indicate failure. mempool_creat_slab_pool() only fails if
it cannot allocate memory.

https://bugzilla.kernel.org/show_bug.cgi?id=189061

Reported-by: bianpan2...@ruc.edu.cn
Signed-off-by: Burak Ok 
Signed-off-by: Andreas Schaertl 
---
 drivers/scsi/snic/snic_main.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/snic/snic_main.c b/drivers/scsi/snic/snic_main.c
index 396b32d..7cf70aa 100644
--- a/drivers/scsi/snic/snic_main.c
+++ b/drivers/scsi/snic/snic_main.c
@@ -591,6 +591,7 @@ snic_probe(struct pci_dev *pdev, const struct pci_device_id 
*ent)
if (!pool) {
SNIC_HOST_ERR(shost, "dflt sgl pool creation failed\n");
 
+   ret = -ENOMEM;
goto err_free_res;
}
 
@@ -601,6 +602,7 @@ snic_probe(struct pci_dev *pdev, const struct pci_device_id 
*ent)
if (!pool) {
SNIC_HOST_ERR(shost, "max sgl pool creation failed\n");
 
+   ret = -ENOMEM;
goto err_free_dflt_sgl_pool;
}
 
@@ -611,6 +613,7 @@ snic_probe(struct pci_dev *pdev, const struct pci_device_id 
*ent)
if (!pool) {
SNIC_HOST_ERR(shost, "snic tmreq info pool creation failed.\n");
 
+   ret = -ENOMEM;
goto err_free_max_sgl_pool;
}
 
-- 
2.7.4

--
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: [PATCH] scsi: qla4xxx: Use dma_pool_zalloc

[Souptick Joarder]

On Wed, Dec 21, 2016 at 5:13 PM, Javali, Nilesh
 wrote:
>
>
> On 13/12/16, 6:35 PM, "Souptick Joarder"  wrote:
>
>>On Tue, Dec 13, 2016 at 4:11 PM, Javali, Nilesh
>> wrote:
>>>
>>>
>>> On 12/12/16, 10:16 AM, "linux-scsi-ow...@vger.kernel.org on behalf of
>>> Souptick Joarder" >> jrdr.li...@gmail.com> wrote:
>>>
On Wed, Dec 7, 2016 at 1:53 AM, Souptick Joarder 
wrote:
> We should use dma_pool_zalloc instead of dma_pool_alloc/memset
>
> Signed-off-by: Souptick joarder 
> ---
>  drivers/scsi/qla4xxx/ql4_mbx.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/qla4xxx/ql4_mbx.c
>b/drivers/scsi/qla4xxx/ql4_mbx.c
> index c291fdf..f2edfd7 100644
> --- a/drivers/scsi/qla4xxx/ql4_mbx.c
> +++ b/drivers/scsi/qla4xxx/ql4_mbx.c
> @@ -1587,12 +1587,11 @@ int qla4xxx_get_chap(struct scsi_qla_host *ha,
>char *username, char *password,
> struct ql4_chap_table *chap_table;
> dma_addr_t chap_dma;
>
> -   chap_table = dma_pool_alloc(ha->chap_dma_pool, GFP_KERNEL,
>_dma);
> +   chap_table = dma_pool_zalloc(ha->chap_dma_pool, GFP_KERNEL,
>_dma);
> if (chap_table == NULL)
> return -ENOMEM;
>
> chap_size = sizeof(struct ql4_chap_table);
> -   memset(chap_table, 0, chap_size);
>
> if (is_qla40XX(ha))
> offset = FLASH_CHAP_OFFSET | (idx * chap_size);
> --
> 1.9.1
>

Any comment on this patch?
>>>
>>> There are multiple other places where dma_pool_alloc needs to be
>>>replaced
>>> by dma_pool_zalloc.
>>
>>
>> are you asking to do this for SCSI subsystem?
>> If yes, I can do that.
>>
>>>
>>> Can you please take care within a single patch.
>>
>> But the same changes are applicable in other subsystems as well.
>> I think I shouldn't send those changes in a single patch as
>>maintainers are different
>> for different modules.
>
> I'm referring to multiple other files within qla4xxx source which uses
> dma_pool_alloc.
> The current patch takes care only of ql4_mbx.c and qla4xxx_get_chap
> function.
> There is qla4xxx_set_chap function as well. Also ql4_init.c and ql4_os.c
> files also use dma_pool_alloc.
> I was requesting to make all these changes related to qla4xxx module
> within a single patch.

Well I will do that.
>
> Thanks,
> Nilesh
>
--
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: JMS56x not working reliably with uas driver

[George Cherian]

On 12/21/2016 05:50 PM, Hans de Goede wrote:

Hi,

On 21-12-16 13:07, George Cherian wrote:



On 12/21/2016 05:12 PM, Oliver Neukum wrote:

On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote:

Hi Oliver,

I was working with this JMicron device and using the uas driver.
I am seeing the following 2 issues.

1) On connect I see the following messages.


Thanks. Do you want to submit it to Greg?
The patch is fine.

Yes please!!!




2) On disconnect I am seeing the following issue

   scsi host4: uas_post_reset: alloc streams error -19 after reset
   sd 4:0:0:0: [sdb] Synchronizing SCSI cache

This is more fatal because after these messages the USB port becomes
unusable. Even an lsusb invocation hangs for ever.


Ouch. That points to a logic error. We should not reset if
a device is gone.
Could you send dmesg of such a case?

here is the dmesg!!
[  203.475382] usb 4-1.3: new SuperSpeed USB device number 3 using
xhci_hcd
[  203.496172] usb 4-1.3: New USB device found, idVendor=152d,
idProduct=9561
[  203.503037] usb 4-1.3: New USB device strings: Mfr=1, Product=2,
SerialNumber=5
[  203.510352] usb 4-1.3: Product: JMS56x Series
[  203.514698] usb 4-1.3: Manufacturer: JMicron
[  203.518966] usb 4-1.3: SerialNumber: 
[  203.594383] usbcore: registered new interface driver usb-storage
[  203.612425] scsi host4: uas
[  203.615418] usbcore: registered new interface driver uas
[  203.620979] scsi 4:0:0:0: Direct-Access ST4000NM 0033-9ZM170
0001 PQ: 0 ANSI: 6
[  203.630240] sd 4:0:0:0: Attached scsi generic sg1 type 0
[  203.630382] sd 4:0:0:0: [sdb] 7814037168 512-byte logical blocks:
(4.00 TB/3.63 TiB)
[  203.631338] sd 4:0:0:0: [sdb] Write Protect is off
[  203.631342] sd 4:0:0:0: [sdb] Mode Sense: 67 00 10 08
[  203.631734] sd 4:0:0:0: [sdb] Write cache: enabled, read cache:
enabled, supports DPO and FUA
[  203.631899] xhci_hcd :00:11.0: ERROR Transfer event for
disabled endpoint or incorrect stream ring
[  203.631904] xhci_hcd :00:11.0: @001f610a1c10 
 1b00 03078001 state 14 ep_info 9403
[  203.631906] xhci_hcd :00:11.0: No epring
[  203.674546]  sdb: sdb1
[  203.676639] sd 4:0:0:0: [sdb] Attached SCSI disk
[  213.222913] scsi host4: uas_post_reset: alloc streams error -19
after reset
[  213.230548] sd 4:0:0:0: [sdb] Synchronizing SCSI cache

Above is the dmesg without the unusual_uas patch applied.
Do you need me to enable any specific dev_dbg and then the dmesg output?


Can you get us a dmesg with the unusual_uas patch applied? Usually once
things go foobar because
of issue-ing a command which the device does not understand, more things
typically come down
as both the device and the host may be in an undefined state then.


Here is the lsusb -t

lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 3: Dev 4, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M

lsusb
Bus 003 Device 002: ID 0bda:5401 Realtek Semiconductor Corp. RTL 8153 
USB 3.0 hub with gigabit ethernet

Bus 004 Device 002: ID 0bda:0401 Realtek Semiconductor Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 004: ID 152d:9561 JMicron Technology Corp. / JMicron USA 
Technology Corp.

lsusb -v
Bus 004 Device 004: ID 152d:9561 JMicron Technology Corp. / JMicron USA 
Technology Corp.

Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 9
  idVendor   0x152d JMicron Technology Corp. / JMicron USA 
Technology Corp.

  idProduct  0x9561
  bcdDevice0.01
  iManufacturer   1 JMicron
  iProduct2 JMS56x Series
  iSerial 5 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  121
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  4 USB Mass Storage
bmAttributes 0xc0
  Self Powered
MaxPower2mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 8 Mass 

[Bug 176951] boot fails unless acpi=off Acer Travelmate X-349

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=176951

--- Comment #9 from Martin Goyot  ---
Can now confirm. Updated Bios, can now run the x64 version.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
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: JMS56x not working reliably with uas driver

[Hans de Goede]

Hi,

On 21-12-16 13:07, George Cherian wrote:



On 12/21/2016 05:12 PM, Oliver Neukum wrote:

On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote:

Hi Oliver,

I was working with this JMicron device and using the uas driver.
I am seeing the following 2 issues.

1) On connect I see the following messages.


Thanks. Do you want to submit it to Greg?
The patch is fine.

Yes please!!!




2) On disconnect I am seeing the following issue

   scsi host4: uas_post_reset: alloc streams error -19 after reset
   sd 4:0:0:0: [sdb] Synchronizing SCSI cache

This is more fatal because after these messages the USB port becomes
unusable. Even an lsusb invocation hangs for ever.


Ouch. That points to a logic error. We should not reset if
a device is gone.
Could you send dmesg of such a case?

here is the dmesg!!
[  203.475382] usb 4-1.3: new SuperSpeed USB device number 3 using xhci_hcd
[  203.496172] usb 4-1.3: New USB device found, idVendor=152d, idProduct=9561
[  203.503037] usb 4-1.3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=5
[  203.510352] usb 4-1.3: Product: JMS56x Series
[  203.514698] usb 4-1.3: Manufacturer: JMicron
[  203.518966] usb 4-1.3: SerialNumber: 
[  203.594383] usbcore: registered new interface driver usb-storage
[  203.612425] scsi host4: uas
[  203.615418] usbcore: registered new interface driver uas
[  203.620979] scsi 4:0:0:0: Direct-Access ST4000NM 0033-9ZM170  0001 PQ: 0 
ANSI: 6
[  203.630240] sd 4:0:0:0: Attached scsi generic sg1 type 0
[  203.630382] sd 4:0:0:0: [sdb] 7814037168 512-byte logical blocks: (4.00 
TB/3.63 TiB)
[  203.631338] sd 4:0:0:0: [sdb] Write Protect is off
[  203.631342] sd 4:0:0:0: [sdb] Mode Sense: 67 00 10 08
[  203.631734] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, 
supports DPO and FUA
[  203.631899] xhci_hcd :00:11.0: ERROR Transfer event for disabled 
endpoint or incorrect stream ring
[  203.631904] xhci_hcd :00:11.0: @001f610a1c10   
1b00 03078001 state 14 ep_info 9403
[  203.631906] xhci_hcd :00:11.0: No epring
[  203.674546]  sdb: sdb1
[  203.676639] sd 4:0:0:0: [sdb] Attached SCSI disk
[  213.222913] scsi host4: uas_post_reset: alloc streams error -19 after reset
[  213.230548] sd 4:0:0:0: [sdb] Synchronizing SCSI cache

Above is the dmesg without the unusual_uas patch applied.
Do you need me to enable any specific dev_dbg and then the dmesg output?


Can you get us a dmesg with the unusual_uas patch applied? Usually once things 
go foobar because
of issue-ing a command which the device does not understand, more things 
typically come down
as both the device and the host may be in an undefined state then.

Regards,

Hans
--
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: JMS56x not working reliably with uas driver

[Oliver Neukum]

On Wed, 2016-12-21 at 17:37 +0530, George Cherian wrote:
> 
> On 12/21/2016 05:12 PM, Oliver Neukum wrote:
> > On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote:
> >> Hi Oliver,
> >>
> >> I was working with this JMicron device and using the uas driver.
> >> I am seeing the following 2 issues.
> >>
> >> 1) On connect I see the following messages.
> >
> > Thanks. Do you want to submit it to Greg?
> > The patch is fine.
> Yes please!!!

So you want me to submit it?
It would be your chance to get a patch upstream.

> >> 2) On disconnect I am seeing the following issue
> >>
> >>scsi host4: uas_post_reset: alloc streams error -19 after reset
> >>sd 4:0:0:0: [sdb] Synchronizing SCSI cache
> >>
> >> This is more fatal because after these messages the USB port becomes
> >> unusable. Even an lsusb invocation hangs for ever.
> >
> > Ouch. That points to a logic error. We should not reset if
> > a device is gone.
> > Could you send dmesg of such a case?
> here is the dmesg!!
> [  203.475382] usb 4-1.3: new SuperSpeed USB device number 3 using xhci_hcd
> [  203.496172] usb 4-1.3: New USB device found, idVendor=152d, 
> idProduct=9561
> [  203.503037] usb 4-1.3: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=5
> [  203.510352] usb 4-1.3: Product: JMS56x Series
> [  203.514698] usb 4-1.3: Manufacturer: JMicron
> [  203.518966] usb 4-1.3: SerialNumber: 
> [  203.594383] usbcore: registered new interface driver usb-storage
> [  203.612425] scsi host4: uas
> [  203.615418] usbcore: registered new interface driver uas
> [  203.620979] scsi 4:0:0:0: Direct-Access ST4000NM 0033-9ZM170 
>   0001 PQ: 0 ANSI: 6
> [  203.630240] sd 4:0:0:0: Attached scsi generic sg1 type 0
> [  203.630382] sd 4:0:0:0: [sdb] 7814037168 512-byte logical blocks: 
> (4.00 TB/3.63 TiB)
> [  203.631338] sd 4:0:0:0: [sdb] Write Protect is off
> [  203.631342] sd 4:0:0:0: [sdb] Mode Sense: 67 00 10 08
> [  203.631734] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: 
> enabled, supports DPO and FUA
> [  203.631899] xhci_hcd :00:11.0: ERROR Transfer event for disabled 
> endpoint or incorrect stream ring
> [  203.631904] xhci_hcd :00:11.0: @001f610a1c10  
>  1b00 03078001 state 14 ep_info 9403
> [  203.631906] xhci_hcd :00:11.0: No epring
> [  203.674546]  sdb: sdb1
> [  203.676639] sd 4:0:0:0: [sdb] Attached SCSI disk
> [  213.222913] scsi host4: uas_post_reset: alloc streams error -19 after 
> reset
> [  213.230548] sd 4:0:0:0: [sdb] Synchronizing SCSI cache
> 
> Above is the dmesg without the unusual_uas patch applied.
> Do you need me to enable any specific dev_dbg and then the dmesg output?

Damn, that is a strange error. Do you know whether it happens on other
XHCI controllers? Which controller are you using and can you please also
post "lsusb -v"?

Regards
Oliver


--
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

JMS56x not working reliably with uas driver

[George Cherian]

Hi Oliver,

I was working with this JMicron device and using the uas driver.
I am seeing the following 2 issues.

1) On connect I see the following messages.
xhci_hcd :00:11.0: ERROR Transfer event for disabled endpoint or 
incorrect stream ring

 This was eliminated using the following scissor patch.

-8<
[PATCH] usb: storage: unusual_uas: Add JMicron JMS56x to unusual device

This device gives the following error on detection.
xhci_hcd :00:11.0: ERROR Transfer event for disabled endpoint or 
incorrect stream ring


The same error is not seen when it is added to unusual_device
list with US_FL_NO_REPORT_OPCODES passed.

Signed-off-by: George Cherian 
---
 drivers/usb/storage/unusual_uas.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/storage/unusual_uas.h 
b/drivers/usb/storage/unusual_uas.h

index cbea9f3..d292299 100644
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -142,6 +142,13 @@ UNUSUAL_DEV(0x152d, 0x0567, 0x, 0x,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_BROKEN_FUA | US_FL_NO_REPORT_OPCODES),

+/* Reported-by George Cherian  */
+UNUSUAL_DEV(0x152d, 0x9561, 0x, 0x,
+"JMicron",
+"JMS56x",
+USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+US_FL_NO_REPORT_OPCODES),
+
 /* Reported-by: Hans de Goede  */
 UNUSUAL_DEV(0x2109, 0x0711, 0x, 0x,
"VIA",
->8

2) On disconnect I am seeing the following issue

 scsi host4: uas_post_reset: alloc streams error -19 after reset
 sd 4:0:0:0: [sdb] Synchronizing SCSI cache

This is more fatal because after these messages the USB port becomes 
unusable. Even an lsusb invocation hangs for ever.


Also please note that the device works fine with usb-storage driver.
I am attaching the usbmon capture of disconnect using uas and 
usb-storage driver.


Any help in this regard is highly appreciated.

Regards,
-George
801f5efb8a00 57530621 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57530654 S Ii:4:002:1 -115:128 2 <
801f61285a00 57530677 S Ci:4:002:0 s a3 00  0003 0004 4 <
801f61285a00 57531618 C Ci:4:002:0 0 4 = c1024000
801f61285a00 57531634 S Co:4:002:0 s 23 01 0019 0003  0
801f61285a00 57531992 C Co:4:002:0 0 0
801f61285a00 57532225 S Ci:4:002:0 s a3 00  0003 0004 4 <
801f61285a00 57533010 C Ci:4:002:0 0 4 = c102
801f61285a00 57533022 S Co:4:002:0 s 23 03 001c 0003  0
801f61285a00 57533405 C Co:4:002:0 0 0
801f61285a00 57553165 S Ci:4:002:0 s a3 00  0003 0004 4 <
801f61285a00 57554174 C Ci:4:002:0 0 4 = b102
801f61285a00 57573164 S Ci:4:002:0 s a3 00  0003 0004 4 <
801f61285a00 57574064 C Ci:4:002:0 0 4 = b102
801f61285a00 57593169 S Ci:4:002:0 s a3 00  0003 0004 4 <
801f61285a00 57594214 C Ci:4:002:0 0 4 = b102
801f5efb8a00 57642612 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57642621 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57658612 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57658618 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57674611 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57674617 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57690610 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57690615 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57706609 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57706615 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57722609 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57722614 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57738611 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57738616 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57754610 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57754615 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57770607 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57770612 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57786609 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57786614 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57802608 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57802613 S Ii:4:002:1 -115:128 2 <
801f61285a00 57803198 S Ci:4:002:0 s a3 00  0003 0004 4 <
801f61285a00 57804109 C Ci:4:002:0 0 4 = a0020100
801f61285a00 57804122 S Co:4:002:0 s 23 01 0014 0003  0
801f61285a00 57804539 C Co:4:002:0 0 0
801f61285a00 57804553 S Co:4:002:0 s 23 01 001d 0003  0
801f61285a00 57804876 C Co:4:002:0 0 0
801f61285a00 57804890 S Co:4:002:0 s 23 01 0019 0003  0
801f61285a00 57805185 C Co:4:002:0 0 0
801f61285a00 57805199 S Co:4:002:0 s 23 01 0010 0003  0
801f61285a00 57805735 C Co:4:002:0 0 0
801f61285a00 57805749 S Ci:4:002:0 s a3 00  0003 0004 4 <
801f61285a00 57806491 C Ci:4:002:0 0 4 = a002
801f61285a00 57806506 S Ci:4:002:0 s a3 00  0003 0004 4 <
801f61285a00 

Re: JMS56x not working reliably with uas driver

[Oliver Neukum]

On Wed, 2016-12-21 at 12:54 +0100, Hans de Goede wrote:
> Hi,
> 
> On 21-12-16 12:42, Oliver Neukum wrote:
> > On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote:
> >> Hi Oliver,
> >>
> >> I was working with this JMicron device and using the uas driver.
> >> I am seeing the following 2 issues.
> >>
> >> 1) On connect I see the following messages.
> >
> > Thanks. Do you want to submit it to Greg?
> > The patch is fine.
> >
> >> 2) On disconnect I am seeing the following issue
> >>
> >>   scsi host4: uas_post_reset: alloc streams error -19 after reset
> >>   sd 4:0:0:0: [sdb] Synchronizing SCSI cache
> >>
> >> This is more fatal because after these messages the USB port becomes
> >> unusable. Even an lsusb invocation hangs for ever.
> >
> > Ouch. That points to a logic error. We should not reset if
> > a device is gone.
> 
> Ah good point, so instead of just seeing a disconnect, something
> is triggering a reset, and then we try to alloc stream on the
> disconnected usb port and that apparently makes the xhci controller
> quite unhappy.

It is problematic because there is a window we cannot avoid.
This needs a full dmesg to say anything more about it.

Regards
Oliver


--
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: [PATCH] scsi: qla4xxx: Use dma_pool_zalloc

[Javali, Nilesh]

On 13/12/16, 6:35 PM, "Souptick Joarder"  wrote:

>On Tue, Dec 13, 2016 at 4:11 PM, Javali, Nilesh
> wrote:
>>
>>
>> On 12/12/16, 10:16 AM, "linux-scsi-ow...@vger.kernel.org on behalf of
>> Souptick Joarder" > jrdr.li...@gmail.com> wrote:
>>
>>>On Wed, Dec 7, 2016 at 1:53 AM, Souptick Joarder 
>>>wrote:
 We should use dma_pool_zalloc instead of dma_pool_alloc/memset

 Signed-off-by: Souptick joarder 
 ---
  drivers/scsi/qla4xxx/ql4_mbx.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/drivers/scsi/qla4xxx/ql4_mbx.c
b/drivers/scsi/qla4xxx/ql4_mbx.c
 index c291fdf..f2edfd7 100644
 --- a/drivers/scsi/qla4xxx/ql4_mbx.c
 +++ b/drivers/scsi/qla4xxx/ql4_mbx.c
 @@ -1587,12 +1587,11 @@ int qla4xxx_get_chap(struct scsi_qla_host *ha,
char *username, char *password,
 struct ql4_chap_table *chap_table;
 dma_addr_t chap_dma;

 -   chap_table = dma_pool_alloc(ha->chap_dma_pool, GFP_KERNEL,
_dma);
 +   chap_table = dma_pool_zalloc(ha->chap_dma_pool, GFP_KERNEL,
_dma);
 if (chap_table == NULL)
 return -ENOMEM;

 chap_size = sizeof(struct ql4_chap_table);
 -   memset(chap_table, 0, chap_size);

 if (is_qla40XX(ha))
 offset = FLASH_CHAP_OFFSET | (idx * chap_size);
 --
 1.9.1

>>>
>>>Any comment on this patch?
>>
>> There are multiple other places where dma_pool_alloc needs to be
>>replaced
>> by dma_pool_zalloc.
>
>
> are you asking to do this for SCSI subsystem?
> If yes, I can do that.
>
>>
>> Can you please take care within a single patch.
>
> But the same changes are applicable in other subsystems as well.
> I think I shouldn't send those changes in a single patch as
>maintainers are different
> for different modules.

I'm referring to multiple other files within qla4xxx source which uses
dma_pool_alloc.
The current patch takes care only of ql4_mbx.c and qla4xxx_get_chap
function.
There is qla4xxx_set_chap function as well. Also ql4_init.c and ql4_os.c
files also use dma_pool_alloc.
I was requesting to make all these changes related to qla4xxx module
within a single patch.

Thanks,
Nilesh

--
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: JMS56x not working reliably with uas driver

[Hans de Goede]

Hi,

On 21-12-16 12:42, Oliver Neukum wrote:

On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote:

Hi Oliver,

I was working with this JMicron device and using the uas driver.
I am seeing the following 2 issues.

1) On connect I see the following messages.


Thanks. Do you want to submit it to Greg?
The patch is fine.


2) On disconnect I am seeing the following issue

  scsi host4: uas_post_reset: alloc streams error -19 after reset
  sd 4:0:0:0: [sdb] Synchronizing SCSI cache

This is more fatal because after these messages the USB port becomes
unusable. Even an lsusb invocation hangs for ever.


Ouch. That points to a logic error. We should not reset if
a device is gone.


Ah good point, so instead of just seeing a disconnect, something
is triggering a reset, and then we try to alloc stream on the
disconnected usb port and that apparently makes the xhci controller
quite unhappy.

Regards,

Hans
--
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: JMS56x not working reliably with uas driver

[Hans de Goede]

Hi,

On 21-12-16 12:39, George Cherian wrote:

Hi Oliver,

I was working with this JMicron device and using the uas driver.
I am seeing the following 2 issues.

1) On connect I see the following messages.
xhci_hcd :00:11.0: ERROR Transfer event for disabled endpoint or incorrect 
stream ring
 This was eliminated using the following scissor patch.

-8<
[PATCH] usb: storage: unusual_uas: Add JMicron JMS56x to unusual device

This device gives the following error on detection.
xhci_hcd :00:11.0: ERROR Transfer event for disabled endpoint or incorrect 
stream ring

The same error is not seen when it is added to unusual_device
list with US_FL_NO_REPORT_OPCODES passed.

Signed-off-by: George Cherian 
---
 drivers/usb/storage/unusual_uas.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/storage/unusual_uas.h 
b/drivers/usb/storage/unusual_uas.h
index cbea9f3..d292299 100644
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -142,6 +142,13 @@ UNUSUAL_DEV(0x152d, 0x0567, 0x, 0x,
 USB_SC_DEVICE, USB_PR_DEVICE, NULL,
 US_FL_BROKEN_FUA | US_FL_NO_REPORT_OPCODES),

+/* Reported-by George Cherian  */
+UNUSUAL_DEV(0x152d, 0x9561, 0x, 0x,
+"JMicron",
+"JMS56x",
+USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+US_FL_NO_REPORT_OPCODES),
+
 /* Reported-by: Hans de Goede  */
 UNUSUAL_DEV(0x2109, 0x0711, 0x, 0x,
 "VIA",
->8

2) On disconnect I am seeing the following issue

 scsi host4: uas_post_reset: alloc streams error -19 after reset
 sd 4:0:0:0: [sdb] Synchronizing SCSI cache

This is more fatal because after these messages the USB port becomes unusable. 
Even an lsusb invocation hangs for ever.

Also please note that the device works fine with usb-storage driver.
I am attaching the usbmon capture of disconnect using uas and usb-storage 
driver.

Any help in this regard is highly appreciated.


Are you still seeen this second problem with the first patch applied ? Is this 
after
an actual disconnect, or after the kernel seeing a disconnect without the device
being actually disconnected.

This second problem sounds like it is an issue with your xhci controller. Can 
you
try this on another motherboard (with another xhci controller) ?

Regards,

Hans
--
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: JMS56x not working reliably with uas driver

[Oliver Neukum]

On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote:
> Hi Oliver,
> 
> I was working with this JMicron device and using the uas driver.
> I am seeing the following 2 issues.
> 
> 1) On connect I see the following messages.

Thanks. Do you want to submit it to Greg?
The patch is fine.

> 2) On disconnect I am seeing the following issue
> 
>   scsi host4: uas_post_reset: alloc streams error -19 after reset
>   sd 4:0:0:0: [sdb] Synchronizing SCSI cache
> 
> This is more fatal because after these messages the USB port becomes 
> unusable. Even an lsusb invocation hangs for ever.

Ouch. That points to a logic error. We should not reset if
a device is gone.
Could you send dmesg of such a case?

Regards
Oliver


--
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

[Bug 176951] boot fails unless acpi=off Acer Travelmate X-349

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=176951

Martin Goyot  changed:

   What|Removed |Added

 CC||mar...@piwany.com

--- Comment #8 from Martin Goyot  ---
I confirm, I have this exact same problem with TravelMate X349-M.

Fedora 25 32-Bit Live system working, but impossible to boot the x64 version,
black frozen screen after boot menu.

I cannot confirm for the BIOS update because of course I don't have windows
anymore so I don't know how I will install it...

-- 
You are receiving this mail because:
You are watching the assignee of the bug.--
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: [PATCH] scsi/bfa: use designated initializers

[Christoph Hellwig]

On Fri, Dec 16, 2016 at 05:05:15PM -0800, Kees Cook wrote:
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> extracted from grsecurity.

Instead of further bloating the idiotic dispatch table just kill it off
entirely:

---
>From d20ca8dee2c620b8199e998269f8e0249bc1ba04 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig 
Date: Wed, 21 Dec 2016 09:15:02 +0100
Subject: bfa: remove bfa_fcs_mod_s

Just call the functions directly instead of obsfucating the call chain.

Signed-off-by: Christoph Hellwig 
---
 drivers/scsi/bfa/bfa_fcs.c | 181 -
 drivers/scsi/bfa/bfa_fcs.h |   4 -
 2 files changed, 46 insertions(+), 139 deletions(-)

diff --git a/drivers/scsi/bfa/bfa_fcs.c b/drivers/scsi/bfa/bfa_fcs.c
index 1e7e139..4aa61e2 100644
--- a/drivers/scsi/bfa/bfa_fcs.c
+++ b/drivers/scsi/bfa/bfa_fcs.c
@@ -28,24 +28,6 @@
 BFA_TRC_FILE(FCS, FCS);
 
 /*
- * FCS sub-modules
- */
-struct bfa_fcs_mod_s {
-   void(*attach) (struct bfa_fcs_s *fcs);
-   void(*modinit) (struct bfa_fcs_s *fcs);
-   void(*modexit) (struct bfa_fcs_s *fcs);
-};
-
-#define BFA_FCS_MODULE(_mod) { _mod ## _modinit, _mod ## _modexit }
-
-static struct bfa_fcs_mod_s fcs_modules[] = {
-   { bfa_fcs_port_attach, NULL, NULL },
-   { bfa_fcs_uf_attach, NULL, NULL },
-   { bfa_fcs_fabric_attach, bfa_fcs_fabric_modinit,
- bfa_fcs_fabric_modexit },
-};
-
-/*
  *  fcs_api BFA FCS API
  */
 
@@ -58,52 +40,19 @@ bfa_fcs_exit_comp(void *fcs_cbarg)
complete(>comp);
 }
 
-
-
 /*
- *  fcs_api BFA FCS API
- */
-
-/*
- * fcs attach -- called once to initialize data structures at driver attach 
time
+ * fcs initialization, called once after bfa initialization is complete
  */
 void
-bfa_fcs_attach(struct bfa_fcs_s *fcs, struct bfa_s *bfa, struct bfad_s *bfad,
-  bfa_boolean_t min_cfg)
+bfa_fcs_init(struct bfa_fcs_s *fcs)
 {
-   int i;
-   struct bfa_fcs_mod_s  *mod;
-
-   fcs->bfa = bfa;
-   fcs->bfad = bfad;
-   fcs->min_cfg = min_cfg;
-   fcs->num_rport_logins = 0;
-
-   bfa->fcs = BFA_TRUE;
-   fcbuild_init();
-
-   for (i = 0; i < ARRAY_SIZE(fcs_modules); i++) {
-   mod = _modules[i];
-   if (mod->attach)
-   mod->attach(fcs);
-   }
+   bfa_sm_send_event(>fabric, BFA_FCS_FABRIC_SM_CREATE);
+   bfa_trc(fcs, 0);
 }
 
 /*
- * fcs initialization, called once after bfa initialization is complete
+ *  fcs_api BFA FCS API
  */
-void
-bfa_fcs_init(struct bfa_fcs_s *fcs)
-{
-   int i;
-   struct bfa_fcs_mod_s  *mod;
-
-   for (i = 0; i < ARRAY_SIZE(fcs_modules); i++) {
-   mod = _modules[i];
-   if (mod->modinit)
-   mod->modinit(fcs);
-   }
-}
 
 /*
  * FCS update cfg - reset the pwwn/nwwn of fabric base logical port
@@ -180,26 +129,14 @@ bfa_fcs_driver_info_init(struct bfa_fcs_s *fcs,
 void
 bfa_fcs_exit(struct bfa_fcs_s *fcs)
 {
-   struct bfa_fcs_mod_s  *mod;
-   int nmods, i;
-
bfa_wc_init(>wc, bfa_fcs_exit_comp, fcs);
-
-   nmods = ARRAY_SIZE(fcs_modules);
-
-   for (i = 0; i < nmods; i++) {
-
-   mod = _modules[i];
-   if (mod->modexit) {
-   bfa_wc_up(>wc);
-   mod->modexit(fcs);
-   }
-   }
-
+   bfa_wc_up(>wc);
+   bfa_trc(fcs, 0);
+   bfa_lps_delete(fcs->fabric.lps);
+   bfa_sm_send_event(>fabric, BFA_FCS_FABRIC_SM_DELETE);
bfa_wc_wait(>wc);
 }
 
-
 /*
  * Fabric module implementation.
  */
@@ -1128,62 +1065,6 @@ bfa_fcs_fabric_stop_comp(void *cbarg)
  */
 
 /*
- * Attach time initialization.
- */
-void
-bfa_fcs_fabric_attach(struct bfa_fcs_s *fcs)
-{
-   struct bfa_fcs_fabric_s *fabric;
-
-   fabric = >fabric;
-   memset(fabric, 0, sizeof(struct bfa_fcs_fabric_s));
-
-   /*
-* Initialize base fabric.
-*/
-   fabric->fcs = fcs;
-   INIT_LIST_HEAD(>vport_q);
-   INIT_LIST_HEAD(>vf_q);
-   fabric->lps = bfa_lps_alloc(fcs->bfa);
-   WARN_ON(!fabric->lps);
-
-   /*
-* Initialize fabric delete completion handler. Fabric deletion is
-* complete when the last vport delete is complete.
-*/
-   bfa_wc_init(>wc, bfa_fcs_fabric_delete_comp, fabric);
-   bfa_wc_up(>wc); /* For the base port */
-
-   bfa_sm_set_state(fabric, bfa_fcs_fabric_sm_uninit);
-   bfa_fcs_lport_attach(>bport, fabric->fcs, FC_VF_ID_NULL, NULL);
-}
-
-void
-bfa_fcs_fabric_modinit(struct bfa_fcs_s *fcs)
-{
-   bfa_sm_send_event(>fabric, BFA_FCS_FABRIC_SM_CREATE);
-   bfa_trc(fcs, 0);
-}
-
-/*
- *   Module cleanup
- */
-void
-bfa_fcs_fabric_modexit(struct bfa_fcs_s *fcs)
-{
-

Re: [PATCH] scsi: do not requeue requests unaligned with device sector size

[Hannes Reinecke]

On 12/21/2016 08:50 AM, Christoph Hellwig wrote:
> On Tue, Dec 20, 2016 at 12:02:27AM -0200, Mauricio Faria de Oliveira wrote:
>> When a SCSI command (e.g., read operation) is partially completed
>> with good status and residual bytes (i.e., not all the bytes from
>> the specified transfer length were transferred) the SCSI midlayer
>> will update the request/bios with the completed bytes and requeue
>> the request in order to complete the remainder/pending bytes.
>>
>> However, when the device sector size is greater than the 512-byte
>> default/kernel sector size, alignment restrictions and validation
>> apply (both to the starting logical block address, and the number
>> of logical blocks to transfer) -- values must be multiples of the
>> device sector size, otherwise the kernel fails the request in the
>> preparation stage (e.g., sd_setup_read_write_cmnd() at sd.c file):
> 
> How do you even get an unaligned residual count?  Except for SES
> processor devices (which will only issue BLOCK_PC commands) this is
> not allowed by SPC:
> 
> "The residual count shall be reported in bytes if the peripheral device
>  type in the destination target descriptor is 03h (i.e., processor device),
>  and in destination device blocks for all other device type codes."

Which actually would be pretty much my objection, too.

This would only be applicable for 512e drives, where we _might_ end up
with a residual smaller than the physical sector size.
But that should be handled by firmware; after all, that's what the 'e'
implies, right?

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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: [PATCH] set a base index for libsas based ata devices

[Christoph Hellwig]

On Tue, Dec 20, 2016 at 10:30:34AM -0800, James Bottomley wrote:
> I'd actually disagree with this assertion; it's why tagging (what you
> mean by ncq) and queue depth are separate.  Queue depth represents the
> number of outstanding commands we sent on the wire; however, it often
> excludes things like sense probes and error handling commands, so
> tagged depth==1 is a different operating environment from untagged. 
>  Some transports actually have no untagged variant nowadays, so it's
> physically impossible to disable tagging.

Yes.  We have the queue_type sysfs file that also used to be writeable
and allow changing the queue type, but it's never been used for
anything.

For debugging you can clear the tagged_supported flag in the driver,
but there should be no reason for doing that during normal operation
for a SAS HBA driver.
--
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