Christoph Hellwig | 30 Sep 17:20 2014

[PATCH] scsi: add a CONFIG_SCSI_MQ_DEFAULT option

Add a Kconfig option to enable the blk-mq path for SCSI by default
to ease testing and deployment in setups that know they benefit
from blk-mq.

Signed-off-by: Christoph Hellwig <hch <at>>
 drivers/scsi/Kconfig | 11 +++++++++++
 drivers/scsi/scsi.c  |  4 ++++
 2 files changed, 15 insertions(+)

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 18a3358..71b0877 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
 <at>  <at>  -45,6 +45,17  <at>  <at>  config SCSI_NETLINK
 	default	n
 	select NET

+	bool "SCSI: use blk-mq I/O path by default"
+	depends on SCSI
+	---help---
+	  This option enables the new blk-mq based I/O path for SCSI
+	  devices by default.  With the option the scsi_mod.use_blk_mq
+	  module/boot option defaults to Y, without it to N, but it can
+	  still be overriden either way.
+	  If unsure say N.
 config SCSI_PROC_FS
(Continue reading)

Christoph Hellwig | 30 Sep 17:20 2014

[PATCH 1/2] sg: fix sparse __user annotation warning

blk_trace_setup takes a __user pointer, so use the local void __user *
pointer instead of casting the argument to char * for it in the sg
ioctl handler.

Signed-off-by: Christoph Hellwig <hch <at>>
 drivers/scsi/sg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 01cf888..b94435b 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
 <at>  <at>  -1138,7 +1138,7  <at>  <at>  sg_ioctl(struct file *filp, unsigned int cmd_in, unsigned long arg)
 				       MKDEV(SCSI_GENERIC_MAJOR, sdp->index),
-				       (char *)arg);
+				       p);
 		return blk_trace_startstop(sdp->device->request_queue, 1);


To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at>
More majordomo info at

(Continue reading)

Hannes Reinecke | 30 Sep 13:50 2014

[PATCHv4 00/23] scsi logging update (the boring part)

Hi all,

after the feedback from v3 I've decided to split off the printk
changes to a second patchset, to be applied on top of this.
So this patchset just contains some logging updates, code
reshuffling and sanity fixes. Nothing major.
Most of it has already been reviewed.

Hannes Reinecke (23):
  Remove scsi_cmd_print_sense_hdr()
  sd: Remove scsi_print_sense() in sd_done()
  aha152x: Debug output update and whitespace cleanup
  scsi: introduce sdev_prefix_printk()
  scsi: Use sdev as argument for sense code printing
  acornscsi: use scsi_print_command()
  fas216: Update logging messages
  53c700: remove scsi_print_sense() usage
  scsi: stop decoding if scsi_normalize_sense() fails
  scsi: do not decode sense extras
  scsi: use 'bool' as return value for scsi_normalize_sense()
  scsi: remove scsi_print_status()
  Implement scsi_opcode_sa_name
  scsi: merge print_opcode_name()
  scsi: consolidate opcode lookup in scsi_opcode_sa_name()
  scsi: remove last argument from print_opcode_name()
  scsi: Remove scsi_print_command when calling abort
  scsi: separate out scsi_(host|driver)byte_string()
  sd: Cleanup logging
  scsi: simplify scsi_log_(send|completion)
  scsi: fixup logging messages in scsi_error.c
(Continue reading)

Luigi Tarenga | 30 Sep 10:52 2014

targetcli do not show iscsi

hi everybody,
I write to you for a problem that sound as my simple mistake
but I can't really find a solution after googling and reading
official doc.

I'm trying to configure a iscsi target on a centos 6.5 box with
a custom kernel compiled from vanilla 3.16.3.

I have compile:

I mount configfs:
# mount | grep config
configfs on /sys/kernel/config type configfs (rw)

manually load iscsi_target_mod (and this show nothing in dmesg)

and when I run targetcli ls command this is the output:
# targetcli ls
o- / 
..................................................................... [...]
   o- backstores 
.......................................................... [...]
   | o- block ................................................ [0 
Storage Object]
   | o- fileio ............................................... [0 
Storage Object]
   | o- pscsi ................................................ [0 
(Continue reading)

michaelc | 29 Sep 20:55 2014

[PATCH 0/2] iscsi patches for 3.18

A couple patches made over the scsi-queue drivers-for-3.18 branch.
They just fix a possible bug with be2iscsi that Dan reported and
also export the iscsi port being used.

To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at>
More majordomo info at

Hannes Reinecke | 29 Sep 13:58 2014

[PATCHv3 00/38] scsi logging update

Hi all,

here's the third version of my scsi logging updates.
Main (and most important) difference to the previous
patchset is that the stacksize does not increase when
printing SCSI CDBs, so the objection from hch should
be resolved with this.

To achieve this I've split up vprintk_emit() into two
functions, the original vprintk_emit() which formats
the string into an on-stack buffer and printk_emit_string()
which just ships out a pre-formatted string.
With that printk_emit_string() doesn't need to allocate
a buffer on stack, and I can use this reduced stack
usage to provide my own on-stack buffer, thereby using
the same stack size as the original version.

Unfortunately I've had to modify kernel/printk/printk.c,
but then printk_emit_string() looks as if it'd be useful
for others, too, so with a bit of luck I'll get away with it.

I've been using the (not yet released) patchset from
Steven Rostedt for moving seq_buf into lib; but he promised
me to send it upstream shortly. If that poses a problem it's
fairly straightforward to move it to scnprintf() etc.

And I've included tons of suggestions from Robert Elliott;
thanks for this.

As usual, comments and reviews are welcome.
(Continue reading)

Hannes Reinecke | 29 Sep 13:47 2014

[PATCH] megaraid_sas: Enable shared tag map

Megaraid_sas uses a shared pool of commands per HBA, so we
should be enabling a shared tag map.
This will allow the I/O scheduler to make better scheduling
decisions and will avoid BUSY states in the driver.

Signed-off-by: Hannes Reinecke <hare <at>>
 drivers/scsi/megaraid/megaraid_sas_base.c | 34 ++++++++++++++++++++++++++++++-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c
index f6a69a3..996fa9a 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
 <at>  <at>  -1659,7 +1659,7  <at>  <at>  static int megasas_slave_configure(struct scsi_device *sdev)
+	sdev->tagged_supported = 1;
 	return 0;

 <at>  <at>  -1667,6 +1667,10  <at>  <at>  static int megasas_slave_alloc(struct scsi_device *sdev)
 	u16             pd_index = 0;
 	struct megasas_instance *instance ;
+	/* We have a shared tag map, so TCQ is always supported */
+	sdev->tagged_supported = 1;
(Continue reading)

Dolev Raviv | 29 Sep 12:32 2014

[PATCH 1/2] scsi: fix sparse warning

This patch fixes newly introduced sparse warning, introduced by
"scis: fixing the "type" for well known LUs".

Sparse warning:
>> drivers/scsi/scsi_scan.c:825: warning: format '%16p' expects type
				'void *', but argument 6 has type 'u64'

Signed-off-by: Dolev Raviv <draviv <at>>

diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index c6c5716..74b28c9 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
 <at>  <at>  -813,8 +813,8  <at>  <at>  static int scsi_add_lun(struct scsi_device *sdev, unsigned char *inq_result,
 		if (scsi_is_wlun(sdev->lun) && sdev->type != TYPE_WLUN) {
 			sdev_printk(KERN_WARNING, sdev,
-				"%s: correcting incorrect peripheral device type 0x%x for W-LUN 0x%16phN\n",
-				__func__, sdev->type, sdev->lun);
+				"%s: correcting incorrect peripheral device type 0x%x for W-LUN 0x%16xhN\n",
+				__func__, sdev->type, (unsigned int)sdev->lun);
 			sdev->type = TYPE_WLUN;



QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
(Continue reading)

Mr. Philip Morise | 29 Sep 11:02 2014

I never forget you

I never forget you

How are you with your family? I hope fine. I'm happy to inform you about my success in getting those funds
transferred under the cooperation of a new partner from   Venezuela, Presently i'm in Venezuela,
meanwhile I didn't forget your past efforts to assist me in transferring those funds despite that it
failed us some how.

Now contact my secretary in Benin Republic West Africa through her e-mail id
(mrs.susandonaldroach <at> her to send you the A.T.M CARD worths sum of ($8.5M US Dollars)
which I kept for your compensation for all the past efforts and attempts to assist me in this transaction.
so feel free and get in touch with my secretary mrs.susan donald roach she will send the A.T.M VISA CARD to you.


Mr. Philip  Morise

To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at>
More majordomo info at

Menny_Hamburger | 28 Sep 16:36 2014

Question regarding timeout handling in scsi_io_completion


A recent patch added a timeout into scsi_io_completion in order to avoid infinite command retries.
In the case where we have a failed device and the device cannot recover from the error state:
If in this case 'error' is left as 0, could this cause issues in the DM layer (mpath for example), which does
not mark the device as failed and continues to queue requests?

To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at>
More majordomo info at

Andras Kovacs | 27 Sep 00:14 2014

blk-mq, scsi-mq, UFS

Hi all,

could someone explain to me:

- what is the difference between blk-mq and scsi-mq
- why don't I observe large speedups when running the same tiotests on Linux
v3.12 (which has no blk-mq) and Linux v3.14 (which does have blk-mq) on a
Xilinx Zynq development board (the two Linux versions are configured by
Xilinx Zynq and I know only how to add kernel command line parameters)?
- when Linux v3.17 becomes available (and Xilinx Zynq ports it for their
development board) will I see large speedups reading/writing to the target
SDD (which is driven through the UFS driver)?

Any and all info would be greatly appreciated.

To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at>
More majordomo info at