Re: [PATCH] fusion: fix excess parameter kernel-doc warning
On 08/27/14 17:55, Christoph Hellwig wrote: > On Wed, Aug 27, 2014 at 04:47:24PM -0700, Randy Dunlap wrote: >>> Goes with commit c9834c70efbaaa1461ec04289d97a842244fb294. >>> >>> Reviewed-by: Ewan D. Milne >> >> Christoph, did you pick up this patch or should I merge it >> with my documentation patches? > > I did as mentioned in my reply to your other patch. Thanks. Sorry I missed that... -- ~Randy -- 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: Re: [RFC PATCH 10/10] scsi/trace: Use scsi_print_command trace point instead of printk
Hi Hannes, I tried to remove duplicated decoder of SCSI command, but the output format of it in constants.c is different from it in traceevents. I have two questions for it. (Ex1) traceevents: TEST_UNIT_READY constants: Test Unit Ready => Which of "XXX_YYY_ZZZ" and "Xxx Yyy Zzz" should the kernel output strings? This difference comes from difference of implementation. The decoder in traceevents are using macro. So, it cannot define separated words. On the other hand, the decoder in constants are using constant string array table. So, it can define separated words. (Ex2) traceevents: (nothing) constants: Set limits(12) => Should we merge those decoder? I understand we use the decoder of constants, but we need to solve these problems. Would you give me your comments? Thanks, Yoshihiro YUNOMAE (2014/08/28 10:40), Yoshihiro YUNOMAE wrote: (2014/08/27 23:16), Hannes Reinecke wrote: On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote: Previous printk messages of SCSI command can be mixed into other printk messages because multiple printk messages are output for it. To avoid the problem, patch 4e64bb8d6 in Hannes' branch(*1) introduced a local buffer. But using local buffers can induce stack overflow, so we want to solve the problem without local buffer if possible. trace_seq_printf can add log messages without local buffer, so we use it. Note: We don't need constans.c any more. (*1) http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging - Result examples (printk) sd 2:0:0:0: [sda] CDB: Read(10) scsi_print_command: host_no=2 channel=0 id=0 lun=0 [sda] CDB (Read(10)) Signed-off-by: Yoshihiro YUNOMAE Cc: Hannes Reinecke Cc: Doug Gilbert Cc: Martin K. Petersen Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: Hidehiro Kawai Cc: Masami Hiramatsu --- drivers/scsi/Makefile |2 drivers/scsi/constants.c| 425 --- drivers/scsi/scsi_trace.c | 408 + include/scsi/scsi.h |8 + include/trace/events/scsi.h | 45 + 5 files changed, 461 insertions(+), 427 deletions(-) delete mode 100644 drivers/scsi/constants.c diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile index 5f0d299..c56f692 100644 --- a/drivers/scsi/Makefile +++ b/drivers/scsi/Makefile @@ -158,7 +158,7 @@ obj-$(CONFIG_SCSI_OSD_INITIATOR) += osd/ # This goes last, so that "real" scsi devices probe earlier obj-$(CONFIG_SCSI_DEBUG)+= scsi_debug.o -scsi_mod-y+= scsi.o hosts.o scsi_ioctl.o constants.o \ +scsi_mod-y+= scsi.o hosts.o scsi_ioctl.o \ scsicam.o scsi_error.o scsi_lib.o scsi_mod-$(CONFIG_SCSI_DMA)+= scsi_lib_dma.o scsi_mod-y+= scsi_scan.o scsi_sysfs.o scsi_devinfo.o diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c deleted file mode 100644 index ce9ceb8..000 --- a/drivers/scsi/constants.c +++ /dev/null @@ -1,425 +0,0 @@ -/* - * ASCII values for a number of symbolic constants, printing functions, - * etc. - * Additions for SCSI 2 and Linux 2.2.x by D. Gilbert (990422) - * Additions for SCSI 3+ (SPC-3 T10/1416-D Rev 07 3 May 2002) - * by D. Gilbert and aeb (20020609) - * Updated to SPC-4 T10/1713-D Rev 36g, D. Gilbert 20130701 - */ - -#include -#include -#include -#include - -#include -#include - -/* Commands with service actions that change the command name */ -#define SERVICE_ACTION_IN_12 0xab -#define SERVICE_ACTION_OUT_12 0xa9 -#define SERVICE_ACTION_BIDIRECTIONAL 0x9d -#define SERVICE_ACTION_IN_16 0x9e -#define SERVICE_ACTION_OUT_16 0x9f -#define THIRD_PARTY_COPY_OUT 0x83 -#define THIRD_PARTY_COPY_IN 0x84 - - - -#ifdef CONFIG_SCSI_CONSTANTS -static const char * cdb_byte0_names[] = { -/* 00-03 */ "Test Unit Ready", "Rezero Unit/Rewind", NULL, "Request Sense", -/* 04-07 */ "Format Unit/Medium", "Read Block Limits", NULL, -"Reassign Blocks", -/* 08-0d */ "Read(6)", NULL, "Write(6)", "Seek(6)", NULL, NULL, -/* 0e-12 */ NULL, "Read Reverse", "Write Filemarks", "Space", "Inquiry", -/* 13-16 */ "Verify(6)", "Recover Buffered Data", "Mode Select(6)", -"Reserve(6)", -/* 17-1a */ "Release(6)", "Copy", "Erase", "Mode Sense(6)", -/* 1b-1d */ "Start/Stop Unit", "Receive Diagnostic", "Send Diagnostic", -/* 1e-1f */ "Prevent/Allow Medium Removal", NULL, -/* 20-22 */ NULL, NULL, NULL, -/* 23-28 */ "Read Format Capacities", "Set Window", -"Read Capacity(10)", NULL, NULL, "Read(10)", -/* 29-2d */ "Read Generation", "Write(10)", "Seek(10)", "Erase(10)", -"Read updated block", -/* 2e-31 */ "Write Verify(10)", "Verify(10)", "Search High", "Search Equal", -/* 32-34 */ "Search Low", "Set Limits", "Prefetch/Read Position", -/* 35-37 */ "Synchronize Cache(10)", "Lock/Unlock Cache(10)", -"Read Defect Data(10)", -/* 38-3c */ "Medium Scan", "Compare", "Copy Verify", "Write Buffer", -"Read Buffer", -/* 3d-3f */ "Update Block", "Read Long(10)", "Write
[PATCH V6 3/5] Introduce xen-scsifront module
Introduces the XEN pvSCSI frontend. With pvSCSI it is possible for a XEN domU to issue SCSI commands to a SCSI LUN assigned to that domU. The SCSI commands are passed to the pvSCSI backend in a driver domain (usually Dom0) which is owner of the physical device. This allows e.g. to use SCSI tape drives in a XEN domU. The code is taken from the pvSCSI implementation in XEN done by Fujitsu based on Linux kernel 2.6.18. Changes from the original version are: - port to upstream kernel - put all code in just one source file - move module to appropriate location in kernel tree - adapt to Linux style guide - some minor code simplifications - replace constants with defines - remove not used defines - add support for larger SG lists by putting them in a granted page Signed-off-by: Juergen Gross Xen related parts Acked-by: David Vrabel --- drivers/scsi/Kconfig |9 + drivers/scsi/Makefile|1 + drivers/scsi/xen-scsifront.c | 1024 ++ 3 files changed, 1034 insertions(+) create mode 100644 drivers/scsi/xen-scsifront.c diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index 18a3358..9130df1 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -576,6 +576,15 @@ config VMWARE_PVSCSI To compile this driver as a module, choose M here: the module will be called vmw_pvscsi. +config XEN_SCSI_FRONTEND + tristate "XEN SCSI frontend driver" + depends on SCSI && XEN + help + The XEN SCSI frontend driver allows the kernel to access SCSI Devices + within another guest OS (usually Dom0). + Only needed if the kernel is running in a XEN guest and generic + SCSI access to a device is needed. + config HYPERV_STORAGE tristate "Microsoft Hyper-V virtual storage driver" depends on SCSI && HYPERV diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile index 5f0d299..59f1ce6 100644 --- a/drivers/scsi/Makefile +++ b/drivers/scsi/Makefile @@ -141,6 +141,7 @@ obj-$(CONFIG_SCSI_ESAS2R) += esas2r/ obj-$(CONFIG_SCSI_PMCRAID) += pmcraid.o obj-$(CONFIG_SCSI_VIRTIO) += virtio_scsi.o obj-$(CONFIG_VMWARE_PVSCSI)+= vmw_pvscsi.o +obj-$(CONFIG_XEN_SCSI_FRONTEND)+= xen-scsifront.o obj-$(CONFIG_HYPERV_STORAGE) += hv_storvsc.o obj-$(CONFIG_ARM) += arm/ diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c new file mode 100644 index 000..0aceb70 --- /dev/null +++ b/drivers/scsi/xen-scsifront.c @@ -0,0 +1,1024 @@ +/* + * Xen SCSI frontend driver + * + * Copyright (c) 2008, FUJITSU Limited + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version 2 + * as published by the Free Software Foundation; or, when distributed + * separately from the Linux kernel or incorporated into other + * software packages, subject to the following license: + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this source file (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, copy, modify, + * merge, publish, distribute, sublicense, and/or sell copies of the Software, + * and to permit persons to whom the Software is furnished to do so, subject to + * the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#include +#include +#include + +#include + + +#define GRANT_INVALID_REF 0 + +#define VSCSIFRONT_OP_ADD_LUN 1 +#define VSCSIFRONT_OP_DEL_LUN 2 + +/* Tuning point. */ +#define VSCSIIF_DEFAULT_CMD_PER_LUN 10 +#define VSCSIIF_MAX_TARGET 64 +#define VSCSIIF_MAX_LUN 255 + +#define VSCSIIF_RING_SIZE __CONST_RING_SIZE(vscsiif, PAGE_SIZE) +#define VSCSIIF_MAX_REQS VSCSIIF_RING_SIZE + +#define vscsiif_grants_sg(_sg) (PFN_UP((_sg) * \ + sizeof(struct scsiif_request_segment))) + +struct vscsifrnt_shadow { + /* command between backend and frontend */ + unsigned char act; + uint16_t rqid; + + unsigned int nr_grants; /* number
[PATCH V6 4/5] Introduce XEN scsiback module
Introduces the XEN pvSCSI backend. With pvSCSI it is possible for a XEN domU to issue SCSI commands to a SCSI LUN assigned to that domU. The SCSI commands are passed to the pvSCSI backend in a driver domain (usually Dom0) which is owner of the physical device. This allows e.g. to use SCSI tape drives in a XEN domU. The code is taken from the pvSCSI implementation in XEN done by Fujitsu based on Linux kernel 2.6.18. Changes from the original version are: - port to upstream kernel - put all code in just one source file - adapt to Linux style guide - use target core infrastructure instead doing pure pass-through - enable module unloading - support SG-list in grant page(s) - support task abort - remove redundant struct backend - allocate resources dynamically - correct minor error in scsiback_fast_flush_area - free allocated resources in case of error during I/O preparation - remove CDB emulation, now handled by target core infrastructure Signed-off-by: Juergen Gross Xen related parts Acked-by: David Vrabel Reviewed-by: Nicholas Bellinger --- drivers/xen/Kconfig|9 + drivers/xen/Makefile |1 + drivers/xen/xen-scsiback.c | 2124 3 files changed, 2134 insertions(+) create mode 100644 drivers/xen/xen-scsiback.c diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 8bc0183..b812462 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -172,6 +172,15 @@ config XEN_PCIDEV_BACKEND If in doubt, say m. +config XEN_SCSI_BACKEND + tristate "XEN SCSI backend driver" + depends on XEN && XEN_BACKEND && TARGET_CORE + help + The SCSI backend driver allows the kernel to export its SCSI Devices + to other guests via a high-performance shared-memory interface. + Only needed for systems running as XEN driver domains (e.g. Dom0) and + if guests need generic access to SCSI devices. + config XEN_PRIVCMD tristate depends on XEN diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index 84044b5..2140398 100644 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -36,6 +36,7 @@ obj-$(CONFIG_XEN_ACPI_HOTPLUG_MEMORY) += xen-acpi-memhotplug.o obj-$(CONFIG_XEN_ACPI_HOTPLUG_CPU) += xen-acpi-cpuhotplug.o obj-$(CONFIG_XEN_ACPI_PROCESSOR) += xen-acpi-processor.o obj-$(CONFIG_XEN_EFI) += efi.o +obj-$(CONFIG_XEN_SCSI_BACKEND) += xen-scsiback.o xen-evtchn-y := evtchn.o xen-gntdev-y := gntdev.o xen-gntalloc-y := gntalloc.o diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c new file mode 100644 index 000..7b565632 --- /dev/null +++ b/drivers/xen/xen-scsiback.c @@ -0,0 +1,2124 @@ +/* + * Xen SCSI backend driver + * + * Copyright (c) 2008, FUJITSU Limited + * + * Based on the blkback driver code. + * Adaption to kernel taget core infrastructure taken from vhost/scsi.c + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version 2 + * as published by the Free Software Foundation; or, when distributed + * separately from the Linux kernel or incorporated into other + * software packages, subject to the following license: + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this source file (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, copy, modify, + * merge, publish, distribute, sublicense, and/or sell copies of the Software, + * and to permit persons to whom the Software is furnished to do so, subject to + * the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + */ + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include + +#include +#include +#include +#include + +#include + +#include +#include +#include +#include +#include +#include + +#include +#include + +#define DPRINTK(_f, _a...) \ + pr_debug("(file=%s, line=%d) " _f, __FILE__ , __LINE__ , ## _a) + +#define VSCSI_VERSION "v0.1" +#define VSCSI_NAMELEN 32 + +struct ids_tuple { + unsigned int hst; /* host*/ + un
[PATCH V6 5/5] add xen pvscsi maintainer
Add myself as maintainer for the Xen pvSCSI stuff. Signed-off-by: Juergen Gross Acked-by: Konrad Rzeszutek Wilk --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 1ff06de..0ae6238 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10128,6 +10128,15 @@ S: Supported F: drivers/block/xen-blkback/* F: drivers/block/xen* +XEN PVSCSI DRIVERS +M: Juergen Gross +L: xen-de...@lists.xenproject.org (moderated for non-subscribers) +L: linux-scsi@vger.kernel.org +S: Supported +F: drivers/scsi/xen-scsifront.c +F: drivers/xen/xen-scsiback.c +F: include/xen/interface/io/vscsiif.h + XEN SWIOTLB SUBSYSTEM M: Konrad Rzeszutek Wilk L: xen-de...@lists.xenproject.org (moderated for non-subscribers) -- 1.8.4.5 -- 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 V6 0/5] Add XEN pvSCSI support
This series adds XEN pvSCSI support. With pvSCSI it is possible to use physical SCSI devices from a XEN domain. The support consists of a backend in the privileged Domain-0 doing the real I/O and a frontend in the unprivileged domU passing I/O-requests to the backend. The code is taken (and adapted) from the original pvSCSI implementation done for Linux 2.6 in 2008 by Fujitsu. Changes in V6: - changes in scsifront module after comments from Konrad Wilk - remove double kfree in scsiback - comments in vscsiif.h adapted after comments from Jan Beulich and David Vrabel in xen-devel - added linux-scsi@vger.kernel.org to MAINTANERS entry Changes in V5: - Added patch to support threaded irqs for interdomain event channels - several changes in xen-scsifront after comments from Christoph Hellwig - several changes in xen-scsiback after comments from Christoph Hellwig - several changes in xen-scsiback after comments from James Bottomley - several changes in xen-scsiback after comments from Nicholas Bellinger Changes in V4: - Re-add define for VSCSIIF_ACT_SCSI_SG_PRESET to vscsiif.h to indicate this action value should not be used in future enhancements Changes in V3: - added some comments to the protocol header file - removed the CDB emulation from xen-scsiback, handled by core target infrastructure - several changes in xen-scsifront after comments from Christoph Hellwig Changes in V2: - use core target infrastructure by backend instead of pure SCSI passthrough - add support for larger SG lists by putting them in grant page(s) - add command abort capability Juergen Gross (5): xen/events: support threaded irqs for interdomain event channels Add XEN pvSCSI protocol description Introduce xen-scsifront module Introduce XEN scsiback module add xen pvscsi maintainer MAINTAINERS|9 + drivers/scsi/Kconfig |9 + drivers/scsi/Makefile |1 + drivers/scsi/xen-scsifront.c | 1024 + drivers/xen/Kconfig|9 + drivers/xen/Makefile |1 + drivers/xen/events/events_base.c |5 +- drivers/xen/xen-scsiback.c | 2124 include/xen/events.h |2 + include/xen/interface/io/vscsiif.h | 229 10 files changed, 3411 insertions(+), 2 deletions(-) create mode 100644 drivers/scsi/xen-scsifront.c create mode 100644 drivers/xen/xen-scsiback.c create mode 100644 include/xen/interface/io/vscsiif.h -- 1.8.4.5 -- 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 V6 2/5] Add XEN pvSCSI protocol description
Add the definition of pvSCSI protocol used between the pvSCSI frontend in a XEN domU and the pvSCSI backend in a XEN driver domain (usually Dom0). This header was originally provided by Fujitsu for XEN based on Linux 2.6.18. Changes are: - added comment - adapt to Linux style guide - add support for larger SG-lists by putting them in an own granted page - remove stale definitions Signed-off-by: Juergen Gross --- include/xen/interface/io/vscsiif.h | 229 + 1 file changed, 229 insertions(+) create mode 100644 include/xen/interface/io/vscsiif.h diff --git a/include/xen/interface/io/vscsiif.h b/include/xen/interface/io/vscsiif.h new file mode 100644 index 000..d07d7ac --- /dev/null +++ b/include/xen/interface/io/vscsiif.h @@ -0,0 +1,229 @@ +/** + * vscsiif.h + * + * Based on the blkif.h code. + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Copyright(c) FUJITSU Limited 2008. + */ + +#ifndef __XEN__PUBLIC_IO_SCSI_H__ +#define __XEN__PUBLIC_IO_SCSI_H__ + +#include "ring.h" +#include "../grant_table.h" + +/* + * Feature and Parameter Negotiation + * = + * The two halves of a Xen pvSCSI driver utilize nodes within the XenStore to + * communicate capabilities and to negotiate operating parameters. This + * section enumerates these nodes which reside in the respective front and + * backend portions of the XenStore, following the XenBus convention. + * + * Any specified default value is in effect if the corresponding XenBus node + * is not present in the XenStore. + * + * XenStore nodes in sections marked "PRIVATE" are solely for use by the + * driver side whose XenBus tree contains them. + * + * + *Backend XenBus Nodes + * + * + *-- Backend Device Identification (PRIVATE) -- + * + * p-devname + * Values: string + * + * A free string used to identify the physical device (e.g. a disk name). + * + * p-dev + * Values: string + * + * A string specifying the backend device: either a 4-tuple "h:c:t:l" + * (host, controller, target, lun, all integers), or a WWN (e.g. + * "naa.60014054ac780582"). + * + * v-dev + * Values: string + * + * A string specifying the frontend device in form of a 4-tuple "h:c:t:l" + * (host, controller, target, lun, all integers). + * + *- Features - + * + * feature-sg-grant + * Values: unsigned [VSCSIIF_SG_TABLESIZE...65535] + * Default Value: 0 + * + * Specifies the maximum number of scatter/gather elements in grant pages + * supported. If not set, the backend supports up to VSCSIIF_SG_TABLESIZE + * SG elements specified directly in the request. + * + * + *Frontend XenBus Nodes + * + * + *--- Request Transport Parameters --- + * + * event-channel + * Values: unsigned + * + * The identifier of the Xen event channel used to signal activity + * in the ring buffer. + * + * ring-ref + * Values: unsigned + * + * The Xen grant reference granting permission for the backend to map + * the sole page in a single page sized ring buffer. + * + * protocol + * Values: string (XEN_IO_PROTO_ABI_*) + * Default Value: XEN_IO_PROTO_ABI_NATIVE + * + * The machine ABI rules governing the format of all ring request and + * response structures. + */ + +/* Requests from the fr
[PATCH V6 1/5] xen/events: support threaded irqs for interdomain event channels
Export bind_interdomain_evtchn_to_irq() so drivers can use threaded interrupt handlers with: irq = bind_interdomain_evtchn_to_irq(remote_dom, remote_port); if (irq < 0) /* error */ ret = request_threaded_irq(...); Signed-off-by: Juergen Gross Acked-by: David Vrabel Acked-by: Konrad Rzeszutek Wilk --- drivers/xen/events/events_base.c | 5 +++-- include/xen/events.h | 2 ++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c index 5b5c5ff..b4bca2d 100644 --- a/drivers/xen/events/events_base.c +++ b/drivers/xen/events/events_base.c @@ -900,8 +900,8 @@ static int bind_ipi_to_irq(unsigned int ipi, unsigned int cpu) return irq; } -static int bind_interdomain_evtchn_to_irq(unsigned int remote_domain, - unsigned int remote_port) +int bind_interdomain_evtchn_to_irq(unsigned int remote_domain, + unsigned int remote_port) { struct evtchn_bind_interdomain bind_interdomain; int err; @@ -914,6 +914,7 @@ static int bind_interdomain_evtchn_to_irq(unsigned int remote_domain, return err ? : bind_evtchn_to_irq(bind_interdomain.local_port); } +EXPORT_SYMBOL_GPL(bind_interdomain_evtchn_to_irq); static int find_virq(unsigned int virq, unsigned int cpu) { diff --git a/include/xen/events.h b/include/xen/events.h index 8bee7a7..5321cd9 100644 --- a/include/xen/events.h +++ b/include/xen/events.h @@ -28,6 +28,8 @@ int bind_ipi_to_irqhandler(enum ipi_vector ipi, unsigned long irqflags, const char *devname, void *dev_id); +int bind_interdomain_evtchn_to_irq(unsigned int remote_domain, + unsigned int remote_port); int bind_interdomain_evtchn_to_irqhandler(unsigned int remote_domain, unsigned int remote_port, irq_handler_t handler, -- 1.8.4.5 -- 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 v3 13/17] arcmsr: fix ioctl data read/write error for adapter type C
On Wed, 2014-08-27 at 14:29 +0200, Tomas Henzl wrote: > On 08/27/2014 10:19 PM, Ching Huang wrote: > > On Tue, 2014-08-26 at 15:20 +0200, Tomas Henzl wrote: > >> On 08/26/2014 10:27 PM, Ching Huang wrote: > >>> On Mon, 2014-08-25 at 12:29 +0200, Tomas Henzl wrote: > On 08/25/2014 07:59 PM, Ching Huang wrote: > > On Fri, 2014-08-22 at 18:00 +0200, Tomas Henzl wrote: > >> On 08/19/2014 09:17 AM, Ching Huang wrote: > >>> From: Ching Huang > >>> > >>> Rewrite ioctl entry and its relate function. > >>> This patch fix ioctl data read/write error and change data I/O access > >>> from byte to Dword. > >>> > >>> Signed-off-by: Ching Huang > >>> --- > >>> > >>> diff -uprN a/drivers/scsi/arcmsr/arcmsr_attr.c > >>> b/drivers/scsi/arcmsr/arcmsr_attr.c > >>> --- a/drivers/scsi/arcmsr/arcmsr_attr.c 2014-02-06 > >>> 17:47:24.0 +0800 > >>> +++ b/drivers/scsi/arcmsr/arcmsr_attr.c 2014-04-29 > >>> 17:10:42.0 +0800 > >>> @@ -70,40 +70,75 @@ static ssize_t arcmsr_sysfs_iop_message_ > >>> struct AdapterControlBlock *acb = (struct AdapterControlBlock > >>> *) host->hostdata; > >>> uint8_t *pQbuffer,*ptmpQbuffer; > >>> int32_t allxfer_len = 0; > >>> + unsigned long flags; > >>> > >>> if (!capable(CAP_SYS_ADMIN)) > >>> return -EACCES; > >>> > >>> /* do message unit read. */ > >>> ptmpQbuffer = (uint8_t *)buf; > >>> - while ((acb->rqbuf_firstindex != acb->rqbuf_lastindex) > >>> - && (allxfer_len < 1031)) { > >>> + spin_lock_irqsave(&acb->rqbuffer_lock, flags); > >>> + if (acb->rqbuf_firstindex != acb->rqbuf_lastindex) { > >> Hi - does this condition (acb->rqbuf_firstindex == > >> acb->rqbuf_lastindex) mean we could just release > >> the spinlock and return ? > >> > > NO. We have to check the input buffer that may have message data come > > from IOP. > >>> pQbuffer = &acb->rqbuffer[acb->rqbuf_firstindex]; > >>> - memcpy(ptmpQbuffer, pQbuffer, 1); > >>> - acb->rqbuf_firstindex++; > >>> - acb->rqbuf_firstindex %= ARCMSR_MAX_QBUFFER; > >>> - ptmpQbuffer++; > >>> - allxfer_len++; > >>> + if (acb->rqbuf_firstindex > acb->rqbuf_lastindex) { > >>> + if ((ARCMSR_MAX_QBUFFER - > >>> acb->rqbuf_firstindex) >= 1032) { > >>> + memcpy(ptmpQbuffer, pQbuffer, 1032); > >>> + acb->rqbuf_firstindex += 1032; > >>> + acb->rqbuf_firstindex %= > >>> ARCMSR_MAX_QBUFFER; > >>> + allxfer_len = 1032; > >>> + } else { > >>> + if (((ARCMSR_MAX_QBUFFER - > >>> acb->rqbuf_firstindex) > >>> + + acb->rqbuf_lastindex) > 1032) > >>> { > >>> + memcpy(ptmpQbuffer, pQbuffer, > >>> + ARCMSR_MAX_QBUFFER > >>> + - > >>> acb->rqbuf_firstindex); > >>> + ptmpQbuffer += > >>> ARCMSR_MAX_QBUFFER > >>> + - acb->rqbuf_firstindex; > >>> + memcpy(ptmpQbuffer, > >>> acb->rqbuffer, 1032 > >>> + - (ARCMSR_MAX_QBUFFER - > >>> + acb->rqbuf_firstindex)); > >> This code looks like you were copying some data from a ring buffer, > >> in that case - shouldn't be acb->rqbuf_lastindex used instead of > >> firstindex? > >> > > Yes, there copying data from a ring buffer. firstindex and lastindex are > > bad name. For readability, I rename the firstindex to getIndex, > > lastindex to putIndex. > My comment is not about names, but in this path '(ARCMSR_MAX_QBUFFER - > acb->rqbuf_firstindex)+ acb->rqbuf_lastindex) > 1032)' > you copy something twice and in both cases the 'firstindex' is used and > never the 'lastindex'. > Is this correct? > >>> The firstindex is a get index and lastindex is a put index of a ring > >>> buffer. > >>> At here, firstindex > lastindex, so the data remain in buffer are > >>> (ARCMSR_MAX_QBUFFER - acb->rqbuf_firstindex)+ acb->rqbuf_lastindex > >> Yes, it's correct, I misinterpreted the from value with the amount of > >> bytes to copy. > >> But well it's also still overcomplicated and I believe that a copy like > >> this could be > >> rearranged with just few lines of code as a result - have you looked at > >> the code I sent? > >> > >> Let's go with this patch as it is otherwise we will neve
[Bug 83391] Oops on sd_mod
https://bugzilla.kernel.org/show_bug.cgi?id=83391 --- Comment #1 from tomsun --- Created attachment 148621 --> https://bugzilla.kernel.org/attachment.cgi?id=148621&action=edit the function disassemble info -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 83391] New: Oops on sd_mod
https://bugzilla.kernel.org/show_bug.cgi?id=83391 Bug ID: 83391 Summary: Oops on sd_mod Product: SCSI Drivers Version: 2.5 Kernel Version: 2.6.32 Hardware: i386 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other Assignee: scsi_drivers-ot...@kernel-bugs.osdl.org Reporter: tomsunc...@gmail.com Regression: No Now i met the oops of sd_mod more times, but i don't know the condition that the oops occured, the info as below. BUG: unable to handle kernel paging request at 88001488c004 IP: [] sd_revalidate_disk+0x107c/0x1900 [sd_mod] PGD 1a05067 PUD 1a09067 PMD 176067 PTE 0 Oops: [#1] SMP last sysfs file: /sys/devices/pci:00/:00:1f.2/host0/scsi_host/host0/scan Pid: 31, comm: ata_aux Tainted: G C 2.6.32-220.el6.x86_64 #1 LENOVO QiTianM8250/LENOVO RIP: e030:[] [] sd_revalidate_disk+0x107c/0x1900 [sd_mod] RSP: e02b:88003eacbc60 EFLAGS: 00010246 RAX: 880039948000 RBX: 880039971000 RCX: 0001 RDX: RSI: RDI: 88003819b420 RBP: 88003eacbd40 R08: 0018 R09: R10: R11: R12: 88001488bfe0 R13: 0200 R14: 88003fc00040 R15: 0200 FS: 7f92c694c700() GS:880004ff7000() knlGS: CS: e033 DS: ES: CR0: 8005003b CR2: 88001488c004 CR3: 379b9000 CR4: 2660 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process ata_aux (pid: 31, threadinfo 88003eaca000, task 88003eac6b00) Stack: 88007530 0005 8139c890 <0> 88003eac71a0 88003eacbcf2 <0> 88003a21aa00 2542eab0 880039957800 880039948000 Call Trace: [] ? ata_scsi_dev_rescan+0x0/0x110 [] ? kobject_get+0x1a/0x30 [] ? blkiocg_file_read_map+0xe0/0x100 [] revalidate_disk+0x38/0x90 [] sd_rescan+0x27/0x40 [sd_mod] [] scsi_rescan_device+0x8d/0xe0 [] ? get_device+0x19/0x20 [] ata_scsi_dev_rescan+0xba/0x110 [] ? ata_scsi_dev_rescan+0x0/0x110 [] worker_thread+0x170/0x2a0 [] ? autoremove_wake_function+0x0/0x40 [] ? _spin_unlock_irqrestore+0x1c/0x20 [] ? worker_thread+0x0/0x2a0 [] kthread+0x96/0xa0 [] child_rip+0xa/0x20 [] ? int_ret_from_sys_call+0x7/0x1b [] ? retint_restore_args+0x5/0x6 [] ? child_rip+0x0/0x20 crash> l* sd_revalidate_disk+0x107c 0xa019d01c is in sd_revalidate_disk (/usr/src/debug/kernel-2.6.32/linux-2.6.32/arch/x86/include/asm/swab.h:53). 48 : "=r" (v.s.a), "=r" (v.s.b) 49 : "0" (v.s.a), "1" (v.s.b)); 50 # endif 51 return v.u; 52 #else /* __i386__ */ 53 asm("bswapq %0" 54 : "=r" (val) 55 : "0" (val)); 56 return val; 57 #endif Would you give me suggestions for this oops? thank you very much! -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [RFC PATCH 10/10] scsi/trace: Use scsi_print_command trace point instead of printk
(2014/08/27 23:16), Hannes Reinecke wrote: On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote: Previous printk messages of SCSI command can be mixed into other printk messages because multiple printk messages are output for it. To avoid the problem, patch 4e64bb8d6 in Hannes' branch(*1) introduced a local buffer. But using local buffers can induce stack overflow, so we want to solve the problem without local buffer if possible. trace_seq_printf can add log messages without local buffer, so we use it. Note: We don't need constans.c any more. (*1) http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging - Result examples (printk) sd 2:0:0:0: [sda] CDB: Read(10) scsi_print_command: host_no=2 channel=0 id=0 lun=0 [sda] CDB (Read(10)) Signed-off-by: Yoshihiro YUNOMAE Cc: Hannes Reinecke Cc: Doug Gilbert Cc: Martin K. Petersen Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: Hidehiro Kawai Cc: Masami Hiramatsu --- drivers/scsi/Makefile |2 drivers/scsi/constants.c| 425 --- drivers/scsi/scsi_trace.c | 408 + include/scsi/scsi.h |8 + include/trace/events/scsi.h | 45 + 5 files changed, 461 insertions(+), 427 deletions(-) delete mode 100644 drivers/scsi/constants.c diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile index 5f0d299..c56f692 100644 --- a/drivers/scsi/Makefile +++ b/drivers/scsi/Makefile @@ -158,7 +158,7 @@ obj-$(CONFIG_SCSI_OSD_INITIATOR) += osd/ # This goes last, so that "real" scsi devices probe earlier obj-$(CONFIG_SCSI_DEBUG)+= scsi_debug.o -scsi_mod-y+= scsi.o hosts.o scsi_ioctl.o constants.o \ +scsi_mod-y+= scsi.o hosts.o scsi_ioctl.o \ scsicam.o scsi_error.o scsi_lib.o scsi_mod-$(CONFIG_SCSI_DMA)+= scsi_lib_dma.o scsi_mod-y+= scsi_scan.o scsi_sysfs.o scsi_devinfo.o diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c deleted file mode 100644 index ce9ceb8..000 --- a/drivers/scsi/constants.c +++ /dev/null @@ -1,425 +0,0 @@ -/* - * ASCII values for a number of symbolic constants, printing functions, - * etc. - * Additions for SCSI 2 and Linux 2.2.x by D. Gilbert (990422) - * Additions for SCSI 3+ (SPC-3 T10/1416-D Rev 07 3 May 2002) - * by D. Gilbert and aeb (20020609) - * Updated to SPC-4 T10/1713-D Rev 36g, D. Gilbert 20130701 - */ - -#include -#include -#include -#include - -#include -#include - -/* Commands with service actions that change the command name */ -#define SERVICE_ACTION_IN_12 0xab -#define SERVICE_ACTION_OUT_12 0xa9 -#define SERVICE_ACTION_BIDIRECTIONAL 0x9d -#define SERVICE_ACTION_IN_16 0x9e -#define SERVICE_ACTION_OUT_16 0x9f -#define THIRD_PARTY_COPY_OUT 0x83 -#define THIRD_PARTY_COPY_IN 0x84 - - - -#ifdef CONFIG_SCSI_CONSTANTS -static const char * cdb_byte0_names[] = { -/* 00-03 */ "Test Unit Ready", "Rezero Unit/Rewind", NULL, "Request Sense", -/* 04-07 */ "Format Unit/Medium", "Read Block Limits", NULL, -"Reassign Blocks", -/* 08-0d */ "Read(6)", NULL, "Write(6)", "Seek(6)", NULL, NULL, -/* 0e-12 */ NULL, "Read Reverse", "Write Filemarks", "Space", "Inquiry", -/* 13-16 */ "Verify(6)", "Recover Buffered Data", "Mode Select(6)", -"Reserve(6)", -/* 17-1a */ "Release(6)", "Copy", "Erase", "Mode Sense(6)", -/* 1b-1d */ "Start/Stop Unit", "Receive Diagnostic", "Send Diagnostic", -/* 1e-1f */ "Prevent/Allow Medium Removal", NULL, -/* 20-22 */ NULL, NULL, NULL, -/* 23-28 */ "Read Format Capacities", "Set Window", -"Read Capacity(10)", NULL, NULL, "Read(10)", -/* 29-2d */ "Read Generation", "Write(10)", "Seek(10)", "Erase(10)", -"Read updated block", -/* 2e-31 */ "Write Verify(10)", "Verify(10)", "Search High", "Search Equal", -/* 32-34 */ "Search Low", "Set Limits", "Prefetch/Read Position", -/* 35-37 */ "Synchronize Cache(10)", "Lock/Unlock Cache(10)", -"Read Defect Data(10)", -/* 38-3c */ "Medium Scan", "Compare", "Copy Verify", "Write Buffer", -"Read Buffer", -/* 3d-3f */ "Update Block", "Read Long(10)", "Write Long(10)", -/* 40-41 */ "Change Definition", "Write Same(10)", -/* 42-48 */ "Unmap/Read sub-channel", "Read TOC/PMA/ATIP", -"Read density support", "Play audio(10)", "Get configuration", -"Play audio msf", "Sanitize/Play audio track/index", -/* 49-4f */ "Play track relative(10)", "Get event status notification", -"Pause/resume", "Log Select", "Log Sense", "Stop play/scan", -NULL, -/* 50-55 */ "Xdwrite", "Xpwrite, Read disk info", "Xdread, Read track info", -"Reserve track", "Send OPC info", "Mode Select(10)", -/* 56-5b */ "Reserve(10)", "Release(10)", "Repair track", "Read master cue", -"Mode Sense(10)", "Close track/session", -/* 5c-5f */ "Read buffer capacity", "Send cue sheet", "Persistent reserve in", -"Persistent reserve out", -/* 60-67 */ NULL, NULL, NULL, NULL, NU
Re: Re: [RFC PATCH 09/10] scsi/trace: Add additional sense code and additional sense code qualifier to scsi_print_sense trace point
(2014/08/27 23:16), Hannes Reinecke wrote: On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote: There are no mean that additional sense code and additional sense code qualifier are output as different messages of sense key, so those information are added. Note: scsi_show_extd_sense() is changed from export symbol to non-export symbol. - Result examples (printk) sd 2:0:0:0: [sda] Add. Sense: Unrecovered read error (ftrace, merged into scsi_print_sense traceevent) scsi_print_sense: host_no=2 channel=0 id=0 lun=0 [sda] Sense Key (Medium Error [current]) Add. Sense (Unrecovered read error) Signed-off-by: Yoshihiro YUNOMAE Cc: Hannes Reinecke Cc: Doug Gilbert Cc: Martin K. Petersen Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: Hidehiro Kawai Cc: Masami Hiramatsu --- drivers/scsi/constants.c| 932 --- drivers/scsi/scsi_trace.c | 920 ++ include/scsi/scsi_dbg.h |2 include/trace/events/scsi.h | 10 4 files changed, 928 insertions(+), 936 deletions(-) diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c index 85b75c8..ce9ceb8 100644 --- a/drivers/scsi/constants.c +++ b/drivers/scsi/constants.c @@ -14,12 +14,6 @@ #include #include -#include -#include -#include -#include - -#include /* Commands with service actions that change the command name */ #define SERVICE_ACTION_IN_12 0xab @@ -429,929 +423,3 @@ void scsi_print_command(struct scsi_cmnd *cmd) print_opcode_name(cmd->device, devname, cmd->cmnd, cmd->cmd_len); } EXPORT_SYMBOL(scsi_print_command); - -#ifdef CONFIG_SCSI_CONSTANTS - -struct error_info { -unsigned short code12;/* 0x0302 looks better than 0x03,0x02 */ -const char * text; -}; - -/* - * The canonical list of T10 Additional Sense Codes is available at: - * http://www.t10.org/lists/asc-num.txt [most recent: 20130605] - */ - -static const struct error_info additional[] = -{ -{0x, "No additional sense information"}, -{0x0001, "Filemark detected"}, -{0x0002, "End-of-partition/medium detected"}, -{0x0003, "Setmark detected"}, -{0x0004, "Beginning-of-partition/medium detected"}, -{0x0005, "End-of-data detected"}, -{0x0006, "I/O process terminated"}, -{0x0007, "Programmable early warning detected"}, -{0x0011, "Audio play operation in progress"}, -{0x0012, "Audio play operation paused"}, -{0x0013, "Audio play operation successfully completed"}, -{0x0014, "Audio play operation stopped due to error"}, -{0x0015, "No current audio status to return"}, -{0x0016, "Operation in progress"}, -{0x0017, "Cleaning requested"}, -{0x0018, "Erase operation in progress"}, -{0x0019, "Locate operation in progress"}, -{0x001A, "Rewind operation in progress"}, -{0x001B, "Set capacity operation in progress"}, -{0x001C, "Verify operation in progress"}, -{0x001D, "ATA pass through information available"}, -{0x001E, "Conflicting SA creation request"}, -{0x001F, "Logical unit transitioning to another power condition"}, -{0x0020, "Extended copy information available"}, - -{0x0100, "No index/sector signal"}, - -{0x0200, "No seek complete"}, - -{0x0300, "Peripheral device write fault"}, -{0x0301, "No write current"}, -{0x0302, "Excessive write errors"}, - -{0x0400, "Logical unit not ready, cause not reportable"}, -{0x0401, "Logical unit is in process of becoming ready"}, -{0x0402, "Logical unit not ready, initializing command required"}, -{0x0403, "Logical unit not ready, manual intervention required"}, -{0x0404, "Logical unit not ready, format in progress"}, -{0x0405, "Logical unit not ready, rebuild in progress"}, -{0x0406, "Logical unit not ready, recalculation in progress"}, -{0x0407, "Logical unit not ready, operation in progress"}, -{0x0408, "Logical unit not ready, long write in progress"}, -{0x0409, "Logical unit not ready, self-test in progress"}, -{0x040A, "Logical unit not accessible, asymmetric access state " - "transition"}, -{0x040B, "Logical unit not accessible, target port in standby state"}, -{0x040C, "Logical unit not accessible, target port in unavailable " - "state"}, -{0x040D, "Logical unit not ready, structure check required"}, -{0x0410, "Logical unit not ready, auxiliary memory not accessible"}, -{0x0411, "Logical unit not ready, notify (enable spinup) required"}, -{0x0412, "Logical unit not ready, offline"}, -{0x0413, "Logical unit not ready, SA creation in progress"}, -{0x0414, "Logical unit not ready, space allocation in progress"}, -{0x0415, "Logical unit not ready, robotics disabled"}, -{0x0416, "Logical unit not ready, configuration required"}, -{0x0417, "Logical unit not ready, calibration required"}, -{0x0418, "Logical unit not ready, a door is open"}, -{0x0419, "Logical unit not ready, operating in sequential mode
Re: Re: [RFC PATCH 08/10] scsi/trace: Use scsi_print_sense trace point instead of printk
(2014/08/27 23:15), Hannes Reinecke wrote: On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote: Previous sense messages can be mixed into other sense messages, because continuous printk (KERN_CONT) was used. To avoid the problem, patch d87f3a6f51 introduced a local buffer in Hannes's baranch (*1). But using local buffers can induce stack overflow, so we want to solve the problem without local buffer if possible. trace_seq_printf can add log messages without local buffer, so we use it. (*1) http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging - Result examples (printk) sd 2:0:0:0: [sda] Sense Key : Medium Error [current] (ftrace) scsi_print_sense: host_no=2 channel=0 id=0 lun=0 [sda] Sense Key (Medium Error [current]) Signed-off-by: Yoshihiro YUNOMAE Cc: Hannes Reinecke Cc: Doug Gilbert Cc: Martin K. Petersen Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: Hidehiro Kawai Cc: Masami Hiramatsu --- drivers/scsi/constants.c| 145 ++- drivers/scsi/scsi_trace.c | 140 -- include/scsi/scsi_eh.h |7 ++ include/trace/events/scsi.h | 48 ++ 4 files changed, 195 insertions(+), 145 deletions(-) diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c index f7b7f32..85b75c8 100644 --- a/drivers/scsi/constants.c +++ b/drivers/scsi/constants.c @@ -19,7 +19,7 @@ #include #include - +#include /* Commands with service actions that change the command name */ #define SERVICE_ACTION_IN_12 0xab @@ -1267,58 +1267,8 @@ static const struct error_info2 additional2[] = {0x70, 0x00, 0xff, "Decompression exception short algorithm id of %x"}, {0, 0, 0, NULL} }; - -/* description of the sense key values */ -static const char * const snstext[] = { -"No Sense",/* 0: There is no sense information */ -"Recovered Error", /* 1: The last command completed successfully - but used error correction */ -"Not Ready",/* 2: The addressed target is not ready */ -"Medium Error",/* 3: Data error detected on the medium */ -"Hardware Error", /* 4: Controller or device failure */ -"Illegal Request", /* 5: Error in request */ -"Unit Attention", /* 6: Removable medium was changed, or - the target has been reset, or ... */ -"Data Protect",/* 7: Access to the data is blocked */ -"Blank Check",/* 8: Reached unexpected written or unwritten - region of the medium */ -"Vendor Specific(9)", -"Copy Aborted",/* A: COPY or COMPARE was aborted */ -"Aborted Command", /* B: The target aborted the command */ -"Equal",/* C: A SEARCH DATA command found data equal, - reserved in SPC-4 rev 36 */ -"Volume Overflow", /* D: Medium full with still data to be written */ -"Miscompare",/* E: Source data and data on the medium - do not agree */ -"Completed",/* F: command completed sense data reported, - may occur for successful command */ -}; -#else -static const char * const snstext[] = { -"0x0", "0x1", "0x2", "0x3", "0x4", "0x5", "0x6", "0x7", -"0x8", "0x9", "0xa", "0xb", "0xc", "0xd", "0xe", "0xf", -}; #endif -/* Get sense key string or NULL if not available */ -const char * -scsi_sense_key_string(unsigned char key) { -return snstext[key & 0xf]; -} -EXPORT_SYMBOL(scsi_sense_key_string); - -const char * -scsi_sense_type_string(struct scsi_sense_hdr *sshdr) -{ -return scsi_sense_is_deferred(sshdr) ? "[deferred]" : "[current]"; -} - -const char * -scsi_sense_format_string(struct scsi_sense_hdr *sshdr) -{ -return sshdr->response_code >= 0x72 ? "[descriptor]" : ""; -} - /* * Get additional sense code string or NULL if not available. * This string may contain a "%x" and should be printed with ascq as arg. @@ -1375,105 +1325,22 @@ void scsi_print_sense_hdr(struct scsi_device *sdev, const char *name, struct scsi_sense_hdr *sshdr) { -sdev_printk(KERN_INFO, sdev, "[%s] Sense Key : %s %s%s\n", name, -scsi_sense_key_string(sshdr->sense_key), -scsi_sense_type_string(sshdr), -scsi_sense_format_string(sshdr)); +trace_scsi_print_sense(sdev, name, sshdr, NULL, 0, 0); scsi_show_extd_sense(sdev, name, sshdr->asc, sshdr->ascq); } EXPORT_SYMBOL(scsi_print_sense_hdr); -static void -scsi_dump_sense_buffer(struct scsi_device *sdev, const char *prefix, - const unsigned char *sense_buffer, int sense_len) -{ -char linebuf[128]; -int i, linelen, remaining; - -if (sense_len < 32) -sense_len = 32; - -remaining = sense_len; -for (i = 0; i < sense_len; i += 16) { -linelen = min(remaining, 16); -remaining -= 16; - -hex_dump_to_buffer(sense_buffer + i, linelen, 16, 1, - linebuf, sizeof(linebu
Re: Re: [RFC PATCH 07/10] scsi/trace: Use scsi_show_result trace point instead of printk
(2014/08/27 23:12), Hannes Reinecke wrote: On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote: Current SCSI trace has hostbyte table and driverbyte table, so we don't need to have the same table in scsi/constants.c. - Result examples (printk) sd 2:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE (ftrace) scsi_show_result: host_no=2 channel=0 id=0 lun=0 [sda] result=(driver=DRIVER_SENSE host=DID_OK) Signed-off-by: Yoshihiro YUNOMAE Cc: Hannes Reinecke Cc: Doug Gilbert Cc: Martin K. Petersen Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: Hidehiro Kawai Cc: Masami Hiramatsu --- drivers/scsi/constants.c| 52 --- drivers/scsi/scsi_trace.c | 16 + include/trace/events/scsi.h | 38 +++ 3 files changed, 53 insertions(+), 53 deletions(-) diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c index 6fad6b4..f7b7f32 100644 --- a/drivers/scsi/constants.c +++ b/drivers/scsi/constants.c @@ -1488,55 +1488,3 @@ void scsi_print_sense(struct scsi_cmnd *cmd) SCSI_SENSE_BUFFERSIZE); } EXPORT_SYMBOL(scsi_print_sense); - -#ifdef CONFIG_SCSI_CONSTANTS - -static const char * const hostbyte_table[]={ -"DID_OK", "DID_NO_CONNECT", "DID_BUS_BUSY", "DID_TIME_OUT", "DID_BAD_TARGET", -"DID_ABORT", "DID_PARITY", "DID_ERROR", "DID_RESET", "DID_BAD_INTR", -"DID_PASSTHROUGH", "DID_SOFT_ERROR", "DID_IMM_RETRY", "DID_REQUEUE", -"DID_TRANSPORT_DISRUPTED", "DID_TRANSPORT_FAILFAST", "DID_TARGET_FAILURE", -"DID_NEXUS_FAILURE" }; -#define NUM_HOSTBYTE_STRS ARRAY_SIZE(hostbyte_table) - -static const char * const driverbyte_table[]={ -"DRIVER_OK", "DRIVER_BUSY", "DRIVER_SOFT", "DRIVER_MEDIA", "DRIVER_ERROR", -"DRIVER_INVALID", "DRIVER_TIMEOUT", "DRIVER_HARD", "DRIVER_SENSE"}; -#define NUM_DRIVERBYTE_STRS ARRAY_SIZE(driverbyte_table) - -void scsi_show_result(struct scsi_device *sdev, const char *name, int result) -{ -int hb = host_byte(result); -int db = driver_byte(result); -const char *hb_string; -const char *db_string; - -hb_string = (hb < NUM_HOSTBYTE_STRS) ? hostbyte_table[hb] : "invalid"; -db_string = (db < NUM_DRIVERBYTE_STRS) ? -driverbyte_table[db] : "invalid"; - - -sdev_printk(KERN_INFO, sdev, -"[%s] Result: hostbyte=%s driverbyte=%s\n", -name, hb_string, db_string); -} - -#else - -void scsi_show_result(struct scsi_device *sdev, const char *name, int result) -{ -sdev_printk(KERN_INFO, sdev, -"[%s] Result: hostbyte=0x%02x driverbyte=0x%02x\n", -name, host_byte(result), driver_byte(result)); -} - -#endif -EXPORT_SYMBOL(scsi_show_result); - -void scsi_print_result(struct scsi_cmnd *cmd) -{ -const char *devname = cmd->request->rq_disk ? -cmd->request->rq_disk->disk_name : "scsi"; -scsi_show_result(cmd->device, devname, cmd->result); -} -EXPORT_SYMBOL(scsi_print_result); diff --git a/drivers/scsi/scsi_trace.c b/drivers/scsi/scsi_trace.c index 2bea4f0..6ffbc40 100644 --- a/drivers/scsi/scsi_trace.c +++ b/drivers/scsi/scsi_trace.c @@ -19,6 +19,8 @@ #include #include +#include + #define SERVICE_ACTION16(cdb) (cdb[1] & 0x1f) #define SERVICE_ACTION32(cdb) ((cdb[8] << 8) | cdb[9]) @@ -286,3 +288,17 @@ scsi_trace_parse_cdb(struct trace_seq *p, unsigned char *cdb, int len) return scsi_trace_misc(p, cdb, len); } } + +void scsi_show_result(struct scsi_device *sdev, const char *name, int result) +{ +trace_scsi_show_result(sdev, name, result); +} +EXPORT_SYMBOL(scsi_show_result); + +void scsi_print_result(struct scsi_cmnd *cmd) +{ +const char *devname = cmd->request->rq_disk ? +cmd->request->rq_disk->disk_name : "scsi"; +scsi_show_result(cmd->device, devname, cmd->result); +} +EXPORT_SYMBOL(scsi_print_result); diff --git a/include/trace/events/scsi.h b/include/trace/events/scsi.h index 8aecdc2..0675195 100644 --- a/include/trace/events/scsi.h +++ b/include/trace/events/scsi.h @@ -123,7 +123,11 @@ scsi_hostbyte_name(DID_IMM_RETRY),\ scsi_hostbyte_name(DID_REQUEUE),\ scsi_hostbyte_name(DID_TRANSPORT_DISRUPTED),\ -scsi_hostbyte_name(DID_TRANSPORT_FAILFAST)) +scsi_hostbyte_name(DID_TRANSPORT_FAILFAST),\ +scsi_hostbyte_name(DID_TARGET_FAILURE),\ +scsi_hostbyte_name(DID_NEXUS_FAILURE),\ +scsi_hostbyte_name(DID_ALLOC_FAILURE),\ +scsi_hostbyte_name(DID_MEDIUM_ERROR)) #define scsi_driverbyte_name(result){ result, #result } #define show_driverbyte_name(val)\ @@ -359,6 +363,38 @@ TRACE_EVENT(scsi_eh_wakeup, TP_printk("host_no=%u", __entry->host_no) ); +TRACE_EVENT(scsi_show_result, + +TP_PROTO(struct scsi_device *sdev, const char *devname, int result), + +TP_ARGS(sdev, devname, result), + +TP_STRUCT__entry( +__field( unsigned int,host_no) +__field( unsigned int,
Re: [PATCH] fusion: fix excess parameter kernel-doc warning
On Wed, Aug 27, 2014 at 04:47:24PM -0700, Randy Dunlap wrote: > > Goes with commit c9834c70efbaaa1461ec04289d97a842244fb294. > > > > Reviewed-by: Ewan D. Milne > > Christoph, did you pick up this patch or should I merge it > with my documentation patches? I did as mentioned in my reply to your other patch. -- 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] fusion: fix excess parameter kernel-doc warning
On 08/18/14 10:07, Ewan Milne wrote: > On Sat, 2014-08-16 at 14:15 -0700, Randy Dunlap wrote: >> From: Randy Dunlap >> >> Fix kernel-doc excess parameter warning: >> >> Warning(..//drivers/message/fusion/mptbase.c:1411): Excess function >> parameter 'prod_name' description in 'mpt_get_product_name' >> >> Signed-off-by: Randy Dunlap >> Cc: dl-mptfusionli...@lsi.com >> Cc: mpt-fusionlinux@avagotech.com >> --- >> drivers/message/fusion/mptbase.c |1 - >> 1 file changed, 1 deletion(-) >> >> Index: lnx-317-rc1/drivers/message/fusion/mptbase.c >> === >> --- lnx-317-rc1.orig/drivers/message/fusion/mptbase.c >> +++ lnx-317-rc1/drivers/message/fusion/mptbase.c >> @@ -1400,7 +1400,6 @@ mpt_verify_adapter(int iocid, MPT_ADAPTE >> * @vendor: pci vendor id >> * @device: pci device id >> * @revision: pci revision id >> - * @prod_name: string returned >> * >> * Returns product string displayed when driver loads, >> * in /proc/mpt/summary and /sysfs/class/scsi_host/host/version_product >> -- > > Goes with commit c9834c70efbaaa1461ec04289d97a842244fb294. > > Reviewed-by: Ewan D. Milne Christoph, did you pick up this patch or should I merge it with my documentation patches? Thanks. -- ~Randy -- 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: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On Wed, 27 Aug 2014, Dale R. Worley wrote: > What I find interesting is that Windows (at least, Windows 7 > Professional) seems to be able to handle the deficient adapter. So does Linux. The difference is that Windows believes the values in the partition table in preference to what the hardware says, whereas Linux believes the hardware in preference to the partition table. Thus, if the hardware says the disk contains 0.8 TB and the partition table says the first partition contains 2.8 TB, Windows will try to access all 2.8 TB but Linux will complain that the partition entry is invalid (because the partition extends beyond the end of the disk). If you try to repartition the drive under Windows using the deficient adapter, you'll see that the problem still exists. It just doesn't show up during normal use. > What > I'd like to do is log the disk commands during the mounting sequence, > preferably at both the SCSI and USB layers. Then at least we'll know > exactly what the driver is doing. Are there kernel options to do > this? You can record the USB transfers by using usbmon (see Documentation/usb/usbmon.txt). The trace will include all the important SCSI data, so you don't need to record anything at the SCSI layer. This isn't really necessary, though. We already know what the driver is doing. > Unfortunately, I don't know any way to log what Windows is doing with > the drive. My experiments with Windows show that it does essentially the same things as Linux does. The important difference is not what commands and data get sent, but whether the OS pays attention to the result. 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: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On Wed, 2014-08-27 at 15:21 -0400, Dale R. Worley wrote: > > From: James Bottomley > > > Did you try read capacity 16 on it? What happened? (the AS2105 rejects > > read capacity 16, so there's no reliable way to deduce the capacity of > > drives over 2TB). > > OK, I had to track down which package contains sg_readcap. > > The adapter that fails gives this output: > > # sg_readcap --16 /dev/sdb > bad field in READ CAPACITY (16) cdb including unsupported service action OK, so that's definitely the tame taxonomy. James -- 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: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
What I find interesting is that Windows (at least, Windows 7 Professional) seems to be able to handle the deficient adapter. What I'd like to do is log the disk commands during the mounting sequence, preferably at both the SCSI and USB layers. Then at least we'll know exactly what the driver is doing. Are there kernel options to do this? Unfortunately, I don't know any way to log what Windows is doing with the drive. Dale -- 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: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
> From: James Bottomley > Did you try read capacity 16 on it? What happened? (the AS2105 rejects > read capacity 16, so there's no reliable way to deduce the capacity of > drives over 2TB). OK, I had to track down which package contains sg_readcap. The adapter that fails gives this output: # sg_readcap --16 /dev/sdb bad field in READ CAPACITY (16) cdb including unsupported service action The adapter that succeeds gives this output: # sg_readcap --16 /dev/sdc Read Capacity results: Protection: prot_en=0, p_type=0, p_i_exponent=0 Logical block provisioning: lbpme=0, lbprz=0 Last logical block address=5860533167 (0x15d50a3af), Number of logical blocks=5860533168 Logical block length=512 bytes Logical blocks per physical block exponent=0 Lowest aligned logical block address=0 Hence: Device size: 3000592982016 bytes, 2861588.5 MiB, 3000.59 GB Dale -- 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 RESEND] libiscsi: Don't retry if xmit_task return a non-transient error code
On 08/17/2014 10:23 AM, Sagi Grimberg wrote: > Allow transport callback xmit_task to return a non-transient > error code -EINVAL to inform us not to retry the task. For any > other error code keep the current retry behavior. > > Signed-off-by: Sagi Grimberg > --- > drivers/scsi/libiscsi.c | 13 ++--- > 1 files changed, 10 insertions(+), 3 deletions(-) > > diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c > index 3d1bc67..03768a9 100644 > --- a/drivers/scsi/libiscsi.c > +++ b/drivers/scsi/libiscsi.c > @@ -1722,10 +1722,17 @@ int iscsi_queuecommand(struct Scsi_Host *host, struct > scsi_cmnd *sc) > goto prepd_fault; > } > } > - if (session->tt->xmit_task(task)) { > + > + reason = session->tt->xmit_task(task); > + if (reason) { > session->cmdsn--; > - reason = FAILURE_SESSION_NOT_READY; > - goto prepd_reject; > + if (reason == -EINVAL) { > + sc->result = DID_ABORT << 16; > + goto prepd_fault; > + } else { > + reason = FAILURE_SESSION_NOT_READY; > + goto prepd_reject; > + } > } > } else { > list_add_tail(&task->running, &conn->cmdqueue); > Looks ok to me. Acked-by: Mike Christie -- 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] lpfc: Avoid to disable pci_dev twice
Mike, Can you confirm - the "nulls" this patch correct are because the probe_one and error_detect threads are running concurrently, thus battling ? If so - this fix looks insufficient and we should rework it. Q: why are they allowed to run concurrently ? I could see this solved at the platform level to let probe_one finish before error_detect is called (and therefore stating error_detect only makes sense to call if probe_one was successful). It's also a much driver-friendly solution. I could see other drivers have much the same issue with concurrency and data structure teardown - and if locks aren't allowed in the error-detect path... it's not good. -- james s On 7/31/2014 10:16 PM, Mike Qiu wrote: On 07/17/2014 02:32 PM, Mike Qiu wrote: Hi, all How about this patch ? Any idea ? In IBM Power servers, when hardware error occurs during probe state, EEH subsystem will call driver's error_detected interface, which will call pci_disable_device(). But driver's probe function also call pci_disable_device() in this situation. So pci_dev will be disabled twice: Device lpfc disabling already-disabled device [ cut here ] WARNING: at drivers/pci/pci.c:1407 CPU: 0 PID: 8744 Comm: kworker/0:0 Tainted: GW 3.10.42-2002.pkvm2_1_1.6.ppc64 #1 Workqueue: events .work_for_cpu_fn task: c0274e3f5400 ti: c027d3958000 task.ti: c027d3958000 NIP: c0471b8c LR: c0471b88 CTR: c043ebe0 REGS: c027d395b650 TRAP: 0700 Tainted: GW (3.10.42-2002.pkvm2_1_1.6.ppc64) MSR: 900100029032 CR: 28b52b44 XER: 2000 CFAR: c0879ab8 SOFTE: 1 ... NIP .pci_disable_device+0xcc/0xe0 LR .pci_disable_device+0xc8/0xe0 Call Trace: .pci_disable_device+0xc8/0xe0 (unreliable) .lpfc_disable_pci_dev+0x50/0x80 [lpfc] .lpfc_pci_probe_one+0x870/0x21a0 [lpfc] .local_pci_probe+0x68/0xb0 .work_for_cpu_fn+0x38/0x60 .process_one_work+0x1a4/0x4d0 .worker_thread+0x37c/0x490 .kthread+0xf0/0x100 .ret_from_kernel_thread+0x5c/0x80 Signed-off-by: Mike Qiu --- drivers/scsi/lpfc/lpfc.h | 1 + drivers/scsi/lpfc/lpfc_init.c | 59 +++ 2 files changed, 55 insertions(+), 5 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h index 434e903..0c7bad9 100644 --- a/drivers/scsi/lpfc/lpfc.h +++ b/drivers/scsi/lpfc/lpfc.h @@ -813,6 +813,7 @@ struct lpfc_hba { #define VPD_MASK0xf /* mask for any vpd data */ uint8_t soft_wwn_enable; +uint8_t probe_done; struct timer_list fcp_poll_timer; struct timer_list eratt_poll; diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c index 06f9a5b..c2e67ae 100644 --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -9519,6 +9519,9 @@ lpfc_pci_probe_one_s3(struct pci_dev *pdev, const struct pci_device_id *pid) } } +/* Set the probe flag */ +phba->probe_done = 1; + /* Perform post initialization setup */ lpfc_post_init_setup(phba); @@ -9795,6 +9798,9 @@ lpfc_sli_prep_dev_for_recover(struct lpfc_hba *phba) static void lpfc_sli_prep_dev_for_reset(struct lpfc_hba *phba) { +if (phba) +return; + lpfc_printf_log(phba, KERN_ERR, LOG_INIT, "2710 PCI channel disable preparing for reset\n"); @@ -9812,7 +9818,8 @@ lpfc_sli_prep_dev_for_reset(struct lpfc_hba *phba) /* Disable interrupt and pci device */ lpfc_sli_disable_intr(phba); -pci_disable_device(phba->pcidev); +if (phba->probe_done && phba->pcidev) +pci_disable_device(phba->pcidev); } /** @@ -10282,6 +10289,9 @@ lpfc_pci_probe_one_s4(struct pci_dev *pdev, const struct pci_device_id *pid) goto out_disable_intr; } +/* Set probe_done flag */ +phba->probe_done = 1; + /* Log the current active interrupt mode */ phba->intr_mode = intr_mode; lpfc_log_intr_mode(phba, intr_mode); @@ -10544,6 +10554,9 @@ lpfc_sli4_prep_dev_for_recover(struct lpfc_hba *phba) static void lpfc_sli4_prep_dev_for_reset(struct lpfc_hba *phba) { +if (!phba) +return; + lpfc_printf_log(phba, KERN_ERR, LOG_INIT, "2826 PCI channel disable preparing for reset\n"); @@ -10562,7 +10575,9 @@ lpfc_sli4_prep_dev_for_reset(struct lpfc_hba *phba) /* Disable interrupt and pci device */ lpfc_sli4_disable_intr(phba); lpfc_sli4_queue_destroy(phba); -pci_disable_device(phba->pcidev); + +if (phba->probe_done && phba->pcidev) +pci_disable_device(phba->pcidev); } /** @@ -10893,9 +10908,21 @@ static pci_ers_result_t lpfc_io_error_detected(struct pci_dev *pdev, pci_channel_state_t state) { struct Scsi_Host *shost = pci_get_drvdata(pdev); -struct lpfc_hba *phba = ((struct lpfc_vport *)shost->hostdata)->phba; +struct lpfc_hba *phba; pci_ers_result_t rc = PCI_ERS_RESULT_DISCONNECT; +if (!shost) +/* Run
[PATCH] ibmraid: fix writeable attribute with no store method
https://bugzilla.kernel.org/show_bug.cgi?id=81311 [ 0.603157] WARNING: at drivers/base/core.c:601 device_create_file+0x8d/0xa0() [ 0.603158] Attribute adapter_id: write permission without 'store' [ 0.603159] Modules linked in: i915(+) i2c_algo_bit drm_kms_helper drm mpt2sas(+) pmcraid(+) raid_class scsi_transport_sas i2c_core video Signed-off-by: Alan Cox --- drivers/scsi/pmcraid.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c index 6f3275d..e2232c3 100644 --- a/drivers/scsi/pmcraid.c +++ b/drivers/scsi/pmcraid.c @@ -4292,7 +4292,7 @@ static ssize_t pmcraid_show_adapter_id( static struct device_attribute pmcraid_adapter_id_attr = { .attr = { .name = "adapter_id", -.mode = S_IRUGO | S_IWUSR, +.mode = S_IRUGO, }, .show = pmcraid_show_adapter_id, }; -- 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: Buffer I/O error after s2ram with usb storage
On Wed, 27 Aug 2014, Douglas Gilbert wrote: > The unit attention doesn't look like a problem, it > looks correct. If the system is unable to detect > removable media being changed while the system is > suspended, then > > If the media has a unique identifier, then this unit > attention at wakeup should trigger sd to make sure > that unique identifier has not changed. Does sd have any code to do this? I'm not aware of any, but there ought to be some. Otherwise there's no way to tell when a so-called media change was just the old media being taken out and put back in. Or maybe this functionality belongs in the block layer rather than in sd. 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: Buffer I/O error after s2ram with usb storage
On Wed, 27 Aug 2014, Matthieu CASTET wrote: > Ping > > I have got also a problem with a usb sdcard reader (without power cut > during suspend) > > > The usb storage driver call scsi_report_bus_reset after device reset, > > > but because of commit dfcf7775 <4>, we don't ignore unit attention if > > > "sshdr.asc == 0x28 && sshdr.ascq == 0x00" ("Not-ready to ready"). > > > > > > If dfcf7775 is reverted there is no more Buffer I/O error. > > > > > > Is that possible to find a way to restore the behavior before dfcf7775 > > > commit (no Buffer I/O error after device reset) after a suspend to ram ? Since that commit was written to fix a problem with certain cdrom drives, maybe we would work around the issue by modifying the commit. Have it go back to the original behavior if the device isn't a cdrom drive. That's not a complete fix (it won't help when a CD drive is attached via USB), but maybe it's better than nothing. 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: [RFC PATCH -logging 00/10] scsi/constants: Output continuous error messages on trace
On 14-08-27 10:23 AM, Hannes Reinecke wrote: On 08/08/2014 03:07 PM, Douglas Gilbert wrote: On 14-08-08 01:50 PM, Yoshihiro YUNOMAE wrote: Hi All, This patch set introduces new traceevents in order to output continuous error messages. Current SCSI printk messages in upstream kernel can be divided by and mixed with other messages. Even if each error message has its device id, sometimes we can easily be lost in mixed logs because the message's device id is separated from it's body. To avoid it, I'd like to use traceevents to store error messages into the ftrace or perf buuffer, because traceevents are atomically commited to the buffer. In this patch set, all printk messages are removed based on a local discussion with Hannes, but I think printk messages should be kept because all users don't enable traceevents and rsyslog can store as files. However, if printk of logging branch is kept, the messages are duplicate and it can induce stack overflow by using local buffer(*1). (*1) https://lkml.org/lkml/2014/5/20/742 So, my suggestion is follows: 1) printk Keeps current implemntation of upstream kernel. The messages are divided and can be mixed, but all users can check the error messages without any settings. 2) traceevents To get the complete messages, we can use ftrace or perf (or something on them). Users can always understand correct messages, but they need to set up the tracers. This patch set is based on Hannes' logging branch: http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging [1/10] ~ [6/10]: just cleanup for logging branch [7/10] ~ [10/10]: introduce new traceevents Any comments are welcome! In sg3_utils there are now string yielding equivalents to the sense buffer "print" functions. They take a form like this: char * get_sense_str(const unsigned char * sense_buffer, int sb_len, int blen, char * b); So this just does the hard work of decoding the sense buffer (or saying it is invalid) the result of which it places in buffer 'b'. And 'b' is returned (so this function can be in the arguments of a driver's printing function). Adding such string functions would give other parts of the SCSI subsystem the capability of tailoring their own messages that include sense data information. Existing sense buffer "print" function could be kept and implemented using the newer "_str" variants. Would that be worth the trouble? Hmm. Probably not. I would rather go the approach we've been taking with the VPD pages, and do _not_ decode any sense code data (except from the usual sense key/ASC/ASCQ values, of course). Instead we should rather ensure that we can get to the raw sense code values from userspace so that we can interpret it later with userspace tools. My plan for updating scsi logging is: - move all lone 'printk' statements into dev_printk() variants and ensure they are printed in one line to avoid breaking logging statements up under high load - Update scsi_trace to use the functionality from constants.c - Convert the current scsi_logging mechanism over to tracepoints. The first bit is mostly done; I'll be sending the patchset for review. The hard part is the third bit; would be really grand if we can model this with the existing scsi_logging_level interface intact. But not sure if that's possible nor if it's desirable. Btw, _now_ would be a good chance to send an update of constants.c with latest SPC bits ... From constants.c: * Updated to SPC-4 T10/1713-D Rev 36g, D. Gilbert 20130701 Not much has changed between then and now (37a). There is a lot pending for SPC-5 plus all the ZBC stuff, little of which has hit the drafts yet. WRITE ATOMIC and a few new asc/ascq codes is about all that I have noticed. Even when new asc/ascq strings are approved, it needs the SPC4/5 technical editor to allocate numbers for them. So even if the timing is good from the kernel POV, not much is available. The next T10 meeting is in a few weeks, lets see what happens there. Doug Gilbert -- 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: RES: RES: AS2105-based enclosure size issues with >2TB HDDs
On Wed, 27 Aug 2014, Oliver Neukum wrote: > > I don't think we want to add another SCSI flag to say that READ > > CAPACITY(10) is unreliable. > > Why not? It would only be friendly to tell the upper layer > of a malfunction if we know about it. To what end? What will the upper layer do with this information? > > Given the difficulty of determining the true capacity, I see two > > alternatives. We could set the capacity to a ridiculously large value > > (like 1 billion TB), or we could leave the capacity set to the low > > value and disable the "block within bounds" checks. Neither of these > > is attractive and they both have issues of their own -- although the > > second is close to what Windows does. > > That seems to be the most attractive solution to me. I'm skeptical that you can convince the SCSI and block-layer developers about this. Maybe they'll accept it if it is applied only to USB transports... > > (For example, udev often tries to read the last sectors of a new drive, > > looking for a GPT or RAID signature. That won't work if the capacity > > is set to some random value.) > > Yes, but clipping has its own dangers. Suppose you use the medium > without a partition table. What would Windows do? In the absence of a partition table, it would believe the value from READ CAPACITY, right? Isn't that the same as clipping? 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: [PATCH 2/2] Drivers: scsi: storvsc: Force discovery of LUNs that may have been removed.
On 08/19/2014 07:54 PM, Christoph Hellwig wrote: On Sat, Aug 16, 2014 at 08:09:48PM -0700, K. Y. Srinivasan wrote: The host asks the guest to scan when a LUN is removed or added. The only way a guest can identify the removed LUN is when an I/O is attempted on a removed LUN - the SRB status code indicates that the LUN is invalid. We currently handle this SRB status and remove the device. Rather than waiting for an I/O to remove the device, force the discovery of LUNs that may have been removed prior to discovering LUNs that may have been added. This looks pretty reasonable to me, but I wonder if we should move this up to common code so that it happens for any host rescan triggered by sysfs or other drivers as well. Not without proper testing. Currently we cannot rescan existing devices; the inquiry string is nailed to the sdev structure. The only way to really refresh the information is to delete it and rescan it again. And I really do _not_ want to do this automatically as the device might be busy due to various reasons (think of multipathing). It tooks us ages to get this working with FC, and we finally settled to have a soft-remove implemented in the transport class. And we still have issues with SAS HBAs, where at least the standard defines a mechanism. Trying this in the SCSI midlayer itself is the road to disaster. If we were to attempt this we would need to lift the dev_loss_tmo mechanism from the FC transport layer and make this a generic facility for every HBA. But this is quite some work. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 09/10] scsi/trace: Add additional sense code and additional sense code qualifier to scsi_print_sense trace point
On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote: There are no mean that additional sense code and additional sense code qualifier are output as different messages of sense key, so those information are added. Note: scsi_show_extd_sense() is changed from export symbol to non-export symbol. - Result examples (printk) sd 2:0:0:0: [sda] Add. Sense: Unrecovered read error (ftrace, merged into scsi_print_sense traceevent) scsi_print_sense: host_no=2 channel=0 id=0 lun=0 [sda] Sense Key (Medium Error [current]) Add. Sense (Unrecovered read error) Signed-off-by: Yoshihiro YUNOMAE Cc: Hannes Reinecke Cc: Doug Gilbert Cc: Martin K. Petersen Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: Hidehiro Kawai Cc: Masami Hiramatsu --- drivers/scsi/constants.c| 932 --- drivers/scsi/scsi_trace.c | 920 ++ include/scsi/scsi_dbg.h |2 include/trace/events/scsi.h | 10 4 files changed, 928 insertions(+), 936 deletions(-) diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c index 85b75c8..ce9ceb8 100644 --- a/drivers/scsi/constants.c +++ b/drivers/scsi/constants.c @@ -14,12 +14,6 @@ #include #include -#include -#include -#include -#include - -#include /* Commands with service actions that change the command name */ #define SERVICE_ACTION_IN_12 0xab @@ -429,929 +423,3 @@ void scsi_print_command(struct scsi_cmnd *cmd) print_opcode_name(cmd->device, devname, cmd->cmnd, cmd->cmd_len); } EXPORT_SYMBOL(scsi_print_command); - -#ifdef CONFIG_SCSI_CONSTANTS - -struct error_info { - unsigned short code12; /* 0x0302 looks better than 0x03,0x02 */ - const char * text; -}; - -/* - * The canonical list of T10 Additional Sense Codes is available at: - * http://www.t10.org/lists/asc-num.txt [most recent: 20130605] - */ - -static const struct error_info additional[] = -{ - {0x, "No additional sense information"}, - {0x0001, "Filemark detected"}, - {0x0002, "End-of-partition/medium detected"}, - {0x0003, "Setmark detected"}, - {0x0004, "Beginning-of-partition/medium detected"}, - {0x0005, "End-of-data detected"}, - {0x0006, "I/O process terminated"}, - {0x0007, "Programmable early warning detected"}, - {0x0011, "Audio play operation in progress"}, - {0x0012, "Audio play operation paused"}, - {0x0013, "Audio play operation successfully completed"}, - {0x0014, "Audio play operation stopped due to error"}, - {0x0015, "No current audio status to return"}, - {0x0016, "Operation in progress"}, - {0x0017, "Cleaning requested"}, - {0x0018, "Erase operation in progress"}, - {0x0019, "Locate operation in progress"}, - {0x001A, "Rewind operation in progress"}, - {0x001B, "Set capacity operation in progress"}, - {0x001C, "Verify operation in progress"}, - {0x001D, "ATA pass through information available"}, - {0x001E, "Conflicting SA creation request"}, - {0x001F, "Logical unit transitioning to another power condition"}, - {0x0020, "Extended copy information available"}, - - {0x0100, "No index/sector signal"}, - - {0x0200, "No seek complete"}, - - {0x0300, "Peripheral device write fault"}, - {0x0301, "No write current"}, - {0x0302, "Excessive write errors"}, - - {0x0400, "Logical unit not ready, cause not reportable"}, - {0x0401, "Logical unit is in process of becoming ready"}, - {0x0402, "Logical unit not ready, initializing command required"}, - {0x0403, "Logical unit not ready, manual intervention required"}, - {0x0404, "Logical unit not ready, format in progress"}, - {0x0405, "Logical unit not ready, rebuild in progress"}, - {0x0406, "Logical unit not ready, recalculation in progress"}, - {0x0407, "Logical unit not ready, operation in progress"}, - {0x0408, "Logical unit not ready, long write in progress"}, - {0x0409, "Logical unit not ready, self-test in progress"}, - {0x040A, "Logical unit not accessible, asymmetric access state " -"transition"}, - {0x040B, "Logical unit not accessible, target port in standby state"}, - {0x040C, "Logical unit not accessible, target port in unavailable " -"state"}, - {0x040D, "Logical unit not ready, structure check required"}, - {0x0410, "Logical unit not ready, auxiliary memory not accessible"}, - {0x0411, "Logical unit not ready, notify (enable spinup) required"}, - {0x0412, "Logical unit not ready, offline"}, - {0x0413, "Logical unit not ready, SA creation in progress"}, - {0x0414, "Logical unit not ready, space allocation in progress"}, - {0x0415, "Logical unit not ready, robotics disabled"}, - {0x0416, "Logical unit not ready, configuration required"}, - {0x0417, "Logical unit not ready, calibration required"}, -
Re: [RFC PATCH 10/10] scsi/trace: Use scsi_print_command trace point instead of printk
On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote: Previous printk messages of SCSI command can be mixed into other printk messages because multiple printk messages are output for it. To avoid the problem, patch 4e64bb8d6 in Hannes' branch(*1) introduced a local buffer. But using local buffers can induce stack overflow, so we want to solve the problem without local buffer if possible. trace_seq_printf can add log messages without local buffer, so we use it. Note: We don't need constans.c any more. (*1) http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging - Result examples (printk) sd 2:0:0:0: [sda] CDB: Read(10) scsi_print_command: host_no=2 channel=0 id=0 lun=0 [sda] CDB (Read(10)) Signed-off-by: Yoshihiro YUNOMAE Cc: Hannes Reinecke Cc: Doug Gilbert Cc: Martin K. Petersen Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: Hidehiro Kawai Cc: Masami Hiramatsu --- drivers/scsi/Makefile |2 drivers/scsi/constants.c| 425 --- drivers/scsi/scsi_trace.c | 408 + include/scsi/scsi.h |8 + include/trace/events/scsi.h | 45 + 5 files changed, 461 insertions(+), 427 deletions(-) delete mode 100644 drivers/scsi/constants.c diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile index 5f0d299..c56f692 100644 --- a/drivers/scsi/Makefile +++ b/drivers/scsi/Makefile @@ -158,7 +158,7 @@ obj-$(CONFIG_SCSI_OSD_INITIATOR) += osd/ # This goes last, so that "real" scsi devices probe earlier obj-$(CONFIG_SCSI_DEBUG) += scsi_debug.o -scsi_mod-y += scsi.o hosts.o scsi_ioctl.o constants.o \ +scsi_mod-y += scsi.o hosts.o scsi_ioctl.o \ scsicam.o scsi_error.o scsi_lib.o scsi_mod-$(CONFIG_SCSI_DMA) += scsi_lib_dma.o scsi_mod-y+= scsi_scan.o scsi_sysfs.o scsi_devinfo.o diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c deleted file mode 100644 index ce9ceb8..000 --- a/drivers/scsi/constants.c +++ /dev/null @@ -1,425 +0,0 @@ -/* - * ASCII values for a number of symbolic constants, printing functions, - * etc. - * Additions for SCSI 2 and Linux 2.2.x by D. Gilbert (990422) - * Additions for SCSI 3+ (SPC-3 T10/1416-D Rev 07 3 May 2002) - * by D. Gilbert and aeb (20020609) - * Updated to SPC-4 T10/1713-D Rev 36g, D. Gilbert 20130701 - */ - -#include -#include -#include -#include - -#include -#include - -/* Commands with service actions that change the command name */ -#define SERVICE_ACTION_IN_12 0xab -#define SERVICE_ACTION_OUT_12 0xa9 -#define SERVICE_ACTION_BIDIRECTIONAL 0x9d -#define SERVICE_ACTION_IN_16 0x9e -#define SERVICE_ACTION_OUT_16 0x9f -#define THIRD_PARTY_COPY_OUT 0x83 -#define THIRD_PARTY_COPY_IN 0x84 - - - -#ifdef CONFIG_SCSI_CONSTANTS -static const char * cdb_byte0_names[] = { -/* 00-03 */ "Test Unit Ready", "Rezero Unit/Rewind", NULL, "Request Sense", -/* 04-07 */ "Format Unit/Medium", "Read Block Limits", NULL, - "Reassign Blocks", -/* 08-0d */ "Read(6)", NULL, "Write(6)", "Seek(6)", NULL, NULL, -/* 0e-12 */ NULL, "Read Reverse", "Write Filemarks", "Space", "Inquiry", -/* 13-16 */ "Verify(6)", "Recover Buffered Data", "Mode Select(6)", - "Reserve(6)", -/* 17-1a */ "Release(6)", "Copy", "Erase", "Mode Sense(6)", -/* 1b-1d */ "Start/Stop Unit", "Receive Diagnostic", "Send Diagnostic", -/* 1e-1f */ "Prevent/Allow Medium Removal", NULL, -/* 20-22 */ NULL, NULL, NULL, -/* 23-28 */ "Read Format Capacities", "Set Window", - "Read Capacity(10)", NULL, NULL, "Read(10)", -/* 29-2d */ "Read Generation", "Write(10)", "Seek(10)", "Erase(10)", -"Read updated block", -/* 2e-31 */ "Write Verify(10)", "Verify(10)", "Search High", "Search Equal", -/* 32-34 */ "Search Low", "Set Limits", "Prefetch/Read Position", -/* 35-37 */ "Synchronize Cache(10)", "Lock/Unlock Cache(10)", - "Read Defect Data(10)", -/* 38-3c */ "Medium Scan", "Compare", "Copy Verify", "Write Buffer", - "Read Buffer", -/* 3d-3f */ "Update Block", "Read Long(10)", "Write Long(10)", -/* 40-41 */ "Change Definition", "Write Same(10)", -/* 42-48 */ "Unmap/Read sub-channel", "Read TOC/PMA/ATIP", - "Read density support", "Play audio(10)", "Get configuration", - "Play audio msf", "Sanitize/Play audio track/index", -/* 49-4f */ "Play track relative(10)", "Get event status notification", -"Pause/resume", "Log Select", "Log Sense", "Stop play/scan", -NULL, -/* 50-55 */ "Xdwrite", "Xpwrite, Read disk info", "Xdread, Read track info", -"Reserve track", "Send OPC info", "Mode Select(10)", -/* 56-5b */ "Reserve(10)", "Release(10)", "Repair track", "Read master cue", -"Mode Sense(10)", "Close track/session", -/* 5c-5f */ "Read buffer capacity", "Send cue sheet", "Persistent reserve in", -"Persistent reserve out", -/* 60-67 */ NULL, NU
Re: [RFC PATCH -logging 00/10] scsi/constants: Output continuous error messages on trace
On 08/08/2014 03:07 PM, Douglas Gilbert wrote: On 14-08-08 01:50 PM, Yoshihiro YUNOMAE wrote: Hi All, This patch set introduces new traceevents in order to output continuous error messages. Current SCSI printk messages in upstream kernel can be divided by and mixed with other messages. Even if each error message has its device id, sometimes we can easily be lost in mixed logs because the message's device id is separated from it's body. To avoid it, I'd like to use traceevents to store error messages into the ftrace or perf buuffer, because traceevents are atomically commited to the buffer. In this patch set, all printk messages are removed based on a local discussion with Hannes, but I think printk messages should be kept because all users don't enable traceevents and rsyslog can store as files. However, if printk of logging branch is kept, the messages are duplicate and it can induce stack overflow by using local buffer(*1). (*1) https://lkml.org/lkml/2014/5/20/742 So, my suggestion is follows: 1) printk Keeps current implemntation of upstream kernel. The messages are divided and can be mixed, but all users can check the error messages without any settings. 2) traceevents To get the complete messages, we can use ftrace or perf (or something on them). Users can always understand correct messages, but they need to set up the tracers. This patch set is based on Hannes' logging branch: http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging [1/10] ~ [6/10]: just cleanup for logging branch [7/10] ~ [10/10]: introduce new traceevents Any comments are welcome! In sg3_utils there are now string yielding equivalents to the sense buffer "print" functions. They take a form like this: char * get_sense_str(const unsigned char * sense_buffer, int sb_len, int blen, char * b); So this just does the hard work of decoding the sense buffer (or saying it is invalid) the result of which it places in buffer 'b'. And 'b' is returned (so this function can be in the arguments of a driver's printing function). Adding such string functions would give other parts of the SCSI subsystem the capability of tailoring their own messages that include sense data information. Existing sense buffer "print" function could be kept and implemented using the newer "_str" variants. Would that be worth the trouble? Hmm. Probably not. I would rather go the approach we've been taking with the VPD pages, and do _not_ decode any sense code data (except from the usual sense key/ASC/ASCQ values, of course). Instead we should rather ensure that we can get to the raw sense code values from userspace so that we can interpret it later with userspace tools. My plan for updating scsi logging is: - move all lone 'printk' statements into dev_printk() variants and ensure they are printed in one line to avoid breaking logging statements up under high load - Update scsi_trace to use the functionality from constants.c - Convert the current scsi_logging mechanism over to tracepoints. The first bit is mostly done; I'll be sending the patchset for review. The hard part is the third bit; would be really grand if we can model this with the existing scsi_logging_level interface intact. But not sure if that's possible nor if it's desirable. Btw, _now_ would be a good chance to send an update of constants.c with latest SPC bits ... Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 08/10] scsi/trace: Use scsi_print_sense trace point instead of printk
On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote: Previous sense messages can be mixed into other sense messages, because continuous printk (KERN_CONT) was used. To avoid the problem, patch d87f3a6f51 introduced a local buffer in Hannes's baranch (*1). But using local buffers can induce stack overflow, so we want to solve the problem without local buffer if possible. trace_seq_printf can add log messages without local buffer, so we use it. (*1) http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging - Result examples (printk) sd 2:0:0:0: [sda] Sense Key : Medium Error [current] (ftrace) scsi_print_sense: host_no=2 channel=0 id=0 lun=0 [sda] Sense Key (Medium Error [current]) Signed-off-by: Yoshihiro YUNOMAE Cc: Hannes Reinecke Cc: Doug Gilbert Cc: Martin K. Petersen Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: Hidehiro Kawai Cc: Masami Hiramatsu --- drivers/scsi/constants.c| 145 ++- drivers/scsi/scsi_trace.c | 140 -- include/scsi/scsi_eh.h |7 ++ include/trace/events/scsi.h | 48 ++ 4 files changed, 195 insertions(+), 145 deletions(-) diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c index f7b7f32..85b75c8 100644 --- a/drivers/scsi/constants.c +++ b/drivers/scsi/constants.c @@ -19,7 +19,7 @@ #include #include - +#include /* Commands with service actions that change the command name */ #define SERVICE_ACTION_IN_12 0xab @@ -1267,58 +1267,8 @@ static const struct error_info2 additional2[] = {0x70, 0x00, 0xff, "Decompression exception short algorithm id of %x"}, {0, 0, 0, NULL} }; - -/* description of the sense key values */ -static const char * const snstext[] = { - "No Sense", /* 0: There is no sense information */ - "Recovered Error", /* 1: The last command completed successfully - but used error correction */ - "Not Ready", /* 2: The addressed target is not ready */ - "Medium Error", /* 3: Data error detected on the medium */ - "Hardware Error", /* 4: Controller or device failure */ - "Illegal Request", /* 5: Error in request */ - "Unit Attention", /* 6: Removable medium was changed, or - the target has been reset, or ... */ - "Data Protect", /* 7: Access to the data is blocked */ - "Blank Check",/* 8: Reached unexpected written or unwritten - region of the medium */ - "Vendor Specific(9)", - "Copy Aborted", /* A: COPY or COMPARE was aborted */ - "Aborted Command", /* B: The target aborted the command */ - "Equal", /* C: A SEARCH DATA command found data equal, - reserved in SPC-4 rev 36 */ - "Volume Overflow", /* D: Medium full with still data to be written */ - "Miscompare", /* E: Source data and data on the medium - do not agree */ - "Completed", /* F: command completed sense data reported, - may occur for successful command */ -}; -#else -static const char * const snstext[] = { - "0x0", "0x1", "0x2", "0x3", "0x4", "0x5", "0x6", "0x7", - "0x8", "0x9", "0xa", "0xb", "0xc", "0xd", "0xe", "0xf", -}; #endif -/* Get sense key string or NULL if not available */ -const char * -scsi_sense_key_string(unsigned char key) { - return snstext[key & 0xf]; -} -EXPORT_SYMBOL(scsi_sense_key_string); - -const char * -scsi_sense_type_string(struct scsi_sense_hdr *sshdr) -{ - return scsi_sense_is_deferred(sshdr) ? "[deferred]" : "[current]"; -} - -const char * -scsi_sense_format_string(struct scsi_sense_hdr *sshdr) -{ - return sshdr->response_code >= 0x72 ? "[descriptor]" : ""; -} - /* * Get additional sense code string or NULL if not available. * This string may contain a "%x" and should be printed with ascq as arg. @@ -1375,105 +1325,22 @@ void scsi_print_sense_hdr(struct scsi_device *sdev, const char *name, struct scsi_sense_hdr *sshdr) { - sdev_printk(KERN_INFO, sdev, "[%s] Sense Key : %s %s%s\n", name, - scsi_sense_key_string(sshdr->sense_key), - scsi_sense_type_string(sshdr), - scsi_sense_format_string(sshdr)); + trace_scsi_print_sense(sdev, name, sshdr, NULL, 0, 0); scsi_show_extd_sense(sdev, name, sshdr->asc, sshdr->ascq); } EXPORT_SYMBOL(scsi_print_sense_hdr); -static void -scsi_dump_sense_buffer(struct scsi_device *sdev, const char *prefix, - const unsigned char *sense_buffer, int sense_len) -{ - char linebuf[128]; - int i, linelen, remaining; - - if (sense_len < 32) - sense_len = 32; - - remaining = sense_len; - for (i = 0; i < sense_le
Re: [RFC PATCH 07/10] scsi/trace: Use scsi_show_result trace point instead of printk
On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote: Current SCSI trace has hostbyte table and driverbyte table, so we don't need to have the same table in scsi/constants.c. - Result examples (printk) sd 2:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE (ftrace) scsi_show_result: host_no=2 channel=0 id=0 lun=0 [sda] result=(driver=DRIVER_SENSE host=DID_OK) Signed-off-by: Yoshihiro YUNOMAE Cc: Hannes Reinecke Cc: Doug Gilbert Cc: Martin K. Petersen Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: Hidehiro Kawai Cc: Masami Hiramatsu --- drivers/scsi/constants.c| 52 --- drivers/scsi/scsi_trace.c | 16 + include/trace/events/scsi.h | 38 +++ 3 files changed, 53 insertions(+), 53 deletions(-) diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c index 6fad6b4..f7b7f32 100644 --- a/drivers/scsi/constants.c +++ b/drivers/scsi/constants.c @@ -1488,55 +1488,3 @@ void scsi_print_sense(struct scsi_cmnd *cmd) SCSI_SENSE_BUFFERSIZE); } EXPORT_SYMBOL(scsi_print_sense); - -#ifdef CONFIG_SCSI_CONSTANTS - -static const char * const hostbyte_table[]={ -"DID_OK", "DID_NO_CONNECT", "DID_BUS_BUSY", "DID_TIME_OUT", "DID_BAD_TARGET", -"DID_ABORT", "DID_PARITY", "DID_ERROR", "DID_RESET", "DID_BAD_INTR", -"DID_PASSTHROUGH", "DID_SOFT_ERROR", "DID_IMM_RETRY", "DID_REQUEUE", -"DID_TRANSPORT_DISRUPTED", "DID_TRANSPORT_FAILFAST", "DID_TARGET_FAILURE", -"DID_NEXUS_FAILURE" }; -#define NUM_HOSTBYTE_STRS ARRAY_SIZE(hostbyte_table) - -static const char * const driverbyte_table[]={ -"DRIVER_OK", "DRIVER_BUSY", "DRIVER_SOFT", "DRIVER_MEDIA", "DRIVER_ERROR", -"DRIVER_INVALID", "DRIVER_TIMEOUT", "DRIVER_HARD", "DRIVER_SENSE"}; -#define NUM_DRIVERBYTE_STRS ARRAY_SIZE(driverbyte_table) - -void scsi_show_result(struct scsi_device *sdev, const char *name, int result) -{ - int hb = host_byte(result); - int db = driver_byte(result); - const char *hb_string; - const char *db_string; - - hb_string = (hb < NUM_HOSTBYTE_STRS) ? hostbyte_table[hb] : "invalid"; - db_string = (db < NUM_DRIVERBYTE_STRS) ? - driverbyte_table[db] : "invalid"; - - - sdev_printk(KERN_INFO, sdev, - "[%s] Result: hostbyte=%s driverbyte=%s\n", - name, hb_string, db_string); -} - -#else - -void scsi_show_result(struct scsi_device *sdev, const char *name, int result) -{ - sdev_printk(KERN_INFO, sdev, - "[%s] Result: hostbyte=0x%02x driverbyte=0x%02x\n", - name, host_byte(result), driver_byte(result)); -} - -#endif -EXPORT_SYMBOL(scsi_show_result); - -void scsi_print_result(struct scsi_cmnd *cmd) -{ - const char *devname = cmd->request->rq_disk ? - cmd->request->rq_disk->disk_name : "scsi"; - scsi_show_result(cmd->device, devname, cmd->result); -} -EXPORT_SYMBOL(scsi_print_result); diff --git a/drivers/scsi/scsi_trace.c b/drivers/scsi/scsi_trace.c index 2bea4f0..6ffbc40 100644 --- a/drivers/scsi/scsi_trace.c +++ b/drivers/scsi/scsi_trace.c @@ -19,6 +19,8 @@ #include #include +#include + #define SERVICE_ACTION16(cdb) (cdb[1] & 0x1f) #define SERVICE_ACTION32(cdb) ((cdb[8] << 8) | cdb[9]) @@ -286,3 +288,17 @@ scsi_trace_parse_cdb(struct trace_seq *p, unsigned char *cdb, int len) return scsi_trace_misc(p, cdb, len); } } + +void scsi_show_result(struct scsi_device *sdev, const char *name, int result) +{ + trace_scsi_show_result(sdev, name, result); +} +EXPORT_SYMBOL(scsi_show_result); + +void scsi_print_result(struct scsi_cmnd *cmd) +{ + const char *devname = cmd->request->rq_disk ? + cmd->request->rq_disk->disk_name : "scsi"; + scsi_show_result(cmd->device, devname, cmd->result); +} +EXPORT_SYMBOL(scsi_print_result); diff --git a/include/trace/events/scsi.h b/include/trace/events/scsi.h index 8aecdc2..0675195 100644 --- a/include/trace/events/scsi.h +++ b/include/trace/events/scsi.h @@ -123,7 +123,11 @@ scsi_hostbyte_name(DID_IMM_RETRY), \ scsi_hostbyte_name(DID_REQUEUE),\ scsi_hostbyte_name(DID_TRANSPORT_DISRUPTED),\ - scsi_hostbyte_name(DID_TRANSPORT_FAILFAST)) + scsi_hostbyte_name(DID_TRANSPORT_FAILFAST), \ + scsi_hostbyte_name(DID_TARGET_FAILURE), \ + scsi_hostbyte_name(DID_NEXUS_FAILURE), \ + scsi_hostbyte_name(DID_ALLOC_FAILURE), \ + scsi_hostbyte_name(DID_MEDIUM_ERROR)) #define scsi_driverbyte_name(result) { result, #result } #define show_driverbyte_name(val) \ @@ -359,6 +363,38 @@ TRACE_EVENT(scsi_eh_wakeup, TP_printk("host_no=%u", __entry->host_no) ); +TRACE_EVENT(scsi_show_result, + + TP_PROTO(struct scsi_device *sdev, const char *devname,
Re: [RFC PATCH 06/10] scsi/sd: Delete extra scsi_show_extd_sense() in sd_print_sense_hdr()
On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote: sd_print_sense_hdr() calls scsi_show_extd_sense(), but scsi_print_sense_hdr() also calls scsi_show_extd_sense(). We can get same result, so we delete it. Note: Calling scsi_show_extd_sense() is introduced in fdd8b297. Signed-off-by: Yoshihiro YUNOMAE Cc: Hannes Reinecke Cc: Doug Gilbert Cc: Martin K. Petersen Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: Hidehiro Kawai Cc: Masami Hiramatsu --- drivers/scsi/sd.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 8d7204a..22dd214 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -3286,8 +3286,6 @@ static void sd_print_sense_hdr(struct scsi_disk *sdkp, struct scsi_sense_hdr *sshdr) { scsi_print_sense_hdr(sdkp->device, sdkp->disk->disk_name, sshdr); - scsi_show_extd_sense(sdkp->device, sdkp->disk->disk_name, -sshdr->asc, sshdr->ascq); } static void sd_print_result(struct scsi_disk *sdkp, int result) -- 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 A similar patch has been applied to my scsi-logging tree. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Buffer I/O error after s2ram with usb storage
On 14-08-27 04:40 AM, Matthieu CASTET wrote: Ping I have got also a problem with a usb sdcard reader (without power cut during suspend) [ 1073.606668] PM: Entering mem sleep [ 1073.606742] Suspending console(s) (use no_console_suspend to debug) [ 1073.607146] sd 1:0:0:0: [sda] Synchronizing SCSI cache [ 1073.639076] sd 1:0:0:0: [sda] Stopping disk [ 1074.186688] PM: suspend of devices complete after 580.127 msecs [...] [ 1075.265183] PM: resume of devices complete after 615.990 msecs [ 1075.265627] PM: Finishing wakeup. [ 1075.265630] Restarting tasks ... [...] [ 1203.404593] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 6, 29065 clusters in bitmap, 32768 in gd; block bitmap corrupt. [ 1203.404628] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 5, 1601 clusters in bitmap, 32321 in gd; block bitmap corrupt. [ 1203.404648] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 4, 0 clusters in bitmap, 32768 in gd; block bitmap corrupt. [ 1203.404667] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 3, 1601 clusters in bitmap, 32321 in gd; block bitmap corrupt. [ 1203.404686] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 2, 0 clusters in bitmap, 32768 in gd; block bitmap corrupt. [ 1203.404705] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 1, 1600 clusters in bitmap, 32321 in gd; block bitmap corrupt. [ 1203.404726] JBD2: Spotted dirty metadata buffer (dev = sdb6, blocknr = 0). There's a risk of filesystem corruption in case of system crash. [ 1204.141482] sd 8:0:0:0: [sdb] Media Changed [ 1204.141490] sd 8:0:0:0: [sdb] [ 1204.141494] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 1204.141497] sd 8:0:0:0: [sdb] [ 1204.141499] Sense Key : Unit Attention [current] [ 1204.141504] Info fld=0x0 [ 1204.141506] sd 8:0:0:0: [sdb] [ 1204.141510] Add. Sense: Not ready to ready change, medium may have changed The unit attention doesn't look like a problem, it looks correct. If the system is unable to detect removable media being changed while the system is suspended, then If the media has a unique identifier, then this unit attention at wakeup should trigger sd to make sure that unique identifier has not changed. Not sure why ext4 starts looking at sdb6 _before_ the sd driver processes that unit attention. Perhaps a TEST UNIT READY should be done earlier in the wake-up sequence to flush out (and process) unit attentions. There is also the case in which the removable media is no longer present; and that should change EXT4-fs processing to a surprise removal. Doug Gilbert [ 1204.141514] sd 8:0:0:0: [sdb] CDB: [ 1204.141516] Read(10): 28 00 00 0a 75 f8 00 00 08 00 [ 1204.141526] end_request: I/O error, dev sdb, sector 685560 Le Mon, 28 Apr 2014 15:01:39 +0200, Matthieu CASTET a écrit : Hi, any news on this. Matthieu CASTET Le Tue, 22 Apr 2014 16:01:15 +0200, Matthieu CASTET a écrit : Hi, while playing with suspend to ram I found a strange behavior with usb key. This can be easily reproduced by doing : - plug a usb key - start to read the usb key : "cat /dev/sdx > /dev/null" - go to suspend : "echo mem > /sys/power/state" - while in suspend, unplug and replug the usb key (simulate usb power loss for computer that keep power) - exit suspend - there is read error on the usb key Because the power was cut during s2ram, the usb stack reset the device <1>. When new data transfer are done, we got a UNIT_ATTENTION from the device <2> and IO error are returned to user space application. After some investigation it seems some (all on the 3 I tested) usb key report as removable, and scsi layer abort the transfer in case of UNIT_ATTENTION <3>. The usb storage driver call scsi_report_bus_reset after device reset, but because of commit dfcf7775 <4>, we don't ignore unit attention if "sshdr.asc == 0x28 && sshdr.ascq == 0x00" ("Not-ready to ready"). If dfcf7775 is reverted there is no more Buffer I/O error. Is that possible to find a way to restore the behavior before dfcf7775 commit (no Buffer I/O error after device reset) after a suspend to ram ? Matthieu CASTET PS : the same error happen if sg_reset -b /dev/sdx is used on the device. <1> [ 117.070255] usb 2-1.4: reset high-speed USB device number 3 using ehci-pci [...] [ 117.543922] Restarting tasks ... done. [ 117.548390] video LNXVIDEO:01: Restoring backlight state <2> [ 117.549179] sd 6:0:0:0: [sdb] Media Changed [ 117.549184] sd 6:0:0:0: [sdb] [ 117.549187] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 117.549189] sd 6:0:0:0: [sdb] [ 117.549191] Sense Key : Unit Attention [current] [ 117.549195] Info fld=0x0 [ 117.549197] sd 6:0:0:0: [sdb] [ 117.549201] Add. Sense: Not ready to ready change, medium may have changed [ 117.549203] sd 6:0:0:0: [sdb] CDB: [ 117.549205] Read(10): 28 00 00 02 c9 00 00 00 f0 00 [ 117.549212] end_request: I/O error, dev sdb, sector 182528 [ 117.549218] Buffer I/O error on device sdb1, logical block 22
Re: [RFC PATCH 05/10] scsi/trace: Use macros for getting driver byte, host byte, msg byte, and status byte
On 08/08/2014 01:50 PM, 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. Signed-off-by: Yoshihiro YUNOMAE Cc: Hannes Reinecke Cc: Doug Gilbert Cc: Martin K. Petersen Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: Hidehiro Kawai Cc: Masami Hiramatsu --- include/trace/events/scsi.h |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/trace/events/scsi.h b/include/trace/events/scsi.h index db6c935..8aecdc2 100644 --- a/include/trace/events/scsi.h +++ b/include/trace/events/scsi.h @@ -328,10 +328,10 @@ DECLARE_EVENT_CLASS(scsi_cmd_done_timeout_template, show_opcode_name(__entry->opcode), __parse_cdb(__get_dynamic_array(cmnd), __entry->cmd_len), __print_hex(__get_dynamic_array(cmnd), __entry->cmd_len), - show_driverbyte_name(((__entry->result) >> 24) & 0xff), - show_hostbyte_name(((__entry->result) >> 16) & 0xff), - show_msgbyte_name(((__entry->result) >> 8) & 0xff), - show_statusbyte_name(__entry->result & 0xff)) + show_driverbyte_name(driver_byte(__entry->result)), + show_hostbyte_name(host_byte(__entry->result)), + show_msgbyte_name(msg_byte(__entry->result)), + show_statusbyte_name(status_byte(__entry->result))) ); DEFINE_EVENT(scsi_cmd_done_timeout_template, scsi_dispatch_cmd_done, -- 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 Applied to my scsi logging tree. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 16/17] arcmsr: support new adapter ARC12x4 series
On 08/19/2014 09:25 AM, Ching Huang wrote: > From: Ching Huang > > Add code for supporting Areca new Raid adapter ARC12x4 series. > > Signed-off-by: Ching Huang > --- Hi Ching, please look at the comments below - > } > @@ -1039,7 +1147,60 @@ static void arcmsr_done4abort_postqueue( > error = (flag_ccb & ARCMSR_CCBREPLY_FLAG_ERROR_MODE1) ? > true : false; > arcmsr_drain_donequeue(acb, pCCB, error); > } > - } > + } > + break; > + case ACB_ADAPTER_TYPE_D: { > + struct MessageUnit_D *pmu = acb->pmuD; > + uint32_t ccb_cdb_phy, outbound_write_pointer; > + uint32_t doneq_index, index_stripped, addressLow, residual; > + bool error; > + struct CommandControlBlock *pCCB; I have noticed this^ in this driver already before. Sometimes it makes sense when a variable is declared in a 'case' block but often it is just a waste of space. In this function this is the third 'bool error' declared. Is there a reason for this style (this function is not the worst case) ? > + outbound_write_pointer = pmu->done_qbuffer[0].addressLow + 1; > + doneq_index = pmu->doneq_index; > + residual = atomic_read(&acb->ccboutstandingcount); > + for (i = 0; i < residual; i++) { > + while ((doneq_index & 0xFFF) != > + (outbound_write_pointer & 0xFFF)) { > + if (doneq_index & 0x4000) { > + index_stripped = doneq_index & 0xFFF; > + index_stripped += 1; > + index_stripped %= > + ARCMSR_MAX_ARC1214_DONEQUEUE; > + pmu->doneq_index = index_stripped ? > + (index_stripped | 0x4000) : > + (index_stripped + 1); > + } else { > + index_stripped = doneq_index; > + index_stripped += 1; > + index_stripped %= > + ARCMSR_MAX_ARC1214_DONEQUEUE; > + pmu->doneq_index = index_stripped ? > + index_stripped : > + ((index_stripped | 0x4000) + 1); > + } > + doneq_index = pmu->doneq_index; > + addressLow = pmu->done_qbuffer[doneq_index & > + 0xFFF].addressLow; > + ccb_cdb_phy = (addressLow & 0xFFF0); > + pARCMSR_CDB = (struct ARCMSR_CDB *) > + (acb->vir2phy_offset + ccb_cdb_phy); > + pCCB = container_of(pARCMSR_CDB, > + struct CommandControlBlock, arcmsr_cdb); > + error = (addressLow & > + ARCMSR_CCBREPLY_FLAG_ERROR_MODE1) ? > + true : false; > + arcmsr_drain_donequeue(acb, pCCB, error); > + writel(doneq_index, > pmu->outboundlist_read_pointer); > + } > + mdelay(10); > + outbound_write_pointer = > + pmu->done_qbuffer[0].addressLow + 1; > + doneq_index = pmu->doneq_index; > + } > + pmu->postq_index = 0; > + pmu->doneq_index = 0x40FF; > + } > + break; > } > } ... > > > @@ -1256,6 +1424,38 @@ static void arcmsr_post_ccb(struct Adapt > writel(ccb_post_stamp, &phbcmu->inbound_queueport_low); > } > } > + break; > + case ACB_ADAPTER_TYPE_D: { > + struct MessageUnit_D *pmu = acb->pmuD; > + u16 index_stripped; > + u16 postq_index; > + unsigned long flags; > + struct InBound_SRB *pinbound_srb; > + > + spin_lock_irqsave(&acb->postq_lock, flags); > + postq_index = pmu->postq_index; > + pinbound_srb = (struct InBound_SRB > *)&(pmu->post_qbuffer[postq_index & 0xFF]); > + pinbound_srb->addressHigh = dma_addr_hi32(cdb_phyaddr); > + pinbound_srb->addressLow = dma_addr_lo32(cdb_phyaddr); > + pinbound_srb->length = ccb->arc_cdb_size >> 2; > + arcmsr_cdb->msgContext = dma_addr_lo32(cdb_phyaddr); > + if (postq_index & 0x4000) { > + index_stripped = postq_index & 0xFF; > + index_strip
Re: [RFC PATCH 04/10] scsi/constants: Cleanup printk message in scsi_dump_sense_buffer()
On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote: Unrecognized sense data should be output after linebuf is filled because "[%s] Unrecognized sense data (in hex): %s" message is output many times in loop. Signed-off-by: Yoshihiro YUNOMAE Cc: Hannes Reinecke Cc: Doug Gilbert Cc: Martin K. Petersen Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: Hidehiro Kawai Cc: Masami Hiramatsu --- drivers/scsi/constants.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c index 5956d4d..6fad6b4 100644 --- a/drivers/scsi/constants.c +++ b/drivers/scsi/constants.c @@ -1385,16 +1385,13 @@ EXPORT_SYMBOL(scsi_print_sense_hdr); static void scsi_dump_sense_buffer(struct scsi_device *sdev, const char *prefix, - const unsigned char *sense_buffer, int sense_len, - struct scsi_sense_hdr *sshdr) + const unsigned char *sense_buffer, int sense_len) { char linebuf[128]; int i, linelen, remaining; if (sense_len < 32) sense_len = 32; - sdev_printk(KERN_INFO, sdev, - "[%s] Unrecognized sense data (in hex):", prefix); remaining = sense_len; for (i = 0; i < sense_len; i += 16) { @@ -1403,9 +1400,10 @@ scsi_dump_sense_buffer(struct scsi_device *sdev, const char *prefix, hex_dump_to_buffer(sense_buffer + i, linelen, 16, 1, linebuf, sizeof(linebuf), false); - sdev_printk(KERN_INFO, sdev, "[%s] Sense: %s\n", - prefix, linebuf); } + sdev_printk(KERN_INFO, sdev, + "[%s] Unrecognized sense data (in hex): %s", + prefix, linebuf); } static void @@ -1467,8 +1465,7 @@ void __scsi_print_sense(struct scsi_device *sdev, const char *name, if (!scsi_normalize_sense(sense_buffer, sense_len, &sshdr)) { /* this may be SCSI-1 sense data */ - scsi_dump_sense_buffer(sdev, name, sense_buffer, - sense_len, &sshdr); + scsi_dump_sense_buffer(sdev, name, sense_buffer, sense_len); return; } -- 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 As discussed this patch is invalid. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/10] scsi/constants: Cleanup printk message in __scsi_print_command()
On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote: All bytes in CDB should be output after linebuf is filled because "[%s] CDB: %s\n" message is output many times in loop. Signed-off-by: Yoshihiro YUNOMAE Cc: Hannes Reinecke Cc: Doug Gilbert Cc: Martin K. Petersen Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: Hidehiro Kawai Cc: Masami Hiramatsu --- drivers/scsi/constants.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c index 9c38b8d..5956d4d 100644 --- a/drivers/scsi/constants.c +++ b/drivers/scsi/constants.c @@ -413,9 +413,8 @@ void __scsi_print_command(struct scsi_device *sdev, const char *prefix, hex_dump_to_buffer(cdb + i, linelen, 16, 1, linebuf, sizeof(linebuf), false); - sdev_printk(KERN_INFO, sdev, "[%s] CDB: %s\n", - prefix, linebuf); } + sdev_printk(KERN_INFO, sdev, "[%s] CDB: %s\n", prefix, linebuf); } EXPORT_SYMBOL(__scsi_print_command); -- 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 As discussed this patch is invalid. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 02/10] scsi/constants: Cleanup printk message in scsi_decode_sense_extras()
On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote: If sense_flags and fixed_valid are zero, the kernel does not need to output a printk message. So, if those conditions are met, it just returns. Signed-off-by: Yoshihiro YUNOMAE Cc: Hannes Reinecke Cc: Doug Gilbert Cc: Martin K. Petersen Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: Hidehiro Kawai Cc: Masami Hiramatsu --- drivers/scsi/constants.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c index a0e8159..9c38b8d 100644 --- a/drivers/scsi/constants.c +++ b/drivers/scsi/constants.c @@ -1438,6 +1438,9 @@ scsi_decode_sense_extras(struct scsi_device *sdev, const char *name, sense_flags |= ucp[3] & 0xe0; } + if (!sense_flags && !fixed_valid) + return; + res = 0; memset(buff, 0, sizeof(buff)); blen = sizeof(buff) - 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 scsi_decode_sense_extras() is utterly weird, as it only decodes tape-specific sense extras. Seeing that 'st' and 'osst' already contains code to handle those cases we should remove this function altogether, as it doesn't serve any purpose. Has been removed with my next scsi logging update, so this patch is not applicable anymore. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 01/10] scsi/constants: Cleanup printk message in __scsi_print_sense()
On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote: A device name is output like "sda: Sense Key : Medium Error [current]" in __scsi_print_sense(), but it should be "[sda] Sense Key : Medium Error [current]" because other printk messages output a device name like "[sda] foo." Signed-off-by: Yoshihiro YUNOMAE Cc: Hannes Reinecke Cc: Doug Gilbert Cc: Martin K. Petersen Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: Hidehiro Kawai Cc: Masami Hiramatsu --- drivers/scsi/constants.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c index c6a7a4a..a0e8159 100644 --- a/drivers/scsi/constants.c +++ b/drivers/scsi/constants.c @@ -1470,7 +1470,7 @@ void __scsi_print_sense(struct scsi_device *sdev, const char *name, return; } - sdev_printk(KERN_INFO, sdev, "%s: Sense Key : %s %s%s\n", name, + sdev_printk(KERN_INFO, sdev, "[%s] Sense Key : %s %s%s\n", name, scsi_sense_key_string(sshdr.sense_key), scsi_sense_type_string(&sshdr), scsi_sense_format_string(&sshdr)); -- 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 A similar fix is already present in my next version of the scsi logging patchset. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] be2iscsi: Bump the driver version
On 08/08/2014 07:00 AM, Jay Kallickal wrote: From: Jayamohan Kallickal Bump the driver version Signed-off-by: John Soni Jose Signed-off-by: Jayamohan Kallickal --- drivers/scsi/be2iscsi/be_main.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/be2iscsi/be_main.h b/drivers/scsi/be2iscsi/be_main.h index 5f8b0fc..3605631 100644 --- a/drivers/scsi/be2iscsi/be_main.h +++ b/drivers/scsi/be2iscsi/be_main.h @@ -36,7 +36,7 @@ #include #define DRV_NAME "be2iscsi" -#define BUILD_STR "10.2.273.0" +#define BUILD_STR "10.4.74.0" #define BE_NAME "Emulex OneConnect" \ "Open-iSCSI Driver version" BUILD_STR #define DRV_DESC BE_NAME " " "Driver" Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] be2iscsi: Fix processing CQE before connection resources are freed
On 08/08/2014 07:00 AM, Jay Kallickal wrote: From: Jayamohan Kallickal Driver should process the completion queue entries before a connection resources are freed. While running mixed traffic due to latency, driver processes the CQE after the connection resources are freed. This fix processes all the completion queue before the connection resources are freed. Signed-off-by: John Soni Jose Signed-off-by: Jayamohan Kallickal --- drivers/scsi/be2iscsi/be_iscsi.c | 29 + drivers/scsi/be2iscsi/be_main.c | 15 ++- drivers/scsi/be2iscsi/be_main.h | 3 +++ 3 files changed, 46 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/be2iscsi/be_iscsi.c b/drivers/scsi/be2iscsi/be_iscsi.c index e25203e..b7391a3 100644 --- a/drivers/scsi/be2iscsi/be_iscsi.c +++ b/drivers/scsi/be2iscsi/be_iscsi.c @@ -1274,6 +1274,31 @@ int beiscsi_ep_poll(struct iscsi_endpoint *ep, int timeout_ms) } /** + * beiscsi_flush_cq()- Flush the CQ created. + * @phba: ptr device priv structure. + * + * Before the connection resource are freed flush + * all the CQ enteries + **/ +static void beiscsi_flush_cq(struct beiscsi_hba *phba) +{ + uint16_t i; + struct be_eq_obj *pbe_eq; + struct hwi_controller *phwi_ctrlr; + struct hwi_context_memory *phwi_context; + + phwi_ctrlr = phba->phwi_ctrlr; + phwi_context = phwi_ctrlr->phwi_ctxt; + + for (i = 0; i < phba->num_cpus; i++) { + pbe_eq = &phwi_context->be_eq[i]; + blk_iopoll_disable(&pbe_eq->iopoll); + beiscsi_process_cq(pbe_eq); + blk_iopoll_enable(&pbe_eq->iopoll); + } +} + +/** * beiscsi_close_conn - Upload the connection * @ep: The iscsi endpoint * @flag: The type of connection closure @@ -1294,6 +1319,10 @@ static int beiscsi_close_conn(struct beiscsi_endpoint *beiscsi_ep, int flag) } ret = beiscsi_mccq_compl(phba, tag, NULL, NULL); + + /* Flush the CQ entries */ + beiscsi_flush_cq(phba); + return ret; } diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c index 8f9f625..cbc9fc2 100644 --- a/drivers/scsi/be2iscsi/be_main.c +++ b/drivers/scsi/be2iscsi/be_main.c @@ -2068,7 +2068,7 @@ static void beiscsi_process_mcc_isr(struct beiscsi_hba *phba) * return * Number of Completion Entries processed. **/ -static unsigned int beiscsi_process_cq(struct be_eq_obj *pbe_eq) +unsigned int beiscsi_process_cq(struct be_eq_obj *pbe_eq) { struct be_queue_info *cq; struct sol_cqe *sol; @@ -2110,6 +2110,18 @@ static unsigned int beiscsi_process_cq(struct be_eq_obj *pbe_eq) cri_index = BE_GET_CRI_FROM_CID(cid); ep = phba->ep_array[cri_index]; + + if (ep == NULL) { + /* connection has already been freed +* just move on to next one +*/ + beiscsi_log(phba, KERN_WARNING, + BEISCSI_LOG_INIT, + "BM_%d : proc cqe of disconn ep: cid %d\n", + cid); + goto proc_next_cqe; + } + beiscsi_ep = ep->dd_data; beiscsi_conn = beiscsi_ep->conn; @@ -2219,6 +2231,7 @@ static unsigned int beiscsi_process_cq(struct be_eq_obj *pbe_eq) break; } +proc_next_cqe: AMAP_SET_BITS(struct amap_sol_cqe, valid, sol, 0); queue_tail_inc(cq); sol = queue_tail_node(cq); diff --git a/drivers/scsi/be2iscsi/be_main.h b/drivers/scsi/be2iscsi/be_main.h index 1e3428a..5f8b0fc 100644 --- a/drivers/scsi/be2iscsi/be_main.h +++ b/drivers/scsi/be2iscsi/be_main.h @@ -840,6 +840,9 @@ void beiscsi_free_mgmt_task_handles(struct beiscsi_conn *beiscsi_conn, void hwi_ring_cq_db(struct beiscsi_hba *phba, unsigned int id, unsigned int num_processed, unsigned char rearm, unsigned char event); + +unsigned int beiscsi_process_cq(struct be_eq_obj *pbe_eq); + static inline bool beiscsi_error(struct beiscsi_hba *phba) { return phba->ue_detected || phba->fw_timeout; Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] be2iscsi: Fix updating the boot enteries in sysfs
On 08/08/2014 07:00 AM, Jay Kallickal wrote: From: Jayamohan Kallickal During port async event driver should check if there is any boot target configured on the adapter. Update sysfs enteries with the boot target parameters. Signed-off-by: Minh Tran Signed-off-by: John Soni Jose Signed-off-by: Jayamohan Kallickal --- drivers/scsi/be2iscsi/be_cmds.c | 38 -- drivers/scsi/be2iscsi/be_cmds.h | 8 drivers/scsi/be2iscsi/be_main.c | 17 + drivers/scsi/be2iscsi/be_main.h | 1 + 4 files changed, 62 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/be2iscsi/be_cmds.c b/drivers/scsi/be2iscsi/be_cmds.c index ea4477f..80d97f3 100644 --- a/drivers/scsi/be2iscsi/be_cmds.c +++ b/drivers/scsi/be2iscsi/be_cmds.c @@ -275,6 +275,19 @@ bool is_link_state_evt(u32 trailer) ASYNC_EVENT_CODE_LINK_STATE); } +static bool is_iscsi_evt(u32 trailer) +{ + return ((trailer >> ASYNC_TRAILER_EVENT_CODE_SHIFT) & + ASYNC_TRAILER_EVENT_CODE_MASK) == + ASYNC_EVENT_CODE_ISCSI; +} + +static int iscsi_evt_type(u32 trailer) +{ + return (trailer >> ASYNC_TRAILER_EVENT_TYPE_SHIFT) & +ASYNC_TRAILER_EVENT_TYPE_MASK; +} + static inline bool be_mcc_compl_is_new(struct be_mcc_compl *compl) { if (compl->flags != 0) { @@ -438,7 +451,7 @@ void beiscsi_async_link_state_process(struct beiscsi_hba *phba, } else if ((evt->port_link_status & ASYNC_EVENT_LINK_UP) || ((evt->port_link_status & ASYNC_EVENT_LOGICAL) && (evt->port_fault == BEISCSI_PHY_LINK_FAULT_NONE))) { - phba->state = BE_ADAPTER_LINK_UP; + phba->state = BE_ADAPTER_LINK_UP | BE_ADAPTER_CHECK_BOOT; beiscsi_log(phba, KERN_ERR, BEISCSI_LOG_CONFIG | BEISCSI_LOG_INIT, @@ -461,7 +474,28 @@ int beiscsi_process_mcc(struct beiscsi_hba *phba) /* Interpret compl as a async link evt */ beiscsi_async_link_state_process(phba, (struct be_async_event_link_state *) compl); - else + else if (is_iscsi_evt(compl->flags)) { + switch (iscsi_evt_type(compl->flags)) { + case ASYNC_EVENT_NEW_ISCSI_TGT_DISC: + case ASYNC_EVENT_NEW_ISCSI_CONN: + case ASYNC_EVENT_NEW_TCP_CONN: + phba->state |= BE_ADAPTER_CHECK_BOOT; + beiscsi_log(phba, KERN_ERR, + BEISCSI_LOG_CONFIG | + BEISCSI_LOG_MBOX, + "BC_%d : Async iscsi Event," + " flags handled = 0x%08x\n", + compl->flags); + break; + default: + beiscsi_log(phba, KERN_ERR, + BEISCSI_LOG_CONFIG | + BEISCSI_LOG_MBOX, + "BC_%d : Unsupported Async" + " Event, flags = 0x%08x\n", + compl->flags); + } + } else beiscsi_log(phba, KERN_ERR, BEISCSI_LOG_CONFIG | BEISCSI_LOG_MBOX, diff --git a/drivers/scsi/be2iscsi/be_cmds.h b/drivers/scsi/be2iscsi/be_cmds.h index ccda0b6..9889743 100644 --- a/drivers/scsi/be2iscsi/be_cmds.h +++ b/drivers/scsi/be2iscsi/be_cmds.h @@ -118,6 +118,14 @@ struct be_mcc_compl { #define ASYNC_TRAILER_EVENT_CODE_SHIFT8 /* bits 8 - 15 */ #define ASYNC_TRAILER_EVENT_CODE_MASK 0xFF #define ASYNC_EVENT_CODE_LINK_STATE 0x1 +#define ASYNC_EVENT_CODE_ISCSI 0x4 + +#define ASYNC_TRAILER_EVENT_TYPE_SHIFT 16 /* bits 16 - 23 */ +#define ASYNC_TRAILER_EVENT_TYPE_MASK 0xF +#define ASYNC_EVENT_NEW_ISCSI_TGT_DISC 0x4 +#define ASYNC_EVENT_NEW_ISCSI_CONN 0x5 +#define ASYNC_EVENT_NEW_TCP_CONN 0x7 + struct be_async_event_trailer { u32 code; }; diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c index d6465ed..8f9f625 100644 --- a/drivers/scsi/be2iscsi/be_main.c +++ b/drivers/scsi/be2iscsi/be_main.c @@ -4379,6 +4379,10 @@ static int beiscsi_setup_boot_info(struct beiscsi_hba *phba) { struct iscsi_boot_kobj *boot_kobj; + /* it has been created previously */ + if (phba->boot_kset) +
Re: [PATCH 2/5] be2iscsi: Fix the copyright year
On 08/08/2014 06:59 AM, Jay Kallickal wrote: From: Jayamohan Kallickal Change the copyright year to 2014 Signed-off-by: John Soni Jose Signed-off-by: Jayamohan Kallickal --- drivers/scsi/be2iscsi/be.h | 2 +- drivers/scsi/be2iscsi/be_cmds.c | 2 +- drivers/scsi/be2iscsi/be_cmds.h | 2 +- drivers/scsi/be2iscsi/be_iscsi.c | 2 +- drivers/scsi/be2iscsi/be_iscsi.h | 2 +- drivers/scsi/be2iscsi/be_main.c | 2 +- drivers/scsi/be2iscsi/be_main.h | 2 +- drivers/scsi/be2iscsi/be_mgmt.c | 2 +- drivers/scsi/be2iscsi/be_mgmt.h | 2 +- 9 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/scsi/be2iscsi/be.h b/drivers/scsi/be2iscsi/be.h index 860f527..81e83a6 100644 --- a/drivers/scsi/be2iscsi/be.h +++ b/drivers/scsi/be2iscsi/be.h @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or diff --git a/drivers/scsi/be2iscsi/be_cmds.c b/drivers/scsi/be2iscsi/be_cmds.c index 1432ed5..ea4477f 100644 --- a/drivers/scsi/be2iscsi/be_cmds.c +++ b/drivers/scsi/be2iscsi/be_cmds.c @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or diff --git a/drivers/scsi/be2iscsi/be_cmds.h b/drivers/scsi/be2iscsi/be_cmds.h index 4e8cb61..ccda0b6 100644 --- a/drivers/scsi/be2iscsi/be_cmds.h +++ b/drivers/scsi/be2iscsi/be_cmds.h @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or diff --git a/drivers/scsi/be2iscsi/be_iscsi.c b/drivers/scsi/be2iscsi/be_iscsi.c index 8616281..e25203e 100644 --- a/drivers/scsi/be2iscsi/be_iscsi.c +++ b/drivers/scsi/be2iscsi/be_iscsi.c @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or diff --git a/drivers/scsi/be2iscsi/be_iscsi.h b/drivers/scsi/be2iscsi/be_iscsi.h index 31ddc84..e0b3b2d 100644 --- a/drivers/scsi/be2iscsi/be_iscsi.h +++ b/drivers/scsi/be2iscsi/be_iscsi.h @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c index 56467df..d6465ed 100644 --- a/drivers/scsi/be2iscsi/be_main.c +++ b/drivers/scsi/be2iscsi/be_main.c @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or diff --git a/drivers/scsi/be2iscsi/be_main.h b/drivers/scsi/be2iscsi/be_main.h index 9ceab42..0ca9d2d 100644 --- a/drivers/scsi/be2iscsi/be_main.h +++ b/drivers/scsi/be2iscsi/be_main.h @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or diff --git a/drivers/scsi/be2iscsi/be_mgmt.c b/drivers/scsi/be2iscsi/be_mgmt.c index a3e5648..785deb3 100644 --- a/drivers/scsi/be2iscsi/be_mgmt.c +++ b/drivers/scsi/be2iscsi/be_mgmt.c @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or diff --git a/drivers/scsi/be2iscsi/be_mgmt.h b/drivers/scsi/be2iscsi/be_mgmt.h index 24a8fc5..bd81446 100644 --- a/drivers/scsi/be2iscsi/be_mgmt.h +++ b/drivers/scsi/be2iscsi/be_mgmt.h @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] be2iscsi: Fix the sparse warning introduced in previous submission
On 08/08/2014 06:59 AM, Jay Kallickal wrote: From: Jayamohan Kallickal commit 73af08e11c6638e2abd6b1fa13cdab58c2bbdbf8 Author: Jayamohan Kallickal Date: Mon May 5 21:41:26 2014 -0400 be2iscsi: Fix interrupt Coalescing mechanism. Signed-off-by: John Soni Jose Signed-off-by: Jayamohan Kallickal --- drivers/scsi/be2iscsi/be_cmds.h | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/scsi/be2iscsi/be_cmds.h b/drivers/scsi/be2iscsi/be_cmds.h index cc7405c..4e8cb61 100644 --- a/drivers/scsi/be2iscsi/be_cmds.h +++ b/drivers/scsi/be2iscsi/be_cmds.h @@ -26,9 +26,9 @@ * The commands are serviced by the ARM processor in the OneConnect's MPU. */ struct be_sge { - u32 pa_lo; - u32 pa_hi; - u32 len; + __le32 pa_lo; + __le32 pa_hi; + __le32 len; }; #define MCC_WRB_SGE_CNT_SHIFT 3 /* bits 3 - 7 of dword 0 */ @@ -624,11 +624,11 @@ static inline struct be_sge *nonembedded_sgl(struct be_mcc_wrb *wrb) / Modify EQ Delay ***/ struct be_cmd_req_modify_eq_delay { struct be_cmd_req_hdr hdr; - u32 num_eq; + __le32 num_eq; struct { - u32 eq_id; - u32 phase; - u32 delay_multiplier; + __le32 eq_id; + __le32 phase; + __le32 delay_multiplier; } delay[MAX_CPUS]; } __packed; Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND] bnx2fc: do not add shared skbs to the fcoe_rx_list
In some cases, the fcoe_rx_list may contains multiple instances of the same skb (the so called "shared skbs"). the bnx2fc_l2_rcv thread is a loop that extracts a skb from the list, modifies (and destroys) its content and the proceed to the next one. The problem is that if the skb is shared, the remaining instances will be corrupted. The solution is to use skb_share_check() before adding the skb to the fcoe_rx_list. [ 6286.808725] [ cut here ] [ 6286.808729] WARNING: at include/scsi/fc_frame.h:173 bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc]() [ 6286.808748] Modules linked in: bnx2x(-) mdio dm_service_time bnx2fc cnic uio fcoe libfcoe 8021q garp stp mrp libfc llc scsi_transport_fc scsi_tgt sg iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel e1000e ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper ptp cryptd hpilo serio_raw hpwdt lpc_ich pps_core ipmi_si pcspkr mfd_core ipmi_msghandler shpchp pcc_cpufreq mperf nfsd auth_rpcgss nfs_acl lockd sunrpc dm_multipath xfs libcrc32c ata_generic pata_acpi sd_mod crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit ata_piix drm_kms_helper ttm drm libata i2c_core hpsa dm_mirror dm_region_hash dm_log dm_mod [last unloaded: mdio] [ 6286.808750] CPU: 3 PID: 1304 Comm: bnx2fc_l2_threa Not tainted 3.10.0-121.el7.x86_64 #1 [ 6286.808750] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 [ 6286.808752] 0b36e715 8800deba1e00 815ec0ba [ 6286.808753] 8800deba1e38 8105dee1 a05618c0 8801e4c81888 [ 6286.808754] e8663868 8801f402b180 8801f56bc000 8800deba1e48 [ 6286.808754] Call Trace: [ 6286.808759] [] dump_stack+0x19/0x1b [ 6286.808762] [] warn_slowpath_common+0x61/0x80 [ 6286.808763] [] warn_slowpath_null+0x1a/0x20 [ 6286.808765] [] bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc] [ 6286.808767] [] ? bnx2fc_disable+0x90/0x90 [bnx2fc] [ 6286.808769] [] kthread+0xcf/0xe0 [ 6286.808770] [] ? kthread_create_on_node+0x140/0x140 [ 6286.808772] [] ret_from_fork+0x7c/0xb0 [ 6286.808773] [] ? kthread_create_on_node+0x140/0x140 [ 6286.808774] ---[ end trace c6cdb939184ccb4e ]--- Signed-off-by: Maurizio Lombardi --- drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c index 79e5c94..72533c5 100644 --- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c +++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c @@ -412,6 +412,7 @@ static int bnx2fc_rcv(struct sk_buff *skb, struct net_device *dev, struct fc_frame_header *fh; struct fcoe_rcv_info *fr; struct fcoe_percpu_s *bg; + struct sk_buff *tmp_skb; unsigned short oxid; interface = container_of(ptype, struct bnx2fc_interface, @@ -424,6 +425,12 @@ static int bnx2fc_rcv(struct sk_buff *skb, struct net_device *dev, goto err; } + tmp_skb = skb_share_check(skb, GFP_ATOMIC); + if (!tmp_skb) + goto err; + + skb = tmp_skb; + if (unlikely(eth_hdr(skb)->h_proto != htons(ETH_P_FCOE))) { printk(KERN_ERR PFX "bnx2fc_rcv: Wrong FC type frame\n"); goto err; -- Maurizio Lombardi -- 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 v3 13/17] arcmsr: fix ioctl data read/write error for adapter type C
On 08/27/2014 10:19 PM, Ching Huang wrote: > On Tue, 2014-08-26 at 15:20 +0200, Tomas Henzl wrote: >> On 08/26/2014 10:27 PM, Ching Huang wrote: >>> On Mon, 2014-08-25 at 12:29 +0200, Tomas Henzl wrote: On 08/25/2014 07:59 PM, Ching Huang wrote: > On Fri, 2014-08-22 at 18:00 +0200, Tomas Henzl wrote: >> On 08/19/2014 09:17 AM, Ching Huang wrote: >>> From: Ching Huang >>> >>> Rewrite ioctl entry and its relate function. >>> This patch fix ioctl data read/write error and change data I/O access >>> from byte to Dword. >>> >>> Signed-off-by: Ching Huang >>> --- >>> >>> diff -uprN a/drivers/scsi/arcmsr/arcmsr_attr.c >>> b/drivers/scsi/arcmsr/arcmsr_attr.c >>> --- a/drivers/scsi/arcmsr/arcmsr_attr.c 2014-02-06 17:47:24.0 >>> +0800 >>> +++ b/drivers/scsi/arcmsr/arcmsr_attr.c 2014-04-29 17:10:42.0 >>> +0800 >>> @@ -70,40 +70,75 @@ static ssize_t arcmsr_sysfs_iop_message_ >>> struct AdapterControlBlock *acb = (struct AdapterControlBlock >>> *) host->hostdata; >>> uint8_t *pQbuffer,*ptmpQbuffer; >>> int32_t allxfer_len = 0; >>> + unsigned long flags; >>> >>> if (!capable(CAP_SYS_ADMIN)) >>> return -EACCES; >>> >>> /* do message unit read. */ >>> ptmpQbuffer = (uint8_t *)buf; >>> - while ((acb->rqbuf_firstindex != acb->rqbuf_lastindex) >>> - && (allxfer_len < 1031)) { >>> + spin_lock_irqsave(&acb->rqbuffer_lock, flags); >>> + if (acb->rqbuf_firstindex != acb->rqbuf_lastindex) { >> Hi - does this condition (acb->rqbuf_firstindex == acb->rqbuf_lastindex) >> mean we could just release >> the spinlock and return ? >> > NO. We have to check the input buffer that may have message data come > from IOP. >>> pQbuffer = &acb->rqbuffer[acb->rqbuf_firstindex]; >>> - memcpy(ptmpQbuffer, pQbuffer, 1); >>> - acb->rqbuf_firstindex++; >>> - acb->rqbuf_firstindex %= ARCMSR_MAX_QBUFFER; >>> - ptmpQbuffer++; >>> - allxfer_len++; >>> + if (acb->rqbuf_firstindex > acb->rqbuf_lastindex) { >>> + if ((ARCMSR_MAX_QBUFFER - >>> acb->rqbuf_firstindex) >= 1032) { >>> + memcpy(ptmpQbuffer, pQbuffer, 1032); >>> + acb->rqbuf_firstindex += 1032; >>> + acb->rqbuf_firstindex %= >>> ARCMSR_MAX_QBUFFER; >>> + allxfer_len = 1032; >>> + } else { >>> + if (((ARCMSR_MAX_QBUFFER - >>> acb->rqbuf_firstindex) >>> + + acb->rqbuf_lastindex) > 1032) >>> { >>> + memcpy(ptmpQbuffer, pQbuffer, >>> + ARCMSR_MAX_QBUFFER >>> + - >>> acb->rqbuf_firstindex); >>> + ptmpQbuffer += >>> ARCMSR_MAX_QBUFFER >>> + - acb->rqbuf_firstindex; >>> + memcpy(ptmpQbuffer, >>> acb->rqbuffer, 1032 >>> + - (ARCMSR_MAX_QBUFFER - >>> + acb->rqbuf_firstindex)); >> This code looks like you were copying some data from a ring buffer, >> in that case - shouldn't be acb->rqbuf_lastindex used instead of >> firstindex? >> > Yes, there copying data from a ring buffer. firstindex and lastindex are > bad name. For readability, I rename the firstindex to getIndex, > lastindex to putIndex. My comment is not about names, but in this path '(ARCMSR_MAX_QBUFFER - acb->rqbuf_firstindex)+ acb->rqbuf_lastindex) > 1032)' you copy something twice and in both cases the 'firstindex' is used and never the 'lastindex'. Is this correct? >>> The firstindex is a get index and lastindex is a put index of a ring buffer. >>> At here, firstindex > lastindex, so the data remain in buffer are >>> (ARCMSR_MAX_QBUFFER - acb->rqbuf_firstindex)+ acb->rqbuf_lastindex >> Yes, it's correct, I misinterpreted the from value with the amount of bytes >> to copy. >> But well it's also still overcomplicated and I believe that a copy like this >> could be >> rearranged with just few lines of code as a result - have you looked at the >> code I sent? >> >> Let's go with this patch as it is otherwise we will never end, repost is not >> needed because >> of this and also not because of arcmsr_Read_iop_rqbuffer_in_DWORD. >> >> I'll continue with reviewing the remaining patches. >> >> tomas >> > I have test
Re: [PATCH v3 13/17] arcmsr: fix ioctl data read/write error for adapter type C
On Tue, 2014-08-26 at 15:20 +0200, Tomas Henzl wrote: > On 08/26/2014 10:27 PM, Ching Huang wrote: > > On Mon, 2014-08-25 at 12:29 +0200, Tomas Henzl wrote: > >> On 08/25/2014 07:59 PM, Ching Huang wrote: > >>> On Fri, 2014-08-22 at 18:00 +0200, Tomas Henzl wrote: > On 08/19/2014 09:17 AM, Ching Huang wrote: > > From: Ching Huang > > > > Rewrite ioctl entry and its relate function. > > This patch fix ioctl data read/write error and change data I/O access > > from byte to Dword. > > > > Signed-off-by: Ching Huang > > --- > > > > diff -uprN a/drivers/scsi/arcmsr/arcmsr_attr.c > > b/drivers/scsi/arcmsr/arcmsr_attr.c > > --- a/drivers/scsi/arcmsr/arcmsr_attr.c 2014-02-06 17:47:24.0 > > +0800 > > +++ b/drivers/scsi/arcmsr/arcmsr_attr.c 2014-04-29 17:10:42.0 > > +0800 > > @@ -70,40 +70,75 @@ static ssize_t arcmsr_sysfs_iop_message_ > > struct AdapterControlBlock *acb = (struct AdapterControlBlock > > *) host->hostdata; > > uint8_t *pQbuffer,*ptmpQbuffer; > > int32_t allxfer_len = 0; > > + unsigned long flags; > > > > if (!capable(CAP_SYS_ADMIN)) > > return -EACCES; > > > > /* do message unit read. */ > > ptmpQbuffer = (uint8_t *)buf; > > - while ((acb->rqbuf_firstindex != acb->rqbuf_lastindex) > > - && (allxfer_len < 1031)) { > > + spin_lock_irqsave(&acb->rqbuffer_lock, flags); > > + if (acb->rqbuf_firstindex != acb->rqbuf_lastindex) { > Hi - does this condition (acb->rqbuf_firstindex == acb->rqbuf_lastindex) > mean we could just release > the spinlock and return ? > > >>> NO. We have to check the input buffer that may have message data come > >>> from IOP. > > pQbuffer = &acb->rqbuffer[acb->rqbuf_firstindex]; > > - memcpy(ptmpQbuffer, pQbuffer, 1); > > - acb->rqbuf_firstindex++; > > - acb->rqbuf_firstindex %= ARCMSR_MAX_QBUFFER; > > - ptmpQbuffer++; > > - allxfer_len++; > > + if (acb->rqbuf_firstindex > acb->rqbuf_lastindex) { > > + if ((ARCMSR_MAX_QBUFFER - > > acb->rqbuf_firstindex) >= 1032) { > > + memcpy(ptmpQbuffer, pQbuffer, 1032); > > + acb->rqbuf_firstindex += 1032; > > + acb->rqbuf_firstindex %= > > ARCMSR_MAX_QBUFFER; > > + allxfer_len = 1032; > > + } else { > > + if (((ARCMSR_MAX_QBUFFER - > > acb->rqbuf_firstindex) > > + + acb->rqbuf_lastindex) > 1032) > > { > > + memcpy(ptmpQbuffer, pQbuffer, > > + ARCMSR_MAX_QBUFFER > > + - > > acb->rqbuf_firstindex); > > + ptmpQbuffer += > > ARCMSR_MAX_QBUFFER > > + - acb->rqbuf_firstindex; > > + memcpy(ptmpQbuffer, > > acb->rqbuffer, 1032 > > + - (ARCMSR_MAX_QBUFFER - > > + acb->rqbuf_firstindex)); > This code looks like you were copying some data from a ring buffer, > in that case - shouldn't be acb->rqbuf_lastindex used instead of > firstindex? > > >>> Yes, there copying data from a ring buffer. firstindex and lastindex are > >>> bad name. For readability, I rename the firstindex to getIndex, > >>> lastindex to putIndex. > >> My comment is not about names, but in this path '(ARCMSR_MAX_QBUFFER - > >> acb->rqbuf_firstindex)+ acb->rqbuf_lastindex) > 1032)' > >> you copy something twice and in both cases the 'firstindex' is used and > >> never the 'lastindex'. > >> Is this correct? > > The firstindex is a get index and lastindex is a put index of a ring buffer. > > At here, firstindex > lastindex, so the data remain in buffer are > > (ARCMSR_MAX_QBUFFER - acb->rqbuf_firstindex)+ acb->rqbuf_lastindex > > Yes, it's correct, I misinterpreted the from value with the amount of bytes > to copy. > But well it's also still overcomplicated and I believe that a copy like this > could be > rearranged with just few lines of code as a result - have you looked at the > code I sent? > > Let's go with this patch as it is otherwise we will never end, repost is not > needed because > of this and also not because of arcmsr_Read_iop_rqbuffer_in_DWORD. > > I'll continue with reviewing the remaining patches. > > tomas > I have test the code you sent. It works. I will modify the code by
Re: Buffer I/O error after s2ram with usb storage
Ping I have got also a problem with a usb sdcard reader (without power cut during suspend) [ 1073.606668] PM: Entering mem sleep [ 1073.606742] Suspending console(s) (use no_console_suspend to debug) [ 1073.607146] sd 1:0:0:0: [sda] Synchronizing SCSI cache [ 1073.639076] sd 1:0:0:0: [sda] Stopping disk [ 1074.186688] PM: suspend of devices complete after 580.127 msecs [...] [ 1075.265183] PM: resume of devices complete after 615.990 msecs [ 1075.265627] PM: Finishing wakeup. [ 1075.265630] Restarting tasks ... [...] [ 1203.404593] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 6, 29065 clusters in bitmap, 32768 in gd; block bitmap corrupt. [ 1203.404628] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 5, 1601 clusters in bitmap, 32321 in gd; block bitmap corrupt. [ 1203.404648] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 4, 0 clusters in bitmap, 32768 in gd; block bitmap corrupt. [ 1203.404667] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 3, 1601 clusters in bitmap, 32321 in gd; block bitmap corrupt. [ 1203.404686] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 2, 0 clusters in bitmap, 32768 in gd; block bitmap corrupt. [ 1203.404705] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 1, 1600 clusters in bitmap, 32321 in gd; block bitmap corrupt. [ 1203.404726] JBD2: Spotted dirty metadata buffer (dev = sdb6, blocknr = 0). There's a risk of filesystem corruption in case of system crash. [ 1204.141482] sd 8:0:0:0: [sdb] Media Changed [ 1204.141490] sd 8:0:0:0: [sdb] [ 1204.141494] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 1204.141497] sd 8:0:0:0: [sdb] [ 1204.141499] Sense Key : Unit Attention [current] [ 1204.141504] Info fld=0x0 [ 1204.141506] sd 8:0:0:0: [sdb] [ 1204.141510] Add. Sense: Not ready to ready change, medium may have changed [ 1204.141514] sd 8:0:0:0: [sdb] CDB: [ 1204.141516] Read(10): 28 00 00 0a 75 f8 00 00 08 00 [ 1204.141526] end_request: I/O error, dev sdb, sector 685560 Le Mon, 28 Apr 2014 15:01:39 +0200, Matthieu CASTET a écrit : > Hi, > > any news on this. > > Matthieu CASTET > > Le Tue, 22 Apr 2014 16:01:15 +0200, > Matthieu CASTET a écrit : > > > Hi, > > > > while playing with suspend to ram I found a strange behavior with usb > > key. > > > > This can be easily reproduced by doing : > > - plug a usb key > > - start to read the usb key : "cat /dev/sdx > /dev/null" > > - go to suspend : "echo mem > /sys/power/state" > > - while in suspend, unplug and replug the usb key (simulate usb power > > loss for computer that keep power) > > - exit suspend > > - there is read error on the usb key > > > > > > Because the power was cut during s2ram, the usb stack reset the device > > <1>. > > When new data transfer are done, we got a UNIT_ATTENTION from the > > device <2> and IO error are returned to user space application. > > > > After some investigation it seems some (all on the 3 I tested) usb key > > report as removable, and scsi layer abort the transfer in case of > > UNIT_ATTENTION <3>. > > > > The usb storage driver call scsi_report_bus_reset after device reset, > > but because of commit dfcf7775 <4>, we don't ignore unit attention if > > "sshdr.asc == 0x28 && sshdr.ascq == 0x00" ("Not-ready to ready"). > > > > If dfcf7775 is reverted there is no more Buffer I/O error. > > > > Is that possible to find a way to restore the behavior before dfcf7775 > > commit (no Buffer I/O error after device reset) after a suspend to ram ? > > > > > > Matthieu CASTET > > > > PS : the same error happen if sg_reset -b /dev/sdx is used on the > > device. > > > > > > <1> > > [ 117.070255] usb 2-1.4: reset high-speed USB device number 3 using > > ehci-pci [...] > > [ 117.543922] Restarting tasks ... done. > > [ 117.548390] video LNXVIDEO:01: Restoring backlight state > > <2> > > [ 117.549179] sd 6:0:0:0: [sdb] Media Changed > > [ 117.549184] sd 6:0:0:0: [sdb] > > [ 117.549187] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > > [ 117.549189] sd 6:0:0:0: [sdb] > > [ 117.549191] Sense Key : Unit Attention [current] > > [ 117.549195] Info fld=0x0 > > [ 117.549197] sd 6:0:0:0: [sdb] > > [ 117.549201] Add. Sense: Not ready to ready change, medium may have > > changed [ 117.549203] sd 6:0:0:0: [sdb] CDB: > > [ 117.549205] Read(10): 28 00 00 02 c9 00 00 00 f0 00 > > [ 117.549212] end_request: I/O error, dev sdb, sector 182528 > > [ 117.549218] Buffer I/O error on device sdb1, logical block 22560 > > [ 117.549225] Buffer I/O error on device sdb1, logical block 22561 > > [ 117.549228] Buffer I/O error on device sdb1, logical block 22562 > > [ 117.549231] Buffer I/O error on device sdb1, logical block 22563 > > [ 117.549233] Buffer I/O error on device sdb1, logical block 22564 > > [ 117.549235] Buffer I/O error on device sdb1, logical block 22565 > > [ 117.549238] Buffer I/O error on device sdb1, logical block 22566 > > [ 117.549240] Buffer I/O error on
Re: RES: RES: AS2105-based enclosure size issues with >2TB HDDs
On Tue, 2014-08-26 at 10:47 -0400, Alan Stern wrote: > On Mon, 25 Aug 2014, Oliver Neukum wrote: > > Just set US_FL_NEEDS_CAP16. If READ CAPACITY(16) fails in that case, > > it is clear that something is wrong. It must be set or READ CAPACITY(10) > > alone would be taken as giving a valid answer. > > You have committed a mental layering violation. :-) Indeed. > US_FL_NEEDS_CAP16 is a usb-storage flag. But the capacity > determination is made by the sd driver, which relies on the SCSI > try_rc_10_first flag. If that flag isn't set, sd tries READ > CAPACITY(16) and then falls back to READ CAPACITY(10) if an error > occurs. That's what happened here. > > I don't think we want to add another SCSI flag to say that READ > CAPACITY(10) is unreliable. Why not? It would only be friendly to tell the upper layer of a malfunction if we know about it. > > At that time we are sure that the drive will be unusable unless we > > determine the correct capacity, so we don't make matters worse if we > > crash it. > > Given the difficulty of determining the true capacity, I see two > alternatives. We could set the capacity to a ridiculously large value > (like 1 billion TB), or we could leave the capacity set to the low > value and disable the "block within bounds" checks. Neither of these > is attractive and they both have issues of their own -- although the > second is close to what Windows does. That seems to be the most attractive solution to me. > (For example, udev often tries to read the last sectors of a new drive, > looking for a GPT or RAID signature. That won't work if the capacity > is set to some random value.) Yes, but clipping has its own dangers. Suppose you use the medium without a partition table. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html