Re: [PATCH] unexport sg v3 helper functions
On Mon, Jul 23 2007, Douglas Gilbert wrote: Jens Axboe wrote: On Sun, Jul 22 2007, FUJITA Tomonori wrote: blk_fill_sghdr_rq, blk_unmap_sghdr_rq, and blk_complete_sghdr_rq were exported for bsg, however bsg was changed to support only sg v4. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] Acked-by: Jens Axboe [EMAIL PROTECTED] Why? The reasoning is right there, a few lines up - bsg doesn't support sg v3 commands. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unexpected scsi timeout
[cc'ing Albert] Vasily Averin wrote: Tejun, Jeff I've noticed that some scsi commands for DVD-drive attached to pata_via successfully finishes without any delays but reports about TIMEOUT condition. It happens because of ATA_ERR bit is set in status register. As result for each command Error Handler thread awakened, requests sense buffer and go to sleep again. Need more info. Please post boot dmesg and the result of 'lspci -nn' and 'hdparm -I /dev/srX' and when such errors occur. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
SCSI support broken in latest 2.4 kernel
Dear Kernel Maintainer, It seems impossible to compile the latest 2.4.35.6 kernel with the scsi_mod module and produce a usable system. I have used the attached config file and the normal compile procedure (make dep; make bzImage; make modules) and ended up with unloadable modules (unresolved symbols). I have tried both gcc 3.3 and 4.1. The same issue exists in at least 2.4.27 as well. Please advise if I can provide any further information which would aid in resolution. Thanks and best regards Abdelrahman Hassan Linux Administrator # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set CONFIG_M586TSC=y # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MELAN is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_X86_TSC is not set CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_USE_STRING_486=y CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_HAS_TSC=y CONFIG_X86_PPRO_FENCE=y # CONFIG_X86_F00F_WORKS_OK is not set CONFIG_X86_MCE=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # CONFIG_EDD is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_HIGHMEM is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_SMP is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # CONFIG_X86_TSC_DISABLE is not set CONFIG_X86_TSC=y # # General setup # CONFIG_NET=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_ISA=y CONFIG_PCI_NAMES=y CONFIG_EISA=y # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set # CONFIG_HOTPLUG_PCI_IBM is not set # CONFIG_HOTPLUG_PCI_SHPC is not set # CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE is not set # CONFIG_HOTPLUG_PCI_SHPC_PHPRM_LEGACY is not set # CONFIG_HOTPLUG_PCI_PCIE is not set # CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_OOM_KILLER is not set CONFIG_PM=y CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set # CONFIG_APM_CPU_IDLE is not set # CONFIG_APM_DISPLAY_BLANK is not set # CONFIG_APM_RTC_IS_GMT is not set # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # ACPI Support # # CONFIG_ACPI is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_PC_PCMCIA is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_IP22 is not set CONFIG_PARPORT_OTHER=y CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_CISS_SCSI_TAPE is not set # CONFIG_CISS_MONITOR_THREAD is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_SX8 is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y CONFIG_BLK_STATS=y # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_MD_MULTIPATH is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y # CONFIG_NETLINK_DEV is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG
[PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining
As Jens said, there is nothing common to scsi_sgtable and sglists. Save the fact that it is a massive conflict at scsi-ml. They touch all the same places. Proposed is a simple way out. Two patchsets That produce the same output at the end. One: scsi_sgtable_than_sg-chaining Two: sg-chaining_than_scsi_sgtable They are layed out like this common to both [PATCH AB1/5] SCSI: SG pools allocation cleanup scsi_sgtable_than_sg-chaining: [PATCH A2/5] SCSI: scsi_sgtable implementation [PATCH A3/5] SCSI: sg-chaining over scsi_sgtable sg-chaining_than_scsi_sgtable: [PATCH B2/5] SCSI: support for allocating large scatterlists [PATCH B3/5] SCSI: scsi_sgtable over sg-chainning Both patchsets are based on linux-2.6-block sglist-drivers (or sglist-arch) on top of a: git-revert 630cfe6f8a137a3d494aefda1e62bc4b9ba02f58. Revert of SCSI: support for allocating large scatterlists First patch will not apply on scsi-misc-2.6 because there is a missing NULL in the call to kmem_cache_create(). (linux-2.6.23-rcx) (If any one need a patchset for that please ask) What we need to do first is agree on the outcome of both sgtable and sglist chaining combined. The easiest way is to look at the 1st patchset AB1/5, A2/5, A3/5. It is the most incremental and easy to read. (Note: This patchset is part of a larger patchset as I sent in my last RFC scsi-ml: scsi_sgtable implementation. You can find a revised set here: www.bhalevy.com/open-osd/downloads/scsi_sgtable) If we all agree on the combined outcome, than we can proceed to decide which route to take. What I would like to ask of Jens is: please review the first 2 patches from the B patchset. AB1/5, B2/5. These together are almost exactly like your reverted patch above, but are a bit more friendly to the scsi_sgtable at the end. For James the first patch [AB1/5] is a good patch that solves real world problems today, like HIGHME64G=y. And maximizes allocations for all kind of ARCHs. Maybe it could be applied to the tree now for the next merge window, regardless of what is done with the rest. I'm just starting to test large IO's ontop of iSCSI. So probably some bugs will be found. Thanks everybody Boaz - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH AB1/5] SCSI: SG pools allocation cleanup.
- The code Automatically calculates at compile time the
maximum size sg-array that will fit in a memory-page and will allocate
pools of BASE_2 size, up to that maximum size.
- split scsi_alloc() into an helper scsi_sgtable_index() that will return
the index of the pool for a given sg_count.
- Remove now unused SCSI_MAX_PHYS_SEGMENTS
- rename sglist_len to sg_pool which is what it always was.
- Some extra prints at scsi_init_queue(). These prints will be removed
once everything stabilizes.
Now that the Arrays are automatically calculated to fit in a page, what
about ARCH's that have a very big page size? I have, just for demonstration,
calculated upto 512 entries. But I suspect that other kernel-subsystems are
bounded to 256 or 128, is that true? should I allow more/less than 512 here?
some common numbers:
Arch | SCSI_MAX_SG_SEGMENTS = | sizeof(struct scatterlist)
--|-|---
x86_64| 128 |32
i386 CONFIG_HIGHMEM64G=y | 205 |20
i386 other| 256 |16
Could some one give example numbers of an ARCH with big page size?
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/scsi/scsi_lib.c | 142 +-
include/scsi/scsi.h |7 --
include/scsi/scsi_cmnd.h | 19 +-
3 files changed, 79 insertions(+), 89 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 5edadfe..71532f9 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -30,40 +30,31 @@
#include scsi_priv.h
#include scsi_logging.h
-
-#define SG_MEMPOOL_NR ARRAY_SIZE(scsi_sg_pools)
#define SG_MEMPOOL_SIZE2
+/*
+ * Should fit within a single page.
+ */
+enum { SCSI_MAX_SG_SEGMENTS = (PAGE_SIZE / sizeof(struct scatterlist)) };
+
+enum { SG_MEMPOOL_NR =
+ (SCSI_MAX_SG_SEGMENTS = 8) +
+ (SCSI_MAX_SG_SEGMENTS = 16) +
+ (SCSI_MAX_SG_SEGMENTS = 32) +
+ (SCSI_MAX_SG_SEGMENTS = 64) +
+ (SCSI_MAX_SG_SEGMENTS = 128) +
+ (SCSI_MAX_SG_SEGMENTS = 256) +
+ (SCSI_MAX_SG_SEGMENTS = 512)
+};
+
struct scsi_host_sg_pool {
- size_t size;
- char*name;
+ unsignedsize;
struct kmem_cache *slab;
mempool_t *pool;
};
+static struct scsi_host_sg_pool scsi_sg_pools[SG_MEMPOOL_NR];
+
-#if (SCSI_MAX_PHYS_SEGMENTS 32)
-#error SCSI_MAX_PHYS_SEGMENTS is too small
-#endif
-
-#define SP(x) { x, sgpool- #x }
-static struct scsi_host_sg_pool scsi_sg_pools[] = {
- SP(8),
- SP(16),
- SP(32),
-#if (SCSI_MAX_PHYS_SEGMENTS 32)
- SP(64),
-#if (SCSI_MAX_PHYS_SEGMENTS 64)
- SP(128),
-#if (SCSI_MAX_PHYS_SEGMENTS 128)
- SP(256),
-#if (SCSI_MAX_PHYS_SEGMENTS 256)
-#error SCSI_MAX_PHYS_SEGMENTS is too large
-#endif
-#endif
-#endif
-#endif
-};
-#undef SP
static void scsi_run_queue(struct request_queue *q);
@@ -703,44 +694,32 @@ static struct scsi_cmnd *scsi_end_request(struct
scsi_cmnd *cmd, int uptodate,
return NULL;
}
+static unsigned scsi_sgtable_index(unsigned nents)
+{
+ int i, size;
+
+ for (i = 0, size = 8; i SG_MEMPOOL_NR-1; i++, size = 1)
+ if (size = nents)
+ return i;
+
+ if (SCSI_MAX_SG_SEGMENTS = nents)
+ return SG_MEMPOOL_NR-1;
+
+ printk(KERN_ERR scsi: bad segment count=%d\n, nents);
+ BUG();
+ return -1;
+}
+
struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd *cmd, gfp_t gfp_mask)
{
- struct scsi_host_sg_pool *sgp;
+ unsigned int pool = scsi_sgtable_index(cmd-use_sg);
struct scatterlist *sgl;
- BUG_ON(!cmd-use_sg);
-
- switch (cmd-use_sg) {
- case 1 ... 8:
- cmd-sglist_len = 0;
- break;
- case 9 ... 16:
- cmd-sglist_len = 1;
- break;
- case 17 ... 32:
- cmd-sglist_len = 2;
- break;
-#if (SCSI_MAX_PHYS_SEGMENTS 32)
- case 33 ... 64:
- cmd-sglist_len = 3;
- break;
-#if (SCSI_MAX_PHYS_SEGMENTS 64)
- case 65 ... 128:
- cmd-sglist_len = 4;
- break;
-#if (SCSI_MAX_PHYS_SEGMENTS 128)
- case 129 ... 256:
- cmd-sglist_len = 5;
- break;
-#endif
-#endif
-#endif
- default:
+ sgl = mempool_alloc(scsi_sg_pools[pool].pool, gfp_mask);
+ if (unlikely(!sgl))
return NULL;
- }
- sgp = scsi_sg_pools + cmd-sglist_len;
- sgl = mempool_alloc(sgp-pool, gfp_mask);
+ cmd-sg_pool = pool;
return sgl;
}
@@ -748,13 +727,7 @@ EXPORT_SYMBOL(scsi_alloc_sgtable);
void scsi_free_sgtable(struct scsi_cmnd *cmd)
{
- struct scatterlist *sgl = cmd-request_buffer;
- struct
[PATCH A2/5] SCSI: scsi_sgtable implementation
As proposed by James Bottomley all I/O members of struct scsi_cmnd
and the resid member, which need to be duplicated for bidirectional
transfers. Can be allocated together with the sg-list they are
pointing to. This way when bidi comes the structure can be duplicated
with minimal change to code, and with no extra baggage when bidi is not
used. The resulting code is the use of a new mechanism called scsi_sgtable.
scsi_cmnd.h
- define a new scsi_sgtable structure that will hold IO descriptors + the
actual scattergather array.
- Hold a pointer to the scsi_sgtable in scsi_cmnd.
- Deprecate old, now unnecessary, IO members of scsi_cmnd. These members are
kept for compatibility with unconverted drivers, still lurking around in
the code tree. They can be removed completely in the future.
- Modify data accessors to now use new members of scsi_sgtable.
scsi_lib.c
- scsi_lib is converted to use the new scsi_sgtable, in stead of the old
members and sg-arrays.
- scsi_{alloc,free}_sgtable() API has changed. This will break scsi_stgt
which will need to be converted to new implementation.
- Special code is inserted to initialize the old compatibility members from
the new structures. This code will be removed.
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/scsi/scsi_lib.c | 113 +++---
include/scsi/scsi_cmnd.h | 40 ++---
2 files changed, 80 insertions(+), 73 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 71532f9..262128c 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -38,13 +38,13 @@
enum { SCSI_MAX_SG_SEGMENTS = (PAGE_SIZE / sizeof(struct scatterlist)) };
enum { SG_MEMPOOL_NR =
- (SCSI_MAX_SG_SEGMENTS = 8) +
- (SCSI_MAX_SG_SEGMENTS = 16) +
- (SCSI_MAX_SG_SEGMENTS = 32) +
- (SCSI_MAX_SG_SEGMENTS = 64) +
- (SCSI_MAX_SG_SEGMENTS = 128) +
- (SCSI_MAX_SG_SEGMENTS = 256) +
- (SCSI_MAX_SG_SEGMENTS = 512)
+ (SCSI_MAX_SG_SEGMENTS 8) +
+ (SCSI_MAX_SG_SEGMENTS 16) +
+ (SCSI_MAX_SG_SEGMENTS 32) +
+ (SCSI_MAX_SG_SEGMENTS 64) +
+ (SCSI_MAX_SG_SEGMENTS 128) +
+ (SCSI_MAX_SG_SEGMENTS 256) +
+ (SCSI_MAX_SG_SEGMENTS 512)
};
struct scsi_host_sg_pool {
@@ -54,7 +54,10 @@ struct scsi_host_sg_pool {
};
static struct scsi_host_sg_pool scsi_sg_pools[SG_MEMPOOL_NR];
-
+static inline unsigned scsi_pool_size(int pool)
+{
+ return scsi_sg_pools[pool].size;
+}
static void scsi_run_queue(struct request_queue *q);
@@ -699,7 +702,7 @@ static unsigned scsi_sgtable_index(unsigned nents)
int i, size;
for (i = 0, size = 8; i SG_MEMPOOL_NR-1; i++, size = 1)
- if (size = nents)
+ if (size nents)
return i;
if (SCSI_MAX_SG_SEGMENTS = nents)
@@ -710,26 +713,26 @@ static unsigned scsi_sgtable_index(unsigned nents)
return -1;
}
-struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd *cmd, gfp_t gfp_mask)
+struct scsi_sgtable *scsi_alloc_sgtable(int sg_count, gfp_t gfp_mask)
{
- unsigned int pool = scsi_sgtable_index(cmd-use_sg);
- struct scatterlist *sgl;
+ unsigned int pool = scsi_sgtable_index(sg_count);
+ struct scsi_sgtable *sgt;
- sgl = mempool_alloc(scsi_sg_pools[pool].pool, gfp_mask);
- if (unlikely(!sgl))
+ sgt = mempool_alloc(scsi_sg_pools[pool].pool, gfp_mask);
+ if (unlikely(!sgt))
return NULL;
- cmd-sg_pool = pool;
- return sgl;
+ memset(sgt, 0, SG_TABLE_SIZEOF(scsi_pool_size(pool)));
+ sgt-sg_count = sg_count;
+ sgt-sg_pool = pool;
+ return sgt;
}
-
EXPORT_SYMBOL(scsi_alloc_sgtable);
-void scsi_free_sgtable(struct scsi_cmnd *cmd)
+void scsi_free_sgtable(struct scsi_sgtable *sgt)
{
- mempool_free(cmd-request_buffer, scsi_sg_pools[cmd-sg_pool].pool);
+ mempool_free(sgt, scsi_sg_pools[sgt-sg_pool].pool);
}
-
EXPORT_SYMBOL(scsi_free_sgtable);
/*
@@ -751,13 +754,12 @@ EXPORT_SYMBOL(scsi_free_sgtable);
*/
static void scsi_release_buffers(struct scsi_cmnd *cmd)
{
- if (cmd-use_sg)
- scsi_free_sgtable(cmd);
+ if (cmd-sgtable)
+ scsi_free_sgtable(cmd-sgtable);
- /*
-* Zero these out. They now point to freed memory, and it is
-* dangerous to hang onto the pointers.
-*/
+ cmd-sgtable = NULL;
+
+ /*FIXME: make code backward compatible with old system */
cmd-request_buffer = NULL;
cmd-request_bufflen = 0;
cmd-use_sg = 0;
@@ -794,7 +796,7 @@ static void scsi_release_buffers(struct scsi_cmnd *cmd)
void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
{
int result = cmd-result;
- int this_count = cmd-request_bufflen;
+ int this_count = scsi_bufflen(cmd);
request_queue_t *q =
[PATCH A3/5] SCSI: sg-chaining over scsi_sgtable
Based on Jens code for sg-chaining but over scsi_sgtable implementation
- Previous scsi_{alloc,free}_sgtable() renamed to
scsi_{alloc,free}_sgtable_page()
- scsi_{alloc,free}_sgtable() using the above now supports sg-chaining with
multiple
sgtable allocations.
- Report arbitrary default of 2048 to block layer.
from Jens:
This is what enables large commands. If we need to allocate an
sgtable that doesn't fit in a single page, allocate several
SCSI_MAX_SG_SEGMENTS sized tables and chain them together.
SCSI defaults to large chained sg tables, if the arch supports it.
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/scsi/scsi_lib.c | 89 +-
1 files changed, 87 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 262128c..13870b5 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -59,6 +59,12 @@ static inline unsigned scsi_pool_size(int pool)
return scsi_sg_pools[pool].size;
}
+/*
+ * IO limit For archs that have sg chaining. This limit is totally arbitrary,
+ * a setting of 2048 will get you at least 8mb ios.
+ */
+#define SCSI_MAX_SG_CHAIN_SEGMENTS 2048
+
static void scsi_run_queue(struct request_queue *q);
/*
@@ -713,7 +719,7 @@ static unsigned scsi_sgtable_index(unsigned nents)
return -1;
}
-struct scsi_sgtable *scsi_alloc_sgtable(int sg_count, gfp_t gfp_mask)
+static struct scsi_sgtable *scsi_alloc_sgtable_page(int sg_count, gfp_t
gfp_mask)
{
unsigned int pool = scsi_sgtable_index(sg_count);
struct scsi_sgtable *sgt;
@@ -727,12 +733,77 @@ struct scsi_sgtable *scsi_alloc_sgtable(int sg_count,
gfp_t gfp_mask)
sgt-sg_pool = pool;
return sgt;
}
+
+struct scsi_sgtable *scsi_alloc_sgtable(int sg_count, gfp_t gfp_mask)
+{
+ struct scsi_sgtable *sgt, *prev, *ret;
+
+ if (sg_count = SCSI_MAX_SG_SEGMENTS)
+ return scsi_alloc_sgtable_page(sg_count, gfp_mask);
+
+ ret = prev = NULL;
+ do {
+ int this;
+
+ if (sg_count SCSI_MAX_SG_SEGMENTS) {
+ this = SCSI_MAX_SG_SEGMENTS - 1; /* room for chain */
+ } else {
+ this = sg_count;
+ }
+
+ sgt = scsi_alloc_sgtable_page(this, gfp_mask);
+ /*
+* FIXME: since second and on allocations are done
+* ~__GFP_WAIT we can fail more easilly, but nothing
+* prevents us from trying smaller pools and chaining
+* more arrays. The last patch in the series does just
+* that.
+*/
+ if (unlikely(!sgt))
+ goto enomem;
+
+ /* first loop through, set return value */
+ if (!ret)
+ ret = sgt;
+
+ /* chain previous sglist, if any */
+ if (prev)
+ sg_chain(prev-sglist, scsi_pool_size(prev-sg_pool),
+ sgt-sglist);
+
+ /*
+* don't allow subsequent mempool allocs to sleep, it would
+* violate the mempool principle.
+*/
+ gfp_mask = ~__GFP_WAIT;
+ gfp_mask |= __GFP_HIGH;
+ sg_count -= this;
+ prev = sgt;
+ } while (sg_count);
+
+ return ret;
+enomem:
+ if (ret)
+ scsi_free_sgtable(ret);
+ return NULL;
+}
EXPORT_SYMBOL(scsi_alloc_sgtable);
-void scsi_free_sgtable(struct scsi_sgtable *sgt)
+static void scsi_free_sgtable_page(struct scsi_sgtable *sgt)
{
mempool_free(sgt, scsi_sg_pools[sgt-sg_pool].pool);
}
+
+static void scsi_free_sgtable(struct scsi_sgtable *sgt)
+{
+ do {
+ struct scatterlist *next, *here_last;
+ here_last = sgt-sglist[scsi_pool_size(sgt-sg_pool) - 1];
+ next = sg_is_chain(here_last) ? sg_chain_ptr(here_last) : NULL;
+ scsi_free_sgtable_page(sgt);
+ sgt = next ? ((struct scsi_sgtable*)next) - 1 : NULL;
+ } while(sgt);
+}
EXPORT_SYMBOL(scsi_free_sgtable);
/*
@@ -1550,8 +1621,22 @@ struct request_queue *__scsi_alloc_queue(struct
Scsi_Host *shost,
if (!q)
return NULL;
+ /*
+* this limit is imposed by hardware restrictions
+*/
blk_queue_max_hw_segments(q, shost-sg_tablesize);
+
+ /*
+* In the future, sg chaining support will be mandatory and this
+* ifdef can then go away. Right now we don't have all archs
+* converted, so better keep it safe.
+*/
+#ifdef ARCH_HAS_SG_CHAIN
+ blk_queue_max_phys_segments(q, SCSI_MAX_SG_CHAIN_SEGMENTS);
+#else
blk_queue_max_phys_segments(q, SCSI_MAX_SG_SEGMENTS);
+#endif
+
blk_queue_max_sectors(q,
[PATCH B2/5] SCSI: support for allocating large scatterlists
A slightly revised sg-chaining patch to accommodate
for the cleanup of sg-pools allocations.
from Jens:
This is what enables large commands. If we need to allocate an
sgtable that doesn't fit in a single page, allocate several
SCSI_MAX_SG_SEGMENTS sized tables and chain them together.
SCSI defaults to large chained sg tables, if the arch supports it.
Was-Signed-by: Jens Axboe [EMAIL PROTECTED]
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/scsi/scsi_lib.c | 136 +++---
include/scsi/scsi_cmnd.h |1 +
2 files changed, 129 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 71532f9..7ee5591 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -54,7 +54,11 @@ struct scsi_host_sg_pool {
};
static struct scsi_host_sg_pool scsi_sg_pools[SG_MEMPOOL_NR];
-
+/*
+ * IO limit For archs that have sg chaining. This limit is totally arbitrary,
+ * a setting of 2048 will get you at least 8mb ios.
+ */
+#define SCSI_MAX_SG_CHAIN_SEGMENTS 2048
static void scsi_run_queue(struct request_queue *q);
@@ -712,21 +716,123 @@ static unsigned scsi_sgtable_index(unsigned nents)
struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd *cmd, gfp_t gfp_mask)
{
- unsigned int pool = scsi_sgtable_index(cmd-use_sg);
- struct scatterlist *sgl;
+ struct scsi_host_sg_pool *sgp;
+ struct scatterlist *sgl, *prev, *ret;
+ unsigned int index;
+ int this, left;
+
+ BUG_ON(!cmd-use_sg);
+
+ left = cmd-use_sg;
+ ret = prev = NULL;
+ do {
+ this = left;
+ if (this SCSI_MAX_SG_SEGMENTS) {
+ this = SCSI_MAX_SG_SEGMENTS - 1;
+ index = SG_MEMPOOL_NR - 1;
+ } else
+ index = scsi_sgtable_index(this);
- sgl = mempool_alloc(scsi_sg_pools[pool].pool, gfp_mask);
- if (unlikely(!sgl))
- return NULL;
+ left -= this;
+
+ sgp = scsi_sg_pools + index;
+
+ sgl = mempool_alloc(sgp-pool, gfp_mask);
+ if (unlikely(!sgl))
+ goto enomem;
+
+ memset(sgl, 0, sizeof(*sgl) * sgp-size);
+
+ /*
+* first loop through, set initial index and return value
+*/
+ if (!ret) {
+ cmd-sg_pool = index;
+ ret = sgl;
+ }
+
+ /*
+* chain previous sglist, if any. we know the previous
+* sglist must be the biggest one, or we would not have
+* ended up doing another loop.
+*/
+ if (prev)
+ sg_chain(prev, SCSI_MAX_SG_SEGMENTS, sgl);
+
+ /*
+* don't allow subsequent mempool allocs to sleep, it would
+* violate the mempool principle.
+*/
+ gfp_mask = ~__GFP_WAIT;
+ gfp_mask |= __GFP_HIGH;
+ prev = sgl;
+ } while (left);
+
+ /*
+* -use_sg may get modified after dma mapping has potentially
+* shrunk the number of segments, so keep a copy of it for free.
+*/
+ cmd-__use_sg = cmd-use_sg;
+ return ret;
+enomem:
+ if (ret) {
+ /*
+* Free entries chained off ret. Since we were trying to
+* allocate another sglist, we know that all entries are of
+* the max size.
+*/
+ sgp = scsi_sg_pools + SG_MEMPOOL_NR - 1;
+ prev = ret;
+ ret = ret[SCSI_MAX_SG_SEGMENTS - 1];
+
+ while ((sgl = sg_chain_ptr(ret)) != NULL) {
+ ret = sgl[SCSI_MAX_SG_SEGMENTS - 1];
+ mempool_free(sgl, sgp-pool);
+ }
- cmd-sg_pool = pool;
- return sgl;
+ mempool_free(prev, sgp-pool);
+ }
+ return NULL;
}
EXPORT_SYMBOL(scsi_alloc_sgtable);
void scsi_free_sgtable(struct scsi_cmnd *cmd)
{
+ struct scatterlist *sgl = cmd-request_buffer;
+ struct scsi_host_sg_pool *sgp;
+
+ /*
+* if this is the biggest size sglist, check if we have
+* chained parts we need to free
+*/
+ if (cmd-__use_sg SCSI_MAX_SG_SEGMENTS) {
+ unsigned short this, left;
+ struct scatterlist *next;
+ unsigned int index;
+
+ left = cmd-__use_sg - (SCSI_MAX_SG_SEGMENTS - 1);
+ next = sg_chain_ptr(sgl[SCSI_MAX_SG_SEGMENTS - 1]);
+ while (left next) {
+ sgl = next;
+ this = left;
+ if (this SCSI_MAX_SG_SEGMENTS) {
+ this = SCSI_MAX_SG_SEGMENTS - 1;
+
[PATCH B3/5] SCSI: scsi_sgtable over sg-chainning
As proposed by James Bottomley all I/O members of struct scsi_cmnd
and the resid member, which need to be duplicated for bidirectional
transfers. Can be allocated together with the sg-list they are
pointing to. This way when bidi comes the structure can be duplicated
with minimal change to code, and with no extra baggage when bidi is not
used. The resulting code is the use of a new mechanism called scsi_sgtable.
This code is over Jens's sg-chaining patches to scsi-ml. and it keeps
functionality and compatibility with large IO threw sg-chaining.
scsi_cmnd.h
- define a new scsi_sgtable structure that will hold IO descriptors + the
actual scattergather array.
- Hold a pointer to the scsi_sgtable in scsi_cmnd.
- Deprecate old, now unnecessary, IO members of scsi_cmnd. These members are
kept for compatibility with unconverted drivers, still lurking around in
the code tree. They can be removed completely in the future.
- Modify data accessors to now use new members of scsi_sgtable.
scsi_lib.c
- scsi_lib is converted to use the new scsi_sgtable, in stead of the old
members and sg-arrays.
- scsi_{alloc,free}_sgtable() API has changed. This will break scsi_stgt
which will need to be converted to new implementation.
- Special code is inserted to initialize the old compatibility members from
the new structures. This code will be removed.
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/scsi/scsi_lib.c | 242 --
include/scsi/scsi_cmnd.h | 41 +---
2 files changed, 127 insertions(+), 156 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 7ee5591..13870b5 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -38,13 +38,13 @@
enum { SCSI_MAX_SG_SEGMENTS = (PAGE_SIZE / sizeof(struct scatterlist)) };
enum { SG_MEMPOOL_NR =
- (SCSI_MAX_SG_SEGMENTS = 8) +
- (SCSI_MAX_SG_SEGMENTS = 16) +
- (SCSI_MAX_SG_SEGMENTS = 32) +
- (SCSI_MAX_SG_SEGMENTS = 64) +
- (SCSI_MAX_SG_SEGMENTS = 128) +
- (SCSI_MAX_SG_SEGMENTS = 256) +
- (SCSI_MAX_SG_SEGMENTS = 512)
+ (SCSI_MAX_SG_SEGMENTS 8) +
+ (SCSI_MAX_SG_SEGMENTS 16) +
+ (SCSI_MAX_SG_SEGMENTS 32) +
+ (SCSI_MAX_SG_SEGMENTS 64) +
+ (SCSI_MAX_SG_SEGMENTS 128) +
+ (SCSI_MAX_SG_SEGMENTS 256) +
+ (SCSI_MAX_SG_SEGMENTS 512)
};
struct scsi_host_sg_pool {
@@ -54,6 +54,11 @@ struct scsi_host_sg_pool {
};
static struct scsi_host_sg_pool scsi_sg_pools[SG_MEMPOOL_NR];
+static inline unsigned scsi_pool_size(int pool)
+{
+ return scsi_sg_pools[pool].size;
+}
+
/*
* IO limit For archs that have sg chaining. This limit is totally arbitrary,
* a setting of 2048 will get you at least 8mb ios.
@@ -703,7 +708,7 @@ static unsigned scsi_sgtable_index(unsigned nents)
int i, size;
for (i = 0, size = 8; i SG_MEMPOOL_NR-1; i++, size = 1)
- if (size = nents)
+ if (size nents)
return i;
if (SCSI_MAX_SG_SEGMENTS = nents)
@@ -714,50 +719,57 @@ static unsigned scsi_sgtable_index(unsigned nents)
return -1;
}
-struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd *cmd, gfp_t gfp_mask)
+static struct scsi_sgtable *scsi_alloc_sgtable_page(int sg_count, gfp_t
gfp_mask)
{
- struct scsi_host_sg_pool *sgp;
- struct scatterlist *sgl, *prev, *ret;
- unsigned int index;
- int this, left;
-
- BUG_ON(!cmd-use_sg);
+ unsigned int pool = scsi_sgtable_index(sg_count);
+ struct scsi_sgtable *sgt;
- left = cmd-use_sg;
- ret = prev = NULL;
- do {
- this = left;
- if (this SCSI_MAX_SG_SEGMENTS) {
- this = SCSI_MAX_SG_SEGMENTS - 1;
- index = SG_MEMPOOL_NR - 1;
- } else
- index = scsi_sgtable_index(this);
+ sgt = mempool_alloc(scsi_sg_pools[pool].pool, gfp_mask);
+ if (unlikely(!sgt))
+ return NULL;
- left -= this;
+ memset(sgt, 0, SG_TABLE_SIZEOF(scsi_pool_size(pool)));
+ sgt-sg_count = sg_count;
+ sgt-sg_pool = pool;
+ return sgt;
+}
- sgp = scsi_sg_pools + index;
+struct scsi_sgtable *scsi_alloc_sgtable(int sg_count, gfp_t gfp_mask)
+{
+ struct scsi_sgtable *sgt, *prev, *ret;
- sgl = mempool_alloc(sgp-pool, gfp_mask);
- if (unlikely(!sgl))
- goto enomem;
+ if (sg_count = SCSI_MAX_SG_SEGMENTS)
+ return scsi_alloc_sgtable_page(sg_count, gfp_mask);
- memset(sgl, 0, sizeof(*sgl) * sgp-size);
+ ret = prev = NULL;
+ do {
+ int this;
- /*
-* first loop through, set initial index and return value
-*/
- if (!ret) {
-
Re: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining
From: Boaz Harrosh [EMAIL PROTECTED] Subject: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining Date: Tue, 24 Jul 2007 11:47:50 +0300 As Jens said, there is nothing common to scsi_sgtable and sglists. Save the fact that it is a massive conflict at scsi-ml. They touch all the same places. Proposed is a simple way out. Two patchsets That produce the same output at the end. One: scsi_sgtable_than_sg-chaining Two: sg-chaining_than_scsi_sgtable Hmm, I thought that I've already posted a scsi_sgtable patch working with sg-chaining together. http://marc.info/?l=linux-scsim=118519987632758w=2 I quoted from my mail: --- I think that the main issue of integrating sgtable and sglist is how to put scatterlist to scsi_sgtable structure. If we allocate a scsi_sgtable structure and sglists separately, the code is pretty simple. But probably it's not the best way from the perspective of performance. If we put sglists into the scsi_sgtable structure (like Boaz's patch does) and allocate and chain sglists only for large I/Os, we would have the better performance (especially for small I/Os). But we will have more complicated code. --- From a quick look over your patchset, you chose the latter. And my patch uses the former. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining
FUJITA Tomonori wrote: From: Boaz Harrosh [EMAIL PROTECTED] Subject: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining Date: Tue, 24 Jul 2007 11:47:50 +0300 As Jens said, there is nothing common to scsi_sgtable and sglists. Save the fact that it is a massive conflict at scsi-ml. They touch all the same places. Proposed is a simple way out. Two patchsets That produce the same output at the end. One: scsi_sgtable_than_sg-chaining Two: sg-chaining_than_scsi_sgtable Hmm, I thought that I've already posted a scsi_sgtable patch working with sg-chaining together. http://marc.info/?l=linux-scsim=118519987632758w=2 I quoted from my mail: --- I think that the main issue of integrating sgtable and sglist is how to put scatterlist to scsi_sgtable structure. If we allocate a scsi_sgtable structure and sglists separately, the code is pretty simple. But probably it's not the best way from the perspective of performance. I was just answering your other mail when this came in so I'll answer here. This Approach is exactly the scsi_data_buffer approach we both had solutions for. At the time I was all for that approach because it is safer and could be kept compatible to old drivers. (Less work for me) But it was decided against it. So suggesting it again is plain going back. Now that We have done the work, I must say that James was right. The sgtable work is nice and elegant. And makes scsi-ml more simple not more complicated. And the bidi looks beautifully trivial on-top of sgtables. If we put sglists into the scsi_sgtable structure (like Boaz's patch does) and allocate and chain sglists only for large I/Os, we would have the better performance (especially for small I/Os). But we will have more complicated code. Only that my proposed solution is more simple more elegant and more robust than even Jens's solution without any sgtable at all. Actually the sgtable does good to chaining. scsi_lib with sglist+sgtable is smaller than Jens's sglist by itself. --- From a quick look over your patchset, you chose the latter. And my patch uses the former. This patchset is not new. I have sent that solution before. (http://marc.info/?l=linux-scsim=117933686313822w=2) In fact when first programing for sgtable I had in mind Jens's work to make sure it will fit and converge. Please lets not go back to old solutions again Boaz - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] mpt fusion: Add logging support
The patches in this patch set adds support for logging facility that can be used to debug a number of Fusion MPT related problems. The logging support can be enabled or disabled changing the kernel configuration flag CONFIF_FUSION_LOGGING The debug level can be programmed on the fly via SysFS (hex values) echo [level] /sys/class/scsi_host/host#/debug_level and also can be passed as module parameter mpt_debug_level for mptbase.ko There are various debug levels that can be found in the source file mptdebug.h Since the difference is of size 175 KB, it is split into five different patches grouped based on the files as described below. [PATCH 1/5] : Changes for logging support in Kconfig, Makefile, mptbase.h and addition of mptdebug.h [PATCH 2/5] : Changes in mptbase.c for logging support [PATCH 3/5] : Changes in mptscsih.c for logging support [PATCH 4/5] : Changes in mptfc.c mptlan.c mptsas.c and mptspi.c for logging support [PATCH 5/5] : Changes in mptctl.c for logging support signed-off-by: Sathya Prakash [EMAIL PROTECTED] --- - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] mpt fusion: Changes for logging support in Kconfig, Makefile, mptbase.h and addition of mptdebug.h
This patch adds a new file mptdebug.h in the fusion source directory, which
contains different debug macros.
The existing debug macros and flags are removed from the mptbase.h and
Makefile
In Kconfig a new configuration parameter FUSION_LOGGING is added to
enable/disable the logging support during compile time.
signed-off-by: Sathya Prakash [EMAIL PROTECTED]
---
diff -Naurp b/drivers/message/fusion/Kconfig a/drivers/message/fusion/Kconfig
--- b/drivers/message/fusion/Kconfig2007-07-23 14:24:35.0 +0530
+++ a/drivers/message/fusion/Kconfig2007-07-23 16:37:01.0 +0530
@@ -102,4 +102,18 @@ config FUSION_LAN
If unsure whether you really want or need this, say N.
+config FUSION_LOGGING
+ bool Fusion MPT logging facility
+ depends on FUSION
+ ---help---
+ This turns on a logging facility that can be used to debug a number
+ of Fusion MPT related problems.
+
+ The debug level can be programmed on the fly via SysFS (hex values)
+
+ echo [level] /sys/class/scsi_host/host#/debug_level
+
+ There are various debug levels that an be found in the source:
+ file:drivers/message/fusion/mptdebug.h
+
endmenu
diff -Naurp b/drivers/message/fusion/Makefile a/drivers/message/fusion/Makefile
--- b/drivers/message/fusion/Makefile 2007-07-09 05:02:17.0 +0530
+++ a/drivers/message/fusion/Makefile 2007-07-23 16:37:08.0 +0530
@@ -1,39 +1,8 @@
# Fusion MPT drivers; recognized debug defines...
-# MPT general:
-#EXTRA_CFLAGS += -DMPT_DEBUG
-#EXTRA_CFLAGS += -DMPT_DEBUG_MSG_FRAME
-#EXTRA_CFLAGS += -DMPT_DEBUG_SG
-#EXTRA_CFLAGS += -DMPT_DEBUG_EVENTS
-#EXTRA_CFLAGS += -DMPT_DEBUG_VERBOSE_EVENTS
-#EXTRA_CFLAGS += -DMPT_DEBUG_INIT
-#EXTRA_CFLAGS += -DMPT_DEBUG_EXIT
-#EXTRA_CFLAGS += -DMPT_DEBUG_FAIL
-#EXTRA_CFLAGS += -DMPT_DEBUG_DV
-#EXTRA_CFLAGS += -DMPT_DEBUG_TM
-#EXTRA_CFLAGS += -DMPT_DEBUG_REPLY
-#
-# driver/module specifics...
-#
-# For mptbase:
-#CFLAGS_mptbase.o += -DMPT_DEBUG_HANDSHAKE
-#CFLAGS_mptbase.o += -DMPT_DEBUG_CONFIG
-#CFLAGS_mptbase.o += -DMPT_DEBUG_DL
-#CFLAGS_mptbase.o += -DMPT_DEBUG_IRQ
-#CFLAGS_mptbase.o += -DMPT_DEBUG_RESET
-#
-# For mptscsih:
-#CFLAGS_mptscsih.o += -DMPT_DEBUG_SCSI
-#
-# For mptctl:
-#CFLAGS_mptctl.o += -DMPT_DEBUG_IOCTL
-#
-# For mptfc:
-#CFLAGS_mptfc.o += -DMPT_DEBUG_FC
-
-# For mptsas:
-#CFLAGS_mptsas.o += -DMPT_DEBUG_SAS
-#CFLAGS_mptsas.o += -DMPT_DEBUG_SAS_WIDE
+# enable verbose logging
+# CONFIG_FUSION_LOGGING needs to be enabled in Kconfig
+#EXTRA_CFLAGS += -DMPT_DEBUG_VERBOSE
#=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-} LSI_LOGIC
diff -Naurp b/drivers/message/fusion/mptbase.h
a/drivers/message/fusion/mptbase.h
--- b/drivers/message/fusion/mptbase.h 2007-07-23 14:24:35.0 +0530
+++ a/drivers/message/fusion/mptbase.h 2007-07-23 16:37:16.0 +0530
@@ -186,6 +186,7 @@
* MPT drivers. NOTE: Users of these macro defs must
* themselves define their own MYNAM.
*/
+#define MYIOC_s_DEBUG_FMT KERN_DEBUG MYNAM : %s:
#define MYIOC_s_INFO_FMT KERN_INFO MYNAM : %s:
#define MYIOC_s_NOTE_FMT KERN_NOTICE MYNAM : %s:
#define MYIOC_s_WARN_FMT KERN_WARNING MYNAM : %s: WARNING -
@@ -543,6 +544,7 @@ typedef struct _MPT_ADAPTER
char board_tracer[16];
u16 nvdata_version_persistent;
u16 nvdata_version_default;
+ int debug_level;
u8 io_missing_delay;
u8 device_missing_delay;
SYSIF_REGS __iomem *chip; /* == c8817000 (mmap) */
@@ -718,171 +720,7 @@ typedef struct _mpt_sge {
/*
* Funky (private) macros...
*/
-#ifdef MPT_DEBUG
-#define dprintk(x) printk x
-#else
-#define dprintk(x)
-#endif
-
-#ifdef MPT_DEBUG_INIT
-#define dinitprintk(x) printk x
-#define DBG_DUMP_FW_REQUEST_FRAME(mfp) \
- { int i, n = 10; \
- u32 *m = (u32 *)(mfp); \
- printk(KERN_INFO ); \
- for (i=0; in; i++) \
- printk( %08x, le32_to_cpu(m[i])); \
- printk(\n); \
- }
-#else
-#define dinitprintk(x)
-#define DBG_DUMP_FW_REQUEST_FRAME(mfp)
-#endif
-
-#ifdef MPT_DEBUG_EXIT
-#define dexitprintk(x) printk x
-#else
-#define dexitprintk(x)
-#endif
-
-#if defined MPT_DEBUG_FAIL || defined (MPT_DEBUG_SG)
-#define dfailprintk(x) printk x
-#else
-#define dfailprintk(x)
-#endif
-
-#ifdef MPT_DEBUG_HANDSHAKE
-#define dhsprintk(x) printk x
-#else
-#define dhsprintk(x)
-#endif
-
-#if defined(MPT_DEBUG_EVENTS) || defined(MPT_DEBUG_VERBOSE_EVENTS)
-#define devtprintk(x) printk x
-#else
-#define devtprintk(x)
-#endif
-
-#ifdef MPT_DEBUG_VERBOSE_EVENTS
-#define
Re: [patch 0/4] aha152x.c - Cleanup, need help in testing and auditing
Randy Dunlap wrote: I prefer either of the !HIGHMEM or slave_alloc changes to adding a BUG_ON(). However, the SCSI people likely won't want to use the slave_alloc() change because then the driver may never get fixed. (Of course, it hasn't got fixed with the BUG happening either.) Anyway, I'll re-read Documentation/DMA*.txt to see if I can fix it. --- Hi Randy. could you please send me the patch you have with the .slave_alloc solution for now. I would like to revise the patchset and send them for inclusion now. They do fix some problems and let users work. We can put a big fat warring and explanation about highmem in the commit log comments so people can watch out. Thanks Boaz - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] mpt fusion: Changes in mptbase.c for logging support
This patch contains changes in mptbase.c to support logging in MPT fusion
drivers.
The changes are majorly in debug printks, the existing debugprintk are
modified accroding to new debug macros defined in the file mptbdebug.h
A new module parameter mpt_debug_level is added to pass the debug level as
module parameter.
signed-off-by: Sathya Prakash [EMAIL PROTECTED]
---
diff -Naurp b/drivers/message/fusion/mptbase.c
a/drivers/message/fusion/mptbase.c
--- b/drivers/message/fusion/mptbase.c 2007-07-23 14:24:35.0 +0530
+++ a/drivers/message/fusion/mptbase.c 2007-07-23 16:40:27.0 +0530
@@ -87,6 +87,10 @@ static int mpt_channel_mapping;
module_param(mpt_channel_mapping, int, 0);
MODULE_PARM_DESC(mpt_channel_mapping, Mapping id's to channels (default=0));
+static int mpt_debug_level;
+module_param(mpt_debug_level, int, 0);
+MODULE_PARM_DESC(mpt_debug_level, debug level - refer to mptdebug.h -
(default=0));
+
#ifdef MFCNT
static int mfcounter = 0;
#define PRINT_MF_COUNT 2
@@ -179,9 +183,7 @@ static void mpt_get_fw_exp_ver(char *buf
//int mpt_HardResetHandler(MPT_ADAPTER *ioc, int sleepFlag);
static int ProcessEventNotification(MPT_ADAPTER *ioc,
EventNotificationReply_t *evReply, int *evHandlers);
-#ifdef MPT_DEBUG_REPLY
static voidmpt_iocstatus_info(MPT_ADAPTER *ioc, u32 ioc_status,
MPT_FRAME_HDR *mf);
-#endif
static voidmpt_fc_log_info(MPT_ADAPTER *ioc, u32 log_info);
static voidmpt_spi_log_info(MPT_ADAPTER *ioc, u32 log_info);
static voidmpt_sas_log_info(MPT_ADAPTER *ioc, u32 log_info);
@@ -229,7 +231,7 @@ mpt_turbo_reply(MPT_ADAPTER *ioc, u32 pa
int req_idx = 0;
int cb_idx;
- dmfprintk((MYIOC_s_INFO_FMT Got TURBO reply req_idx=%08x\n,
+ dmfprintk(ioc, printk(MYIOC_s_DEBUG_FMT Got TURBO reply
req_idx=%08x\n,
ioc-name, pa));
switch (pa MPI_CONTEXT_REPLY_TYPE_SHIFT) {
@@ -312,9 +314,9 @@ mpt_reply(MPT_ADAPTER *ioc, u32 pa)
cb_idx = mr-u.frame.hwhdr.msgctxu.fld.cb_idx;
mf = MPT_INDEX_2_MFPTR(ioc, req_idx);
- dmfprintk((MYIOC_s_INFO_FMT Got non-TURBO reply=%p req_idx=%x
cb_idx=%x Function=%x\n,
+ dmfprintk(ioc, printk(MYIOC_s_DEBUG_FMT Got non-TURBO reply=%p
req_idx=%x cb_idx=%x Function=%x\n,
ioc-name, mr, req_idx, cb_idx, mr-u.hdr.Function));
- DBG_DUMP_REPLY_FRAME(mr)
+ DBG_DUMP_REPLY_FRAME(ioc, (u32 *)mr)
/* Check/log IOC log info
*/
@@ -329,10 +331,8 @@ mpt_reply(MPT_ADAPTER *ioc, u32 pa)
mpt_sas_log_info(ioc, log_info);
}
-#ifdef MPT_DEBUG_REPLY
if (ioc_stat MPI_IOCSTATUS_MASK)
mpt_iocstatus_info(ioc, (u32)ioc_stat, mf);
-#endif
/* Check for (valid) IO callback! */
if (cb_idx 1 || cb_idx = MPT_MAX_PROTOCOL_DRIVERS ||
@@ -414,17 +414,17 @@ mpt_base_reply(MPT_ADAPTER *ioc, MPT_FRA
int freereq = 1;
u8 func;
- dmfprintk((MYIOC_s_INFO_FMT mpt_base_reply() called\n, ioc-name));
-
-#if defined(MPT_DEBUG_MSG_FRAME)
- if (!(reply-u.hdr.MsgFlags MPI_MSGFLAGS_CONTINUATION_REPLY)) {
- dmfprintk((KERN_INFO MYNAM : Original request frame (@%p)
header\n, mf));
- DBG_DUMP_REQUEST_FRAME_HDR(mf)
+ dmfprintk(ioc, printk(MYIOC_s_DEBUG_FMT mpt_base_reply() called\n,
ioc-name));
+#ifdef CONFIG_FUSION_LOGGING
+ if ((ioc-debug_level MPT_DEBUG_MSG_FRAME)
+ !(reply-u.hdr.MsgFlags
MPI_MSGFLAGS_CONTINUATION_REPLY)) {
+ dmfprintk(ioc, printk(KERN_INFO MYNAM : Original request frame
(@%p) header\n, mf));
+ DBG_DUMP_REQUEST_FRAME_HDR(ioc, (u32 *)mf)
}
#endif
func = reply-u.hdr.Function;
- dmfprintk((MYIOC_s_INFO_FMT mpt_base_reply, Function=%02Xh\n,
+ dmfprintk(ioc, printk(MYIOC_s_DEBUG_FMT mpt_base_reply,
Function=%02Xh\n,
ioc-name, func));
if (func == MPI_FUNCTION_EVENT_NOTIFICATION) {
@@ -435,7 +435,7 @@ mpt_base_reply(MPT_ADAPTER *ioc, MPT_FRA
results = ProcessEventNotification(ioc, pEvReply, evHandlers);
if (results != evHandlers) {
/* CHECKME! Any special handling needed here? */
- devtverboseprintk((MYIOC_s_WARN_FMT Called %d event
handlers, sum results = %d\n,
+ devtverboseprintk(ioc, printk(MYIOC_s_WARN_FMT Called
%d event handlers, sum results = %d\n,
ioc-name, evHandlers, results));
}
@@ -446,7 +446,7 @@ mpt_base_reply(MPT_ADAPTER *ioc, MPT_FRA
if (pEvReply-MsgFlags MPI_MSGFLAGS_CONTINUATION_REPLY) {
freereq = 0;
} else {
- devtverboseprintk((MYIOC_s_WARN_FMT EVENT_NOTIFICATION
reply %p returns Request frame\n,
+ devtverboseprintk(ioc, printk(MYIOC_s_WARN_FMT
[PATCH 3/5] mpt fusion: Changes in mptscsih.c for logging support
This patch contains changes in mptscsih.c to support logging in MPT fusion
drivers.
The changes are majorly in debug printks, the existing debugprintk are
modified accroding to new debug macros defined in the file mptbdebug.h
A new sysfs attribute is added to retrieve and modify the debug level.
signed-off-by: Sathya Prakash [EMAIL PROTECTED]
---
diff -Naurp b/drivers/message/fusion/mptscsih.c
a/drivers/message/fusion/mptscsih.c
--- b/drivers/message/fusion/mptscsih.c 2007-07-23 14:24:35.0 +0530
+++ a/drivers/message/fusion/mptscsih.c 2007-07-23 18:06:42.0 +0530
@@ -191,7 +191,7 @@ mptscsih_getFreeChainBuffer(MPT_ADAPTER
int rc;
int chain_idx;
- dsgprintk((MYIOC_s_INFO_FMT getFreeChainBuffer called\n,
+ dsgprintk(ioc, printk(MYIOC_s_DEBUG_FMT getFreeChainBuffer called\n,
ioc-name));
spin_lock_irqsave(ioc-FreeQlock, flags);
if (!list_empty(ioc-FreeChainQ)) {
@@ -203,12 +203,12 @@ mptscsih_getFreeChainBuffer(MPT_ADAPTER
offset = (u8 *)chainBuf - (u8 *)ioc-ChainBuffer;
chain_idx = offset / ioc-req_sz;
rc = SUCCESS;
- dsgprintk((MYIOC_s_ERR_FMT getFreeChainBuffer chainBuf=%p
ChainBuffer=%p offset=%d chain_idx=%d\n,
+ dsgprintk(ioc, printk(MYIOC_s_DEBUG_FMT getFreeChainBuffer
chainBuf=%p ChainBuffer=%p offset=%d chain_idx=%d\n,
ioc-name, chainBuf, ioc-ChainBuffer, offset,
chain_idx));
} else {
rc = FAILED;
chain_idx = MPT_HOST_NO_CHAIN;
- dfailprintk((MYIOC_s_INFO_FMT getFreeChainBuffer failed\n,
+ dfailprintk(ioc, printk(MYIOC_s_DEBUG_FMT getFreeChainBuffer
failed\n,
ioc-name));
}
spin_unlock_irqrestore(ioc-FreeQlock, flags);
@@ -337,7 +337,7 @@ nextSGEset:
*/
pReq-ChainOffset = 0;
RequestNB = (((sgeOffset - 1) ioc-NBShiftFactor) +
1) 0x03;
- dsgprintk((MYIOC_s_INFO_FMT
+ dsgprintk(ioc, printk(MYIOC_s_DEBUG_FMT
Single Buffer RequestNB=%x, sgeOffset=%d\n,
ioc-name, RequestNB, sgeOffset));
ioc-RequestNB[req_idx] = RequestNB;
}
@@ -353,7 +353,7 @@ nextSGEset:
* Loop until done.
*/
- dsgprintk((MYIOC_s_INFO_FMT SG: Chain Required! sg done %d\n,
+ dsgprintk(ioc, printk(MYIOC_s_DEBUG_FMT SG: Chain Required! sg
done %d\n,
ioc-name, sg_done));
/* Set LAST_ELEMENT flag for last non-chain element
@@ -386,7 +386,7 @@ nextSGEset:
*/
pReq-ChainOffset = (u8) (sgeOffset 2);
RequestNB = (((sgeOffset - 1) ioc-NBShiftFactor) +
1) 0x03;
- dsgprintk((MYIOC_s_ERR_FMT Chain Buffer Needed,
RequestNB=%x sgeOffset=%d\n, ioc-name, RequestNB, sgeOffset));
+ dsgprintk(ioc, printk(MYIOC_s_DEBUG_FMT Chain Buffer
Needed, RequestNB=%x sgeOffset=%d\n, ioc-name, RequestNB, sgeOffset));
ioc-RequestNB[req_idx] = RequestNB;
}
@@ -397,7 +397,7 @@ nextSGEset:
* in current buffer. Get a chain buffer.
*/
if ((mptscsih_getFreeChainBuffer(ioc, newIndex)) == FAILED) {
- dfailprintk((MYIOC_s_INFO_FMT
+ dfailprintk(ioc, printk(MYIOC_s_DEBUG_FMT
getFreeChainBuffer FAILED SCSI cmd=%02x (%p)\n,
ioc-name, pReq-CDB[0], SCpnt));
return FAILED;
@@ -419,7 +419,7 @@ nextSGEset:
* out the Address and Flags fields.
*/
chainSge = (char *) psge;
- dsgprintk((KERN_INFO Current buff @ %p (index 0x%x),
+ dsgprintk(ioc, printk(KERN_DEBUG Current buff @ %p (index
0x%x),
psge, req_idx));
/* Start the SGE for the next buffer
@@ -428,7 +428,7 @@ nextSGEset:
sgeOffset = 0;
sg_done = 0;
- dsgprintk((KERN_INFO Chain buff @ %p (index 0x%x)\n,
+ dsgprintk(ioc, printk(KERN_DEBUG Chain buff @ %p (index
0x%x)\n,
psge, chain_idx));
/* Start the SGE for the next buffer
@@ -456,7 +456,7 @@ mptscsih_issue_sep_command(MPT_ADAPTER *
return;
if ((mf = mpt_get_msg_frame(ioc-InternalCtx, ioc)) == NULL) {
- dfailprintk((MYIOC_s_WARN_FMT %s: no msg frames!!\n,
+ dfailprintk(ioc, printk(MYIOC_s_WARN_FMT %s: no msg
frames!!\n,
ioc-name,__FUNCTION__));
return;
}
@@ -467,93 +467,158 @@
[PATCH 5/5] mpt fusion: Changes in mptctl.c for logging support
This patch contains changes in mptctl.c to support logging in MPT fusion drivers
The changes are majorly in debug printks, the existing debugprintk are
modified accroding to new debug macros defined in the file mptbdebug.h
signed-off-by: Sathya Prakash [EMAIL PROTECTED]
---
diff -Naurp b/drivers/message/fusion/mptctl.c a/drivers/message/fusion/mptctl.c
--- b/drivers/message/fusion/mptctl.c 2007-07-23 14:24:35.0 +0530
+++ a/drivers/message/fusion/mptctl.c 2007-07-23 16:46:23.0 +0530
@@ -181,7 +181,7 @@ static inline int
mptctl_syscall_down(MPT_ADAPTER *ioc, int nonblock)
{
int rc = 0;
- dctlprintk((KERN_INFO MYNAM ::mptctl_syscall_down(%p,%d) called\n,
ioc, nonblock));
+// dctlprintk(ioc, printk(KERN_DEBUG MYNAM ::mptctl_syscall_down(%p,%d)
called\n, ioc, nonblock));
if (nonblock) {
if (!mutex_trylock(ioc-ioctl-ioctl_mutex))
@@ -190,7 +190,7 @@ mptctl_syscall_down(MPT_ADAPTER *ioc, in
if (mutex_lock_interruptible(ioc-ioctl-ioctl_mutex))
rc = -ERESTARTSYS;
}
- dctlprintk((KERN_INFO MYNAM ::mptctl_syscall_down return %d\n, rc));
+// dctlprintk(ioc, printk(KERN_DEBUG MYNAM ::mptctl_syscall_down return
%d\n, rc));
return rc;
}
@@ -209,18 +209,19 @@ mptctl_reply(MPT_ADAPTER *ioc, MPT_FRAME
u16 iocStatus;
u8 cmd;
- dctlprintk((mptctl_reply()!\n));
if (req)
cmd = req-u.hdr.Function;
else
return 1;
+ dctlprintk(ioc, printk(MYIOC_s_DEBUG_FMT \tcompleting mpi function
(0x%02X), req=%p,
+ reply=%p\n, ioc-name, req-u.hdr.Function, req, reply));
if (ioc-ioctl) {
if (reply==NULL) {
- dctlprintk((mptctl_reply() NULL Reply
- Function=%x!\n, cmd));
+ dctlprintk(ioc, printk(MYIOC_s_DEBUG_FMT
mptctl_reply() NULL Reply
+ Function=%x!\n, ioc-name, cmd));
ioc-ioctl-status |= MPT_IOCTL_STATUS_COMMAND_GOOD;
ioc-ioctl-reset = ~MPTCTL_RESET_OK;
@@ -233,14 +234,9 @@ mptctl_reply(MPT_ADAPTER *ioc, MPT_FRAME
}
- dctlprintk((mptctl_reply() with req=%p
- reply=%p Function=%x!\n, req, reply, cmd));
-
/* Copy the reply frame (which much exist
* for non-SCSI I/O) to the IOC structure.
*/
- dctlprintk((Copying Reply Frame @%p to ioc%d!\n,
- reply, ioc-id));
memcpy(ioc-ioctl-ReplyFrame, reply,
min(ioc-reply_sz, 4*reply-u.reply.MsgLength));
ioc-ioctl-status |= MPT_IOCTL_STATUS_RF_VALID;
@@ -252,8 +248,24 @@ mptctl_reply(MPT_ADAPTER *ioc, MPT_FRAME
if (iocStatus == MPI_IOCSTATUS_SUCCESS)
ioc-ioctl-status |= MPT_IOCTL_STATUS_COMMAND_GOOD;
+ if (iocStatus || reply-u.reply.IOCLogInfo)
+ dctlprintk(ioc, printk(MYIOC_s_DEBUG_FMT \tiocstatus
(0x%04X),
+ loginfo (0x%08X)\n, ioc-name,
+ iocStatus,
+ le32_to_cpu(reply-u.reply.IOCLogInfo)));
+
if ((cmd == MPI_FUNCTION_SCSI_IO_REQUEST) ||
(cmd == MPI_FUNCTION_RAID_SCSI_IO_PASSTHROUGH)) {
+
+ if (reply-u.sreply.SCSIStatus ||
reply-u.sreply.SCSIState)
+ dctlprintk(ioc, printk(MYIOC_s_DEBUG_FMT
+ \tscsi_status (0x%02x), scsi_state
(0x%02x),
+ tag = (0x%04x), transfer_count
(0x%08x)\n, ioc-name,
+ reply-u.sreply.SCSIStatus,
+ reply-u.sreply.SCSIState,
+ le16_to_cpu(reply-u.sreply.TaskTag),
+
le32_to_cpu(reply-u.sreply.TransferCount)));
+
ioc-ioctl-reset = ~MPTCTL_RESET_OK;
if ((iocStatus == MPI_IOCSTATUS_SCSI_DATA_UNDERRUN) ||
@@ -298,8 +310,8 @@ static void mptctl_timeout_expired (MPT_
{
int rc = 1;
- dctlprintk((KERN_NOTICE MYNAM : Timeout Expired! Host %d\n,
- ioctl-ioc-id));
+ dctlprintk(ioctl-ioc, printk(MYIOC_s_DEBUG_FMT : Timeout Expired!
Host %d\n,
+ ioctl-ioc-name, ioctl-ioc-id));
if (ioctl == NULL)
return;
@@ -311,7 +323,7 @@ static void mptctl_timeout_expired (MPT_
/* Issue a reset for this device.
* The IOC is not responding.
*/
- dctlprintk((MYIOC_s_INFO_FMT Calling HardReset! \n,
+ dctlprintk(ioctl-ioc, printk(MYIOC_s_DEBUG_FMT Calling
HardReset! \n,
Re: [PATCH] Enable 16-bit CDBs for aic7xxx/aic79xxx
Just wondering, have you tried testing it with our patches to support long cdb? If not, it would be great if you could try doing that. A snapshot of them is in http://www.bhalevy.com/open-osd/download/sgtable_bidi_varlen/ Benny Hannes Reinecke wrote: Hannes Reinecke wrote: Hi James, this patch enables 16-bit CDBs for aic7xxx and aic79xx. aic7xxx actuallys supports up to 32-bit CDBs, so it might be that aic79xx does that, too. But this would include some more hacking, so this is way easier. Yeah, grand. That should read '16-byte CDBs', of course. But at least I've been consistent :-) New patch attached. Cheers, Hannes Enable 16-byte CDBs for aic7xxx/aix79xx The patch enables support for 16-byte CDBs in aic7xxx and aic79xx. aic7xxx can actually support up to 32-byte CDBs, should they ever see the light of day. Signed-off-by: Hannes Reinecke [EMAIL PROTECTED] diff --git a/drivers/scsi/aic7xxx/aic79xx_osm.c b/drivers/scsi/aic7xxx/aic79xx_osm.c index 286ab83..8502085 100644 --- a/drivers/scsi/aic7xxx/aic79xx_osm.c +++ b/drivers/scsi/aic7xxx/aic79xx_osm.c @@ -1089,6 +1089,7 @@ ahd_linux_register_host(struct ahd_softc *ahd, struct scsi_host_template *templa host-max_id = (ahd-features AHD_WIDE) ? 16 : 8; host-max_lun = AHD_NUM_LUNS; host-max_channel = 0; + host-max_cmd_len = MAX_CDB_LEN; host-sg_tablesize = AHD_NSEG; ahd_lock(ahd, s); ahd_set_unit(ahd, ahd_linux_unit++); diff --git a/drivers/scsi/aic7xxx/aic7xxx_osm.c b/drivers/scsi/aic7xxx/aic7xxx_osm.c index 1803ab6..a6b3071 100644 --- a/drivers/scsi/aic7xxx/aic7xxx_osm.c +++ b/drivers/scsi/aic7xxx/aic7xxx_osm.c @@ -1047,6 +1047,7 @@ ahc_linux_register_host(struct ahc_softc *ahc, struct scsi_host_template *templa host-max_id = (ahc-features AHC_WIDE) ? 16 : 8; host-max_lun = AHC_NUM_LUNS; host-max_channel = (ahc-features AHC_TWIN) ? 1 : 0; + host-max_cmd_len = 32; host-sg_tablesize = AHC_NSEG; ahc_lock(ahc, s); ahc_set_unit(ahc, ahc_linux_unit++); - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] mpt fusion: Changes in mptscsih.c for logging support
Prakash, Sathya wrote:
This patch contains changes in mptscsih.c to support logging in MPT fusion
drivers.
The changes are majorly in debug printks, the existing debugprintk are
modified accroding to new debug macros defined in the file mptbdebug.h
A new sysfs attribute is added to retrieve and modify the debug level.
signed-off-by: Sathya Prakash [EMAIL PROTECTED]
---
diff -Naurp b/drivers/message/fusion/mptscsih.c
a/drivers/message/fusion/mptscsih.c
--- b/drivers/message/fusion/mptscsih.c 2007-07-23 14:24:35.0
+0530
+++ a/drivers/message/fusion/mptscsih.c 2007-07-23 18:06:42.0
+0530
@@ -191,7 +191,7 @@ mptscsih_getFreeChainBuffer(MPT_ADAPTER
int rc;
int chain_idx;
- dsgprintk((MYIOC_s_INFO_FMT getFreeChainBuffer called\n,
+ dsgprintk(ioc, printk(MYIOC_s_DEBUG_FMT getFreeChainBuffer called\n,
ioc-name));
spin_lock_irqsave(ioc-FreeQlock, flags);
if (!list_empty(ioc-FreeChainQ)) {
@@ -203,12 +203,12 @@ mptscsih_getFreeChainBuffer(MPT_ADAPTER
offset = (u8 *)chainBuf - (u8 *)ioc-ChainBuffer;
chain_idx = offset / ioc-req_sz;
rc = SUCCESS;
- dsgprintk((MYIOC_s_ERR_FMT getFreeChainBuffer chainBuf=%p
ChainBuffer=%p offset=%d chain_idx=%d\n,
+ dsgprintk(ioc, printk(MYIOC_s_DEBUG_FMT getFreeChainBuffer
chainBuf=%p ChainBuffer=%p offset=%d chain_idx=%d\n,
ioc-name, chainBuf, ioc-ChainBuffer, offset,
chain_idx));
} else {
rc = FAILED;
chain_idx = MPT_HOST_NO_CHAIN;
- dfailprintk((MYIOC_s_INFO_FMT getFreeChainBuffer failed\n,
+ dfailprintk(ioc, printk(MYIOC_s_DEBUG_FMT getFreeChainBuffer
failed\n,
ioc-name));
}
spin_unlock_irqrestore(ioc-FreeQlock, flags);
@@ -337,7 +337,7 @@ nextSGEset:
*/
pReq-ChainOffset = 0;
RequestNB = (((sgeOffset - 1) ioc-NBShiftFactor) +
1) 0x03;
- dsgprintk((MYIOC_s_INFO_FMT
+ dsgprintk(ioc, printk(MYIOC_s_DEBUG_FMT
Single Buffer RequestNB=%x, sgeOffset=%d\n,
ioc-name, RequestNB, sgeOffset));
ioc-RequestNB[req_idx] = RequestNB;
}
@@ -353,7 +353,7 @@ nextSGEset:
* Loop until done.
*/
- dsgprintk((MYIOC_s_INFO_FMT SG: Chain Required! sg done %d\n,
+ dsgprintk(ioc, printk(MYIOC_s_DEBUG_FMT SG: Chain Required! sg
done %d\n,
ioc-name, sg_done));
/* Set LAST_ELEMENT flag for last non-chain element
@@ -386,7 +386,7 @@ nextSGEset:
*/
pReq-ChainOffset = (u8) (sgeOffset 2);
RequestNB = (((sgeOffset - 1) ioc-NBShiftFactor) +
1) 0x03;
- dsgprintk((MYIOC_s_ERR_FMT Chain Buffer Needed,
RequestNB=%x sgeOffset=%d\n, ioc-name, RequestNB, sgeOffset));
+ dsgprintk(ioc, printk(MYIOC_s_DEBUG_FMT Chain Buffer
Needed, RequestNB=%x sgeOffset=%d\n, ioc-name, RequestNB, sgeOffset));
ioc-RequestNB[req_idx] = RequestNB;
}
@@ -397,7 +397,7 @@ nextSGEset:
* in current buffer. Get a chain buffer.
*/
if ((mptscsih_getFreeChainBuffer(ioc, newIndex)) == FAILED) {
- dfailprintk((MYIOC_s_INFO_FMT
+ dfailprintk(ioc, printk(MYIOC_s_DEBUG_FMT
getFreeChainBuffer FAILED SCSI cmd=%02x (%p)\n,
ioc-name, pReq-CDB[0], SCpnt));
return FAILED;
@@ -419,7 +419,7 @@ nextSGEset:
* out the Address and Flags fields.
*/
chainSge = (char *) psge;
- dsgprintk((KERN_INFO Current buff @ %p (index 0x%x),
+ dsgprintk(ioc, printk(KERN_DEBUG Current buff @ %p (index
0x%x),
psge, req_idx));
/* Start the SGE for the next buffer
@@ -428,7 +428,7 @@ nextSGEset:
sgeOffset = 0;
sg_done = 0;
- dsgprintk((KERN_INFO Chain buff @ %p (index 0x%x)\n,
+ dsgprintk(ioc, printk(KERN_DEBUG Chain buff @ %p (index
0x%x)\n,
psge, chain_idx));
/* Start the SGE for the next buffer
@@ -456,7 +456,7 @@ mptscsih_issue_sep_command(MPT_ADAPTER *
return;
if ((mf = mpt_get_msg_frame(ioc-InternalCtx, ioc)) == NULL) {
- dfailprintk((MYIOC_s_WARN_FMT %s: no msg frames!!\n,
+ dfailprintk(ioc, printk(MYIOC_s_WARN_FMT %s: no msg
frames!!\n,
ioc-name,__FUNCTION__));
return;
}
@@ -467,93 +467,158 @@
Re: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining
From: Boaz Harrosh [EMAIL PROTECTED] Subject: Re: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining Date: Tue, 24 Jul 2007 13:01:34 +0300 FUJITA Tomonori wrote: From: Boaz Harrosh [EMAIL PROTECTED] Subject: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining Date: Tue, 24 Jul 2007 11:47:50 +0300 As Jens said, there is nothing common to scsi_sgtable and sglists. Save the fact that it is a massive conflict at scsi-ml. They touch all the same places. Proposed is a simple way out. Two patchsets That produce the same output at the end. One: scsi_sgtable_than_sg-chaining Two: sg-chaining_than_scsi_sgtable Hmm, I thought that I've already posted a scsi_sgtable patch working with sg-chaining together. http://marc.info/?l=linux-scsim=118519987632758w=2 I quoted from my mail: --- I think that the main issue of integrating sgtable and sglist is how to put scatterlist to scsi_sgtable structure. If we allocate a scsi_sgtable structure and sglists separately, the code is pretty simple. But probably it's not the best way from the perspective of performance. I was just answering your other mail when this came in so I'll answer here. This Approach is exactly the scsi_data_buffer approach we both had solutions for. At the time I was all for that approach because it is safer and could be kept compatible to old drivers. (Less work for me) But it was decided against it. So suggesting it again is plain going back. Well, the approach to shuffle the entire request setup around was rejected. But was the approach to use two data buffers for bidi completely rejected? If we put sglists into the scsi_sgtable structure (like Boaz's patch does) and allocate and chain sglists only for large I/Os, we would have the better performance (especially for small I/Os). But we will have more complicated code. Only that my proposed solution is more simple more elegant and more robust than even Jens's solution without any sgtable at all. Actually the sgtable does good to chaining. scsi_lib with sglist+sgtable is smaller than Jens's sglist by itself. Your patch chains sgtables instead of sglists. It uses more memory for simple code. But I think that it's a nice approach. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] unexport sg v3 helper functions
Jens Axboe wrote: On Mon, Jul 23 2007, Douglas Gilbert wrote: Jens Axboe wrote: On Sun, Jul 22 2007, FUJITA Tomonori wrote: blk_fill_sghdr_rq, blk_unmap_sghdr_rq, and blk_complete_sghdr_rq were exported for bsg, however bsg was changed to support only sg v4. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] Acked-by: Jens Axboe [EMAIL PROTECTED] Why? The reasoning is right there, a few lines up - bsg doesn't support sg v3 commands. I can read. Why doesn't bsg support sg v3 commands? - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SCSI support broken in latest 2.4 kernel
On Tue, Jul 24, 2007 at 11:33:33AM +0300, Abdelrahman wrote: It seems impossible to compile the latest 2.4.35.6 kernel with the scsi_mod module and produce a usable system. I have used the attached config file and the normal compile procedure (make dep; make bzImage; make modules) and ended up with unloadable modules (unresolved symbols). I have tried both gcc 3.3 and 4.1. The same issue exists in at least 2.4.27 as well. Please advise if I can provide any further information which would aid in resolution. Which symbols? -- Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] unexport sg v3 helper functions
On Tue, Jul 24 2007, Douglas Gilbert wrote: Jens Axboe wrote: On Mon, Jul 23 2007, Douglas Gilbert wrote: Jens Axboe wrote: On Sun, Jul 22 2007, FUJITA Tomonori wrote: blk_fill_sghdr_rq, blk_unmap_sghdr_rq, and blk_complete_sghdr_rq were exported for bsg, however bsg was changed to support only sg v4. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] Acked-by: Jens Axboe [EMAIL PROTECTED] Why? The reasoning is right there, a few lines up - bsg doesn't support sg v3 commands. I can read. Then write better questions Why? isn't very useful. Why doesn't bsg support sg v3 commands? You should know, the discussion on that happened at the storage summit and on linux-scsi. It was decided to drop sg v3 support from bsg, and only focus on making bsg the driver for sg v4 commands. As you know, we already have dual paths for sg v3. For sg v4 we can get rid of that pain, and just have a single driver for handling that. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/3] ps3: Disk Storage Driver
Andrew Morton wrote: +start_sector = req-sector*priv-blocking_factor; +sectors = req-nr_sectors*priv-blocking_factor; s/*/ * /. checkpatch missed this. Ok, this is something we need to decide on. Currently we only ask for consistent spacing on all the mathematic operators. This is mostly as we do see a large number of non-spaced uses in defines and the like. I am happy to expand these tests so they are always spaced on both sides style if that is the preference. -apw - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/3] ps3: Disk Storage Driver
Andy Whitcroft wrote: Andrew Morton wrote: + start_sector = req-sector*priv-blocking_factor; + sectors = req-nr_sectors*priv-blocking_factor; s/*/ * /. checkpatch missed this. Ok, this is something we need to decide on. Currently we only ask for consistent spacing on all the mathematic operators. This is mostly as we do see a large number of non-spaced uses in defines and the like. I am happy to expand these tests so they are always spaced on both sides style if that is the preference. That is most definitely the preference: spaces surround operators. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/3] ps3: Disk Storage Driver
Jeff Garzik [EMAIL PROTECTED] writes: Andy Whitcroft wrote: Andrew Morton wrote: + start_sector = req-sector*priv-blocking_factor; + sectors = req-nr_sectors*priv-blocking_factor; s/*/ * /. checkpatch missed this. Ok, this is something we need to decide on. Currently we only ask for consistent spacing on all the mathematic operators. This is mostly as we do see a large number of non-spaced uses in defines and the like. I am happy to expand these tests so they are always spaced on both sides style if that is the preference. That is most definitely the preference: spaces surround operators. ^binary Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH AB1/5] SCSI: SG pools allocation cleanup.
Boaz Harrosh wrote:
First patch will not apply on scsi-misc-2.6 because there
is a missing NULL in the call to kmem_cache_create(). (linux-2.6.23-rcx)
(If any one need a patchset for that please ask)
It will have more problems if Jens's:
ac133644304cd1721dfb77193e0502f8afd4ea9b - scsi: simplify scsi_free_sgtable()
is not applied. any way here is an: over scsi-misc one.
Also A2/5 will have issues.
From 20f05cf739fc414033b4ca11e9f52e9f6d8db95b Mon Sep 17 00:00:00 2001
From: Boaz Harrosh [EMAIL PROTECTED]
Date: Mon, 23 Jul 2007 18:51:59 +0300
Subject: [PATCH] SCSI: SG pools allocation cleanup.
- The code Automatically calculates at compile time the
maximum size sg-array that will fit in a memory-page and will allocate
pools of BASE_2 size, up to that maximum size.
- split scsi_alloc() into an helper scsi_sgtable_index() that will return
the index of the pool for a given sg_count.
- Remove now unused SCSI_MAX_PHYS_SEGMENTS
- rename sglist_len to sg_pool which is what it always was.
- Some extra prints at scsi_init_queue(). These prints will be removed
once everything stabilizes.
Now that the Arrays are automatically calculated to fit in a page, what
about ARCH's that have a very big page size? I have, just for demonstration,
calculated upto 512 entries. But I suspect that other kernel-subsystems are
bounded to 256 or 128, is that true? should I allow more/less than 512 here?
some common numbers:
Arch | SCSI_MAX_SG_SEGMENTS = | sizeof(struct scatterlist)
--|-|---
x86_64| 128 |32
i386 CONFIG_HIGHMEM64G=y | 205 |20
i386 other| 256 |16
Could some one give example numbers of an ARCH with big page size?
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/scsi/scsi_lib.c | 140 +-
include/scsi/scsi.h |7 --
include/scsi/scsi_cmnd.h | 19 +-
3 files changed, 79 insertions(+), 87 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 1f5a07b..c065de5 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -29,40 +29,31 @@
#include scsi_priv.h
#include scsi_logging.h
-
-#define SG_MEMPOOL_NR ARRAY_SIZE(scsi_sg_pools)
#define SG_MEMPOOL_SIZE2
+/*
+ * Should fit within a single page.
+ */
+enum { SCSI_MAX_SG_SEGMENTS = (PAGE_SIZE / sizeof(struct scatterlist)) };
+
+enum { SG_MEMPOOL_NR =
+ (SCSI_MAX_SG_SEGMENTS = 8) +
+ (SCSI_MAX_SG_SEGMENTS = 16) +
+ (SCSI_MAX_SG_SEGMENTS = 32) +
+ (SCSI_MAX_SG_SEGMENTS = 64) +
+ (SCSI_MAX_SG_SEGMENTS = 128) +
+ (SCSI_MAX_SG_SEGMENTS = 256) +
+ (SCSI_MAX_SG_SEGMENTS = 512)
+};
+
struct scsi_host_sg_pool {
- size_t size;
- char*name;
+ unsignedsize;
struct kmem_cache *slab;
mempool_t *pool;
};
+static struct scsi_host_sg_pool scsi_sg_pools[SG_MEMPOOL_NR];
+
-#if (SCSI_MAX_PHYS_SEGMENTS 32)
-#error SCSI_MAX_PHYS_SEGMENTS is too small
-#endif
-
-#define SP(x) { x, sgpool- #x }
-static struct scsi_host_sg_pool scsi_sg_pools[] = {
- SP(8),
- SP(16),
- SP(32),
-#if (SCSI_MAX_PHYS_SEGMENTS 32)
- SP(64),
-#if (SCSI_MAX_PHYS_SEGMENTS 64)
- SP(128),
-#if (SCSI_MAX_PHYS_SEGMENTS 128)
- SP(256),
-#if (SCSI_MAX_PHYS_SEGMENTS 256)
-#error SCSI_MAX_PHYS_SEGMENTS is too large
-#endif
-#endif
-#endif
-#endif
-};
-#undef SP
static void scsi_run_queue(struct request_queue *q);
@@ -701,44 +692,32 @@ static struct scsi_cmnd *scsi_end_request(struct
scsi_cmnd *cmd, int uptodate,
return NULL;
}
+static unsigned scsi_sgtable_index(unsigned nents)
+{
+ int i, size;
+
+ for (i = 0, size = 8; i SG_MEMPOOL_NR-1; i++, size = 1)
+ if (size = nents)
+ return i;
+
+ if (SCSI_MAX_SG_SEGMENTS = nents)
+ return SG_MEMPOOL_NR-1;
+
+ printk(KERN_ERR scsi: bad segment count=%d\n, nents);
+ BUG();
+ return -1;
+}
+
struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd *cmd, gfp_t gfp_mask)
{
- struct scsi_host_sg_pool *sgp;
+ unsigned int pool = scsi_sgtable_index(cmd-use_sg);
struct scatterlist *sgl;
- BUG_ON(!cmd-use_sg);
-
- switch (cmd-use_sg) {
- case 1 ... 8:
- cmd-sglist_len = 0;
- break;
- case 9 ... 16:
- cmd-sglist_len = 1;
- break;
- case 17 ... 32:
- cmd-sglist_len = 2;
- break;
-#if (SCSI_MAX_PHYS_SEGMENTS 32)
- case 33 ... 64:
- cmd-sglist_len = 3;
- break;
-#if (SCSI_MAX_PHYS_SEGMENTS 64)
- case 65 ... 128:
- cmd-sglist_len = 4;
- break;
-#if
[PATCH RFC] qla2xxx: fix ignored size and offset parameters in qla2x00_sysfs_read_[nvram vpd]
From: Richard Lary [EMAIL PROTECTED]
This patch fixes Segmemtation fault which occurs when executing:
#udevinfo -a -p /sys/class/scsi_host/{qla2xxx_host}
The qla2xxx driver ignores the size and offset parameters when
reading nvram and vpd attributes.
Signed-off-by: Richard Lary [EMAIL PROTECTED]
---
Example:
looking at device '/class/scsi_host/host5':
KERNEL==host5
SUBSYSTEM==scsi_host
SYSFS{proc_name}==_NULL_
SYSFS{unchecked_isa_dma}==0
SYSFS{sg_tablesize}==255
SYSFS{cmd_per_lun}==3
SYSFS{host_busy}==0
SYSFS{unique_id}==0
SYSFS{beacon}==Disabled
SYSFS{zio_timer}==200 us
SYSFS{zio}==Disabled
SYSFS{state}==Link Up - F_Port
SYSFS{pci_info}==PCI-X Mode 1 _100 MHz_
SYSFS{model_desc}==IBM eServer BC 4Gb FC Expansion Card SFF
SYSFS{model_name}==QMC2462S
SYSFS{isp_id}==
SYSFS{isp_name}==ISP2422
SYSFS{serial_num}==N83786
SYSFS{fw_version}==4.00.26 _IP_
SYSFS{driver_version}==8.01.07-k3-rl
looking at device '/devices/pci:00/:00:01.0/:01:02.0/host5':
ID==host5
BUS==
DRIVER==
SYSFS{sfp}==
Segmentation fault
Applies to: scsi-misc-2.6.git
Index: b/drivers/scsi/qla2xxx/qla_attr.c
===
--- a/drivers/scsi/qla2xxx/qla_attr.c
+++ b/drivers/scsi/qla2xxx/qla_attr.c
@@ -87,17 +87,35 @@ qla2x00_sysfs_read_nvram(struct kobject
struct scsi_qla_host *ha = to_qla_host(dev_to_shost(container_of(kobj,
struct device, kobj)));
unsigned long flags;
+ int size = ha-nvram_size;
+ char *nvram_buf;
- if (!capable(CAP_SYS_ADMIN) || off != 0)
+ if (!capable(CAP_SYS_ADMIN) || off size)
return 0;
+ nvram_buf = (char *)vmalloc(size);
+ if (nvram_buf == NULL) {
+ qla_printk(KERN_WARNING, ha,
+ Unable to allocate memory for nvram retrieval
+ (%x).\n, size);
+
+ return 0;
+ }
+
+ if (off + count size) {
+ size -= off;
+ count = size;
+ }
+
/* Read NVRAM. */
spin_lock_irqsave(ha-hardware_lock, flags);
- ha-isp_ops.read_nvram(ha, (uint8_t *)buf, ha-nvram_base,
- ha-nvram_size);
+ ha-isp_ops.read_nvram(ha, (uint8_t *)nvram_buf, ha-nvram_base, size);
spin_unlock_irqrestore(ha-hardware_lock, flags);
- return ha-nvram_size;
+ memcpy(buf, nvram_buf[off], count);
+
+ vfree(nvram_buf);
+ return count;
}
static ssize_t
@@ -292,16 +310,35 @@ qla2x00_sysfs_read_vpd(struct kobject *k
struct scsi_qla_host *ha = to_qla_host(dev_to_shost(container_of(kobj,
struct device, kobj)));
unsigned long flags;
+ int size = ha-vpd_size;
+ char *vpd_buf;
- if (!capable(CAP_SYS_ADMIN) || off != 0)
+ if (!capable(CAP_SYS_ADMIN) || off size)
return 0;
+
+ vpd_buf = (char *)vmalloc(size);
+ if (vpd_buf == NULL) {
+ qla_printk(KERN_WARNING, ha,
+ Unable to allocate memory for vpd retrieval
+ (%x).\n, size);
+
+ return 0;
+ }
+
+ if (off + count size) {
+ size -= off;
+ count = size;
+ }
/* Read NVRAM. */
spin_lock_irqsave(ha-hardware_lock, flags);
- ha-isp_ops.read_nvram(ha, (uint8_t *)buf, ha-vpd_base, ha-vpd_size);
+ ha-isp_ops.read_nvram(ha, (uint8_t *)vpd_buf, ha-vpd_base, size);
spin_unlock_irqrestore(ha-hardware_lock, flags);
- return ha-vpd_size;
+ memcpy(buf, vpd_buf[off], count);
+
+ vfree(vpd_buf);
+ return count;
}
static ssize_t
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 regression: lpfc_sli.c: off-by-10
Adrian,
Thanks.
Syntax-wise, it is incorrect. However there's no risk. The datastructure
its indexing into is a union, and its size is sufficient for the index.
The union supports old and new firmware interfaces. We mistakenly used the
array for the old interface and should have used the (larger) array for
the newer interface.
We're posting a set of fixes later this week and will include the fix for
this.
-- james s
Adrian Bunk wrote:
The Coverity checker spotted the following off-by-10
in drivers/scsi/lpfc/lpfc_sli.c:
-- snip --
...
static int
lpfc_sli_process_unsol_iocb(struct lpfc_hba *phba, struct lpfc_sli_ring *pring,
struct lpfc_iocbq *saveq)
{
...
saveq-context3 = lpfc_sli_replace_hbqbuff(phba,
irsp-un.ulpWord[15]);
...
-- snip --
due to the following code in drivers/scsi/lpfc/lpfc_hw.h:
-- snip --
...
#define IOCB_WORD_SZ8
...
typedef struct _IOCB { /* IOCB structure */
...
uint32_t ulpWord[IOCB_WORD_SZ - 2]; /* generic 6 'words' */
...
-- snip --
cu
Adrian
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining
From: FUJITA Tomonori [EMAIL PROTECTED] Subject: Re: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining Date: Tue, 24 Jul 2007 20:12:47 +0900 From: Boaz Harrosh [EMAIL PROTECTED] Subject: Re: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining Date: Tue, 24 Jul 2007 13:01:34 +0300 FUJITA Tomonori wrote: From: Boaz Harrosh [EMAIL PROTECTED] Subject: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining Date: Tue, 24 Jul 2007 11:47:50 +0300 As Jens said, there is nothing common to scsi_sgtable and sglists. Save the fact that it is a massive conflict at scsi-ml. They touch all the same places. Proposed is a simple way out. Two patchsets That produce the same output at the end. One: scsi_sgtable_than_sg-chaining Two: sg-chaining_than_scsi_sgtable Hmm, I thought that I've already posted a scsi_sgtable patch working with sg-chaining together. http://marc.info/?l=linux-scsim=118519987632758w=2 I quoted from my mail: --- I think that the main issue of integrating sgtable and sglist is how to put scatterlist to scsi_sgtable structure. If we allocate a scsi_sgtable structure and sglists separately, the code is pretty simple. But probably it's not the best way from the perspective of performance. I was just answering your other mail when this came in so I'll answer here. This Approach is exactly the scsi_data_buffer approach we both had solutions for. At the time I was all for that approach because it is safer and could be kept compatible to old drivers. (Less work for me) But it was decided against it. So suggesting it again is plain going back. Well, the approach to shuffle the entire request setup around was rejected. But was the approach to use two data buffers for bidi completely rejected? I should have said that, was the approach to use separate buffer for sglists instead of putting the sglists and the parameters in one buffer completely rejected? - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/3] ps3: Disk Storage Driver
Andreas Schwab wrote: Jeff Garzik [EMAIL PROTECTED] writes: Andy Whitcroft wrote: Andrew Morton wrote: + start_sector = req-sector*priv-blocking_factor; + sectors = req-nr_sectors*priv-blocking_factor; s/*/ * /. checkpatch missed this. Ok, this is something we need to decide on. Currently we only ask for consistent spacing on all the mathematic operators. This is mostly as we do see a large number of non-spaced uses in defines and the like. I am happy to expand these tests so they are always spaced on both sides style if that is the preference. That is most definitely the preference: spaces surround operators. ^binary Yes. :) Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining
FUJITA Tomonori wrote: I should have said that, was the approach to use separate buffer for sglists instead of putting the sglists and the parameters in one buffer completely rejected? I think that James should be asked this question. My understanding was that he preferred allocating the sgtable header along with the scatterlist array. There are pro's and con's either way. In my opinion separating the headers is better for mapping buffers that have a power of 2 #pages (which seems to be the typical case) since when you're losing one entry in the sgtable for the header you'd waste a lot more when you just cross the bucket boundary. E.g. for 64 pages you need to allocate from the 64 to 127 bucket rather than the 33 to 64 bucket). Separated, one sgtable header structure can just be embedded in struct scsi_cmnd for uni-directional transfers (wasting some space when transferring no data, but saving space and cycles in the common case vs. allocating it from a separate memory pool) and the one for bidi read buffers can be allocated separately just for bidi commands. Benny - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/4] aha152x.c - Cleanup, need help in testing and auditing
On Tue, 24 Jul 2007 13:12:19 +0300 Boaz Harrosh wrote:
Randy Dunlap wrote:
I prefer either of the !HIGHMEM or slave_alloc changes to adding
a BUG_ON(). However, the SCSI people likely won't want to use the
slave_alloc() change because then the driver may never get fixed.
(Of course, it hasn't got fixed with the BUG happening either.)
Anyway, I'll re-read Documentation/DMA*.txt to see if I can fix it.
---
Hi Randy.
could you please send me the patch you have with the .slave_alloc
solution for now. I would like to revise the patchset and send them
for inclusion now. They do fix some problems and let users work.
We can put a big fat warring and explanation about highmem in the
commit log comments so people can watch out.
From: Randy Dunlap [EMAIL PROTECTED]
Cause highmem buffers to be bounced to low memory until this
driver supports highmem addresses. Otherwise it just oopses
on NULL buffer addresses.
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
drivers/scsi/aha152x.c |7 +++
1 file changed, 7 insertions(+)
--- linux-2622.orig/drivers/scsi/aha152x.c
+++ linux-2622/drivers/scsi/aha152x.c
@@ -3476,6 +3476,12 @@ static int aha152x_proc_info(struct Scsi
return thislength length ? thislength : length;
}
+static int aha152x_adjust_queue(struct scsi_device *device)
+{
+ blk_queue_bounce_limit(device-request_queue, BLK_BOUNCE_HIGH);
+ return 0;
+}
+
static struct scsi_host_template aha152x_driver_template = {
.module = THIS_MODULE,
.name = AHA152X_REVID,
@@ -3492,6 +3498,7 @@ static struct scsi_host_template aha152x
.sg_tablesize = SG_ALL,
.cmd_per_lun= 1,
.use_clustering = DISABLE_CLUSTERING,
+ .slave_alloc= aha152x_adjust_queue,
};
#if !defined(PCMCIA)
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] libsas: SMP request handler shouldn't crash when rphy is NULL
sas_smp_handler crashes when smp utils are used with an aic94xx host
because certain devices (the sas_host itself, specifically) lack rphy
structures. No rphy means no SMP target support, but we shouldn't crash
here.
Signed-off-by: Darrick J. Wong [EMAIL PROTECTED]
---
drivers/scsi/libsas/sas_expander.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/libsas/sas_expander.c
b/drivers/scsi/libsas/sas_expander.c
index b500f0c..8603ae6 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -1879,7 +1879,7 @@ int sas_smp_handler(struct Scsi_Host *shost, struct
sas_rphy *rphy,
struct request *req)
{
struct domain_device *dev;
- int ret, type = rphy-identify.device_type;
+ int ret, type;
struct request *rsp = req-next_rq;
if (!rsp) {
@@ -1888,12 +1888,13 @@ int sas_smp_handler(struct Scsi_Host *shost, struct
sas_rphy *rphy,
return -EINVAL;
}
- /* seems aic94xx doesn't support */
+ /* no rphy means no smp target support (ie aic94xx host) */
if (!rphy) {
printk(%s: can we send a smp request to a host?\n,
__FUNCTION__);
return -EINVAL;
}
+ type = rphy-identify.device_type;
if (type != SAS_EDGE_EXPANDER_DEVICE
type != SAS_FANOUT_EXPANDER_DEVICE) {
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining
On Tue, 2007-07-24 at 17:01 +0300, Benny Halevy wrote: FUJITA Tomonori wrote: I should have said that, was the approach to use separate buffer for sglists instead of putting the sglists and the parameters in one buffer completely rejected? I think that James should be asked this question. My understanding was that he preferred allocating the sgtable header along with the scatterlist array. All I really cared about was insulating the drivers from future changes in this area. It strikes me that for chained sglist implementations, this can all become a block layer responsibility, since more than SCSI will want to make use of it. Just remember, though that whatever is picked has to work in both memory constrained embedded systems as well as high end clusters. It seems to me (but this isn't a mandate) that a single tunable sg element chunk size will accomplish this the best (as in get rid of the entire SCSI sglist sizing machinery) . However, I'm perfectly happy to go with whatever the empirical evidence says is best .. and hopefully, now we don't have to pick this once and for all time ... we can alter it if whatever is chosen proves to be suboptimal. There are pro's and con's either way. In my opinion separating the headers is better for mapping buffers that have a power of 2 #pages (which seems to be the typical case) since when you're losing one entry in the sgtable for the header you'd waste a lot more when you just cross the bucket boundary. E.g. for 64 pages you need to allocate from the 64 to 127 bucket rather than the 33 to 64 bucket). Separated, one sgtable header structure can just be embedded in struct scsi_cmnd for uni-directional transfers (wasting some space when transferring no data, but saving space and cycles in the common case vs. allocating it from a separate memory pool) and the one for bidi read buffers can be allocated separately just for bidi commands. This is all opinion ... could someone actually run some performance tests? James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/3] ps3: Disk Storage Driver
On Tue, 24 Jul 2007 08:37:09 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: Andy Whitcroft wrote: Andrew Morton wrote: + start_sector = req-sector*priv-blocking_factor; + sectors = req-nr_sectors*priv-blocking_factor; s/*/ * /. checkpatch missed this. Ok, this is something we need to decide on. Currently we only ask for consistent spacing on all the mathematic operators. This is mostly as we do see a large number of non-spaced uses in defines and the like. I am happy to expand these tests so they are always spaced on both sides style if that is the preference. That is most definitely the preference: spaces surround operators. I must say that I find it hard to object to start = radix_tree_next_hole(mapping-page_tree, offset, max+1); but when the expression is more complex the spaces help. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Enable 16-bit CDBs for aic7xxx/aic79xxx
On Mon, 2007-07-23 at 10:47 +0200, Hannes Reinecke wrote: Hi James, this patch enables 16-bit CDBs for aic7xxx and aic79xx. aic7xxx actuallys supports up to 32-bit CDBs, so it might be that aic79xx does that, too. But this would include some more hacking, so this is way easier. Please apply. Cheers, Hannes plain text document attachment (aic7xxx-enable-16byte-cdbs) Enable 16-bit CDBs for aic7xxx/aix79xx The patch enables support for 16-bit CDBs in aic7xxx and aic79xx. aic7xxx can actually support up to 32-bit CDBs, should they ever see the light of day. Signed-off-by: Hannes Reinecke [EMAIL PROTECTED] diff --git a/drivers/scsi/aic7xxx/aic79xx_osm.c b/drivers/scsi/aic7xxx/aic79xx_osm.c index 286ab83..8502085 100644 --- a/drivers/scsi/aic7xxx/aic79xx_osm.c +++ b/drivers/scsi/aic7xxx/aic79xx_osm.c @@ -1089,6 +1089,7 @@ ahd_linux_register_host(struct ahd_softc *ahd, struct scsi_host_template *templa host-max_id = (ahd-features AHD_WIDE) ? 16 : 8; host-max_lun = AHD_NUM_LUNS; host-max_channel = 0; + host-max_cmd_len = MAX_CDB_LEN; If aic79xx only supports 16 byte CDBs without modification, shouldn't this be set to 16? MAX_CDB_LEN could easily end up being patched to be larger and then aic79xx would be in trouble. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: QLGC,ISP SCSI driver not finding attached devices
Hi all, Timing does not apear to be an issue. I have checked all the udelay/msleep calls I could find and thoes that get called are delaying by the correct delay (4 to 7us specified value). I have added some more debugging info and it looks like somthing is getting corrupted in the INQUIRY command as it is returning: Sense Key : Illegal Request [current] Add. Sense: Invalid field in cdb According a of the SCSI2 Std that I have, this equates to one of the following: EVPD set and Vital Product Data not supported EVPD clear and Page Code non-zero Control Field Flag set and Link not set Looking into the issue a bit further, it turns out the the Sparc32 memset is broaken - it does not always set the last byte. As a result, the Control Field is set to random value (0xE0 in this case). This explains all sorts of odd issues. Next step is to fix memset. I will try again once I am sure memset is working. Regards Mark Fortescue. On Mon, 23 Jul 2007, James Bottomley wrote: On Mon, 2007-07-23 at 23:41 +0100, Mark Fortescue wrote: Hi James, Can you point me in the direction of any documentation to aid me in identifing what debugging I need to work out what is going on? they're all in include/scsi/scsi.h The code is divided into four bytes (from LSB): status, message, host and driver. The status is what the SCSI command actually returned (if anything) the message is what the transport said (least used of the status codes). The host byte signals an error condition with the card and the driver byte with the driver (plus an optional suggestion of what to do about it). For targets without any connected disk, I get scan responses of: scsi scan: INQUIRY failed with code 0x4 after app 417ms. That's host byte 0x04 which is DID_BAD_TARGET. For targets with a disk connected, I get scan responses of: scsi scan: INQUIRY failed with code 0x802 after app 170ms. Thats SCSI status 0x02 (which is CHECK_CONDITION) and driver byte of 0x08, which is DRIVER_SENSE (as in the device returned a sense code). This is really strange, because the INQUIRY command isn't supposed to be allowed to return a sense code for precisely this initial scan reason. This tends to point to a device failure. James - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: QLGC,ISP SCSI driver not finding attached devices
From: Mark Fortescue [EMAIL PROTECTED]
Date: Tue, 24 Jul 2007 18:46:06 +0100 (BST)
Looking into the issue a bit further, it turns out the the Sparc32 memset
is broaken - it does not always set the last byte. As a result, the
Control Field is set to random value (0xE0 in this case). This explains
all sorts of odd issues. Next step is to fix memset. I will try again once
I am sure memset is working.
There was a memset() fix posted recently which I am merging soon.
Subject: [PATCH 2.4.25] sparc32: fix bug in sparc optimized memset
From: root [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Date: Thu, 19 Jul 2007 20:07:22 +0400
Sender: David S. Miller [EMAIL PROTECTED]
User-Agent: Mutt/1.5.15 (2007-04-06)
Fake-Sender:[EMAIL PROTECTED]
Sparc optimized memset (arch/sparc/lib/memset.S) does not fill last byte of the
memory area,
if area size is less than 8 bytes and start address is not word (4-bytes)
aligned,
Recent Linux kernels have same memset.S and affected by this bug too.
Here is code chunk where bug located:
/* %o0 - memory address, %o1 - size, %g3 - value */
8:
add%o0, 1, %o0
subcc%o1, 1, %o1
bne,a8b
stb %g3, [%o0 - 1]
This code should write byte every loop iteration, but last time delay
instruction stb is not
executed because branch instruction sets annul bit.
Patch replaces bne,a by bne instruction.
Error can be reproduced by simple kernel module:
#include linux/module.h
#include linux/config.h
#include linux/kernel.h
#include linux/errno.h
#include string.h
static void do_memset(void **p, int size)
{
memset(p, 0x00, size);
}
static int __init memset_test_init(void)
{
char fooc[8];
int *fooi;
memset(fooc, 0xba, sizeof(fooc));
do_memset((void**)(fooc + 3), 1);
fooi = (int*) fooc;
printk(%08X %08X\n, fooi[0], fooi[1]);
return -1;
}
static void __exit memset_test_cleanup(void)
{
return;
}
module_init(memset_test_init);
module_exit(memset_test_cleanup);
MODULE_LICENSE(GPL);
EXPORT_NO_SYMBOLS;
Signed-off-by: Alexander Shmelev [EMAIL PROTECTED]
---
--- linux-2.4.25-orig/arch/sparc/lib/memset.S 2003-11-28 21:26:19.0
+0300
+++ linux-2.4.25/arch/sparc/lib/memset.S2007-07-19 18:56:05.0
+0400
@@ -163,7 +163,7 @@
8:
add%o0, 1, %o0
subcc %o1, 1, %o1
- bne,a 8b
+ bne 8b
EX(stb %g3, [%o0 - 1], add %o1, 1)
0:
retl
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] qla2xxx: fix ignored size and offset parameters in qla2x00_sysfs_read_[nvram vpd]
Richard A Lary wrote:
From: Richard Lary [EMAIL PROTECTED]
This patch fixes Segmemtation fault which occurs when executing:
#udevinfo -a -p /sys/class/scsi_host/{qla2xxx_host}
The qla2xxx driver ignores the size and offset parameters when
reading nvram and vpd attributes.
Thank you for finding the problem.
Please find comments below.
Updated patch will be followed, soon.
Thank you,
Seokmann
Signed-off-by: Richard Lary [EMAIL PROTECTED]
---
Example:
looking at device '/class/scsi_host/host5':
KERNEL==host5
SUBSYSTEM==scsi_host
SYSFS{proc_name}==_NULL_
SYSFS{unchecked_isa_dma}==0
SYSFS{sg_tablesize}==255
SYSFS{cmd_per_lun}==3
SYSFS{host_busy}==0
SYSFS{unique_id}==0
SYSFS{beacon}==Disabled
SYSFS{zio_timer}==200 us
SYSFS{zio}==Disabled
SYSFS{state}==Link Up - F_Port
SYSFS{pci_info}==PCI-X Mode 1 _100 MHz_
SYSFS{model_desc}==IBM eServer BC 4Gb FC Expansion Card SFF
SYSFS{model_name}==QMC2462S
SYSFS{isp_id}==
SYSFS{isp_name}==ISP2422
SYSFS{serial_num}==N83786
SYSFS{fw_version}==4.00.26 _IP_
SYSFS{driver_version}==8.01.07-k3-rl
looking at device '/devices/pci:00/:00:01.0/:01:02.0/host5':
ID==host5
BUS==
DRIVER==
SYSFS{sfp}==
Segmentation fault
Applies to: scsi-misc-2.6.git
Index: b/drivers/scsi/qla2xxx/qla_attr.c
===
--- a/drivers/scsi/qla2xxx/qla_attr.c
+++ b/drivers/scsi/qla2xxx/qla_attr.c
@@ -87,17 +87,35 @@ qla2x00_sysfs_read_nvram(struct kobject
struct scsi_qla_host *ha = to_qla_host(dev_to_shost(container_of(kobj,
struct device, kobj)));
unsigned long flags;
+ int size = ha-nvram_size;
+ char *nvram_buf;
- if (!capable(CAP_SYS_ADMIN) || off != 0)
+ if (!capable(CAP_SYS_ADMIN) || off size)
return 0;
+ nvram_buf = (char *)vmalloc(size);
+ if (nvram_buf == NULL) {
+ qla_printk(KERN_WARNING, ha,
+ Unable to allocate memory for nvram retrieval
+ (%x).\n, size);
+
+ return 0;
+ }
IMO, as given buf is valid address which can be accessed by the driver, extra
vmalloc() is not necessary.
+
+ if (off + count size) {
+ size -= off;
+ count = size;
+ }
Before this check, it would be good to check 'if count == 0' and return 0.
+
/* Read NVRAM. */
spin_lock_irqsave(ha-hardware_lock, flags);
- ha-isp_ops.read_nvram(ha, (uint8_t *)buf, ha-nvram_base,
- ha-nvram_size);
+ ha-isp_ops.read_nvram(ha, (uint8_t *)nvram_buf, ha-nvram_base, size);
spin_unlock_irqrestore(ha-hardware_lock, flags);
- return ha-nvram_size;
+ memcpy(buf, nvram_buf[off], count);
+
+ vfree(nvram_buf);
As vmalloc(), memcpy() and vfree() also are not necessary.
+ return count;
}
static ssize_t
@@ -292,16 +310,35 @@ qla2x00_sysfs_read_vpd(struct kobject *k
struct scsi_qla_host *ha = to_qla_host(dev_to_shost(container_of(kobj,
struct device, kobj)));
unsigned long flags;
+ int size = ha-vpd_size;
+ char *vpd_buf;
- if (!capable(CAP_SYS_ADMIN) || off != 0)
+ if (!capable(CAP_SYS_ADMIN) || off size)
return 0;
Also, check if count == 0 and return 0 if so.
+ vpd_buf = (char *)vmalloc(size);
+ if (vpd_buf == NULL) {
+ qla_printk(KERN_WARNING, ha,
+ Unable to allocate memory for vpd retrieval
+ (%x).\n, size);
+
+ return 0;
+ }
Same here, extra memory allocation is not required.
+ if (off + count size) {
+ size -= off;
+ count = size;
+ }
/* Read NVRAM. */
spin_lock_irqsave(ha-hardware_lock, flags);
- ha-isp_ops.read_nvram(ha, (uint8_t *)buf, ha-vpd_base, ha-vpd_size);
+ ha-isp_ops.read_nvram(ha, (uint8_t *)vpd_buf, ha-vpd_base, size);
spin_unlock_irqrestore(ha-hardware_lock, flags);
- return ha-vpd_size;
+ memcpy(buf, vpd_buf[off], count);
+
+ vfree(vpd_buf);
Same here, as vmalloc(), memcpy() and vfree() are not necessary.
+ return count;
}
static ssize_t
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: QLGC,ISP SCSI driver not finding attached devices
Hi David and James,
Thank you for your help in investigating the issues I have been having.
I thought I rememberd seeing somthing about memset.
Having changed the memset code, I have found that the ESP scsi BUS
Timeout can be reverted back to 250ms. Both SCSI drivers are now working
properly both built in and as modules.
Tomorows task is to see if I can get my floppy disk changes to work (my
SS1 has an 82077, not an 82072 and it is not sun4m compatible).
Regards
Mark Fortescue.
On Tue, 24 Jul 2007, David Miller wrote:
From: Mark Fortescue [EMAIL PROTECTED]
Date: Tue, 24 Jul 2007 18:46:06 +0100 (BST)
Looking into the issue a bit further, it turns out the the Sparc32 memset
is broaken - it does not always set the last byte. As a result, the
Control Field is set to random value (0xE0 in this case). This explains
all sorts of odd issues. Next step is to fix memset. I will try again once
I am sure memset is working.
There was a memset() fix posted recently which I am merging soon.
Subject: [PATCH 2.4.25] sparc32: fix bug in sparc optimized memset
From: root [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Date: Thu, 19 Jul 2007 20:07:22 +0400
Sender: David S. Miller [EMAIL PROTECTED]
User-Agent: Mutt/1.5.15 (2007-04-06)
Fake-Sender:[EMAIL PROTECTED]
Sparc optimized memset (arch/sparc/lib/memset.S) does not fill last byte of the
memory area,
if area size is less than 8 bytes and start address is not word (4-bytes)
aligned,
Recent Linux kernels have same memset.S and affected by this bug too.
Here is code chunk where bug located:
/* %o0 - memory address, %o1 - size, %g3 - value */
8:
add%o0, 1, %o0
subcc%o1, 1, %o1
bne,a8b
stb %g3, [%o0 - 1]
This code should write byte every loop iteration, but last time delay
instruction stb is not
executed because branch instruction sets annul bit.
Patch replaces bne,a by bne instruction.
Error can be reproduced by simple kernel module:
#include linux/module.h
#include linux/config.h
#include linux/kernel.h
#include linux/errno.h
#include string.h
static void do_memset(void **p, int size)
{
memset(p, 0x00, size);
}
static int __init memset_test_init(void)
{
char fooc[8];
int *fooi;
memset(fooc, 0xba, sizeof(fooc));
do_memset((void**)(fooc + 3), 1);
fooi = (int*) fooc;
printk(%08X %08X\n, fooi[0], fooi[1]);
return -1;
}
static void __exit memset_test_cleanup(void)
{
return;
}
module_init(memset_test_init);
module_exit(memset_test_cleanup);
MODULE_LICENSE(GPL);
EXPORT_NO_SYMBOLS;
Signed-off-by: Alexander Shmelev [EMAIL PROTECTED]
---
--- linux-2.4.25-orig/arch/sparc/lib/memset.S 2003-11-28 21:26:19.0
+0300
+++ linux-2.4.25/arch/sparc/lib/memset.S2007-07-19 18:56:05.0
+0400
@@ -163,7 +163,7 @@
8:
add%o0, 1, %o0
subcc %o1, 1, %o1
- bne,a 8b
+ bne 8b
EX(stb %g3, [%o0 - 1], add %o1, 1)
0:
retl
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: QLGC,ISP SCSI driver not finding attached devices
From: Mark Fortescue [EMAIL PROTECTED] Date: Tue, 24 Jul 2007 22:28:42 +0100 (BST) I thought I rememberd seeing somthing about memset. Having changed the memset code, I have found that the ESP scsi BUS Timeout can be reverted back to 250ms. Both SCSI drivers are now working properly both built in and as modules. Thanks Mark. What I'll do is merge in the sparc32 memset() fix then, once that is in, send James a patch to revert the ESP bus timeout back down to 250. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] mpt fusion: Changes in mptscsih.c for logging support
On Tuesday, July 24, 2007 4:31 AM, Boaz Harrosh wrote: NACK This driver was already converted to accessors please don't use old (going a way soon) scsi_cmnd members directly Sathya - a little background on this. I believe this all started with the Proposals to change the way all drivers work with SCSI commands email from James Bottomley back on May 11th. here: http://marc.info/?t=11789086433r=1w=2. The fusion driver was ported by FUJITA Tomonori in this patch http://marc.info/?l=linux-scsim=117896437623559w=2. So the bottomline, is anywere we access the scsi_cmnd pointer in the debug prints, needs to be ported using the new wrappers (in scsi_cmnd.h). Can you please review and repost? Thanks, Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] qla4xxx: use mempool_create_slab_pool
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/qla4xxx/ql4_os.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c
index e69160a..15ff730 100644
--- a/drivers/scsi/qla4xxx/ql4_os.c
+++ b/drivers/scsi/qla4xxx/ql4_os.c
@@ -576,8 +576,7 @@ static int qla4xxx_mem_alloc(struct scsi_qla_host *ha)
QUEUE_SIZE));
/* Allocate memory for srb pool. */
- ha-srb_mempool = mempool_create(SRB_MIN_REQ, mempool_alloc_slab,
-mempool_free_slab, srb_cachep);
+ ha-srb_mempool = mempool_create_slab_pool(SRB_MIN_REQ, srb_cachep);
if (ha-srb_mempool == NULL) {
dev_warn(ha-pdev-dev,
Memory Allocation failed - SRB Pool.\n);
--
1.5.2.4
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mptsas: add SMP passthrough support via bsg
From: Moore, Eric [EMAIL PROTECTED] Subject: RE: [PATCH 3/3] mptsas: add SMP passthrough support via bsg Date: Tue, 24 Jul 2007 18:22:08 -0600 On Monday, July 23, 2007 11:28 PM, FUJITA Tomonori wrote: With 2.6.23-rc1 + mptsas smp patch, you get directories /sys/class/bsg like: I hadn't enabled bsg support in the linux kernel, that was my problem. What do you mean? You might hit the bug that you can't build scsi as a modular. It was fixed before rc1. # ./sgv4-tools/smp_rep_manufacturer /sys/class/bsg/expander-0:1 I think that James tested this with aic94xx, however, I guess that nobody has tested this with mptsas. I got garbage (I'm using the 2.6.23-git11 patch from last week, before rc1): # ./smp_rep_manufacturer /sys/class/bsg/expander-2:0 SAS-1.1 format: 1 vendor identification: _BUS_ADD product identification: RESS=unix:abstra product revision level: ct=/ component vendor identification: tmp/dbus component id: 11609 component revision level: 69 With Doug Gilberts tools it works: # smp_rep_manufacturer --sa=0x500605b016b0 /dev/mptctl Report manufacturer response: SAS-1.1 format: 0 vendor identification: LSILOGIC product identification: SASx12 A.0 product revision level: Also, unloading and reloading the driver resulted in two expander entryies in /sys/class/bsg.The old entry was not deleted when I unloaded the driver. When I tryied to run smp_rep_manufacture on the old expander instance, it panicked. I forgot to remove bsg entries. James fixed the bug. Please try 2.6.23-rc1. But probably, the tool still don't work against an expander. Does it work against the Virtual SMP Port? I'm not sure what the intent of this else case. This code is for an invisible SMP target in LSI SAS HBAs. There are better ways to get the target's address, I think. Any suggestions? I've never heard that we(as in LSI) are attaching invisable SMP targets to HBA's. I've seen the Virtual SMP Port, but those are not hidden, the driver would report them to the transport layer, therefore rphy should be non-zero. I just used Doug's word, invisible SMP target. For instance a 12 phy expander would have 13 phys(with the last being the virtual phy). I doubt we need to have this else case in the code, as it will be returning the sas_address to the first attached device(which may not always be an expander).Are you executing the else path? I guess so. If I do: ./sgv4-tools/smp_rep_manufacturer /sys/class/bsg/sas_host0 I hit the else path (check sas_bsg_initialize in scsi_transport_sas.c). Yeah, I guess that it would be better to send mpt's smpReply to user space then user-space tools can examine it. You know, That's what mpt ioctl and Doug' smp_utils do. But we can't use the in-buffer for this since it's used for the smp response. We could use sense buffer for this. there is no sense data associated to a SMP request.there is response-data, but that is something else. Yeah, I know. I just said we can't use the in-buffer for mpt's smpReply. I'm not sure rather it would be good idea to send the smp_reply back up the stack, as this data would be unique only to fusion. In the reply, there is ioc_status, loginfo, and sas_status. With this info, you can determine how to process the SMP request. The sas_status defines are located at the top of mpi_sas.h (look for Values of SASStatus). ioc_status is in mpi.h (look for MPI_IOCSTATUS_XXX), and loginfo is defined in mpi_log_sas.h. Oh, I thought that LSI wants to send the smp_reply back to user space since Doug's smp-utils does. But If you don't want, I'll just put the response check code that you suggested in the previous mail. Thanks, - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/3] ps3: Disk Storage Driver
Andy Whitcroft writes: Ok, this is something we need to decide on. Currently we only ask for consistent spacing on all the mathematic operators. This is mostly as we do see a large number of non-spaced uses in defines and the like. I am happy to expand these tests so they are always spaced on both sides style if that is the preference. It depends very much on the context - on the precedence and relative importance of one operator with respect to other operators and the statement as a whole. In general I prefer spaces around binary operators, but there are situations where not putting spaces around some operators can enhance the readability of the statement as a whole. If checkpatch.pl starts whinging about operators without spaces that will just be yet another reason not to use it IMHO. Also, I prefer the style where the ? and : operators have a space after them but not before them, rather than a space either side. Paul. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 8366] aic79xx and aic7xxx driver issues
On Tue, 2007-07-24 at 18:05 -0700, [EMAIL PROTECTED] wrote: -- (http://bugzilla.kernel.org/attachment.cgi?id=12126action=view) failed driver dmesg This driver fails at time of boot up. there are many scsi errors shown in the output. It is the new aic7xxx driver. This is about the most significant line (scsi0:A:3:0): parity error detected in Data-in phase. SEQADDR(0x84) SCSIRATE(0x80) The SCSIRATE indicates wide. I'd bet this is a narrow device; in which case, does echo 0 /sys/class/spi_transport/target0:0:3/max_wide and then triggering a revalidate with echo 1 /sys/class/spi_transport/target0:0:3/revalidate produce anything different? James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mptsas: add SMP passthrough support via bsg
From: Moore, Eric [EMAIL PROTECTED] Subject: RE: [PATCH 3/3] mptsas: add SMP passthrough support via bsg Date: Tue, 24 Jul 2007 18:22:08 -0600 I'm not sure what the intent of this else case. This code is for an invisible SMP target in LSI SAS HBAs. There are better ways to get the target's address, I think. Any suggestions? I've never heard that we(as in LSI) are attaching invisable SMP targets to HBA's. I've seen the Virtual SMP Port, but those are not hidden, the driver would report them to the transport layer, therefore rphy should be non-zero. For instance a 12 phy expander would have 13 phys(with the last being the virtual phy). I doubt we need to have this else case in the code, as it will be returning the sas_address to the first attached device(which may not always be an expander).Are you executing the else path? In the else path, I try to get the virtual phy's address. That is, I try to do what sas_low_phy_scandir_select() in Doug's lsscsi tool does. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] mpt fusion: Changes in mptscsih.c for logging support
Resubmitting the patch with the following change:
In function mptscsih_info_scsiio(), the bufflen and resid fields of the
Scsi_cmnd structure were accessed directly in the previous patch.
In this modified patch data accessor functions are used to access those fields.
signed-off-by: Sathya Prakash [EMAIL PROTECTED]
---
diff -Naurp b/drivers/message/fusion/mptscsih.c
a/drivers/message/fusion/mptscsih.c
--- b/drivers/message/fusion/mptscsih.c 2007-07-23 14:24:35.0 +0530
+++ a/drivers/message/fusion/mptscsih.c 2007-07-25 10:49:11.0 +0530
@@ -191,7 +191,7 @@ mptscsih_getFreeChainBuffer(MPT_ADAPTER
int rc;
int chain_idx;
- dsgprintk((MYIOC_s_INFO_FMT getFreeChainBuffer called\n,
+ dsgprintk(ioc, printk(MYIOC_s_DEBUG_FMT getFreeChainBuffer called\n,
ioc-name));
spin_lock_irqsave(ioc-FreeQlock, flags);
if (!list_empty(ioc-FreeChainQ)) {
@@ -203,12 +203,12 @@ mptscsih_getFreeChainBuffer(MPT_ADAPTER
offset = (u8 *)chainBuf - (u8 *)ioc-ChainBuffer;
chain_idx = offset / ioc-req_sz;
rc = SUCCESS;
- dsgprintk((MYIOC_s_ERR_FMT getFreeChainBuffer chainBuf=%p
ChainBuffer=%p offset=%d chain_idx=%d\n,
+ dsgprintk(ioc, printk(MYIOC_s_DEBUG_FMT getFreeChainBuffer
chainBuf=%p ChainBuffer=%p offset=%d chain_idx=%d\n,
ioc-name, chainBuf, ioc-ChainBuffer, offset,
chain_idx));
} else {
rc = FAILED;
chain_idx = MPT_HOST_NO_CHAIN;
- dfailprintk((MYIOC_s_INFO_FMT getFreeChainBuffer failed\n,
+ dfailprintk(ioc, printk(MYIOC_s_DEBUG_FMT getFreeChainBuffer
failed\n,
ioc-name));
}
spin_unlock_irqrestore(ioc-FreeQlock, flags);
@@ -337,7 +337,7 @@ nextSGEset:
*/
pReq-ChainOffset = 0;
RequestNB = (((sgeOffset - 1) ioc-NBShiftFactor) +
1) 0x03;
- dsgprintk((MYIOC_s_INFO_FMT
+ dsgprintk(ioc, printk(MYIOC_s_DEBUG_FMT
Single Buffer RequestNB=%x, sgeOffset=%d\n,
ioc-name, RequestNB, sgeOffset));
ioc-RequestNB[req_idx] = RequestNB;
}
@@ -353,7 +353,7 @@ nextSGEset:
* Loop until done.
*/
- dsgprintk((MYIOC_s_INFO_FMT SG: Chain Required! sg done %d\n,
+ dsgprintk(ioc, printk(MYIOC_s_DEBUG_FMT SG: Chain Required! sg
done %d\n,
ioc-name, sg_done));
/* Set LAST_ELEMENT flag for last non-chain element
@@ -386,7 +386,7 @@ nextSGEset:
*/
pReq-ChainOffset = (u8) (sgeOffset 2);
RequestNB = (((sgeOffset - 1) ioc-NBShiftFactor) +
1) 0x03;
- dsgprintk((MYIOC_s_ERR_FMT Chain Buffer Needed,
RequestNB=%x sgeOffset=%d\n, ioc-name, RequestNB, sgeOffset));
+ dsgprintk(ioc, printk(MYIOC_s_DEBUG_FMT Chain Buffer
Needed, RequestNB=%x sgeOffset=%d\n, ioc-name, RequestNB, sgeOffset));
ioc-RequestNB[req_idx] = RequestNB;
}
@@ -397,7 +397,7 @@ nextSGEset:
* in current buffer. Get a chain buffer.
*/
if ((mptscsih_getFreeChainBuffer(ioc, newIndex)) == FAILED) {
- dfailprintk((MYIOC_s_INFO_FMT
+ dfailprintk(ioc, printk(MYIOC_s_DEBUG_FMT
getFreeChainBuffer FAILED SCSI cmd=%02x (%p)\n,
ioc-name, pReq-CDB[0], SCpnt));
return FAILED;
@@ -419,7 +419,7 @@ nextSGEset:
* out the Address and Flags fields.
*/
chainSge = (char *) psge;
- dsgprintk((KERN_INFO Current buff @ %p (index 0x%x),
+ dsgprintk(ioc, printk(KERN_DEBUG Current buff @ %p (index
0x%x),
psge, req_idx));
/* Start the SGE for the next buffer
@@ -428,7 +428,7 @@ nextSGEset:
sgeOffset = 0;
sg_done = 0;
- dsgprintk((KERN_INFO Chain buff @ %p (index 0x%x)\n,
+ dsgprintk(ioc, printk(KERN_DEBUG Chain buff @ %p (index
0x%x)\n,
psge, chain_idx));
/* Start the SGE for the next buffer
@@ -456,7 +456,7 @@ mptscsih_issue_sep_command(MPT_ADAPTER *
return;
if ((mf = mpt_get_msg_frame(ioc-InternalCtx, ioc)) == NULL) {
- dfailprintk((MYIOC_s_WARN_FMT %s: no msg frames!!\n,
+ dfailprintk(ioc, printk(MYIOC_s_WARN_FMT %s: no msg
frames!!\n,
ioc-name,__FUNCTION__));
return;
}
@@ -467,93 +467,158 @@ mptscsih_issue_sep_command(MPT_ADAPTER *
SEPMsg-TargetID
Re: unexpected scsi timeout
Vasily Averin wrote: Tejun Heo wrote: [cc'ing Albert] Vasily Averin wrote: Tejun, Jeff I've noticed that some scsi commands for DVD-drive attached to pata_via successfully finishes without any delays but reports about TIMEOUT condition. It happens because of ATA_ERR bit is set in status register. As result for each command Error Handler thread awakened, requests sense buffer and go to sleep again. Need more info. Please post boot dmesg and the result of 'lspci -nn' and 'hdparm -I /dev/srX' and when such errors occur. It was 2.6.22 kernel with pata_via and sata_via drivers, scsi and cdrom debug was temporally enabled via sysctl (please see logs near Jul 24 13:42:46 timestamp) Btw. I'm not sure that it was an error, I've looked on the sources and IMHO it's normal command processing cdrom without disk inserted into drive. I've checked 2.6.19, 2.6.20 and 2.6.22 kernels and got the same behavior. Hi Vasily, Your log looks ok. It's normal for TEST_UNIT_READY to return ATA_ERR when no disc inside and libata EH triggered to request sense. -- albert - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
