Re: Re: [PATCH 1/3] scsi/trace: Use macros for getting driver byte, host byte, msg byte, and status byte
(2014/09/02 0:15), Christoph Hellwig wrote: On Mon, Sep 01, 2014 at 12:33:28PM +, Yoshihiro YUNOMAE wrote: For getting driver byte, host byte, msg byte, and status byte, macros are implemented in scsi/scsi.h, so we use it. As mentioned about three times in various previous scsi logging discussions this is entirely wrong and breaks decoding binary trace buffers. No, this patch uses just macros, so this does not change decoders. However, other patches change decoders in format files, so we need to consider about these decoders more, as you say. We'll discuss on https://lkml.org/lkml/2014/8/28/657. Thanks, Yoshihiro YUNOMAE -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [uas/3.16.1] panic in uas_data_cmplt()
Hi, On 09/02/2014 06:18 AM, Chunwei Chen wrote: Dear all: The kernel version is 3.16.1-1-ARCH Today I keep getting this panic when booting up. http://i.imgur.com/0Rx93Kr.jpg It might be that the UAS device was in some strange state, because that after I unplugged and power-cycled the UAS, everything went normal again. Does anyone know what's the root cause of this issue? Or could anyone provide some instruction on how to debug this issue? There seem to be some issues in the error handling paths of the uas driver. I plan to rewrite them completely for robustness and go through them with a fine comb to fix any possible bugs while at it. I'll send out a mail when I've a new version ready for testing. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [uas/3.16.1] panic in uas_data_cmplt()
On 西元2014年09月02日 14:50, Hans de Goede wrote: Hi, On 09/02/2014 06:18 AM, Chunwei Chen wrote: Dear all: The kernel version is 3.16.1-1-ARCH Today I keep getting this panic when booting up. http://i.imgur.com/0Rx93Kr.jpg It might be that the UAS device was in some strange state, because that after I unplugged and power-cycled the UAS, everything went normal again. Does anyone know what's the root cause of this issue? Or could anyone provide some instruction on how to debug this issue? There seem to be some issues in the error handling paths of the uas driver. I plan to rewrite them completely for robustness and go through them with a fine comb to fix any possible bugs while at it. I'll send out a mail when I've a new version ready for testing. Regards, Hans Hi Hans, Thanks for looking into this. Kind regards, Chunwei -- 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: Adaptec 71605H HBA randomly failing to detect any drives at init
On Mon, Sep 1, 2014 at 9:36 PM, Andrew Robertson andyrobertson...@gmail.com wrote: Hi, I have an Adaptec 71605H HBA that's randomly failing to detect any drives at boot. I have two systems with this HBA, and both are showing the exact same behavior. I can reproduce this randomly about 3 out of 4 times, where most of the time it comes up where lsscsi shows no drives attached (other than my boot disk, not attached to this HBA) - but then occasionally it works fine (~1 out of 4 reboots) and detects the drives. On a good boot, the kernel messages include: [ 27.575091] pm80xx pm8001_exec_internal_task_abort 834:TMF task timeout. [ 27.754640] sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 tries: 1 On a bad boot, it doesn't include these messages; instead it hangs for ~60 seconds after Enter sas_scsi_recover_host busy and then just continues to boot (and that seems to never recover). It also never cleanly shuts down in this state (it hangs forever on modprobe -q -r ipmi_devintf and I have to power-cycle the machine -- I suspect this is more of a symptom that the kernel is busy doing other things - possibly still trying to init scsi - isntead an ipmi-specific issue). I'm happy to test patches/etc on this system if necessary -- and/or if someone can help point me in the right direction, I'd appreciate it. Hi Andy, Can you share the following details? 1. Fw version in the card you have. Use below command to get the fw_version sys file. 2. Expander and drive details and how you connected it to HBA? 3. Can you enable full logs and hot plug the expander/devices and share the log if the discovery fails. Find /sys -iname fw_version Find /sys -iname logging_level Echo oxfff logging_level sys file Also can you test with latest Linux stable release? Thanks, Suresh Thanks, Andy
Re: Adaptec 71605H HBA randomly failing to detect any drives at init
Le Mon, 1 Sep 2014 09:06:46 -0700 Andrew Robertson andyrobertson...@gmail.com écrivait: I'm happy to test patches/etc on this system if necessary -- and/or if someone can help point me in the right direction, I'd appreciate it. In my experience the 7xxx5 are very sensitive to cable length and backplane type: basically work fine with 50 cm cables, and fails with 80 cm cables with some backplanes (works with Supermicro, not with AIC, etc). So what is the backplane and cables you're using? -- Emmanuel Florac | Direction technique | Intellique | eflo...@intellique.com | +33 1 78 94 84 02 -- 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] SCSI: Don't store LUN bits in CDB[1] for USB mass-storage devices
The SCSI specification requires that the second Command Data Byte
should contain the LUN value in its high-order bits if the recipient
device reports SCSI level 2 or below. Nevertheless, some USB
mass-storage devices use those bits for other purposes in
vendor-specific commands. Currently Linux has no way to send such
commands, because the SCSI stack always overwrites the LUN bits.
Testing shows that Windows 7 and XP do not store the LUN bits in the
CDB when sending commands to a USB device. This doesn't matter if the
device uses the Bulk-Only or UAS transports (which virtually all
modern USB mass-storage devices do), as these have a separate
mechanism for sending the LUN value.
Therefore this patch introduces a flag in the Scsi_Host structure to
inform the SCSI midlayer that a transport does not require the LUN
bits to be stored in the CDB, and it makes usb-storage set this flag
for all devices using the Bulk-Only transport. (UAS is handled by a
separate driver, but it doesn't really matter because no SCSI-2 or
lower device is at all likely to use UAS.)
The patch also cleans up the code responsible for storing the LUN
value by adding a bitflag to the scsi_device structure. The test for
whether to stick the LUN value in the CDB can be made when the device
is probed, and stored for future use rather than being made over and
over in the fast path.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Reported-by: Tiziano Bacocco tiziano.baco...@gmail.com
Acked-by: Christoph Hellwig h...@lst.de
Acked-by: Martin K. Petersen martin.peter...@oracle.com
Acked-by: James Bottomley james.bottom...@hansenpartnership.com
---
[as1762]
drivers/scsi/scsi.c|8 ++--
drivers/scsi/scsi_scan.c | 10 ++
drivers/scsi/scsi_sysfs.c | 12
drivers/usb/storage/usb.c |8
include/scsi/scsi_device.h |1 +
include/scsi/scsi_host.h |3 +++
6 files changed, 36 insertions(+), 6 deletions(-)
Index: usb-3.16/include/scsi/scsi_host.h
===
--- usb-3.16.orig/include/scsi/scsi_host.h
+++ usb-3.16/include/scsi/scsi_host.h
@@ -692,6 +692,9 @@ struct Scsi_Host {
*/
struct workqueue_struct *tmf_work_q;
+ /* The transport requires the LUN bits NOT to be stored in CDB[1] */
+ unsigned no_scsi2_lun_in_cdb:1;
+
/*
* Value host_blocked counts down from
*/
Index: usb-3.16/include/scsi/scsi_device.h
===
--- usb-3.16.orig/include/scsi/scsi_device.h
+++ usb-3.16/include/scsi/scsi_device.h
@@ -174,6 +174,7 @@ struct scsi_device {
unsigned wce_default_on:1; /* Cache is ON by default */
unsigned no_dif:1; /* T10 PI (DIF) should be disabled */
unsigned broken_fua:1; /* Don't set FUA bit */
+ unsigned lun_in_cdb:1; /* Store LUN bits in CDB[1] */
atomic_t disk_events_disable_depth; /* disable depth for disk events */
Index: usb-3.16/drivers/scsi/scsi.c
===
--- usb-3.16.orig/drivers/scsi/scsi.c
+++ usb-3.16/drivers/scsi/scsi.c
@@ -670,14 +670,10 @@ int scsi_dispatch_cmd(struct scsi_cmnd *
return SCSI_MLQUEUE_DEVICE_BUSY;
}
- /*
-* If SCSI-2 or lower, store the LUN value in cmnd.
-*/
- if (cmd-device-scsi_level = SCSI_2
- cmd-device-scsi_level != SCSI_UNKNOWN) {
+ /* Store the LUN value in cmnd, if needed. */
+ if (cmd-device-lun_in_cdb)
cmd-cmnd[1] = (cmd-cmnd[1] 0x1f) |
(cmd-device-lun 5 0xe0);
- }
scsi_log_send(cmd);
Index: usb-3.16/drivers/scsi/scsi_scan.c
===
--- usb-3.16.orig/drivers/scsi/scsi_scan.c
+++ usb-3.16/drivers/scsi/scsi_scan.c
@@ -736,6 +736,16 @@ static int scsi_probe_lun(struct scsi_de
sdev-scsi_level++;
sdev-sdev_target-scsi_level = sdev-scsi_level;
+ /*
+* If SCSI-2 or lower, and if the transport requires it,
+* store the LUN value in CDB[1].
+*/
+ sdev-lun_in_cdb = 0;
+ if (sdev-scsi_level = SCSI_2
+ sdev-scsi_level != SCSI_UNKNOWN
+ !sdev-host-no_scsi2_lun_in_cdb)
+ sdev-lun_in_cdb = 1;
+
return 0;
}
Index: usb-3.16/drivers/scsi/scsi_sysfs.c
===
--- usb-3.16.orig/drivers/scsi/scsi_sysfs.c
+++ usb-3.16/drivers/scsi/scsi_sysfs.c
@@ -1263,7 +1263,19 @@ void scsi_sysfs_device_initialize(struct
sdev-sdev_dev.class = sdev_class;
dev_set_name(sdev-sdev_dev, %d:%d:%d:%llu,
sdev-host-host_no, sdev-channel, sdev-id, sdev-lun);
+ /*
+* Get a default scsi_level from the target (derived from sibling
+* devices). This is the
[PATCH] bnx2fc: fix incorrect DMA memory mapping in bnx2fc_unmap_sg_list()
This patch is based on a problem and solution from Maurizio Lombardi
where bnx2fc isn't consistent in which device struct we using for DMA
map and unmap operations. Make them consistent by using dma_sg_unmap
in bnx2fc_unmap_sg_list like bnx2fc_map_sg.
Reviewed-by: Eddie Wai eddie@broadcom.com
Signed-off-by: Chad Dupuis chad.dup...@qlogic.com
---
drivers/scsi/bnx2fc/bnx2fc_io.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/bnx2fc/bnx2fc_io.c b/drivers/scsi/bnx2fc/bnx2fc_io.c
index 4c5891e..0679782 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_io.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_io.c
@@ -1654,6 +1654,10 @@ static int bnx2fc_map_sg(struct bnx2fc_cmd *io_req)
u64 addr;
int i;
+ /*
+* Use dma_map_sg directly to ensure we're using the correct
+* dev struct off of pcidev.
+*/
sg_count = dma_map_sg(hba-pcidev-dev, scsi_sglist(sc),
scsi_sg_count(sc), sc-sc_data_direction);
scsi_for_each_sg(sc, sg, sg_count, i) {
@@ -1703,9 +1707,16 @@ static int bnx2fc_build_bd_list_from_sg(struct
bnx2fc_cmd *io_req)
static void bnx2fc_unmap_sg_list(struct bnx2fc_cmd *io_req)
{
struct scsi_cmnd *sc = io_req-sc_cmd;
+ struct bnx2fc_interface *interface = io_req-port-priv;
+ struct bnx2fc_hba *hba = interface-hba;
- if (io_req-bd_tbl-bd_valid sc) {
- scsi_dma_unmap(sc);
+ /*
+* Use dma_unmap_sg directly to ensure we're using the correct
+* dev struct off of pcidev.
+*/
+ if (io_req-bd_tbl-bd_valid sc scsi_sg_count(sc)) {
+ dma_unmap_sg(hba-pcidev-dev, scsi_sglist(sc),
+ scsi_sg_count(sc), sc-sc_data_direction);
io_req-bd_tbl-bd_valid = 0;
}
}
--
1.8.5.2
--
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 2/5] kexec: Export kexec_in_progress
On 08/30/2014 03:02 PM, Eric W. Biederman wrote: Brian King brk...@linux.vnet.ibm.com writes: On 08/04/2014 09:21 AM, Brian King wrote: On 07/28/2014 03:28 PM, Brian King wrote: Export kexec_in_progress for use by device drivers and other modules to optimize kexec boot. Signed-off-by: Brian King brk...@linux.vnet.ibm.com --- kernel/kexec.c |2 ++ 1 file changed, 2 insertions(+) diff -puN kernel/kexec.c~kexec_export_in_prog kernel/kexec.c --- linux/kernel/kexec.c~kexec_export_in_prog 2014-07-23 17:05:24.851887935 -0500 +++ linux-bjking1/kernel/kexec.c 2014-07-23 17:05:24.856887970 -0500 @@ -1716,3 +1716,5 @@ int kernel_kexec(void) mutex_unlock(kexec_mutex); return error; } + +EXPORT_SYMBOL_GPL(kexec_in_progress); Eric, Can I get an ack on this so we can take this entire series through the SCSI tree? Eric, Any issues with this patch? No huge issues except that patch description is largely uniformitive and actually wrong. kexec_in_progress is never set at boot/kernel startup. Good point. How about this instead: Export kexec_in_progress for use by device drivers and other modules to optimize shutdown handling during kexec. Thanks, Brian -- Brian King Power Linux I/O IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/2] target: Add documentation on the target userspace pass-through driver
On 08/31/2014 02:22 PM, Richard W.M. Jones wrote: Reading this several times, I now think I get what it's trying to say, but I think it needs to introduces the terms (as the Economist style does). Something like this: TCM is the new name for LIO, an in-kernel iSCSI target (server). Existing TCM targets run in the kernel. TCMU (TCM in Userspace) allows userspace programs to be written which act as iSCSI targets. This document describes the design. The existing kernel provides modules for different SCSI transport protocols. TCM also modularizes the data storage. There are existing modules for file, block device, RAM or using another SCSI device as storage. These are called backstores or storage engines. These built-in modules are implemented entirely as kernel code. And hopefully having defined a bit of background, the rest of the document just flows nicely: Thanks much! I've put this in the doc, and will hopefully send out a final patchset for inclusion with the new text in the next week or so. begin naming potential-bikeshed wasteoftime The only change I made was another instead of the new name -- because to be honest I don't know if there was actually an attempt at a name change, and if so if it was successful or not :) LIO seems to have stuck, but TCM seems to refer just to the backend part of LIO. end bikeshed Thanks again -- Andy -- 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 1/1] Drivers: scsi: storvsc: Get rid of warning messages
Get rid of the warning messages since they will clutter up various system logs
and are of questionable value to the end user. For debugging purposes, this
information can be gotten by setting the scsi log level appropriately.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
drivers/scsi/storvsc_drv.c | 12
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index fecac5d0..733e5f7 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1152,24 +1152,12 @@ static void storvsc_on_io_completion(struct hv_device
*device,
stor_pkt-vm_srb.sense_info_length =
vstor_packet-vm_srb.sense_info_length;
- if (vstor_packet-vm_srb.scsi_status != 0 ||
- vstor_packet-vm_srb.srb_status != SRB_STATUS_SUCCESS){
- dev_warn(device-device,
-cmd 0x%x scsi status 0x%x srb status 0x%x\n,
-stor_pkt-vm_srb.cdb[0],
-vstor_packet-vm_srb.scsi_status,
-vstor_packet-vm_srb.srb_status);
- }
if ((vstor_packet-vm_srb.scsi_status 0xFF) == 0x02) {
/* CHECK_CONDITION */
if (vstor_packet-vm_srb.srb_status
SRB_STATUS_AUTOSENSE_VALID) {
/* autosense data available */
- dev_warn(device-device,
-stor pkt %p autosense data valid - len %d\n,
-request,
-vstor_packet-vm_srb.sense_info_length);
memcpy(request-sense_buffer,
vstor_packet-vm_srb.sense_data,
--
1.7.4.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] target: target_core_transport: Don't try to strlen() an integer
In transport_dump_vpd_ident_type() we try to call strlen() on the integer len which is obviously a typo; take the length of the string already in buf instead. Fixes: 6cfa853ceee4a (target: target_core_transport.c: Cleaning up missing null-terminate in conjunction with strncpy) Signed-off-by: Mark Brown broo...@kernel.org --- drivers/target/target_core_transport.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c index 1dd11818f38f..3ce85edc2ea9 100644 --- a/drivers/target/target_core_transport.c +++ b/drivers/target/target_core_transport.c @@ -953,7 +953,7 @@ int transport_dump_vpd_ident_type( strlcat(buf, SCSI name string\n, sizeof(buf)); break; default: - len = strlen(len); + len = strlen(buf); snprintf(buf[len], sizeof(buf) - len, Unsupported: 0x%02x\n, vpd-device_identifier_type); ret = -EINVAL; -- 2.1.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: Re: [RFC PATCH 07/10] scsi/trace: Use scsi_show_result trace point instead of printk
Hi Christoph,
Sorry for the late reply.
(2014/08/29 9:50), Christoph Hellwig wrote:
I'm not sure this is the correct way.
Currently we have quite some code duplication in scsi_trace.c and
constants.c, correct.
So I definitely would like to see them both merged.
But constants.c is influenced by CONFIG_SCSI_CONSTANTS, whereas
scsi_trace isn't, and the functions in constants.c are used throughout the
scsi stack.
So I'd rather see to have scsi_trace to be updated to use the functions
from constants.c, and remove the duplicate code in
scsi_trace.
The tracepoints need to use the magic print_flags co helpers so that
output works properly if using the binary tracebuffer and user space tools that
decoded it (e.g. trace-cmd or perf), so using a kernel function for decoding is
not an option.
Ah, I see.
The format files in SCSI traceevents output decoders, so we don't
need to implement own decoders in userland.
I think the current problem is duplicated decoders, so we'll
consolidate those. If we use decoders in constants.c, the decoders are
not output in format file, so user tools cannot decode the binary.
On the other hand, if we use decoders in scsi_trace.c, the output format
of command names is changed and there are unsupported command names.
We would use decoders in scsi_trace.c and add new command names to
decoders in scsi_trace.c, I think.
How do you think about this? Hannes?
As another topic, we found that we cannot decode SCSI traceevents by
using current decoder in format files. For example, format file of
scsi_dispatch_cmd_timeout outputs prot_op as follows:
__print_symbolic(REC-prot_op, { SCSI_PROT_NORMAL, SCSI_PROT_NORMAL },
{ SCSI_PROT_READ_INSERT, SCSI_PROT_READ_INSERT }, {
SCSI_PROT_WRITE_STRIP, SCSI_PROT_WRITE_STRIP }, {
SCSI_PROT_READ_STRIP, SCSI_PROT_READ_STRIP }, {
SCSI_PROT_WRITE_INSERT, SCSI_PROT_WRITE_INSERT }, {
SCSI_PROT_READ_PASS, SCSI_PROT_READ_PASS }, { SCSI_PROT_WRITE_PASS,
SCSI_PROT_WRITE_PASS })
Decoding will fail to do macro expansion here, so we need to fix this.
(We don't use enum for traceevents.)
Thanks,
Yoshihiro YUNOMAE
But we can make these tracepoints dependent on CONFIG_SCSI_CONSTANTS to
still allow building lighter kernels if we really care about it.
--
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
--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.com
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] libiscsi: fix potential buffer overrun in __iscsi_conn_send_pdu
From: Mike Christie micha...@cs.wisc.edu
This patches fixes a potential buffer overrun in __iscsi_conn_send_pdu.
This function is used by iscsi drivers and userspace to send iscsi PDUs/
commands. For login commands, we have a set buffer size. For all other
commands we do not support data buffers.
This was reported by Dan Carpenter here:
http://www.spinics.net/lists/linux-scsi/msg66838.html
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Mike Christie micha...@cs.wisc.edu
---
drivers/scsi/libiscsi.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index ea025e4..191b597 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -717,11 +717,21 @@ __iscsi_conn_send_pdu(struct iscsi_conn *conn, struct
iscsi_hdr *hdr,
return NULL;
}
+ if (data_size ISCSI_DEF_MAX_RECV_SEG_LEN) {
+ iscsi_conn_printk(KERN_ERR, conn, Invalid buffer len
of %u for login task. Max len is %u\n, data_size, ISCSI_DEF_MAX_RECV_SEG_LEN);
+ return NULL;
+ }
+
task = conn-login_task;
} else {
if (session-state != ISCSI_STATE_LOGGED_IN)
return NULL;
+ if (data_size != 0) {
+ iscsi_conn_printk(KERN_ERR, conn, Can not send data
buffer of len %u for op 0x%x\n, data_size, opcode);
+ return NULL;
+ }
+
BUG_ON(conn-c_stage == ISCSI_CONN_INITIAL_STAGE);
BUG_ON(conn-c_stage == ISCSI_CONN_STOPPED);
--
1.7.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
