[PATCH 2/3] iscsi-target: Drop legacy iscsi_target_tq.c logic

[Nicholas A. Bellinger]

From: Nicholas Bellinger 

Now that iscsi_conn allocates new [rx,tx] threads using kthread.h
primitives on the fly, and kthread_stop() is called directly during
connection shutdown, it's time to go ahead and drop iscsi_target_tq.c
legacy code.

The use of multiple struct completion in iscsi_activate_thread_set()
has been proven to cause issues during repeated iser login/logout.

Cc: Sagi Grimberg 
Cc: Slava Shwartsman 
Signed-off-by: Nicholas Bellinger 
---
 drivers/target/iscsi/Makefile |   1 -
 drivers/target/iscsi/iscsi_target.c   |   3 -
 drivers/target/iscsi/iscsi_target_erl0.c  |   1 -
 drivers/target/iscsi/iscsi_target_login.c |   1 -
 drivers/target/iscsi/iscsi_target_tq.c| 495 --
 drivers/target/iscsi/iscsi_target_tq.h|  84 -
 drivers/target/iscsi/iscsi_target_util.c  |   1 -
 include/target/iscsi/iscsi_target_core.h  |   6 +-
 8 files changed, 2 insertions(+), 590 deletions(-)
 delete mode 100644 drivers/target/iscsi/iscsi_target_tq.c
 delete mode 100644 drivers/target/iscsi/iscsi_target_tq.h

diff --git a/drivers/target/iscsi/Makefile b/drivers/target/iscsi/Makefile
index 13a9240..0f43be9 100644
--- a/drivers/target/iscsi/Makefile
+++ b/drivers/target/iscsi/Makefile
@@ -1,6 +1,5 @@
 iscsi_target_mod-y +=  iscsi_target_parameters.o \
iscsi_target_seq_pdu_list.o \
-   iscsi_target_tq.o \
iscsi_target_auth.o \
iscsi_target_datain_values.o \
iscsi_target_device.o \
diff --git a/drivers/target/iscsi/iscsi_target.c 
b/drivers/target/iscsi/iscsi_target.c
index cb97b59..ca731b5 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -33,7 +33,6 @@
 #include 
 #include "iscsi_target_parameters.h"
 #include "iscsi_target_seq_pdu_list.h"
-#include "iscsi_target_tq.h"
 #include "iscsi_target_configfs.h"
 #include "iscsi_target_datain_values.h"
 #include "iscsi_target_erl0.h"
@@ -4369,8 +4368,6 @@ int iscsit_close_connection(
 
iscsit_put_transport(conn->conn_transport);
 
-   conn->thread_set = NULL;
-
pr_debug("Moving to TARG_CONN_STATE_FREE.\n");
conn->conn_state = TARG_CONN_STATE_FREE;
kfree(conn);
diff --git a/drivers/target/iscsi/iscsi_target_erl0.c 
b/drivers/target/iscsi/iscsi_target_erl0.c
index e008ed2..959a14c 100644
--- a/drivers/target/iscsi/iscsi_target_erl0.c
+++ b/drivers/target/iscsi/iscsi_target_erl0.c
@@ -23,7 +23,6 @@
 
 #include 
 #include "iscsi_target_seq_pdu_list.h"
-#include "iscsi_target_tq.h"
 #include "iscsi_target_erl0.h"
 #include "iscsi_target_erl1.h"
 #include "iscsi_target_erl2.h"
diff --git a/drivers/target/iscsi/iscsi_target_login.c 
b/drivers/target/iscsi/iscsi_target_login.c
index 345f073..af20ddf 100644
--- a/drivers/target/iscsi/iscsi_target_login.c
+++ b/drivers/target/iscsi/iscsi_target_login.c
@@ -26,7 +26,6 @@
 
 #include 
 #include 
-#include "iscsi_target_tq.h"
 #include "iscsi_target_device.h"
 #include "iscsi_target_nego.h"
 #include "iscsi_target_erl0.h"
diff --git a/drivers/target/iscsi/iscsi_target_tq.c 
b/drivers/target/iscsi/iscsi_target_tq.c
deleted file mode 100644
index 26aa509..000
--- a/drivers/target/iscsi/iscsi_target_tq.c
+++ /dev/null
@@ -1,495 +0,0 @@
-/***
- * This file contains the iSCSI Login Thread and Thread Queue functions.
- *
- * (c) Copyright 2007-2013 Datera, Inc.
- *
- * Author: Nicholas A. Bellinger 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- 
**/
-
-#include 
-#include 
-#include 
-
-#include 
-#include "iscsi_target_tq.h"
-#include "iscsi_target.h"
-
-static LIST_HEAD(inactive_ts_list);
-static DEFINE_SPINLOCK(inactive_ts_lock);
-static DEFINE_SPINLOCK(ts_bitmap_lock);
-
-static void iscsi_add_ts_to_inactive_list(struct iscsi_thread_set *ts)
-{
-   if (!list_empty(&ts->ts_list)) {
-   WARN_ON(1);
-   return;
-   }
-   spin_lock(&inactive_ts_lock);
-   list_add_tail(&ts->ts_list, &inactive_ts_list);
-   iscsit_global->inactive_ts++;
-   spin_unlock(&inactive_ts_lock);
-}
-
-static struct iscsi_thread_set *iscsi_get_ts_from_inactive_list(void)
-{
-   struct iscsi_thread_set *ts;
-
-   spin_lock(&inactive_ts_lock);
-   if (list_empty(&inactive_ts_list)) {
-   s

[PATCH 1/3] iscsi-target: Convert iscsi_thread_set usage to kthread.h

[Nicholas A. Bellinger]

From: Nicholas Bellinger 

This patch converts iscsi-target code to use modern kthread.h API
callers for creating RX/TX threads for each new iscsi_conn descriptor,
and releasing associated RX/TX threads during connection shutdown.

This is done using iscsit_start_kthreads() -> kthread_run() to start
new kthreads from within iscsi_post_login_handler(), and invoking
kthread_stop() from existing iscsit_close_connection() code.

Also, convert iscsit_logout_post_handler_closesession() code to use
cmpxchg when determing when iscsit_cause_connection_reinstatement()
needs to sleep waiting for completion.

Reported-by: Sagi Grimberg 
Cc: Sagi Grimberg 
Cc: Slava Shwartsman 
Signed-off-by: Nicholas Bellinger 
---
 drivers/target/iscsi/iscsi_target.c   | 106 +-
 drivers/target/iscsi/iscsi_target_erl0.c  |  13 ++--
 drivers/target/iscsi/iscsi_target_login.c |  59 +++--
 include/target/iscsi/iscsi_target_core.h  |   7 ++
 4 files changed, 116 insertions(+), 69 deletions(-)

diff --git a/drivers/target/iscsi/iscsi_target.c 
b/drivers/target/iscsi/iscsi_target.c
index 2accb6e..cb97b59 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -537,7 +537,7 @@ static struct iscsit_transport iscsi_target_transport = {
 
 static int __init iscsi_target_init_module(void)
 {
-   int ret = 0;
+   int ret = 0, size;
 
pr_debug("iSCSI-Target "ISCSIT_VERSION"\n");
 
@@ -546,6 +546,7 @@ static int __init iscsi_target_init_module(void)
pr_err("Unable to allocate memory for iscsit_global\n");
return -1;
}
+   spin_lock_init(&iscsit_global->ts_bitmap_lock);
mutex_init(&auth_id_lock);
spin_lock_init(&sess_idr_lock);
idr_init(&tiqn_idr);
@@ -555,15 +556,11 @@ static int __init iscsi_target_init_module(void)
if (ret < 0)
goto out;
 
-   ret = iscsi_thread_set_init();
-   if (ret < 0)
+   size = BITS_TO_LONGS(ISCSIT_BITMAP_BITS) * sizeof(long);
+   iscsit_global->ts_bitmap = vzalloc(size);
+   if (!iscsit_global->ts_bitmap) {
+   pr_err("Unable to allocate iscsit_global->ts_bitmap\n");
goto configfs_out;
-
-   if (iscsi_allocate_thread_sets(TARGET_THREAD_SET_COUNT) !=
-   TARGET_THREAD_SET_COUNT) {
-   pr_err("iscsi_allocate_thread_sets() returned"
-   " unexpected value!\n");
-   goto ts_out1;
}
 
lio_qr_cache = kmem_cache_create("lio_qr_cache",
@@ -572,7 +569,7 @@ static int __init iscsi_target_init_module(void)
if (!lio_qr_cache) {
pr_err("nable to kmem_cache_create() for"
" lio_qr_cache\n");
-   goto ts_out2;
+   goto bitmap_out;
}
 
lio_dr_cache = kmem_cache_create("lio_dr_cache",
@@ -617,10 +614,8 @@ dr_out:
kmem_cache_destroy(lio_dr_cache);
 qr_out:
kmem_cache_destroy(lio_qr_cache);
-ts_out2:
-   iscsi_deallocate_thread_sets();
-ts_out1:
-   iscsi_thread_set_free();
+bitmap_out:
+   vfree(iscsit_global->ts_bitmap);
 configfs_out:
iscsi_target_deregister_configfs();
 out:
@@ -630,8 +625,6 @@ out:
 
 static void __exit iscsi_target_cleanup_module(void)
 {
-   iscsi_deallocate_thread_sets();
-   iscsi_thread_set_free();
iscsit_release_discovery_tpg();
iscsit_unregister_transport(&iscsi_target_transport);
kmem_cache_destroy(lio_qr_cache);
@@ -641,6 +634,7 @@ static void __exit iscsi_target_cleanup_module(void)
 
iscsi_target_deregister_configfs();
 
+   vfree(iscsit_global->ts_bitmap);
kfree(iscsit_global);
 }
 
@@ -3710,17 +3704,16 @@ static int iscsit_send_reject(
 
 void iscsit_thread_get_cpumask(struct iscsi_conn *conn)
 {
-   struct iscsi_thread_set *ts = conn->thread_set;
int ord, cpu;
/*
-* thread_id is assigned from iscsit_global->ts_bitmap from
-* within iscsi_thread_set.c:iscsi_allocate_thread_sets()
+* bitmap_id is assigned from iscsit_global->ts_bitmap from
+* within iscsit_start_kthreads()
 *
-* Here we use thread_id to determine which CPU that this
-* iSCSI connection's iscsi_thread_set will be scheduled to
+* Here we use bitmap_id to determine which CPU that this
+* iSCSI connection's RX/TX threads will be scheduled to
 * execute upon.
 */
-   ord = ts->thread_id % cpumask_weight(cpu_online_mask);
+   ord = conn->bitmap_id % cpumask_weight(cpu_online_mask);
for_each_online_cpu(cpu) {
if (ord-- == 0) {
cpumask_set_cpu(cpu, conn->conn_cpumask);
@@ -3909,7 +3902,7 @@ check_rsp_state:
switch (state) {
case ISTATE_SEND_LOGOUTRSP:
if (!iscsit_logout_post_handler(cmd, conn))
-   goto restart;
+   retur

[PATCH 3/3] iser-target: Handle special case for logout during connection failure

[Nicholas A. Bellinger]

From: Nicholas Bellinger 

This patch adds special case handling during ISCSI_OP_LOGIN_RSP ib_wr
failure, where isert_cq_comp_err() is responsible for calling the
remaining isert_response_completion() -> isert_do_control_comp() ->
iscsit_logout_post_handler() to drop the last iscsi_conn reference.

It fixes a bug where iscsit_logout_post_handler() would not be called
if the outgoing ISCSI_OP_LOGIN_RSP failed during iscsi_conn ib_wr
descriptor cleanup.

Reported-by: Sagi Grimberg 
Reported-by: Slava Shwartsman 
Signed-off-by: Nicholas Bellinger 
---
 drivers/infiniband/ulp/isert/ib_isert.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/ulp/isert/ib_isert.c 
b/drivers/infiniband/ulp/isert/ib_isert.c
index 075b19c..ff0d436 100644
--- a/drivers/infiniband/ulp/isert/ib_isert.c
+++ b/drivers/infiniband/ulp/isert/ib_isert.c
@@ -1996,10 +1996,20 @@ isert_cq_comp_err(struct isert_conn *isert_conn, struct 
ib_wc *wc)
 
desc = (struct iser_tx_desc *)(uintptr_t)wc->wr_id;
isert_cmd = desc->isert_cmd;
-   if (!isert_cmd)
+   if (!isert_cmd) {
isert_unmap_tx_desc(desc, ib_dev);
-   else
-   isert_completion_put(desc, isert_cmd, ib_dev, true);
+   } else {
+   struct isert_device *device = isert_conn->conn_device;
+   struct iscsi_conn *conn = isert_conn->conn;
+   struct iscsi_cmd *cmd = isert_cmd->iscsi_cmd;
+
+   if (cmd->i_state == ISTATE_SEND_LOGOUTRSP &&
+   conn->conn_state == TARG_CONN_STATE_IN_LOGOUT)
+   isert_response_completion(desc, isert_cmd, 
isert_conn,
+ device->ib_device);
+   else
+   isert_completion_put(desc, isert_cmd, ib_dev, 
true);
+   }
} else {
isert_conn->post_recv_buf_count--;
if (!isert_conn->post_recv_buf_count)
-- 
1.9.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 0/3] iscsi/iser-target: Convert to kthread.h + fix logout failure

[Nicholas A. Bellinger]

From: Nicholas Bellinger 

Hello Sagi & Slava,

Following the earlier pre-LSF discussion, here is a patch series
to convert iscsi/iser target to using modern kthread.h primitives
when starting / stopping RX + TX kernel threads during iscsi_conn
creation / shutdown.

So far this code has been tested with traditional iscsi-target
login / logout code-paths, and needs to be verified via iser-target
login / logout code-paths as well.

Also, patch #3 is a seperate iser-target bugfix to handle a failed
outgoing ISCSI_OP_LOGOUT_RSP in isert_cq_comp_err() completion
interrupt path code.  This one may or may not have been triggering
earlier, but addresses a possible iser-target specific logout bug.

Please review + test for v4.1-rc1 code.

Thank you,

--nab

Nicholas Bellinger (3):
  iscsi-target: Convert iscsi_thread_set usage to kthread.h
  iscsi-target: Drop legacy iscsi_target_tq.c logic
  iser-target: Handle special case for logout during connection failure

 drivers/infiniband/ulp/isert/ib_isert.c   |  16 +-
 drivers/target/iscsi/Makefile |   1 -
 drivers/target/iscsi/iscsi_target.c   | 109 +++
 drivers/target/iscsi/iscsi_target_erl0.c  |  14 +-
 drivers/target/iscsi/iscsi_target_login.c |  60 +++-
 drivers/target/iscsi/iscsi_target_tq.c| 495 --
 drivers/target/iscsi/iscsi_target_tq.h|  84 -
 drivers/target/iscsi/iscsi_target_util.c  |   1 -
 include/target/iscsi/iscsi_target_core.h  |  13 +-
 9 files changed, 131 insertions(+), 662 deletions(-)
 delete mode 100644 drivers/target/iscsi/iscsi_target_tq.c
 delete mode 100644 drivers/target/iscsi/iscsi_target_tq.h

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

RE: [Scst-devel] scst qla2xxx.ko VS kernel qla2xxx.ko

[Suresh Babu Kandukuru]

Greg . Thank you very much for the detailed mail . I will mail you and the list 
for any further quires to the list . Thanks.

/Suresh 

-Original Message-
From: Dr. Greg Wettstein [mailto:g...@wind.enjellic.com] 
Sent: Saturday, March 21, 2015 1:36 AM
To: Suresh Babu Kandukuru; Bart Van Assche; scst-de...@lists.sourceforge.net
Cc: linux-scsi@vger.kernel.org
Subject: Re: [Scst-devel] scst qla2xxx.ko VS kernel qla2xxx.ko

On Mar 13,  4:18am, Suresh Babu Kandukuru wrote:
} Subject: Re: [Scst-devel] scst qla2xxx.ko  VS kernel qla2xxx.ko

Hi, I hope the week is closing out well for everyone.

> Thanks Bart . We have tested with 2.2.0 and 3.0.1 
> (scst-svn-6135-branches-3.0.x ) ., loaded all the scst ko files along 
> with qla2xxx_scst.ko qla2x00t.ko . Still this did not any FC ports in 
> /sys/class/fc_hosts/.. .  The QLOGIC HBA we are using is "QLogic 
> QLE8362 - 7101674, Sun Storage 16Gb FC PCIe Universal HBA, QLogic. " . 
> Does the scst qla2xxx_scst.ko driver supports this ?. what we are 
> missing here ?. Any pointers are helpful . Thanks

We have had the opportunity to architect, build, maintain and debug complex 
converged data and storage networks.  The switches on these networks are a 
million dollars apiece and there are multiple switches in multiple data-centers.

The storage, running at about one-half petabyte levels, is all SCST based and 
we use Qlogic HBA's and CNA's on both the initiators and targets.  Given the 
somewhat colorful history with respect to Qlogic target driver support we had 
to roll up our sleeves and write an interface driver which allows SCST to run 
on top of the Qlogic target driver in stock Linux kernels.

I just put an integrated patchset which includes SCST 3.0.0, our target 
interface driver and a few patches to the in-kernel target driver we carry to 
make all of this work correctly and address various regressions in the stock 
target driver.  You can grab the patchset from the following URL:

ftp://ftp.enjellic.com/pub/scst/sqa-1.2_scst-3.0.0_3.10.67.patch.gz

All of the storage targets are direct FCOE attachments using Qlogic
8362 CNA's.  The above patchset is what we are currently using in production 
and it has been validated over hundreds and hundreds of terrabytes of I/O, 
which includes exposure to some rather rigorous fabric and TMF event processing 
situations.  We have also tracked down some rather elusive switch based FCOE 
transport issues with this codebase.

Obviously your mileage may vary.

If you drop the above patch onto a 3.10 kernel source tree and build a kernel 
with the appropriate configuration options it should work with whatever cards 
are supported by the stock Linux kernel.  One of the patches which is included 
sets the card to QLA2XXX_INI_MODE_EXCLUSIVE which causes the card to come up 
'target capable' by default which mirrors the behavior of the SCST supplied 
Qlogic target driver.

In your note you indicate your card is a 'QLogic QLE8362 - 7101674, Sun Storage 
16Gb FC PCIe Universal HBA' which I assume is probably an OEM rebranded card.  
The 8362 is actually a Converged Network Adapter
(CNA) rather then an HBA.  The 2672 is the 'fibre-channel' HBA version of the 
card.  The stock Qlogic cards are dual-personality cards which allows their 
operational mode, ie 16 GBPS FC or 10 GBPS ethernet, to be selected through the 
BIOS setup utilities.

Given your e-mail address, I'm sure you've jumped through all these hoops but 
one obviously wants to have the card setup with the right personality and 
correct optics for your physical transport layer.

You also probably want to make sure you have both your HBA/CNA and motherboard 
up to the most recent versions of their respective firmware.  There are issues 
particularly with Intel S2600 motherboards and these cards which requires 
updated firmware on both sides.

If the card is detected and found to be target capable by the stock Linux 
kernel Qlogic driver you will find the available target PWWN's in the following 
directory:

/sys/kernel/scst_tgt/targets/sqatgt

If there are none present there is the possibility that the card has been 
modified in firmware to prohibit target mode or has a modified PCI id which is 
causing problems for the driver probe logic.  If that is the case the card 
isn't going to be a candidate for use in target mode.  We tend to recommend 
that people buy straight Qlogic branded cards to avoid these sorts of issues.

Just as an FYI/CYA there are session management issues/bugs in the Qlogic 
target driver, regardless of breed; SCST, Qlogic SCST or kernel.  These can 
show up during asynchronous fabric processing events, particularly if you are 
aggressive in placing the card and fabric under duress.

We are in the process of upgrading our patchset to 3.0.1 which will include a 
number of additional fixes to the in-kernel Qlogic target driver.  I will shoot 
a note off to the list when it is available if you or others find this stuff 
useful.

I hope the above 

[GIT PULL] target fixes for v4.0-rc5

[Nicholas A. Bellinger]

Hi Linus,

Here are current target-pending fixes for v4.0-rc5 code that have made
their way into the queue over the last weeks.

Please go ahead and pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master

The fixes this round include:

  - Fix long-standing iser-target logout bug related to early conn_logout_comp
completion, resulting in iscsi_conn use-after-tree OOpsen.  (Sagi + nab)

  - Fix long-standing tcm_fc bug in ft_invl_hw_context() failure handing
for DDP hw offload.  (DanC)

  - Fix incorrect use of unprotected __transport_register_session() in
tcm_qla2xxx + other single local se_node_acl fabrics.  (Bart)

  - Fix reference leak in target_submit_cmd() -> target_get_sess_cmd() for
ack_kref=1 failure path.  (Bart)

  - Fix pSCSI backend ->get_device_type() statistics OOPs with un-configured
device.  (Olaf + nab)

  - Fix virtual LUN=0 target_configure_device failure OOPs at modprobe time.
(Claudio + nab)

  - Fix FUA write false positive failure regression in v4.0-rc1 code.
(Christophe Vu-Brugier + HCH)

Thank you,

--nab

Bart Van Assche (3):
  tcm_qla2xxx: Fix incorrect use of __transport_register_session
  loop/usb/vhost-scsi/xen-scsiback: Fix use of
__transport_register_session
  target: Fix reference leak in target_get_sess_cmd() error path

Christophe Vu-Brugier (1):
  target: do not reject FUA CDBs when write cache is enabled but
emulate_write_cache is 0

Dan Carpenter (1):
  tcm_fc: missing curly braces in ft_invl_hw_context()

Nicholas Bellinger (5):
  target: Disallow changing of WRITE cache/FUA attrs after export
  Revert "iscsi-target: Avoid IN_LOGOUT failure case for iser-target"
  iscsi-target: Avoid early conn_logout_comp for iser connections
  target/pscsi: Fix NULL pointer dereference in get_device_type
  target: Fix virtual LUN=0 target_configure_device failure OOPs

 drivers/scsi/qla2xxx/tcm_qla2xxx.c |  2 +-
 drivers/target/iscsi/iscsi_target.c| 14 +
 drivers/target/iscsi/iscsi_target_erl0.c   |  4 +---
 drivers/target/loopback/tcm_loop.c |  7 ++-
 drivers/target/target_core_device.c| 32 +++---
 drivers/target/target_core_pscsi.c |  2 +-
 drivers/target/target_core_sbc.c   |  3 +--
 drivers/target/target_core_spc.c   | 19 +++---
 drivers/target/target_core_transport.c |  4 
 drivers/target/tcm_fc/tfc_io.c |  3 ++-
 drivers/usb/gadget/legacy/tcm_usb_gadget.c |  5 ++---
 drivers/vhost/scsi.c   |  5 ++---
 drivers/xen/xen-scsiback.c |  7 ++-
 include/target/target_core_backend.h   |  1 +
 14 files changed, 61 insertions(+), 47 deletions(-)

--
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 v1 16/47] fusion: use __arch_phys_wc_add()

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" 

If and when this gets enabled the driver should address
using ioremap_wc() on the same area, that could require
a bit of work as it would mean a split with two ioremap'd
areas. Annotate this.

Cc: Andy Lutomirski 
Cc: Suresh Siddha 
Cc: Venkatesh Pallipadi 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Daniel Vetter 
Cc: Nagalakshmi Nandigama 
Cc: Praveen Krishnamoorthy 
Cc: Sreekanth Reddy 
Cc: Abhijit Mahajan 
Cc: Juergen Gross 
Cc: Dave Airlie 
Cc: Antonino Daplas 
Cc: Tomi Valkeinen 
Cc: Jean-Christophe Plagniol-Villard 
Cc: mpt-fusionlinux@avagotech.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez 
---
 drivers/message/fusion/mptbase.c | 19 ---
 drivers/message/fusion/mptbase.h |  2 +-
 2 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 187f836..c7b1a55 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -59,10 +59,6 @@
 #include 
 #include/* needed for in_interrupt() proto */
 #include 
-#include 
-#ifdef CONFIG_MTRR
-#include 
-#endif
 #include 
 #include 
 
@@ -2820,11 +2816,8 @@ mpt_adapter_dispose(MPT_ADAPTER *ioc)
pci_disable_device(ioc->pcidev);
pci_release_selected_regions(ioc->pcidev, ioc->bars);
 
-#if defined(CONFIG_MTRR) && 0
-   if (ioc->mtrr_reg > 0) {
-   mtrr_del(ioc->mtrr_reg, 0, 0);
-   dprintk(ioc, printk(MYIOC_s_INFO_FMT "MTRR region 
de-registered\n", ioc->name));
-   }
+#if 0
+   __arch_phys_wc_del(ioc->wc_cookie);
 #endif
 
/*  Zap the adapter lookup ptr!  */
@@ -4512,17 +4505,13 @@ PrimeIocFifos(MPT_ADAPTER *ioc)
 
ioc->req_frames_low_dma = (u32) (alloc_dma & 0x);
 
-#if defined(CONFIG_MTRR) && 0
+#if 0
/*
 *  Enable Write Combining MTRR for IOC's memory region.
 *  (at least as much as we can; "size and base must be
 *  multiples of 4 kiB"
 */
-   ioc->mtrr_reg = mtrr_add(ioc->req_frames_dma,
-sz,
-MTRR_TYPE_WRCOMB, 1);
-   dprintk(ioc, printk(MYIOC_s_DEBUG_FMT "MTRR region registered 
(base:size=%08x:%x)\n",
-   ioc->name, ioc->req_frames_dma, sz));
+   ioc->wc_cookie = arch_phys_wc_add(ioc->req_frames_dma, sz);
 #endif
 
for (i = 0; i < ioc->req_depth; i++) {
diff --git a/drivers/message/fusion/mptbase.h b/drivers/message/fusion/mptbase.h
index 8f14090..f0bff11 100644
--- a/drivers/message/fusion/mptbase.h
+++ b/drivers/message/fusion/mptbase.h
@@ -671,7 +671,7 @@ typedef struct _MPT_ADAPTER
u8  *HostPageBuffer; /* SAS - host page buffer 
support */
u32 HostPageBuffer_sz;
dma_addr_t  HostPageBuffer_dma;
-   int  mtrr_reg;
+   int wc_cookie;
struct pci_dev  *pcidev;/* struct pci_dev pointer */
int bars;   /* bitmask of BAR's that must 
be configured */
int msi_enable;
-- 
2.3.2.209.gd67f9d5.dirty

--
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: [Scst-devel] scst qla2xxx.ko VS kernel qla2xxx.ko

[Bart Van Assche]

On 03/20/2015 01:06 PM, Dr. Greg Wettstein wrote:

We have had the opportunity to architect, build, maintain and debug
complex converged data and storage networks.  The switches on these
networks are a million dollars apiece and there are multiple switches
in multiple data-centers.

The storage, running at about one-half petabyte levels, is all SCST
based and we use Qlogic HBA's and CNA's on both the initiators and
targets.  Given the somewhat colorful history with respect to Qlogic
target driver support we had to roll up our sleeves and write an
interface driver which allows SCST to run on top of the Qlogic target
driver in stock Linux kernels.

I just put an integrated patchset which includes SCST 3.0.0, our
target interface driver and a few patches to the in-kernel target
driver we carry to make all of this work correctly and address various
regressions in the stock target driver.  You can grab the patchset
from the following URL:

ftp://ftp.enjellic.com/pub/scst/sqa-1.2_scst-3.0.0_3.10.67.patch.gz

All of the storage targets are direct FCOE attachments using Qlogic
8362 CNA's.  The above patchset is what we are currently using in
production and it has been validated over hundreds and hundreds of
terrabytes of I/O, which includes exposure to some rather rigorous
fabric and TMF event processing situations.  We have also tracked down
some rather elusive switch based FCOE transport issues with this
codebase.

Obviously your mileage may vary.

If you drop the above patch onto a 3.10 kernel source tree and build a
kernel with the appropriate configuration options it should work with
whatever cards are supported by the stock Linux kernel.  One of the
patches which is included sets the card to QLA2XXX_INI_MODE_EXCLUSIVE
which causes the card to come up 'target capable' by default which
mirrors the behavior of the SCST supplied Qlogic target driver.

In your note you indicate your card is a 'QLogic QLE8362 - 7101674,
Sun Storage 16Gb FC PCIe Universal HBA' which I assume is probably an
OEM rebranded card.  The 8362 is actually a Converged Network Adapter
(CNA) rather then an HBA.  The 2672 is the 'fibre-channel' HBA version
of the card.  The stock Qlogic cards are dual-personality cards which
allows their operational mode, ie 16 GBPS FC or 10 GBPS ethernet, to
be selected through the BIOS setup utilities.

Given your e-mail address, I'm sure you've jumped through all these
hoops but one obviously wants to have the card setup with the right
personality and correct optics for your physical transport layer.

You also probably want to make sure you have both your HBA/CNA and
motherboard up to the most recent versions of their respective
firmware.  There are issues particularly with Intel S2600 motherboards
and these cards which requires updated firmware on both sides.

If the card is detected and found to be target capable by the stock
Linux kernel Qlogic driver you will find the available target PWWN's
in the following directory:

/sys/kernel/scst_tgt/targets/sqatgt

If there are none present there is the possibility that the card has
been modified in firmware to prohibit target mode or has a modified
PCI id which is causing problems for the driver probe logic.  If that
is the case the card isn't going to be a candidate for use in target
mode.  We tend to recommend that people buy straight Qlogic branded
cards to avoid these sorts of issues.

Just as an FYI/CYA there are session management issues/bugs in the
Qlogic target driver, regardless of breed; SCST, Qlogic SCST or
kernel.  These can show up during asynchronous fabric processing
events, particularly if you are aggressive in placing the card and
fabric under duress.

We are in the process of upgrading our patchset to 3.0.1 which will
include a number of additional fixes to the in-kernel Qlogic target
driver.  I will shoot a note off to the list when it is available if
you or others find this stuff useful.

I hope the above is helpful.


Hello Greg,

Having to download an SCST target driver that is not in the SCST tree is 
inconvenient for SCST users. If we would add your version of the SCST 
QLogic target driver in the SCST tree, would you be willing to maintain 
that target driver ? We can provide help to make sure that that driver 
builds against multiple kernel versions. If you want I can send you a 
copy of the output of the SCST nightly build process. That nightly build 
process checks whether SCST and its target drivers build correctly 
against a wide range of kernel versions.


Bart.
--
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: [Scst-devel] scst qla2xxx.ko VS kernel qla2xxx.ko

[Dr. Greg Wettstein]

On Mar 13,  4:18am, Suresh Babu Kandukuru wrote:
} Subject: Re: [Scst-devel] scst qla2xxx.ko  VS kernel qla2xxx.ko

Hi, I hope the week is closing out well for everyone.

> Thanks Bart . We have tested with 2.2.0 and 3.0.1
> (scst-svn-6135-branches-3.0.x ) ., loaded all the scst ko files
> along with qla2xxx_scst.ko qla2x00t.ko . Still this did not any FC
> ports in /sys/class/fc_hosts/.. .  The QLOGIC HBA we are using is
> "QLogic QLE8362 - 7101674, Sun Storage 16Gb FC PCIe Universal HBA,
> QLogic. " . Does the scst qla2xxx_scst.ko driver supports this
> ?. what we are missing here ?. Any pointers are helpful . Thanks

We have had the opportunity to architect, build, maintain and debug
complex converged data and storage networks.  The switches on these
networks are a million dollars apiece and there are multiple switches
in multiple data-centers.

The storage, running at about one-half petabyte levels, is all SCST
based and we use Qlogic HBA's and CNA's on both the initiators and
targets.  Given the somewhat colorful history with respect to Qlogic
target driver support we had to roll up our sleeves and write an
interface driver which allows SCST to run on top of the Qlogic target
driver in stock Linux kernels.

I just put an integrated patchset which includes SCST 3.0.0, our
target interface driver and a few patches to the in-kernel target
driver we carry to make all of this work correctly and address various
regressions in the stock target driver.  You can grab the patchset
from the following URL:

ftp://ftp.enjellic.com/pub/scst/sqa-1.2_scst-3.0.0_3.10.67.patch.gz

All of the storage targets are direct FCOE attachments using Qlogic
8362 CNA's.  The above patchset is what we are currently using in
production and it has been validated over hundreds and hundreds of
terrabytes of I/O, which includes exposure to some rather rigorous
fabric and TMF event processing situations.  We have also tracked down
some rather elusive switch based FCOE transport issues with this
codebase.

Obviously your mileage may vary.

If you drop the above patch onto a 3.10 kernel source tree and build a
kernel with the appropriate configuration options it should work with
whatever cards are supported by the stock Linux kernel.  One of the
patches which is included sets the card to QLA2XXX_INI_MODE_EXCLUSIVE
which causes the card to come up 'target capable' by default which
mirrors the behavior of the SCST supplied Qlogic target driver.

In your note you indicate your card is a 'QLogic QLE8362 - 7101674,
Sun Storage 16Gb FC PCIe Universal HBA' which I assume is probably an
OEM rebranded card.  The 8362 is actually a Converged Network Adapter
(CNA) rather then an HBA.  The 2672 is the 'fibre-channel' HBA version
of the card.  The stock Qlogic cards are dual-personality cards which
allows their operational mode, ie 16 GBPS FC or 10 GBPS ethernet, to
be selected through the BIOS setup utilities.

Given your e-mail address, I'm sure you've jumped through all these
hoops but one obviously wants to have the card setup with the right
personality and correct optics for your physical transport layer.

You also probably want to make sure you have both your HBA/CNA and
motherboard up to the most recent versions of their respective
firmware.  There are issues particularly with Intel S2600 motherboards
and these cards which requires updated firmware on both sides.

If the card is detected and found to be target capable by the stock
Linux kernel Qlogic driver you will find the available target PWWN's
in the following directory:

/sys/kernel/scst_tgt/targets/sqatgt

If there are none present there is the possibility that the card has
been modified in firmware to prohibit target mode or has a modified
PCI id which is causing problems for the driver probe logic.  If that
is the case the card isn't going to be a candidate for use in target
mode.  We tend to recommend that people buy straight Qlogic branded
cards to avoid these sorts of issues.

Just as an FYI/CYA there are session management issues/bugs in the
Qlogic target driver, regardless of breed; SCST, Qlogic SCST or
kernel.  These can show up during asynchronous fabric processing
events, particularly if you are aggressive in placing the card and
fabric under duress.

We are in the process of upgrading our patchset to 3.0.1 which will
include a number of additional fixes to the in-kernel Qlogic target
driver.  I will shoot a note off to the list when it is available if
you or others find this stuff useful.

I hope the above is helpful.

Good luck with your project.

Greg

}-- End of excerpt from Suresh Babu Kandukuru

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.   Specializing in information infra-structure
Fargo, ND  58102development.
PH: 701-281-1686
FAX: 701-281-3949   EMAIL: g...@enjellic.com
--
"If you plugged up your nose and mouth right be

Re: iSCSI regression with linux 3.9 and 4.0

[Mike Christie]

On 03/20/2015 07:57 AM, Christian Hesse wrote:
> Hello everybody!
> 
> I reported this issue at LKML [0] but received no answer. Hopefully
> linux-scsi is a better place...
> 
> Beginning with linux 3.19 I see an iSCSI regressen. This works perfectly with
> linux 3.18.x (tested with 3.18.6) and before. Effected kernels I tested are
> 3.19.0, 3.19.2 and 4.0rc4.r199.gb314aca.
> 

Could you take a wrireshark/tcpdump trace when running 3.18 and 3.19? We
can then see what bits are different and narrow down the patch/change.

--
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 15/15] iscsi-target: don't export static symbol

[Nicholas A. Bellinger]

On Wed, 2015-03-11 at 17:56 +0100, Julia Lawall wrote:
> From: Julia Lawall 
> 
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
> 
> // 
> @r@
> type T;
> identifier f;
> @@
> 
> static T f (...) { ... }
> 
> @@
> identifier r.f;
> declarer name EXPORT_SYMBOL;
> @@
> 
> -EXPORT_SYMBOL(f);
> // 
> 
> Signed-off-by: Julia Lawall 
> 
> ---
>  drivers/target/iscsi/iscsi_target.c |1 -
>  1 file changed, 1 deletion(-)
> 
> diff -u -p a/drivers/target/iscsi/iscsi_target.c 
> b/drivers/target/iscsi/iscsi_target.c
> --- a/drivers/target/iscsi/iscsi_target.c
> +++ b/drivers/target/iscsi/iscsi_target.c
> @@ -2155,7 +2155,6 @@ reject:
>   cmd->text_in_ptr = NULL;
>   return iscsit_reject_cmd(cmd, ISCSI_REASON_PROTOCOL_ERROR, buf);
>  }
> -EXPORT_SYMBOL(iscsit_handle_text_cmd);
>  
>  int iscsit_logout_closesession(struct iscsi_cmd *cmd, struct iscsi_conn 
> *conn)
>  {
> 

Applied to target-pending/for-next.

Thanks Julia!

--nab


--
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: noise in target_core_register_fabric

[Nicholas A. Bellinger]

On Wed, 2015-03-18 at 08:49 +0100, Olaf Hering wrote:
> On Wed, Mar 04, Olaf Hering wrote:
> 
> > Is there a need to fill dmesg with noise like shown below whenever
> > targetcli-3.0 runs a command? I think the pr_err calls in those functions
> > should be converted to pr_debug.
> 
> Any update on this?
> 
> > [ 1240.045518] target_core_register_fabric() trying autoload for fc
> > [ 1240.045520] target_core_get_fabric() failed for fc
> 

Hi Olaf,

Applying the following patch to target-pending/for-next.

Thank you,

--nab

>From 62554910a94a62f7b9b79cee3ca6bac95abe3c29 Mon Sep 17 00:00:00 2001
From: Nicholas Bellinger 
Date: Fri, 20 Mar 2015 11:36:50 -0700
Subject: [PATCH] target: Convert fabric module autoload failures to pr_debug

This patch converts the fabric module autoload failures from
pr_err to pr_debug in target_core_register_fabric() code, to
reduce the amount of noise during normal operation.

Reported-by: Olaf Hering 
Signed-off-by: Nicholas Bellinger 
---
 drivers/target/target_core_configfs.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/target/target_core_configfs.c 
b/drivers/target/target_core_configfs.c
index 75d89ad..69baf1c 100644
--- a/drivers/target/target_core_configfs.c
+++ b/drivers/target/target_core_configfs.c
@@ -142,8 +142,8 @@ static struct config_group *target_core_register_fabric(
 
tf = target_core_get_fabric(name);
if (!tf) {
-   pr_err("target_core_register_fabric() trying autoload for %s\n",
-   name);
+   pr_debug("target_core_register_fabric() trying autoload for 
%s\n",
+name);
 
/*
 * Below are some hardcoded request_module() calls to 
automatically
@@ -165,8 +165,8 @@ static struct config_group *target_core_register_fabric(
 */
ret = request_module("iscsi_target_mod");
if (ret < 0) {
-   pr_err("request_module() failed for"
-  " iscsi_target_mod.ko: %d\n", ret);
+   pr_debug("request_module() failed for"
+" iscsi_target_mod.ko: %d\n", ret);
return ERR_PTR(-EINVAL);
}
} else if (!strncmp(name, "loopback", 8)) {
@@ -178,8 +178,8 @@ static struct config_group *target_core_register_fabric(
 */
ret = request_module("tcm_loop");
if (ret < 0) {
-   pr_err("request_module() failed for"
-  " tcm_loop.ko: %d\n", ret);
+   pr_debug("request_module() failed for"
+" tcm_loop.ko: %d\n", ret);
return ERR_PTR(-EINVAL);
}
}
@@ -188,8 +188,8 @@ static struct config_group *target_core_register_fabric(
}
 
if (!tf) {
-   pr_err("target_core_get_fabric() failed for %s\n",
-  name);
+   pr_debug("target_core_get_fabric() failed for %s\n",
+name);
return ERR_PTR(-EINVAL);
}
pr_debug("Target_Core_ConfigFS: REGISTER -> Located fabric:"

--
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 regression with linux 3.9 and 4.0

[Christian Hesse]

Ewan Milne  on Fri, 2015/03/20 11:46:
> On Fri, 2015-03-20 at 16:24 +0100, Christian Hesse wrote:
> > I found 'max_sectors_kb' which is inside in directory called 'queue'. Is
> > that the value you asked for?
> > 
> > for 4.0 git:
> > 
> > # cat max_sectors_kb
> > 32767
> 
> If you change max_sectors_kb to a lower value (e.g. 512) can you get the
> device to work?

I will check that on monday. Sitting behind a slow dial up connection right
now...
 
> There is a max_hw_sectors_kb value but you can't change it.  Is it
> 32768 also for 4.0?

# cat max_hw_sectors_kb
32767

It's 3276*7*, not 32768.

> Your device reports a maximum transfer length of 2^32-1 blocks but
> I suspect that it might not be actually able to do that.  I don't see
> what else would be causing the error.  Maybe there is a transport
> limitation that is getting in the way?

What kind of transport limitation can that be? Network MTU and friends should
no be an issue, no?
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Chris   get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/*   gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}


pgp9LNXSP25S2.pgp
Description: OpenPGP digital signature

Re: [PATCH] scsi: sd: add a capacity_override attribute

[Ewan Milne]

On Fri, 2015-03-20 at 12:03 -0400, Alan Stern wrote:
> On Fri, 20 Mar 2015, Ewan Milne wrote:
> 
> > On Fri, 2015-03-20 at 11:19 -0400, Alan Stern wrote:
> > > On Fri, 20 Mar 2015, Ewan Milne wrote:
> > > 
> > > > On Tue, 2015-03-17 at 14:08 -0400, Alan Stern wrote:
> > > > > This patch provides a sysfs interface allowing users to override the
> > > > > capacity of a SCSI disk.  This will help in situations where a buggy
> > > > > USB-SATA adapter fails to support READ CAPACITY(16) and reports only
> > > > > the low 32 bits of the capacity in its READ CAPACITY(10) reply.  For
> > > > > an example, see this thread:
> > > > > 
> > > > >   http://marc.info/?l=linux-scsi&m=140908235510961&w=2
> > > > > 
> > > > > The interface is awkward because it requires the user to tell the
> > > > > system to re-read the disk's partition table afterward, but at least
> > > > > it provides a way to handle deficient hardware.
> > > > 
> > > > I think that it is confusing that writing into the capacity_override
> > > > sysfs node does not get immediately reflected in the gendisk structure.
> > > > Would it hurt to call sd_revalidate_disk() after the value is changed
> > > > in capacity_override_store()?
> > > 
> > > It wouldn't hurt, but it wouldn't help much either.
> > > 
> > > sd_revalidate_disk() might cause the new size to show up in the
> > > gendisk structure, but it would not cause the partition table to be
> > > parsed again.  That's the real reason for doing this -- when a drive
> > > seems to have fewer blocks than it really does, partitions that extend
> > > beyond the "end" of the drive are rejected.
> > 
> > OK, I see.
> > 
> > > 
> > > > The thing is, if someone overrides the capacity but does not do anything
> > > > right away to revalidate the disk, it could change at some arbitrary
> > > > time in the future when the revalidation happens for some other reason.
> > > 
> > > That's why the documentation says that users must force the system to 
> > > re-read the partition table after writing the sysfs attribute.  In my 
> > > tests, doing that caused a revalidation.
> > > 
> > > Are you saying that could have been a coincidence?  It's possible -- I 
> > > don't understand the design of the block layer.
> > 
> > No, I think that re-reading the partition table will revalidate.  What I
> > was concerned about is some unsuspecting user writing to the
> > capacity_override sysfs node, observing that it didn't seem to do
> > anything, and being surprised when it changed later.  (I've seen some
> > issues with multipath, for example, which will stop using a path if the
> > capacity changes.)  I guess it's a "principle of least surprise" thing.
> > 
> > Having said that, if this is what is needed to make the devices work...
> > 
> > Reviewed-by: Ewan D. Milne 
> 
> Thanks.  I don't _mind_ adding an sd_revalidate_disk() call if you 
> think it will improve the patch.  What's your suggestion?
> 

If that does not cause the partition table to be updated, then it
doesn't solve your problem, so I'd leave it the way it is, for now.

-Ewan

> Alan Stern
> 
> --
> 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] scsi: sd: add a capacity_override attribute

[Alan Stern]

On Fri, 20 Mar 2015, Ewan Milne wrote:

> On Fri, 2015-03-20 at 11:19 -0400, Alan Stern wrote:
> > On Fri, 20 Mar 2015, Ewan Milne wrote:
> > 
> > > On Tue, 2015-03-17 at 14:08 -0400, Alan Stern wrote:
> > > > This patch provides a sysfs interface allowing users to override the
> > > > capacity of a SCSI disk.  This will help in situations where a buggy
> > > > USB-SATA adapter fails to support READ CAPACITY(16) and reports only
> > > > the low 32 bits of the capacity in its READ CAPACITY(10) reply.  For
> > > > an example, see this thread:
> > > > 
> > > > http://marc.info/?l=linux-scsi&m=140908235510961&w=2
> > > > 
> > > > The interface is awkward because it requires the user to tell the
> > > > system to re-read the disk's partition table afterward, but at least
> > > > it provides a way to handle deficient hardware.
> > > 
> > > I think that it is confusing that writing into the capacity_override
> > > sysfs node does not get immediately reflected in the gendisk structure.
> > > Would it hurt to call sd_revalidate_disk() after the value is changed
> > > in capacity_override_store()?
> > 
> > It wouldn't hurt, but it wouldn't help much either.
> > 
> > sd_revalidate_disk() might cause the new size to show up in the
> > gendisk structure, but it would not cause the partition table to be
> > parsed again.  That's the real reason for doing this -- when a drive
> > seems to have fewer blocks than it really does, partitions that extend
> > beyond the "end" of the drive are rejected.
> 
> OK, I see.
> 
> > 
> > > The thing is, if someone overrides the capacity but does not do anything
> > > right away to revalidate the disk, it could change at some arbitrary
> > > time in the future when the revalidation happens for some other reason.
> > 
> > That's why the documentation says that users must force the system to 
> > re-read the partition table after writing the sysfs attribute.  In my 
> > tests, doing that caused a revalidation.
> > 
> > Are you saying that could have been a coincidence?  It's possible -- I 
> > don't understand the design of the block layer.
> 
> No, I think that re-reading the partition table will revalidate.  What I
> was concerned about is some unsuspecting user writing to the
> capacity_override sysfs node, observing that it didn't seem to do
> anything, and being surprised when it changed later.  (I've seen some
> issues with multipath, for example, which will stop using a path if the
> capacity changes.)  I guess it's a "principle of least surprise" thing.
> 
> Having said that, if this is what is needed to make the devices work...
> 
> Reviewed-by: Ewan D. Milne 

Thanks.  I don't _mind_ adding an sd_revalidate_disk() call if you 
think it will improve the patch.  What's your suggestion?

Alan Stern

--
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 regression with linux 3.9 and 4.0

[Ewan Milne]

On Fri, 2015-03-20 at 16:24 +0100, Christian Hesse wrote:
> Ewan Milne  on Fri, 2015/03/20 11:04:
> > On Fri, 2015-03-20 at 15:31 +0100, Christian Hesse wrote:
> > > Ewan Milne  on Fri, 2015/03/20 09:51:
> > > > On Fri, 2015-03-20 at 13:57 +0100, Christian Hesse wrote:
> > > > > Hello everybody!
> > > > > 
> > > > > I reported this issue at LKML [0] but received no answer. Hopefully
> > > > > linux-scsi is a better place...
> > > > > 
> > > > > Beginning with linux 3.19 I see an iSCSI regressen. This works
> > > > > perfectly with linux 3.18.x (tested with 3.18.6) and before. Effected
> > > > > kernels I tested are 3.19.0, 3.19.2 and 4.0rc4.r199.gb314aca.
> > > > > 
> > > > > The logs tell the story:
> > > > > 
> > > > > [snip log]
> > > > > 
> > > > > [0] https://lkml.org/lkml/2015/2/19/91
> > > > 
> > > > Sense key 0x5 ASC/ASCQ 0x24 0x00 is ILLEGAL REQUEST, INVALID FIELD IN
> > > > CDB.  The CDB was 2A 00 34 5B 07 FF 00 2F 88 00, which is a WRITE_10
> > > > to LBA 878381055 with a length of 12168 blocks (a little less than 6MB).
> > > > It looks like this is within the reported capacity of the device, and
> > > > there are no other bits set in the CDB.
> > > > 
> > > > Looks like you could get this error if RWWP (reject without write
> > > > protection) is set in the control mode page.  I don't see any messages
> > > > about the protection type, though.  What does sysfs report?
> > > 
> > > Is that what you are interested in?
> > > 
> > > # cat protection_mode protection_type 
> > > none
> > > 0
> > > 
> > > In case it matters: The iSCSI device is LUKS encrypted, that is why device
> > > mapper shows up.
> > > 
> > > I removed the discard option from filesystem's default mount option, but
> > > that brings no difference except the message is not printed.
> > 
> > It is most likely the device that is returning the error, there is a
> > place in the iSCSI Initiator that generates an ILLEGAL REQUEST sense,
> > but it is not the same ASC/ASCQ.
> > 
> > There was this change:
> > 
> > commit bcdb247c6b6a1f3e72b9b787b73f47dd509d17ec
> > Author: Martin K. Petersen 
> > Date:   Tue Jun 3 18:45:51 2014 -0400
> > 
> > sd: Limit transfer length
> > 
> > Until now the per-command transfer length has exclusively been gated by
> > the max_sectors parameter in the scsi_host template. Given that the size
> > of this parameter has been bumped to an unsigned int we have to be
> > careful not to exceed the target device's capabilities.
> > 
> > If the if the device specifies a Maximum Transfer Length in the Block
> > Limits VPD we'll use that value. Otherwise we'll use 0x for
> > devices that have use_16_for_rw set and 0x for the rest. We then
> > combine the chosen disk limit with max_sectors in the host template. The
> > smaller of the two will be used to set the max_hw_sectors queue limit.
> > 
> > Signed-off-by: Martin K. Petersen 
> > Reviewed-by: Ewan D. Milne 
> > Signed-off-by: Christoph Hellwig 
> > 
> > What is the value of max_sectors_kb and queue_max_sectors_kb in sysfs
> > for the device?  Is it different than what is reported on 3.18?
> 
> I found 'max_sectors_kb' which is inside in directory called 'queue'. Is that
> the value you asked for?
> 
> for 4.0 git:
> 
> # cat max_sectors_kb
> 32767

If you change max_sectors_kb to a lower value (e.g. 512) can you get the
device to work?

There is a max_hw_sectors_kb value but you can't change it.  Is it
32768 also for 4.0?

Your device reports a maximum transfer length of 2^32-1 blocks but
I suspect that it might not be actually able to do that.  I don't see
what else would be causing the error.  Maybe there is a transport
limitation that is getting in the way?

-Ewan

> 
> for 3.18.6:
> 
> # cat max_sectors_kb
> 512
> 
> > Does your target support the Block Limits VPD (page B0)?  (i.e. can
> > you run "sg_inq /dev/sda -p bl" from the sg3_utils package?)
> 
> This does not differ for different kernels. I think this is expected.
> 
> # sg_inq /dev/sdb -p bl
> VPD INQUIRY: Block limits page (SBC)
>   Maximum compare and write length: 1 blocks
>   Optimal transfer length granularity: 1 blocks
>   Maximum transfer length: 4294967295 blocks
>   Optimal transfer length: 4294967295 blocks
>   Maximum prefetch, xdread, xdwrite transfer length: 0 blocks
>   Maximum unmap LBA count: 8388607
>   Maximum unmap block descriptor count: 1
>   Optimal unmap granularity: 16383
>   Unmap granularity alignment valid: 0
>   Unmap granularity alignment: 0
>   Maximum write same length: 0x blocks
>   Maximum atomic transfer length: 0
>   Atomic alignment: 0
>   Atomic transfer length granularity: 0


--
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: sd: add a capacity_override attribute

[Ewan Milne]

On Fri, 2015-03-20 at 11:19 -0400, Alan Stern wrote:
> On Fri, 20 Mar 2015, Ewan Milne wrote:
> 
> > On Tue, 2015-03-17 at 14:08 -0400, Alan Stern wrote:
> > > This patch provides a sysfs interface allowing users to override the
> > > capacity of a SCSI disk.  This will help in situations where a buggy
> > > USB-SATA adapter fails to support READ CAPACITY(16) and reports only
> > > the low 32 bits of the capacity in its READ CAPACITY(10) reply.  For
> > > an example, see this thread:
> > > 
> > >   http://marc.info/?l=linux-scsi&m=140908235510961&w=2
> > > 
> > > The interface is awkward because it requires the user to tell the
> > > system to re-read the disk's partition table afterward, but at least
> > > it provides a way to handle deficient hardware.
> > 
> > I think that it is confusing that writing into the capacity_override
> > sysfs node does not get immediately reflected in the gendisk structure.
> > Would it hurt to call sd_revalidate_disk() after the value is changed
> > in capacity_override_store()?
> 
> It wouldn't hurt, but it wouldn't help much either.
> 
> sd_revalidate_disk() might cause the new size to show up in the
> gendisk structure, but it would not cause the partition table to be
> parsed again.  That's the real reason for doing this -- when a drive
> seems to have fewer blocks than it really does, partitions that extend
> beyond the "end" of the drive are rejected.

OK, I see.

> 
> > The thing is, if someone overrides the capacity but does not do anything
> > right away to revalidate the disk, it could change at some arbitrary
> > time in the future when the revalidation happens for some other reason.
> 
> That's why the documentation says that users must force the system to 
> re-read the partition table after writing the sysfs attribute.  In my 
> tests, doing that caused a revalidation.
> 
> Are you saying that could have been a coincidence?  It's possible -- I 
> don't understand the design of the block layer.

No, I think that re-reading the partition table will revalidate.  What I
was concerned about is some unsuspecting user writing to the
capacity_override sysfs node, observing that it didn't seem to do
anything, and being surprised when it changed later.  (I've seen some
issues with multipath, for example, which will stop using a path if the
capacity changes.)  I guess it's a "principle of least surprise" thing.

Having said that, if this is what is needed to make the devices work...

Reviewed-by: Ewan D. Milne 

> 
> Alan Stern
> 
> --
> 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: iSCSI regression with linux 3.9 and 4.0

[Christian Hesse]

Ewan Milne  on Fri, 2015/03/20 11:04:
> On Fri, 2015-03-20 at 15:31 +0100, Christian Hesse wrote:
> > Ewan Milne  on Fri, 2015/03/20 09:51:
> > > On Fri, 2015-03-20 at 13:57 +0100, Christian Hesse wrote:
> > > > Hello everybody!
> > > > 
> > > > I reported this issue at LKML [0] but received no answer. Hopefully
> > > > linux-scsi is a better place...
> > > > 
> > > > Beginning with linux 3.19 I see an iSCSI regressen. This works
> > > > perfectly with linux 3.18.x (tested with 3.18.6) and before. Effected
> > > > kernels I tested are 3.19.0, 3.19.2 and 4.0rc4.r199.gb314aca.
> > > > 
> > > > The logs tell the story:
> > > > 
> > > > [snip log]
> > > > 
> > > > [0] https://lkml.org/lkml/2015/2/19/91
> > > 
> > > Sense key 0x5 ASC/ASCQ 0x24 0x00 is ILLEGAL REQUEST, INVALID FIELD IN
> > > CDB.  The CDB was 2A 00 34 5B 07 FF 00 2F 88 00, which is a WRITE_10
> > > to LBA 878381055 with a length of 12168 blocks (a little less than 6MB).
> > > It looks like this is within the reported capacity of the device, and
> > > there are no other bits set in the CDB.
> > > 
> > > Looks like you could get this error if RWWP (reject without write
> > > protection) is set in the control mode page.  I don't see any messages
> > > about the protection type, though.  What does sysfs report?
> > 
> > Is that what you are interested in?
> > 
> > # cat protection_mode protection_type 
> > none
> > 0
> > 
> > In case it matters: The iSCSI device is LUKS encrypted, that is why device
> > mapper shows up.
> > 
> > I removed the discard option from filesystem's default mount option, but
> > that brings no difference except the message is not printed.
> 
> It is most likely the device that is returning the error, there is a
> place in the iSCSI Initiator that generates an ILLEGAL REQUEST sense,
> but it is not the same ASC/ASCQ.
> 
> There was this change:
> 
> commit bcdb247c6b6a1f3e72b9b787b73f47dd509d17ec
> Author: Martin K. Petersen 
> Date:   Tue Jun 3 18:45:51 2014 -0400
> 
> sd: Limit transfer length
> 
> Until now the per-command transfer length has exclusively been gated by
> the max_sectors parameter in the scsi_host template. Given that the size
> of this parameter has been bumped to an unsigned int we have to be
> careful not to exceed the target device's capabilities.
> 
> If the if the device specifies a Maximum Transfer Length in the Block
> Limits VPD we'll use that value. Otherwise we'll use 0x for
> devices that have use_16_for_rw set and 0x for the rest. We then
> combine the chosen disk limit with max_sectors in the host template. The
> smaller of the two will be used to set the max_hw_sectors queue limit.
> 
> Signed-off-by: Martin K. Petersen 
> Reviewed-by: Ewan D. Milne 
> Signed-off-by: Christoph Hellwig 
> 
> What is the value of max_sectors_kb and queue_max_sectors_kb in sysfs
> for the device?  Is it different than what is reported on 3.18?

I found 'max_sectors_kb' which is inside in directory called 'queue'. Is that
the value you asked for?

for 4.0 git:

# cat max_sectors_kb
32767

for 3.18.6:

# cat max_sectors_kb
512

> Does your target support the Block Limits VPD (page B0)?  (i.e. can
> you run "sg_inq /dev/sda -p bl" from the sg3_utils package?)

This does not differ for different kernels. I think this is expected.

# sg_inq /dev/sdb -p bl
VPD INQUIRY: Block limits page (SBC)
  Maximum compare and write length: 1 blocks
  Optimal transfer length granularity: 1 blocks
  Maximum transfer length: 4294967295 blocks
  Optimal transfer length: 4294967295 blocks
  Maximum prefetch, xdread, xdwrite transfer length: 0 blocks
  Maximum unmap LBA count: 8388607
  Maximum unmap block descriptor count: 1
  Optimal unmap granularity: 16383
  Unmap granularity alignment valid: 0
  Unmap granularity alignment: 0
  Maximum write same length: 0x blocks
  Maximum atomic transfer length: 0
  Atomic alignment: 0
  Atomic transfer length granularity: 0
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Chris   get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/*   gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}


pgpKyWfPxHrKe.pgp
Description: OpenPGP digital signature

Re: [PATCH] scsi: sd: add a capacity_override attribute

[Alan Stern]

On Fri, 20 Mar 2015, Ewan Milne wrote:

> On Tue, 2015-03-17 at 14:08 -0400, Alan Stern wrote:
> > This patch provides a sysfs interface allowing users to override the
> > capacity of a SCSI disk.  This will help in situations where a buggy
> > USB-SATA adapter fails to support READ CAPACITY(16) and reports only
> > the low 32 bits of the capacity in its READ CAPACITY(10) reply.  For
> > an example, see this thread:
> > 
> > http://marc.info/?l=linux-scsi&m=140908235510961&w=2
> > 
> > The interface is awkward because it requires the user to tell the
> > system to re-read the disk's partition table afterward, but at least
> > it provides a way to handle deficient hardware.
> 
> I think that it is confusing that writing into the capacity_override
> sysfs node does not get immediately reflected in the gendisk structure.
> Would it hurt to call sd_revalidate_disk() after the value is changed
> in capacity_override_store()?

It wouldn't hurt, but it wouldn't help much either.

sd_revalidate_disk() might cause the new size to show up in the
gendisk structure, but it would not cause the partition table to be
parsed again.  That's the real reason for doing this -- when a drive
seems to have fewer blocks than it really does, partitions that extend
beyond the "end" of the drive are rejected.

> The thing is, if someone overrides the capacity but does not do anything
> right away to revalidate the disk, it could change at some arbitrary
> time in the future when the revalidation happens for some other reason.

That's why the documentation says that users must force the system to 
re-read the partition table after writing the sysfs attribute.  In my 
tests, doing that caused a revalidation.

Are you saying that could have been a coincidence?  It's possible -- I 
don't understand the design of the block layer.

Alan Stern

--
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 regression with linux 3.9 and 4.0

[Ewan Milne]

On Fri, 2015-03-20 at 11:04 -0400, Ewan Milne wrote:
> Does your target support the Block Limits VPD (page B0)?  (i.e. can
> you run "sg_inq /dev/sda -p bl" from the sg3_utils package?)
> 

I meant /dev/sdb, sorry.


--
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 regression with linux 3.9 and 4.0

[Ewan Milne]

On Fri, 2015-03-20 at 15:31 +0100, Christian Hesse wrote:
> Ewan Milne  on Fri, 2015/03/20 09:51:
> > On Fri, 2015-03-20 at 13:57 +0100, Christian Hesse wrote:
> > > Hello everybody!
> > > 
> > > I reported this issue at LKML [0] but received no answer. Hopefully
> > > linux-scsi is a better place...
> > > 
> > > Beginning with linux 3.19 I see an iSCSI regressen. This works perfectly
> > > with linux 3.18.x (tested with 3.18.6) and before. Effected kernels I
> > > tested are 3.19.0, 3.19.2 and 4.0rc4.r199.gb314aca.
> > > 
> > > The logs tell the story:
> > > 
> > > Feb 19 11:26:49 thebe kernel: scsi host6: iSCSI Initiator over TCP/IP
> > > Feb 19 11:26:49 thebe kernel: scsi 6:0:0:0: Direct-Access QNAP
> > > iSCSI Storage4.0  PQ: 0 ANSI: 5 Feb 19 11:26:49 thebe kernel: sd
> > > 6:0:0:0: [sdb] 1073741824 512-byte logical blocks: (549 GB/512 GiB) Feb
> > > 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Write Protect is off Feb 19
> > > 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Mode Sense: 2f 00 00 00 Feb 19
> > > 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Write cache: disabled, read
> > > cache: enabled, doesn't support DPO or FUA Feb 19 11:26:49 thebe kernel:
> > > sdb: unknown partition table Feb 19 11:26:49 thebe kernel: sd 6:0:0:0:
> > > [sdb] Attached SCSI disk Feb 19 11:26:49 thebe iscsid[10804]:
> > > Connection1:0 to [target:
> > > iqn.2004-04.com.qnap:ts-859:iscsi.xxx.c40a18, portal:
> > > xx.xx.xx.xx,3260] through [iface: default] is operational now Feb 19
> > > 11:26:57 thebe kernel:  sdb: unknown partition table Feb 19 11:28:20
> > > thebe kernel: EXT4-fs (dm-8): mounting with "discard" option, but the
> > > device does not support discard Feb 19 11:28:20 thebe kernel: EXT4-fs
> > > (dm-8): mounted filesystem with ordered data mode. Opts: (null) Feb 19
> > > 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] UNKNOWN Result: hostbyte=0x00
> > > driverbyte=0x08 Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] Sense
> > > Key : 0x5 [current] Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb]
> > > ASC=0x24 ASCQ=0x0 Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] CDB:
> > > Feb 19 11:28:24 thebe kernel: cdb[0]=0x2a: 2a 00 34 5b 07 ff 00 2f 88 00
> > > Feb 19 11:28:24 thebe kernel: blk_update_request: critical target error,
> > > dev sdb, sector 878381055 Feb 19 11:28:24 thebe kernel: EXT4-fs warning
> > > (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503
> > > (offset 8388608 size 7278592 starting block 108749056) Feb 19 11:28:24
> > > thebe kernel: Buffer I/O error on device dm-8, logical block 108749056
> > > Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical
> > > block 108749057 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device
> > > dm-8, logical block 108749058 Feb 19 11:28:24 thebe kernel: Buffer I/O
> > > error on device dm-8, logical block 108749059 Feb 19 11:28:24 thebe
> > > kernel: Buffer I/O error on device dm-8, logical block 108749060 Feb 19
> > > 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block
> > > 108749061 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8,
> > > logical block 108749062 Feb 19 11:28:24 thebe kernel: Buffer I/O error on
> > > device dm-8, logical block 108749063 Feb 19 11:28:24 thebe kernel: Buffer
> > > I/O error on device dm-8, logical block 108749064 Feb 19 11:28:24 thebe
> > > kernel: Buffer I/O error on device dm-8, logical block 108749065 Feb 19
> > > 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317:
> > > I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592
> > > starting block 108749312) Feb 19 11:28:24 thebe kernel: EXT4-fs warning
> > > (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503
> > > (offset 8388608 size 7278592 starting block 108749568) Feb 19 11:28:24
> > > thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error
> > > -121 writing to inode 33196503 (offset 8388608 size 7278592 starting
> > > block 108749824) Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device
> > > dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset
> > > 8388608 size 7278592 starting block 108750080) Feb 19 11:28:24 thebe
> > > kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121
> > > writing to inode 33196503 (offset 8388608 size 7278592 starting block
> > > 108750336) Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] UNKNOWN
> > > Result: hostbyte=0x00 driverbyte=0x08 Feb 19 11:29:10 thebe kernel: sd
> > > 6:0:0:0: [sdb] Sense Key : 0x5 [current] Feb 19 11:29:10 thebe kernel: sd
> > > 6:0:0:0: [sdb] ASC=0x24 ASCQ=0x0 Feb 19 11:29:10 thebe kernel: sd
> > > 6:0:0:0: [sdb] CDB: Feb 19 11:29:10 thebe kernel: cdb[0]=0x2a: 2a 00 20
> > > 44 89 17 00 20 50 00 Feb 19 11:29:10 thebe kernel: blk_update_request:
> > > critical target error, dev sdb, sector 541362455 Feb 19 11:29:10 thebe
> > > kernel: Buffer I/O error on dev dm-8, logical block 66621731, lost sync
> > > page write Feb 19 11:29

Re: [PATCH] scsi: sd: add a capacity_override attribute

[Ewan Milne]

On Tue, 2015-03-17 at 14:08 -0400, Alan Stern wrote:
> This patch provides a sysfs interface allowing users to override the
> capacity of a SCSI disk.  This will help in situations where a buggy
> USB-SATA adapter fails to support READ CAPACITY(16) and reports only
> the low 32 bits of the capacity in its READ CAPACITY(10) reply.  For
> an example, see this thread:
> 
>   http://marc.info/?l=linux-scsi&m=140908235510961&w=2
> 
> The interface is awkward because it requires the user to tell the
> system to re-read the disk's partition table afterward, but at least
> it provides a way to handle deficient hardware.

I think that it is confusing that writing into the capacity_override
sysfs node does not get immediately reflected in the gendisk structure.
Would it hurt to call sd_revalidate_disk() after the value is changed
in capacity_override_store()?

The thing is, if someone overrides the capacity but does not do anything
right away to revalidate the disk, it could change at some arbitrary
time in the future when the revalidation happens for some other reason.

-Ewan

> 
> Signed-off-by: Alan Stern 
> CC: Dale R. Worley 
> 
> ---
> 
> 
> [as1777]
> 
> 
>  Documentation/ABI/testing/sysfs-class-scsi_disk |   19 
>  drivers/scsi/sd.c   |   37 
> 
>  drivers/scsi/sd.h   |1 
>  3 files changed, 57 insertions(+)
> 
> Index: usb-4.0/Documentation/ABI/testing/sysfs-class-scsi_disk
> ===
> --- /dev/null
> +++ usb-4.0/Documentation/ABI/testing/sysfs-class-scsi_disk
> @@ -0,0 +1,19 @@
> +What:
> /sys/class/scsi_disk/HOST:CHANNEL:TARGET:LUN/capacity_override
> +Date:March 2015
> +KernelVersion:   4.1
> +Contact: Alan Stern 
> +Description:
> + This file provides a way for users to override the
> + automatically determined disk capacity.  For example, some
> + buggy USB-SATA adapters report only the low 32 bits of a
> + drive's block count, resulting in a calculated capacity
> + value that is the actual capacity modulo 2 TB.
> +
> + After the correct capacity (in native-size blocks -- often
> + 512 bytes per block but sometimes 4096) is written to this
> + file, the user must tell the system to re-read the disk's
> + partition table by running the command:
> +
> + /usr/sbin/blockdev --rereadpt /dev/sdX
> +
> + where X is the disk's drive letter.
> Index: usb-4.0/drivers/scsi/sd.h
> ===
> --- usb-4.0.orig/drivers/scsi/sd.h
> +++ usb-4.0/drivers/scsi/sd.h
> @@ -66,6 +66,7 @@ struct scsi_disk {
>   struct gendisk  *disk;
>   atomic_topeners;
>   sector_tcapacity;   /* size in 512-byte sectors */
> + sector_tcapacity_override;  /* in native-size blocks */
>   u32 max_xfer_blocks;
>   u32 max_ws_blocks;
>   u32 max_unmap_blocks;
> Index: usb-4.0/drivers/scsi/sd.c
> ===
> --- usb-4.0.orig/drivers/scsi/sd.c
> +++ usb-4.0/drivers/scsi/sd.c
> @@ -477,6 +477,35 @@ max_write_same_blocks_store(struct devic
>  }
>  static DEVICE_ATTR_RW(max_write_same_blocks);
>  
> +static ssize_t
> +capacity_override_show(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct scsi_disk *sdkp = to_scsi_disk(dev);
> +
> + return sprintf(buf, "%llu\n",
> + (unsigned long long) sdkp->capacity_override);
> +}
> +
> +static ssize_t
> +capacity_override_store(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct scsi_disk *sdkp = to_scsi_disk(dev);
> + unsigned long long cap;
> + int err;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EACCES;
> +
> + err = kstrtoull(buf, 10, &cap);
> + if (err)
> + return err;
> + sdkp->capacity_override = cap;
> + return count;
> +}
> +static DEVICE_ATTR_RW(capacity_override);
> +
>  static struct attribute *sd_disk_attrs[] = {
>   &dev_attr_cache_type.attr,
>   &dev_attr_FUA.attr,
> @@ -489,6 +518,7 @@ static struct attribute *sd_disk_attrs[]
>   &dev_attr_provisioning_mode.attr,
>   &dev_attr_max_write_same_blocks.attr,
>   &dev_attr_max_medium_access_timeouts.attr,
> + &dev_attr_capacity_override.attr,
>   NULL,
>  };
>  ATTRIBUTE_GROUPS(sd_disk);
> @@ -2152,6 +2182,13 @@ sd_read_capacity(struct scsi_disk *sdkp,
>   struct scsi_device *sdp = sdkp->device;
>   sector_t old_capacity = sdkp->capacity;
>  
> + /* Did the user override the reported capacity? */
> + if (!sdkp->first_scan && sdkp->capacity_override) {
> + sector_

Re: iSCSI regression with linux 3.9 and 4.0

[Christian Hesse]

Ewan Milne  on Fri, 2015/03/20 09:51:
> On Fri, 2015-03-20 at 13:57 +0100, Christian Hesse wrote:
> > Hello everybody!
> > 
> > I reported this issue at LKML [0] but received no answer. Hopefully
> > linux-scsi is a better place...
> > 
> > Beginning with linux 3.19 I see an iSCSI regressen. This works perfectly
> > with linux 3.18.x (tested with 3.18.6) and before. Effected kernels I
> > tested are 3.19.0, 3.19.2 and 4.0rc4.r199.gb314aca.
> > 
> > The logs tell the story:
> > 
> > Feb 19 11:26:49 thebe kernel: scsi host6: iSCSI Initiator over TCP/IP
> > Feb 19 11:26:49 thebe kernel: scsi 6:0:0:0: Direct-Access QNAP
> > iSCSI Storage4.0  PQ: 0 ANSI: 5 Feb 19 11:26:49 thebe kernel: sd
> > 6:0:0:0: [sdb] 1073741824 512-byte logical blocks: (549 GB/512 GiB) Feb
> > 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Write Protect is off Feb 19
> > 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Mode Sense: 2f 00 00 00 Feb 19
> > 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Write cache: disabled, read
> > cache: enabled, doesn't support DPO or FUA Feb 19 11:26:49 thebe kernel:
> > sdb: unknown partition table Feb 19 11:26:49 thebe kernel: sd 6:0:0:0:
> > [sdb] Attached SCSI disk Feb 19 11:26:49 thebe iscsid[10804]:
> > Connection1:0 to [target:
> > iqn.2004-04.com.qnap:ts-859:iscsi.xxx.c40a18, portal:
> > xx.xx.xx.xx,3260] through [iface: default] is operational now Feb 19
> > 11:26:57 thebe kernel:  sdb: unknown partition table Feb 19 11:28:20
> > thebe kernel: EXT4-fs (dm-8): mounting with "discard" option, but the
> > device does not support discard Feb 19 11:28:20 thebe kernel: EXT4-fs
> > (dm-8): mounted filesystem with ordered data mode. Opts: (null) Feb 19
> > 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] UNKNOWN Result: hostbyte=0x00
> > driverbyte=0x08 Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] Sense
> > Key : 0x5 [current] Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb]
> > ASC=0x24 ASCQ=0x0 Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] CDB:
> > Feb 19 11:28:24 thebe kernel: cdb[0]=0x2a: 2a 00 34 5b 07 ff 00 2f 88 00
> > Feb 19 11:28:24 thebe kernel: blk_update_request: critical target error,
> > dev sdb, sector 878381055 Feb 19 11:28:24 thebe kernel: EXT4-fs warning
> > (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503
> > (offset 8388608 size 7278592 starting block 108749056) Feb 19 11:28:24
> > thebe kernel: Buffer I/O error on device dm-8, logical block 108749056
> > Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical
> > block 108749057 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device
> > dm-8, logical block 108749058 Feb 19 11:28:24 thebe kernel: Buffer I/O
> > error on device dm-8, logical block 108749059 Feb 19 11:28:24 thebe
> > kernel: Buffer I/O error on device dm-8, logical block 108749060 Feb 19
> > 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block
> > 108749061 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8,
> > logical block 108749062 Feb 19 11:28:24 thebe kernel: Buffer I/O error on
> > device dm-8, logical block 108749063 Feb 19 11:28:24 thebe kernel: Buffer
> > I/O error on device dm-8, logical block 108749064 Feb 19 11:28:24 thebe
> > kernel: Buffer I/O error on device dm-8, logical block 108749065 Feb 19
> > 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317:
> > I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592
> > starting block 108749312) Feb 19 11:28:24 thebe kernel: EXT4-fs warning
> > (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503
> > (offset 8388608 size 7278592 starting block 108749568) Feb 19 11:28:24
> > thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error
> > -121 writing to inode 33196503 (offset 8388608 size 7278592 starting
> > block 108749824) Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device
> > dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset
> > 8388608 size 7278592 starting block 108750080) Feb 19 11:28:24 thebe
> > kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121
> > writing to inode 33196503 (offset 8388608 size 7278592 starting block
> > 108750336) Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] UNKNOWN
> > Result: hostbyte=0x00 driverbyte=0x08 Feb 19 11:29:10 thebe kernel: sd
> > 6:0:0:0: [sdb] Sense Key : 0x5 [current] Feb 19 11:29:10 thebe kernel: sd
> > 6:0:0:0: [sdb] ASC=0x24 ASCQ=0x0 Feb 19 11:29:10 thebe kernel: sd
> > 6:0:0:0: [sdb] CDB: Feb 19 11:29:10 thebe kernel: cdb[0]=0x2a: 2a 00 20
> > 44 89 17 00 20 50 00 Feb 19 11:29:10 thebe kernel: blk_update_request:
> > critical target error, dev sdb, sector 541362455 Feb 19 11:29:10 thebe
> > kernel: Buffer I/O error on dev dm-8, logical block 66621731, lost sync
> > page write Feb 19 11:29:10 thebe kernel: Aborting journal on device
> > dm-8-8. Feb 19 11:29:10 thebe kernel: EXT4-fs error (device dm-8):
> > ext4_journal_check_start:56: Detected aborted journal Feb 19 11:29:10
> > thebe ke

Re: iSCSI regression with linux 3.9 and 4.0

[Ewan Milne]

On Fri, 2015-03-20 at 13:57 +0100, Christian Hesse wrote:
> Hello everybody!
> 
> I reported this issue at LKML [0] but received no answer. Hopefully
> linux-scsi is a better place...
> 
> Beginning with linux 3.19 I see an iSCSI regressen. This works perfectly with
> linux 3.18.x (tested with 3.18.6) and before. Effected kernels I tested are
> 3.19.0, 3.19.2 and 4.0rc4.r199.gb314aca.
> 
> The logs tell the story:
> 
> Feb 19 11:26:49 thebe kernel: scsi host6: iSCSI Initiator over TCP/IP
> Feb 19 11:26:49 thebe kernel: scsi 6:0:0:0: Direct-Access QNAP iSCSI 
> Storage4.0  PQ: 0 ANSI: 5
> Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] 1073741824 512-byte logical 
> blocks: (549 GB/512 GiB)
> Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Write Protect is off
> Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Mode Sense: 2f 00 00 00
> Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Write cache: disabled, read 
> cache: enabled, doesn't support DPO or FUA
> Feb 19 11:26:49 thebe kernel:  sdb: unknown partition table
> Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Attached SCSI disk
> Feb 19 11:26:49 thebe iscsid[10804]: Connection1:0 to [target: 
> iqn.2004-04.com.qnap:ts-859:iscsi.xxx.c40a18, portal: xx.xx.xx.xx,3260] 
> through [iface: default] is operational now
> Feb 19 11:26:57 thebe kernel:  sdb: unknown partition table
> Feb 19 11:28:20 thebe kernel: EXT4-fs (dm-8): mounting with "discard" option, 
> but the device does not support discard
> Feb 19 11:28:20 thebe kernel: EXT4-fs (dm-8): mounted filesystem with ordered 
> data mode. Opts: (null)
> Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] UNKNOWN Result: hostbyte=0x00 
> driverbyte=0x08
> Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] Sense Key : 0x5 [current]
> Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] ASC=0x24 ASCQ=0x0
> Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] CDB: 
> Feb 19 11:28:24 thebe kernel: cdb[0]=0x2a: 2a 00 34 5b 07 ff 00 2f 88 00
> Feb 19 11:28:24 thebe kernel: blk_update_request: critical target error, dev 
> sdb, sector 878381055
> Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): 
> ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 
> size 7278592 starting block 108749056)
> Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
> 108749056
> Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
> 108749057
> Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
> 108749058
> Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
> 108749059
> Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
> 108749060
> Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
> 108749061
> Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
> 108749062
> Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
> 108749063
> Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
> 108749064
> Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
> 108749065
> Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): 
> ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 
> size 7278592 starting block 108749312)
> Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): 
> ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 
> size 7278592 starting block 108749568)
> Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): 
> ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 
> size 7278592 starting block 108749824)
> Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): 
> ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 
> size 7278592 starting block 108750080)
> Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): 
> ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 
> size 7278592 starting block 108750336)
> Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] UNKNOWN Result: hostbyte=0x00 
> driverbyte=0x08
> Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] Sense Key : 0x5 [current]
> Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] ASC=0x24 ASCQ=0x0
> Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] CDB: 
> Feb 19 11:29:10 thebe kernel: cdb[0]=0x2a: 2a 00 20 44 89 17 00 20 50 00
> Feb 19 11:29:10 thebe kernel: blk_update_request: critical target error, dev 
> sdb, sector 541362455
> Feb 19 11:29:10 thebe kernel: Buffer I/O error on dev dm-8, logical block 
> 66621731, lost sync page write
> Feb 19 11:29:10 thebe kernel: Aborting journal on device dm-8-8.
> Feb 19 11:29:10 thebe kernel: EXT4-fs error (device dm-8): 
> ext4_journal_check_start:56: Detected aborted journal
> Feb 19 11:29:10 thebe kernel: EXT4-fs (dm-8): Remounting filesystem read-only
> Feb 19 11:29:20 thebe kernel: EXT4-fs error (device dm

iSCSI regression with linux 3.9 and 4.0

[Christian Hesse]

Hello everybody!

I reported this issue at LKML [0] but received no answer. Hopefully
linux-scsi is a better place...

Beginning with linux 3.19 I see an iSCSI regressen. This works perfectly with
linux 3.18.x (tested with 3.18.6) and before. Effected kernels I tested are
3.19.0, 3.19.2 and 4.0rc4.r199.gb314aca.

The logs tell the story:

Feb 19 11:26:49 thebe kernel: scsi host6: iSCSI Initiator over TCP/IP
Feb 19 11:26:49 thebe kernel: scsi 6:0:0:0: Direct-Access QNAP iSCSI 
Storage4.0  PQ: 0 ANSI: 5
Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] 1073741824 512-byte logical 
blocks: (549 GB/512 GiB)
Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Write Protect is off
Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Mode Sense: 2f 00 00 00
Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Write cache: disabled, read 
cache: enabled, doesn't support DPO or FUA
Feb 19 11:26:49 thebe kernel:  sdb: unknown partition table
Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Attached SCSI disk
Feb 19 11:26:49 thebe iscsid[10804]: Connection1:0 to [target: 
iqn.2004-04.com.qnap:ts-859:iscsi.xxx.c40a18, portal: xx.xx.xx.xx,3260] 
through [iface: default] is operational now
Feb 19 11:26:57 thebe kernel:  sdb: unknown partition table
Feb 19 11:28:20 thebe kernel: EXT4-fs (dm-8): mounting with "discard" option, 
but the device does not support discard
Feb 19 11:28:20 thebe kernel: EXT4-fs (dm-8): mounted filesystem with ordered 
data mode. Opts: (null)
Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] UNKNOWN Result: hostbyte=0x00 
driverbyte=0x08
Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] Sense Key : 0x5 [current]
Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] ASC=0x24 ASCQ=0x0
Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] CDB: 
Feb 19 11:28:24 thebe kernel: cdb[0]=0x2a: 2a 00 34 5b 07 ff 00 2f 88 00
Feb 19 11:28:24 thebe kernel: blk_update_request: critical target error, dev 
sdb, sector 878381055
Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: 
I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting 
block 108749056)
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
108749056
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
108749057
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
108749058
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
108749059
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
108749060
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
108749061
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
108749062
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
108749063
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
108749064
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 
108749065
Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: 
I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting 
block 108749312)
Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: 
I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting 
block 108749568)
Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: 
I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting 
block 108749824)
Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: 
I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting 
block 108750080)
Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: 
I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting 
block 108750336)
Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] UNKNOWN Result: hostbyte=0x00 
driverbyte=0x08
Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] Sense Key : 0x5 [current]
Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] ASC=0x24 ASCQ=0x0
Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] CDB: 
Feb 19 11:29:10 thebe kernel: cdb[0]=0x2a: 2a 00 20 44 89 17 00 20 50 00
Feb 19 11:29:10 thebe kernel: blk_update_request: critical target error, dev 
sdb, sector 541362455
Feb 19 11:29:10 thebe kernel: Buffer I/O error on dev dm-8, logical block 
66621731, lost sync page write
Feb 19 11:29:10 thebe kernel: Aborting journal on device dm-8-8.
Feb 19 11:29:10 thebe kernel: EXT4-fs error (device dm-8): 
ext4_journal_check_start:56: Detected aborted journal
Feb 19 11:29:10 thebe kernel: EXT4-fs (dm-8): Remounting filesystem read-only
Feb 19 11:29:20 thebe kernel: EXT4-fs error (device dm-8): ext4_put_super:780: 
Couldn't clean up the journal

[0] https://lkml.org/lkml/2015/2/19/91
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Chris   get my mail address:*/=0;

Re: use dedicated storage for scsi_debug LUNs

[Olaf Hering]

On Fri, Mar 06, Martin K. Petersen wrote:

> > "Olaf" == Olaf Hering  writes:
> Olaf> Does that target code offer what scsi_debug offers, a bunch of
> Olaf> stuff listable with 'lsscsi'? The latter can be passed to
> Olaf> backstores/pscsi.
> Yes.

Indeed, with /backstores/fileio/ and /loopback/.

It would be nice if one could specify a fixed identifier for each fileio
during creation. Right now the symlinks in /dev/disk/by-*/* are all
random. Its not easily possible to map file_or_dev=$file to the
resulting SCSI device.

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