[PATCH 3/5] add sg segment limitation info to device structure
iommu code merges sg segments without considering lld's sg segment
restrictions. iommu code can't access to the limitations because they
are in request_queue. This patch adds max_segment_size to device
structure. seg_boundary_mask will be added too later.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
include/linux/device.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index 3a38d1f..8046b60 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -443,6 +443,13 @@ struct device {
struct dma_coherent_mem *dma_mem; /* internal for coherent mem
override */
+
+ /*
+* a low level driver may set these to teach IOMMU code about
+* sg limitations.
+*/
+ unsigned int max_segment_size;
+
/* arch specific additions */
struct dev_archdata archdata;
--
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
[PATCH 5/5] x86-64: pci-gart iommu uses max_segment_size
This enables pci-gart iommu to merge sg lists properly about lld's max
segment size limit.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
arch/x86_64/kernel/pci-gart.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c
index 4918c57..be98341 100644
--- a/arch/x86_64/kernel/pci-gart.c
+++ b/arch/x86_64/kernel/pci-gart.c
@@ -381,6 +381,7 @@ int gart_map_sg(struct device *dev, struct scatterlist *sg,
int nents, int dir)
int start;
unsigned long pages = 0;
int need = 0, nextneed;
+ unsigned len;
if (nents == 0)
return 0;
@@ -390,6 +391,7 @@ int gart_map_sg(struct device *dev, struct scatterlist *sg,
int nents, int dir)
out = 0;
start = 0;
+ len = 0;
for (i = 0; i nents; i++) {
struct scatterlist *s = sg[i];
dma_addr_t addr = page_to_phys(s-page) + s-offset;
@@ -404,16 +406,20 @@ int gart_map_sg(struct device *dev, struct scatterlist
*sg, int nents, int dir)
/* Can only merge when the last chunk ends on a page
boundary and the new one doesn't have an offset. */
if (!iommu_merge || !nextneed || !need || s-offset ||
+ (dev-max_segment_size
+dev-max_segment_size s-length + len) ||
(ps-offset + ps-length) % PAGE_SIZE) {
if (dma_map_cont(sg, start, i, sg+out, pages,
need) 0)
goto error;
out++;
+ len = 0;
pages = 0;
start = i;
}
}
+ len += s-length;
need = nextneed;
pages += to_pages(s-offset, s-length);
}
--
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
[PATCH 2/5] sata_inic162x: use dma_max_segment_size in scsi_host_template
This removes blk_queue_max_segment_size and uses dma_max_segment_size
in scsi_host_template.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/ata/sata_inic162x.c | 19 +++
1 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/ata/sata_inic162x.c b/drivers/ata/sata_inic162x.c
index fdbed8e..ae3590f 100644
--- a/drivers/ata/sata_inic162x.c
+++ b/drivers/ata/sata_inic162x.c
@@ -108,17 +108,11 @@ struct inic_port_priv {
u8 cached_pirq_mask;
};
-static int inic_slave_config(struct scsi_device *sdev)
-{
- /* This controller is braindamaged. dma_boundary is 0x
-* like others but it will lock up the whole machine HARD if
-* 65536 byte PRD entry is fed. Reduce maximum segment size.
-*/
- blk_queue_max_segment_size(sdev-request_queue, 65536 - 512);
-
- return ata_scsi_slave_config(sdev);
-}
-
+/*
+ * This controller is braindamaged. dma_boundary is 0x
+ * like others but it will lock up the whole machine HARD if
+ * 65536 byte PRD entry is fed. Reduce maximum segment size.
+ */
static struct scsi_host_template inic_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
@@ -132,7 +126,8 @@ static struct scsi_host_template inic_sht = {
.use_clustering = ATA_SHT_USE_CLUSTERING,
.proc_name = DRV_NAME,
.dma_boundary = ATA_DMA_BOUNDARY,
- .slave_configure= inic_slave_config,
+ .dma_max_segment_size = 65536 - 512,
+ .slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
};
--
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
[PATCH 4/5] scsi_add_host sets device max_segment_size
scsi_add_host sets shost_gendev.parent-max_segment_size to enables iommu code to merge sg lists properly about lld's max segment size limit. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- drivers/scsi/hosts.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c index 22877d3..a71a836 100644 --- a/drivers/scsi/hosts.c +++ b/drivers/scsi/hosts.c @@ -206,6 +206,9 @@ int scsi_add_host(struct Scsi_Host *shost, struct device *dev) if (!shost-shost_gendev.parent) shost-shost_gendev.parent = dev ? dev : platform_bus; + if (dev) + dev-max_segment_size = shost-dma_max_segment_size; + error = device_add(shost-shost_gendev); if (error) goto out; -- 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
[PATCH 0/5] fix iommu sg list merge problem
iommu code merges sg lists without considering lld's restrictions so some llds need a workaround to split sg lists again. This patchset fixes iommu to handle lld's max segment size limit properly. The problem is that iommu code can't access to the restrictions because they are in request_queue. iommu code can access to only device structure. I chose the simplest approach, adding max_segment_size to device structure. We could remove the lld restrictions in request_queue strucutre and have a new strucutre (something like struct io_restrictions). Then somehow we could link the new structure with request_queue and device strucutres. But iommu needs only max_segment_size and seg_boundary_mask, so the simplest approach is not so bad, I think. scsi_add_host sets shost_gendev.parent-max_segment_size for iommu code (copied form shost-dma_max_segment_size). This patchset includes only the x86_64 iommu patch but my git tree includes x86_64, ppc, ia64, parisc, and alpha patches. As far as I know, thye are all the iommu code that merges sg lists. The iommu patchse are only compile tested. git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git iommu 3 llds, aacraid, scsi_debug, and sata_inic162x sets shost-dma_max_segment_size in slave_configure hook. But dma_max_segment_size is a lld restriction. I adds dma_max_segment_size to scsi_host_template and scsi_host. llds specify dma_max_segment_size in scsi_host_template, scsi-ml sets dma_max_segment_size in devices and call blk_queue_max_segment_size. This patchset includes only the sata_inic162x patch but all the patches for llds, aacraid and scsi_debug are in the git tree. - 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] add dma_max_segment_size option to scsi_host_template
This patch moves blk_queue_max_segment_size to scsi_alloc_queue from
llds. It enables scsi_add_host to tells iommu lld's
dma_max_segment_size. If a low-level driver doesn't specify
dma_max_segment_size, scsi-ml uses 65536 (MAX_SEGMENT_SIZE). So there
are not any functional changes.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/hosts.c |5 +
drivers/scsi/scsi_lib.c |1 +
include/scsi/scsi_host.h |6 ++
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index 96bc312..22877d3 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -365,6 +365,11 @@ struct Scsi_Host *scsi_host_alloc(struct
scsi_host_template *sht, int privsize)
else
shost-dma_boundary = 0x;
+ if (sht-dma_max_segment_size)
+ shost-dma_max_segment_size = sht-dma_max_segment_size;
+ else
+ shost-dma_max_segment_size = 65536;
+
rval = scsi_setup_command_freelist(shost);
if (rval)
goto fail_kfree;
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index a417a6f..2ec77a9 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1564,6 +1564,7 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host
*shost,
blk_queue_max_sectors(q, shost-max_sectors);
blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
blk_queue_segment_boundary(q, shost-dma_boundary);
+ blk_queue_max_segment_size(q, shost-dma_max_segment_size);
if (!shost-use_clustering)
clear_bit(QUEUE_FLAG_CLUSTER, q-queue_flags);
diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
index 3b8a6a8..1eb8435 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -383,6 +383,11 @@ struct scsi_host_template {
unsigned long dma_boundary;
/*
+* dma scatter gather segment size limit.
+*/
+ unsigned int dma_max_segment_size;
+
+ /*
* This specifies machine infinity for host templates which don't
* limit the transfer size. Note this limit represents an absolute
* maximum, and may be over the transfer limits allowed for
@@ -571,6 +576,7 @@ struct Scsi_Host {
short unsigned int sg_tablesize;
short unsigned int max_sectors;
unsigned long dma_boundary;
+ unsigned int dma_max_segment_size;
/*
* Used to assign serial numbers to the cmds.
* Protected by the host lock.
--
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 1/5] add dma_max_segment_size option to scsi_host_template
On Wed, 26 Sep 2007 06:11:45 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: FUJITA Tomonori wrote: This patch moves blk_queue_max_segment_size to scsi_alloc_queue from llds. It enables scsi_add_host to tells iommu lld's dma_max_segment_size. If a low-level driver doesn't specify dma_max_segment_size, scsi-ml uses 65536 (MAX_SEGMENT_SIZE). So there are not any functional changes. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- drivers/scsi/hosts.c |5 + drivers/scsi/scsi_lib.c |1 + include/scsi/scsi_host.h |6 ++ 3 files changed, 12 insertions(+), 0 deletions(-) hm... All the patches look technically correct, but IMO this really should behave more the the dma_mask interface: platform sets a sane dma_mask (usually 0x), and LLDD calls dma_set_mask() or pci_set_dma_mask(). Thus, IMO an LLDD should call dma_set_max_seg(), and then SCSI midlayer can obtain that value from struct device. Yeah, I agreed that max_segment_size should work like dma_mask (that's why I simply put max_segment_size to device structure). scsi_debug doesn't use dma but calls blk_queue_max_segment_size (I guess that it wants large I/Os). If we can remove it (thanks to chaining sg), scsi-ml gets that value that llds set via dma_set_max_seg and calls blk_queue_max_segment_size. - 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/5] fix iommu sg list merge problem
On Wed, 26 Sep 2007 12:02:21 +0200 Muli Ben-Yehuda [EMAIL PROTECTED] wrote: On Wed, Sep 26, 2007 at 05:57:57PM +0900, FUJITA Tomonori wrote: iommu code merges sg lists without considering lld's restrictions so some llds need a workaround to split sg lists again. This patchset fixes iommu to handle lld's max segment size limit properly. The patches look reasonable to me. This patchset includes only the x86_64 iommu patch There are multiple x86-64 IOMMUs, but only GART is in-tree and supports merging. but my git tree includes x86_64, ppc, ia64, parisc, and alpha patches. As far as I know, thye are all the iommu code that merges sg lists. The iommu patchse are only compile tested. git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git iommu Do you think it will be possible to abstract the merging code into common code, rather than duplicating it for every IOMMU? Yeah, I thought about it and it's possible (but not so easy). parisc has IOMMU merging helper code and two parisc IOMMUs use it. ia64 sba_iommu is almost identical to parisc code. x86_64 gart, power, and alpha do in their own way. But I think that we can merging helper code useful for all. I'll see what we can have after fixing the mering problem. - 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/5] fix iommu sg list merge problem
On Wed, 26 Sep 2007 09:38:32 -0500 James Bottomley [EMAIL PROTECTED] wrote: On Wed, 2007-09-26 at 23:34 +0900, FUJITA Tomonori wrote: Yeah, I thought about it and it's possible (but not so easy). parisc has IOMMU merging helper code and two parisc IOMMUs use it. ia64 sba_iommu is almost identical to parisc code. x86_64 gart, power, and alpha do in their own way. But I think that we can merging helper code useful for all. Er ... it should be identical ... the SBA iommu is the same ... I thought we moved the common code out to a shared file. 2.6.23-rc8-mm1 has two iommu_coalesce_chunks in drivers/iommu-helpers.h and arch/ioa64/hp/common/sb_iommu.c iommu_coalesce_chunks are almost same. parisc's iommu_coalesce_chunks is simpler a bit. - 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] add sg segment limitation info to device structure
On Wed, 26 Sep 2007 09:05:58 -0700
Greg KH [EMAIL PROTECTED] wrote:
On Wed, Sep 26, 2007 at 05:58:01PM +0900, FUJITA Tomonori wrote:
iommu code merges sg segments without considering lld's sg segment
restrictions. iommu code can't access to the limitations because they
are in request_queue. This patch adds max_segment_size to device
structure. seg_boundary_mask will be added too later.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
include/linux/device.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index 3a38d1f..8046b60 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -443,6 +443,13 @@ struct device {
struct dma_coherent_mem *dma_mem; /* internal for coherent mem
override */
+
+ /*
+* a low level driver may set these to teach IOMMU code about
+* sg limitations.
+*/
+ unsigned int max_segment_size;
Does this really need to be here? Can't it go into the bus specific
device that needs this?
dma_map_sg() is bus specific? I think that this really need to
be. It needs to work like dma_mask in device structure.
-
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/5] add dma_max_segment_size option to scsi_host_template
On Wed, 26 Sep 2007 10:42:06 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
FUJITA Tomonori wrote:
On Wed, 26 Sep 2007 06:11:45 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
FUJITA Tomonori wrote:
This patch moves blk_queue_max_segment_size to scsi_alloc_queue from
llds. It enables scsi_add_host to tells iommu lld's
dma_max_segment_size. If a low-level driver doesn't specify
dma_max_segment_size, scsi-ml uses 65536 (MAX_SEGMENT_SIZE). So there
are not any functional changes.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/hosts.c |5 +
drivers/scsi/scsi_lib.c |1 +
include/scsi/scsi_host.h |6 ++
3 files changed, 12 insertions(+), 0 deletions(-)
hm... All the patches look technically correct, but IMO this really
should behave more the the dma_mask interface: platform sets a sane
dma_mask (usually 0x), and LLDD calls dma_set_mask() or
pci_set_dma_mask().
Thus, IMO an LLDD should call dma_set_max_seg(), and then SCSI midlayer
can obtain that value from struct device.
Yeah, I agreed that max_segment_size should work like dma_mask (that's
why I simply put max_segment_size to device structure).
Yep!
scsi_debug doesn't use dma but calls blk_queue_max_segment_size (I
guess that it wants large I/Os). If we can remove it (thanks to
chaining sg), scsi-ml gets that value that llds set via
dma_set_max_seg and calls blk_queue_max_segment_size.
[/me checks the code] Actually scsi_debug has its own pseudo-bus and
struct device, so it sounds like scsi_debug can call dma_set_max_seg()
just like any other LLDD?
You are right. scsi_debug's pseudo-bus works.
But probabaly, scsi_debug doesn't need to call
blk_queue_max_segment_size now.
Maybe dev_set_max_seg() is a better name, if people get really picky (I
don't care).
How about dma_set_max_seg_size()?
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index a417a6f..7adadfb 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1554,6 +1554,7 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host
*shost,
request_fn_proc *request_fn)
{
struct request_queue *q;
+ struct device *dev = shost-shost_gendev.parent;
q = blk_init_queue(request_fn, NULL);
if (!q)
@@ -1565,6 +1566,9 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host
*shost,
blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
blk_queue_segment_boundary(q, shost-dma_boundary);
+ if (dev-max_segment_size)
+ blk_queue_max_segment_size(q, dev-max_segment_size);
+
if (!shost-use_clustering)
clear_bit(QUEUE_FLAG_CLUSTER, q-queue_flags);
return q;
diff --git a/include/linux/device.h b/include/linux/device.h
index 3a38d1f..8046b60 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -443,6 +443,13 @@ struct device {
struct dma_coherent_mem *dma_mem; /* internal for coherent mem
override */
+
+ /*
+* a low level driver may set these to teach IOMMU code about
+* sg limitations.
+*/
+ unsigned int max_segment_size;
+
/* arch specific additions */
struct dev_archdata archdata;
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 2dc21cb..30404b8 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -31,6 +31,11 @@ static inline int valid_dma_direction(int dma_direction)
(dma_direction == DMA_FROM_DEVICE));
}
+static inline void dma_set_max_seg_size(struct device *dev, unsigned int size)
+{
+ dev-max_segment_size = size;
+}
+
#ifdef CONFIG_HAS_DMA
#include asm/dma-mapping.h
#else
-
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: queued patches for SCSI for 2.6.24
On Tue, 25 Sep 2007 20:42:35 -0500 James Bottomley [EMAIL PROTECTED] wrote: On Wed, 2007-09-26 at 10:28 +0900, FUJITA Tomonori wrote: On Tue, 25 Sep 2007 20:00:02 -0500 James Bottomley [EMAIL PROTECTED] wrote: Andrew asked that I provide a status report of pending updates. The list is attached below. It's pretty much driver updates and minor bug fixes. The main functionality changes are Kay's sysfs updates and the shift of the ULD attachement towards the block prep function. Can we make new 'supporrted_mode' and 'active_mode' attributes look better? http://marc.info/?l=linux-scsim=118991196128245w=2 Sure, but Jeff's suggestion was a good one to avoid me having to change hundreds of files. Could you roll it up and resubmit? This can be cleanly applied to scsi-misc. - From: FUJITA Tomonori [EMAIL PROTECTED] Subject: [PATCH] set supported_mode to MODE_INITIATOR by default This sets supported_mode to MODE_INITIATOR if a lld doesn't specify supported_mode in scsi_host_template. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- drivers/scsi/hosts.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c index adc9559..694015d 100644 --- a/drivers/scsi/hosts.c +++ b/drivers/scsi/hosts.c @@ -342,6 +342,10 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int privsize) shost-unchecked_isa_dma = sht-unchecked_isa_dma; shost-use_clustering = sht-use_clustering; shost-ordered_tag = sht-ordered_tag; + + if (!sht-supported_mode) + sht-supported_mode = MODE_INITIATOR; + shost-active_mode = sht-supported_mode; if (sht-max_host_blocked) -- 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: queued patches for SCSI for 2.6.24
On Tue, 25 Sep 2007 22:37:33 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: FUJITA Tomonori wrote: diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c index adc9559..694015d 100644 --- a/drivers/scsi/hosts.c +++ b/drivers/scsi/hosts.c @@ -342,6 +342,10 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int privsize) shost-unchecked_isa_dma = sht-unchecked_isa_dma; shost-use_clustering = sht-use_clustering; shost-ordered_tag = sht-ordered_tag; + + if (!sht-supported_mode) + sht-supported_mode = MODE_INITIATOR; + shost-active_mode = sht-supported_mode; I almost hesitate to speak up, after making the original suggestion, but: Are there any const-ness worries for scsi_host_template, or plans for the future? I do not see any other examples of the host template members getting modified. Yeah, that's why I said it's hacky in the previous discussion. Changing scsi_host_template behind llds is not nice, I think. Perhaps this value should instead be mirrored in scsi_host, like many others? supported_mode should be static like 'name'. I'm not sure about having supported_mode in scsi_host. All the scsi_hosts of one driver always use the same supported_mode value unlike active_mode. - 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: queued patches for SCSI for 2.6.24
On Tue, 25 Sep 2007 22:45:53 -0500 James Bottomley [EMAIL PROTECTED] wrote: On Tue, 2007-09-25 at 23:34 -0400, Jeff Garzik wrote: Matthew Wilcox wrote: On Tue, Sep 25, 2007 at 10:37:33PM -0400, Jeff Garzik wrote: Are there any const-ness worries for scsi_host_template, or plans for the future? I do not see any other examples of the host template members getting modified. Goodness, Jeff, you haven't looked too hard. There's dozens of examples I've come across trawling the horrible unmaintained drivers. I'd love to see scsi_host_template become const, but it's not happening any time soon, and we can address this little piece when the time comes. Well, sure, the driver is the owner of that memory. We're talking about common code. If everybody agrees SHT is R/W in the core, Fujita-san's patch is fine. Well, I don't like mucking with the template either. This whole mess is generated basically because the zero default of the template should be treated as initiator. How about this, which makes that manifest? But how can we handle dual-mode drivers? luce:/sys/class/scsi_host/host0$ cat supported_mode Initiator, Target The values are not enumerated. They are like FC_PORT_ROLE. - 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: queued patches for SCSI for 2.6.24
On Tue, 25 Sep 2007 23:01:53 -0500 James Bottomley [EMAIL PROTECTED] wrote: On Wed, 2007-09-26 at 12:55 +0900, FUJITA Tomonori wrote: On Tue, 25 Sep 2007 22:45:53 -0500 James Bottomley [EMAIL PROTECTED] wrote: On Tue, 2007-09-25 at 23:34 -0400, Jeff Garzik wrote: Matthew Wilcox wrote: On Tue, Sep 25, 2007 at 10:37:33PM -0400, Jeff Garzik wrote: Are there any const-ness worries for scsi_host_template, or plans for the future? I do not see any other examples of the host template members getting modified. Goodness, Jeff, you haven't looked too hard. There's dozens of examples I've come across trawling the horrible unmaintained drivers. I'd love to see scsi_host_template become const, but it's not happening any time soon, and we can address this little piece when the time comes. Well, sure, the driver is the owner of that memory. We're talking about common code. If everybody agrees SHT is R/W in the core, Fujita-san's patch is fine. Well, I don't like mucking with the template either. This whole mess is generated basically because the zero default of the template should be treated as initiator. How about this, which makes that manifest? But how can we handle dual-mode drivers? luce:/sys/class/scsi_host/host0$ cat supported_mode Initiator, Target The values are not enumerated. They are like FC_PORT_ROLE. Any driver that does other than the default INITIATOR has to set it in the template. The code only defaults zero (which is what the templates get if its unset) to MODE_INITIATOR. Oh yeah, the patch is fine. I just wanted to say that supported_mode/active_mode are designed not to be enumerated and we can't just set INITIATOR to zero and TARGET to non-zero. - 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: queued patches for SCSI for 2.6.24
On Tue, 25 Sep 2007 22:45:53 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Tue, 2007-09-25 at 23:34 -0400, Jeff Garzik wrote:
Matthew Wilcox wrote:
On Tue, Sep 25, 2007 at 10:37:33PM -0400, Jeff Garzik wrote:
Are there any const-ness worries for scsi_host_template, or plans for
the future? I do not see any other examples of the host template
members getting modified.
Goodness, Jeff, you haven't looked too hard. There's dozens of examples
I've come across trawling the horrible unmaintained drivers. I'd love
to see scsi_host_template become const, but it's not happening any time
soon, and we can address this little piece when the time comes.
Well, sure, the driver is the owner of that memory.
We're talking about common code.
If everybody agrees SHT is R/W in the core, Fujita-san's patch is fine.
Well, I don't like mucking with the template either.
This whole mess is generated basically because the zero default of the
template should be treated as initiator. How about this, which makes
that manifest?
James
diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index adc9559..7e26440 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -342,7 +342,11 @@ struct Scsi_Host *scsi_host_alloc(struct
scsi_host_template *sht, int privsize)
shost-unchecked_isa_dma = sht-unchecked_isa_dma;
shost-use_clustering = sht-use_clustering;
shost-ordered_tag = sht-ordered_tag;
- shost-active_mode = sht-supported_mode;
+ if (sht-supported_mode == MODE_UNKNOWN)
+ /* means we didn't set it ... default to INITIATOR */
+ shost-active_mode = MODE_INITIATOR;
+ else
+ shost-active_mode = sht-supported_mode;
if (sht-max_host_blocked)
shost-max_host_blocked = sht-max_host_blocked;
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 0088c4d..4965e9e 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -209,11 +209,13 @@ show_shost_mode(unsigned int mode, char *buf)
static ssize_t show_shost_supported_mode(struct class_device *class_dev,
char *buf)
{
struct Scsi_Host *shost = class_to_shost(class_dev);
+ unsigned int supported_mode = shost-hostt-supported_mode;
- if (shost-hostt-supported_mode == MODE_UNKNOWN)
- return snprintf(buf, 20, unknown\n);
- else
- return show_shost_mode(shost-hostt-supported_mode, buf);
+ if (supported_mode == MODE_UNKNOWN)
+ /* by default this should be initiator */
+ supported_mode = MODE_INITIATOR;
+
+ return show_shost_mode(shost-hostt-supported_mode, buf);
should be:
return show_shost_mode(supported_mode, buf);
static CLASS_DEVICE_ATTR(supported_mode, S_IRUGO | S_IWUSR,
show_shost_supported_mode, NULL);
-
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: What's in linux-2.6-block.git for 2.6.24
On Sun, 23 Sep 2007 15:19:13 +0200
Torsten Kaiser [EMAIL PROTECTED] wrote:
On 9/21/07, Jens Axboe [EMAIL PROTECTED] wrote:
SG chaining bits:
- This is the bulk of the patchset. It consists of three major
components:
- sglist-core, which add helpers for iterating sg lists and
switches the block layer and SCSI to use those. Should not
have any functional changes.
- sglist-drivers, which converts drivers to use the sg list
helpers. Again, should not contain functional changes.
- sglist-arch, which adds support to most architectures and
actually enables sg chaining.
Adding linux-ide and linux-scsi as CC like Andrew did with my last report.
I still have trouble with my Silicon Image, Inc. SiI 3132 Serial ATA
Raid II Controller as reported on 2.6.23-rc4-mm1 on the new
2.6.23-rc6-mm1.
I'm not 100% sure if this caused by the sg chaining, but the patch
from http://lkml.org/lkml/2007/9/10/251 which touches that chaining
makes a difference, so it might be related.
First report: http://lkml.org/lkml/2007/9/1/92
With patch it fails fewer times: http://lkml.org/lkml/2007/9/14/107
To update the statistik:
prior to 2.6.23-rc4-mm1: no trouble with any drives on the SiI 3132.
2.6.23-rc4-mm1 without patch: 2 out of 2 bad.
back to 2.6.23-rc3-mm1: 18x good.
2.6.23-rc4-mm1 with patch: 2 out of 8 bad
after that second mail:
2.6.23-rc4-mm1 with patch: 1 out of 5 bad
2.6.23-rc6-mm1: 1 out of 2 bad
git-block.patch in 2.6.23-rc6-mm1 includes my patch that disables sg
chaining for libata but it still includes libata's sg chaining
changes. So these changes breaks libata or libata was broken after
2.6.23-rc3-mm1.
Can you try Jens's sglist-arch branch? If it works, probably libata in
-mm has bugs.
For your convenience, I put a sglist-arch branch patch against v2.6.23-rc7:
http://www.kernel.org/pub/linux/kernel/people/tomo/misc/v2.6.23-rc7-sglist-arch.diff.bz2
switching back to 2.6.23-rc3-mm1 to rule out the hardware:
2.6.23-rc3-mm1: 6x good
The error messages from the failed 2.6.23-rc6-mm1:
Sep 18 18:50:01 treogen [ 33.34] md1: bitmap initialized from
disk: read 10/10 pages, set 0 bits
Sep 18 18:50:01 treogen [ 33.34] created bitmap (145 pages) for device
md1
Sep 18 18:50:01 treogen [ 63.44] ata1.00: exception Emask 0x0
SAct 0x1 SErr 0x0 action 0x6 frozen
Sep 18 18:50:01 treogen [ 63.44] ata1.00: cmd
61/08:00:09:d6:42/00:00:25:00:00/40 tag 0 cdb 0x0 data 4096 out
Sep 18 18:50:01 treogen [ 63.44] res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Sep 18 18:50:01 treogen [ 63.44] ata1.00: status: {DRDY }
Sep 18 18:50:01 treogen [ 63.44] ata1: hard resetting link
Sep 18 18:50:01 treogen [ 65.74] ata1: softreset failed (port not ready)
Sep 18 18:50:01 treogen [ 65.74] ata1: reset failed (errno=-5),
retrying in 8 secs
Sep 18 18:50:01 treogen [ 73.44] ata1: hard resetting link
Sep 18 18:50:01 treogen [ 75.74] ata1: softreset failed (port not ready)
Sep 18 18:50:01 treogen [ 75.74] ata1: reset failed (errno=-5),
retrying in 8 secs
Sep 18 18:50:01 treogen [ 83.44] ata1: hard resetting link
Sep 18 18:50:01 treogen [ 85.74] ata1: softreset failed (port not ready)
Sep 18 18:50:01 treogen [ 85.74] ata1: reset failed (errno=-5),
retrying in 33 secs
Sep 18 18:50:01 treogen [ 118.44] ata1: limiting SATA link speed
to 1.5 Gbps
Sep 18 18:50:01 treogen [ 118.44] ata1: hard resetting link
Sep 18 18:50:01 treogen [ 120.74] ata1: softreset failed (port not ready)
Sep 18 18:50:01 treogen [ 120.74] ata1: reset failed, giving up
Sep 18 18:50:01 treogen [ 120.74] ata1.00: disabled
Sep 18 18:50:01 treogen [ 120.74] ata1: EH complete
Sep 18 18:50:01 treogen [ 120.74] sd 0:0:0:0: [sda] Result:
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Sep 18 18:50:01 treogen [ 120.74] end_request: I/O error, dev
sda, sector 625137161
Sep 18 18:50:01 treogen [ 120.74] md: super_written gets
error=-5, uptodate=0
Sep 18 18:50:01 treogen [ 120.74] raid5: Disk failure on sda2,
disabling device. Operation continuing on 2 devices
After that many more errors like this, only differing in the sector number:
Sep 18 18:50:01 treogen [ 120.81] sd 0:0:0:0: [sda] Result:
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Sep 18 18:50:01 treogen [ 120.81] end_request: I/O error, dev
sda, sector 19550919
Any more infos needed?
Torsten
-
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: 2.6.23-rc4-mm1
On Tue, 18 Sep 2007 12:18:40 +0200 Jens Axboe [EMAIL PROTECTED] wrote: On Mon, Sep 17 2007, FUJITA Tomonori wrote: On Mon, 17 Sep 2007 15:28:19 +0200 Jens Axboe [EMAIL PROTECTED] wrote: On Sat, Sep 15 2007, FUJITA Tomonori wrote: On Fri, 14 Sep 2007 21:16:35 -0700 Paul Jackson [EMAIL PROTECTED] wrote: FUJITA Tomonori wrote: Can you try this patch (against 2.6.23-rc4-mm1)? From 592bd2049cb3e6e1f1dde7cf631879f26ddffeaa Mon Sep 17 00:00:00 2001 From: FUJITA Tomonori [EMAIL PROTECTED] Date: Mon, 10 Sep 2007 04:17:13 +0100 Subject: [PATCH] qla1280: sg chaining fixes Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- drivers/scsi/qla1280.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) This patch works for me. I was getting the scsi errors reported earlier in this thread, running 2.6.23-rc4-mm1 on one of our big SGI Altix systems. Applying this patch fixed it, so far as I can tell, which is to say my system boots cleanly once again. Thanks for testing! Jens, we could enable use_sg_chaining option for qla1280. Added, thanks! Thanks. BTW, please don't forget to integrate the following patches: - revert sg segment size ifdefs http://marc.info/?l=linux-scsim=118881264013097w=2 - remove sglist_len http://marc.info/?l=linux-scsim=118907920405100w=2 Added, and I rebased the sglist-* branches to current again. So everything should be fully uptodate once more. Thanks, here are a few more things. - please drop the iscsi patch since Mike has major changes to iscsi I/O path. - ipr sg chaining need to be disabled since libata is not ready. - you can add Doug's ACK to scsi_debug patch: http://marc.info/?l=linux-scsim=118926325931801w=2 - 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-rc4-mm1
On Mon, 17 Sep 2007 15:28:19 +0200 Jens Axboe [EMAIL PROTECTED] wrote: On Sat, Sep 15 2007, FUJITA Tomonori wrote: On Fri, 14 Sep 2007 21:16:35 -0700 Paul Jackson [EMAIL PROTECTED] wrote: FUJITA Tomonori wrote: Can you try this patch (against 2.6.23-rc4-mm1)? From 592bd2049cb3e6e1f1dde7cf631879f26ddffeaa Mon Sep 17 00:00:00 2001 From: FUJITA Tomonori [EMAIL PROTECTED] Date: Mon, 10 Sep 2007 04:17:13 +0100 Subject: [PATCH] qla1280: sg chaining fixes Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- drivers/scsi/qla1280.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) This patch works for me. I was getting the scsi errors reported earlier in this thread, running 2.6.23-rc4-mm1 on one of our big SGI Altix systems. Applying this patch fixed it, so far as I can tell, which is to say my system boots cleanly once again. Thanks for testing! Jens, we could enable use_sg_chaining option for qla1280. Added, thanks! Thanks. BTW, please don't forget to integrate the following patches: - revert sg segment size ifdefs http://marc.info/?l=linux-scsim=118881264013097w=2 - remove sglist_len http://marc.info/?l=linux-scsim=118907920405100w=2 - 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 16/22] advansys: Eliminate prototypes
On Sun, 16 Sep 2007 09:31:34 -0600
Matthew Wilcox [EMAIL PROTECTED] wrote:
On Sat, Sep 15, 2007 at 09:39:05AM -0500, James Bottomley wrote:
I get a compile failure at this point in your patch sequence:
Thanks. I'd been compiling with CONFIG_ISA=n, so hadn't spotted these
two problems. I've set it back to Y now.
If I compile your latest patchset with CONFIG_ISA=n, I got:
drivers/built-in.o: In function `advansys_init':
advansys.c:(.init.text+0x3edc): undefined reference to `isa_register_driver'
advansys.c:(.init.text+0x3efb): undefined reference to `isa_register_driver'
advansys.c:(.init.text+0x3f22): undefined reference to `isa_unregister_driver'
advansys.c:(.init.text+0x3f36): undefined reference to `isa_unregister_driver'
drivers/built-in.o: In function `advansys_exit':
advansys.c:(.exit.text+0x210): undefined reference to `isa_unregister_driver'
advansys.c:(.exit.text+0x21a): undefined reference to `isa_unregister_driver'
make[1]: *** [.tmp_vmlinux1] Error 1
make[1]: Leaving directory `/home/fujita/git/linux-2.6'
make: *** [debian/stamp-build-kernel] Error 2
Is this already fixed like this?
-
From: FUJITA Tomonori [EMAIL PROTECTED]
Subject: [PATCH] isa: add fake isa_register_driver and isa_unregister_driver
add fake isa_register_driver and isa_unregister_driver for !CONFIG_ISA
case.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
include/linux/isa.h | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/include/linux/isa.h b/include/linux/isa.h
index 1b85533..6d3aaaf 100644
--- a/include/linux/isa.h
+++ b/include/linux/isa.h
@@ -22,7 +22,17 @@ struct isa_driver {
#define to_isa_driver(x) container_of((x), struct isa_driver, driver)
+#ifdef CONFIG_ISA
int isa_register_driver(struct isa_driver *, unsigned int);
void isa_unregister_driver(struct isa_driver *);
+#else
+static inline int isa_register_driver(struct isa_driver *idrv, unsigned int n)
+{
+ return 0;
+}
+static inline void isa_unregister_driver(struct isa_driver *idrv)
+{
+}
+#endif
#endif /* __LINUX_ISA_H */
--
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 16/22] advansys: Eliminate prototypes
On Sun, 16 Sep 2007 17:03:50 -0600
Matthew Wilcox [EMAIL PROTECTED] wrote:
On Mon, Sep 17, 2007 at 07:41:06AM +0900, FUJITA Tomonori wrote:
On Sun, 16 Sep 2007 09:31:34 -0600
Matthew Wilcox [EMAIL PROTECTED] wrote:
On Sat, Sep 15, 2007 at 09:39:05AM -0500, James Bottomley wrote:
I get a compile failure at this point in your patch sequence:
Thanks. I'd been compiling with CONFIG_ISA=n, so hadn't spotted these
two problems. I've set it back to Y now.
If I compile your latest patchset with CONFIG_ISA=n, I got:
drivers/built-in.o: In function `advansys_init':
advansys.c:(.init.text+0x3efb): undefined reference to `isa_register_driver'
advansys.c:(.init.text+0x3f22): undefined reference to
`isa_unregister_driver'
Fixed by http://marc.info/?l=linux-kernelm=118780055118323w=2 which I
thought was in -mm, but I can't find it. I've just reset it to Linus
Andrew. Thanks for mentioning it.
Oh, I see.
Now I'm back home, I'll add your sg patch to my tree. I'd forgotten
about it ...
I updated the previous patch for your latest patchset. I removed the
sg chaining support so you can send it to scsi-misc now.
Just a one-line patch is necessary for the sg chaining support. It'll
be push to mainline via Jens' tree.
From: FUJITA Tomonori [EMAIL PROTECTED]
Subject: [PATCH] advansys: convert to use the data buffer accessors
- remove the unnecessary map_single path.
- convert to use the new accessors for the sg lists and the
parameters.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/advansys.c | 83 +-
1 files changed, 24 insertions(+), 59 deletions(-)
diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index bd5bbc9..bc24f74 100644
--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -4301,15 +4301,7 @@ advansys_proc_info(struct Scsi_Host *shost, char
*buffer, char **start,
static void asc_scsi_done(struct scsi_cmnd *scp)
{
- struct asc_board *boardp = shost_priv(scp-device-host);
-
- if (scp-use_sg)
- dma_unmap_sg(boardp-dev,
-(struct scatterlist *)scp-request_buffer,
-scp-use_sg, scp-sc_data_direction);
- else if (scp-request_bufflen)
- dma_unmap_single(boardp-dev, scp-SCp.dma_handle,
-scp-request_bufflen, scp-sc_data_direction);
+ scsi_dma_unmap(scp);
ASC_STATS(scp-device-host, done);
@@ -8210,11 +8202,11 @@ static void adv_isr_callback(ADV_DVC_VAR *adv_dvc_varp,
ADV_SCSI_REQ_Q *scsiqp)
* then return the number of underrun bytes.
*/
resid_cnt = le32_to_cpu(scsiqp-data_cnt);
- if (scp-request_bufflen != 0 resid_cnt != 0
- resid_cnt = scp-request_bufflen) {
+ if (scsi_bufflen(scp) != 0 resid_cnt != 0
+ resid_cnt = scsi_bufflen(scp)) {
ASC_DBG(1, underrun condition %lu bytes\n,
(ulong)resid_cnt);
- scp-resid = resid_cnt;
+ scsi_set_resid(scp, resid_cnt);
}
break;
@@ -9877,6 +9869,7 @@ static int advansys_slave_configure(struct scsi_device
*sdev)
static int asc_build_req(struct asc_board *boardp, struct scsi_cmnd *scp,
struct asc_scsi_q *asc_scsi_q)
{
+ int use_sg;
memset(asc_scsi_q, 0, sizeof(*asc_scsi_q));
/*
@@ -9919,40 +9912,28 @@ static int asc_build_req(struct asc_board *boardp,
struct scsi_cmnd *scp,
* Build ASC_SCSI_Q for a contiguous buffer or a scatter-gather
* buffer command.
*/
- if (scp-use_sg == 0) {
+ use_sg = scsi_dma_map(scp);
+ if (use_sg == 0) {
/*
* CDB request of single contiguous buffer.
*/
ASC_STATS(scp-device-host, cont_cnt);
- scp-SCp.dma_handle = scp-request_bufflen ?
- dma_map_single(boardp-dev, scp-request_buffer,
- scp-request_bufflen,
- scp-sc_data_direction) : 0;
- asc_scsi_q-q1.data_addr = cpu_to_le32(scp-SCp.dma_handle);
- asc_scsi_q-q1.data_cnt = cpu_to_le32(scp-request_bufflen);
+ scp-SCp.dma_handle = 0;
ASC_STATS_ADD(scp-device-host, cont_xfer,
ASC_CEILING(scp-request_bufflen, 512));
- asc_scsi_q-q1.sg_queue_cnt = 0;
- asc_scsi_q-sg_head = NULL;
} else {
/*
* CDB scatter-gather request list.
*/
int sgcnt;
- int use_sg;
struct scatterlist *slp;
struct asc_sg_head *asc_sg_head;
- slp = (struct scatterlist *)scp-request_buffer
Re: 2.6.23-rc4-mm1
On Fri, 14 Sep 2007 21:16:35 -0700
Paul Jackson [EMAIL PROTECTED] wrote:
FUJITA Tomonori wrote:
Can you try this patch (against 2.6.23-rc4-mm1)?
From 592bd2049cb3e6e1f1dde7cf631879f26ddffeaa Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Mon, 10 Sep 2007 04:17:13 +0100
Subject: [PATCH] qla1280: sg chaining fixes
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/qla1280.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
This patch works for me.
I was getting the scsi errors reported earlier in
this thread, running 2.6.23-rc4-mm1 on one of our
big SGI Altix systems.
Applying this patch fixed it, so far as I can tell,
which is to say my system boots cleanly once again.
Thanks for testing!
Jens, we could enable use_sg_chaining option for qla1280.
From: FUJITA Tomonori [EMAIL PROTECTED]
Subject: [PATCH] qla1280: enable use_sg_chaining option
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/qla1280.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/qla1280.c b/drivers/scsi/qla1280.c
index 7c1eaec..83249af 100644
--- a/drivers/scsi/qla1280.c
+++ b/drivers/scsi/qla1280.c
@@ -4259,6 +4259,7 @@ static struct scsi_host_template qla1280_driver_template
= {
.sg_tablesize = SG_ALL,
.cmd_per_lun= 1,
.use_clustering = ENABLE_CLUSTERING,
+ .use_sg_chaining= ENABLE_SG_CHAINING,
};
--
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 update] SCSI: update Kconfig help text to indicate SCSI core's widespread usage
On Sat, 15 Sep 2007 14:30:10 +0200 Stefan Richter [EMAIL PROTECTED] wrote: FUJITA Tomonori wrote: On Sat, 15 Sep 2007 08:16:03 +0200 Stefan Richter [EMAIL PROTECTED] wrote: Or would be for newer SCSI transports such as Fibre Channel, FireWire storage, iSCSI, SAS, and more, be OK? scsi-ml has SPI, FC, iSCSI, SAS, and SRP transport classes (SRP is in scsi-misc now). It's a bit strange to omit only SRP, I think. But I might be too SRP-biased. such as... and more suggests that there are indeed more SCSI transports supported by Linux than mentioned in this help text. I think that you can remove such as if you add SRP and SSA. for SCSI transports such as Fibre Channel, FireWire, SAS, iSCSI, SRP, or SSA should be fine. But I'm not sure that scsi-ml has a SSA hba driver. If not, we could remove SSA. We could also write such as Fibre Channel, iSCSI, SAS, and more, if you suspect bias on my side. ;-) Help texts should be concise. -- Stefan Richter -=-=-=== =--= - http://arcgraph.de/sr/ - 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: command failing at iSCSI disconnect
On Fri, 14 Sep 2007 14:43:43 -0700 Dave Jiang [EMAIL PROTECTED] wrote: I'm using the latest linus git tree. This is in fileio mode with IOMode=wb. It seems that if I do I/O and then immediately disconnect then the cache sync commands fail. Is this expected behavior or should the connection wait till all existing commands has been flushed before logout? Thanks! [EMAIL PROTECTED]:~/iscsi2# iscsiadm -m node -T iqn.2007.com.mvista:disk1 -p 192.168.1.239:3260 --logout Logout session [sd 1:0:0:0: [sdb] Synchronizing SCSI cache sid: 1, target: iqn.2007.com.mvista:disk1, portal: 192.168.1.239,3260] iscsi: cmd 0x35 is not queued (6) iscsi: cmd 0x35 is not queued (6) iscsi: cmd 0x35 is not queued (6) sd 1:0:0:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 I think that the fix is in Mike's iscsi git tree. It would be better to ask at open-iscsi mailing list. - 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] set supported_mode for lots of llds
On Sat, 15 Sep 2007 23:07:10 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: FUJITA Tomonori wrote: The majority of llds don't set supported_mode in scsi_host_template so we get: luce:/sys/class/scsi_host/host0$ cat supported_mode unknown It's harmless but it would be better to get: luce:/sys/class/scsi_host/host0$ cat supported_mode Initiator Given that this is the /vast/ majority, just set it once as a default value, and let target drivers change the mode if different. I thought that it's a bit hacky but it should work. From: FUJITA Tomonori [EMAIL PROTECTED] Subject: [PATCH] set supported_mode to MODE_INITIATOR by default This sets supported_mode to MODE_INITIATOR if a lld doesn't set supported_mode in scsi_host_template. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- drivers/scsi/hosts.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c index adc9559..694015d 100644 --- a/drivers/scsi/hosts.c +++ b/drivers/scsi/hosts.c @@ -342,6 +342,10 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int privsize) shost-unchecked_isa_dma = sht-unchecked_isa_dma; shost-use_clustering = sht-use_clustering; shost-ordered_tag = sht-ordered_tag; + + if (!sht-supported_mode) + sht-supported_mode = MODE_INITIATOR; + shost-active_mode = sht-supported_mode; if (sht-max_host_blocked) -- 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 update] SCSI: update Kconfig help text to indicate SCSI core's widespread usage
On Fri, 14 Sep 2007 23:14:21 +0200 (CEST) Stefan Richter [EMAIL PROTECTED] wrote: Signed-off-by: Stefan Richter [EMAIL PROTECTED] --- And one more update: There is SAS too, and I forgot 'is' in on a disk which __ accessed via. drivers/scsi/Kconfig | 67 ++- 1 file changed, 35 insertions(+), 32 deletions(-) Index: linux-2.6.23-rc6/drivers/scsi/Kconfig === --- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig +++ linux-2.6.23-rc6/drivers/scsi/Kconfig @@ -12,23 +12,31 @@ config SCSI depends on BLOCK select SCSI_DMA if HAS_DMA ---help--- - If you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM or - any other SCSI device under Linux, say Y and make sure that you know - the name of your SCSI host adapter (the card inside your computer - that speaks the SCSI protocol, also called SCSI controller), - because you will be asked for it. - - You also need to say Y here if you have a device which speaks - the SCSI protocol. Examples of this include the parallel port - version of the IOMEGA ZIP drive, USB storage devices, Fibre - Channel, FireWire storage and the IDE-SCSI emulation driver. + This option enables core support for SCSI protocols. + You need it + - for classic parallel SCSI hardware, + - for newer SCSI transports such as Fibre Channel, FireWire storage, + SAS, or iSCSI, There is SRP too. - 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-rc4-mm1
error on device sda1, logical block 0
Buffer I/O error on device sda1, logical block 1
Buffer I/O error on device sda1, logical block 2
Buffer I/O error on device sda1, logical block 3
mount: fs type devfs not supported by kernel
ext3: No journal on filesystem on sda1
umount: devfs: not mounted
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 28010831
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 31080815
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 31080855
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 31080919
Buffer I/O error on device sda1, logical block 3885107
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 28411047
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 31135687
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 31138007
sd 0:0:0:0: [sda] 6sd 0:0:0:0: [sda] Result: hostbyte=0x07
driverbyte=0x00
The only patch which touches qla1280 is git-block.patch. From a quick
squizz the change looks OK, although it's tricky and something might have
broken.
(the dprintk at line 2929 needs to print remseg, not seg_cnt).
Can you retest with that change reverted (below)? If it's not that then
perhaps something in scsi core broke, dunno.
Even if we revert the qla1280 patch, scsi-ml still sends chaining sg
list. So it doesn't work.
The following patch disables chaining sg list for qla1280. If the fix
that I've just sent doesn't work, please try this.
-
From: FUJITA Tomonori [EMAIL PROTECTED]
Subject: [PATCH] add use_sg_chaining option to scsi_host_template
This option is true if a low-level driver can support sg
chaining. This will be removed eventually when all the drivers are
converted to support sg chaining. q-max_phys_segments is set to
SCSI_MAX_SG_SEGMENTS if false.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
arch/ia64/hp/sim/simscsi.c|1 +
drivers/scsi/3w-9xxx.c|1 +
drivers/scsi/3w-.c|1 +
drivers/scsi/BusLogic.c |1 +
drivers/scsi/NCR53c406a.c |3 ++-
drivers/scsi/a100u2w.c|1 +
drivers/scsi/aacraid/linit.c |1 +
drivers/scsi/aha1740.c|1 +
drivers/scsi/aic7xxx/aic79xx_osm.c|1 +
drivers/scsi/aic7xxx/aic7xxx_osm.c|1 +
drivers/scsi/aic7xxx_old.c|1 +
drivers/scsi/arcmsr/arcmsr_hba.c |1 +
drivers/scsi/dc395x.c |1 +
drivers/scsi/dpt_i2o.c|1 +
drivers/scsi/eata.c |3 ++-
drivers/scsi/hosts.c |1 +
drivers/scsi/hptiop.c |1 +
drivers/scsi/ibmmca.c |1 +
drivers/scsi/ibmvscsi/ibmvscsi.c |1 +
drivers/scsi/initio.c |1 +
drivers/scsi/ipr.c|1 +
drivers/scsi/lpfc/lpfc_scsi.c |2 ++
drivers/scsi/mac53c94.c |1 +
drivers/scsi/megaraid.c |1 +
drivers/scsi/megaraid/megaraid_mbox.c |1 +
drivers/scsi/megaraid/megaraid_sas.c |1 +
drivers/scsi/mesh.c |1 +
drivers/scsi/nsp32.c |1 +
drivers/scsi/pcmcia/sym53c500_cs.c|1 +
drivers/scsi/qla2xxx/qla_os.c |2 ++
drivers/scsi/qla4xxx/ql4_os.c |1 +
drivers/scsi/qlogicfas.c |1 +
drivers/scsi/scsi_lib.c |5 -
drivers/scsi/stex.c |1 +
drivers/scsi/sym53c416.c |1 +
drivers/scsi/sym53c8xx_2/sym_glue.c |1 +
drivers/scsi/u14-34f.c|1 +
drivers/scsi/ultrastor.c |1 +
drivers/scsi/wd7000.c |1 +
include/scsi/scsi_host.h | 13 +
40 files changed, 59 insertions(+), 3 deletions(-)
diff --git a/arch/ia64/hp/sim/simscsi.c b/arch/ia64/hp/sim/simscsi.c
index 4552a1c..e711657 100644
--- a/arch/ia64/hp/sim/simscsi.c
+++ b/arch/ia64/hp/sim/simscsi.c
@@ -360,6 +360,7 @@ static struct scsi_host_template driver_template = {
.max_sectors= 1024,
.cmd_per_lun= SIMSCSI_REQ_QUEUE_LEN,
.use_clustering = DISABLE_CLUSTERING,
+ .use_sg_chaining= ENABLE_SG_CHAINING,
};
static int __init
diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
index efd9d8d..fb14014 100644
--- a/drivers/scsi/3w-9xxx.c
+++ b/drivers/scsi/3w-9xxx.c
@@ -1990,6 +1990,7 @@ static struct scsi_host_template driver_template = {
.max_sectors= TW_MAX_SECTORS,
.cmd_per_lun= TW_MAX_CMDS_PER_LUN
Re: 2.6.23-rc4-mm1
On Mon, 10 Sep 2007 12:20:38 -0700 Andrew Morton [EMAIL PROTECTED] wrote: On Mon, 10 Sep 2007 20:59:49 +0200 Torsten Kaiser [EMAIL PROTECTED] wrote: On 9/10/07, Andrew Morton [EMAIL PROTECTED] wrote: On Mon, 10 Sep 2007 18:49:26 +0100 Andy Whitcroft [EMAIL PROTECTED] wrote: I have a couple of old NUMA-Q systems which are unable to read their boot disks with 2.6.23-rc4-mm1. The disks appear to be recognised and even the partition tables read correctly, and then they go pop: I reported a similar problem on Sep 1, but until now got no response. You still haven't had a response ;) Let's add a cc. Oh, you reported it against 2.6.23-rc4-mm1 (http://lkml.org/lkml/2007/9/1/92) and I did cc linux-ide in my response. I'll continue to point out where this sort of thing occurs because last week I was told that a reson why so many bug reports are ignored is because linux-kernel has too much traffic. many SCSI people don't subscribe to linux-kernel, I think. The system boots, reads the partition tables, starts the RAID and then kicks one drive out because of errors. Andy is using qla1280. You're using sata. So it's probably a different bug, with the same symptoms. This might be a sg chaining bug too (probabaly sg chaining libata patch). Can you try the following patch that I've just sent: http://lkml.org/lkml/2007/9/10/251 The patch also disables chaining sg list for libata. - 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: [0/22] Advansys updates 2007-09-09
On Sun, 9 Sep 2007 08:53:58 -0600
Matthew Wilcox [EMAIL PROTECTED] wrote:
Here's another mammoth patch series for the advansys driver against
scsi-misc. I've tested that it compiles at each stage and that the
final result works.
Some important parts to note:
1/22 Essential bugfix. Please apply ASAP.
4/22 Reformat microcode. Boring and large.
6,7,8,9/22 Remove internal queueing from driver
11/22 Allow advansys to accept 16-byte commands for wide boards
13/22 Remove some custom wrappers
15/22 Add DRV_NAME
16/22 Eliminate prototypes. Boring and large.
19/22 Fix simultaneous calls to -queuecommand
This is on the top of the patchset. Can I get your ACK on it?
This depends on scsi-misc, the patchset, and sg chaining stuff.
--
From: FUJITA Tomonori [EMAIL PROTECTED]
Subject: [PATCH] advansys: convert to use the data buffer accessors
- remove the unnecessary map_single path.
- convert to use the new accessors for the sg lists and the
parameters.
- add sg chaining support
Jens Axboe [EMAIL PROTECTED] added sg chaining support.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/advansys.c | 93 +++
1 files changed, 29 insertions(+), 64 deletions(-)
diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index abad6d1..62b58a7 100644
--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -4499,15 +4499,7 @@ advansys_proc_info(struct Scsi_Host *shost, char
*buffer, char **start,
static void asc_scsi_done(struct scsi_cmnd *scp)
{
- struct asc_board *boardp = ASC_BOARDP(scp-device-host);
-
- if (scp-use_sg)
- dma_unmap_sg(boardp-dev,
-(struct scatterlist *)scp-request_buffer,
-scp-use_sg, scp-sc_data_direction);
- else if (scp-request_bufflen)
- dma_unmap_single(boardp-dev, scp-SCp.dma_handle,
-scp-request_bufflen, scp-sc_data_direction);
+ scsi_dma_unmap(scp);
ASC_STATS(scp-device-host, done);
@@ -8460,12 +8452,12 @@ static void adv_isr_callback(ADV_DVC_VAR *adv_dvc_varp,
ADV_SCSI_REQ_Q *scsiqp)
* then return the number of underrun bytes.
*/
resid_cnt = le32_to_cpu(scsiqp-data_cnt);
- if (scp-request_bufflen != 0 resid_cnt != 0
- resid_cnt = scp-request_bufflen) {
+ if (scsi_bufflen(scp) != 0 resid_cnt != 0
+ resid_cnt = scsi_bufflen(scp)) {
ASC_DBG1(1,
adv_isr_callback: underrun condition %lu
bytes\n,
(ulong)resid_cnt);
- scp-resid = resid_cnt;
+ scsi_set_resid(scp, resid_cnt);
}
break;
@@ -9410,12 +9402,12 @@ static void asc_isr_callback(ASC_DVC_VAR *asc_dvc_varp,
ASC_QDONE_INFO *qdonep)
* If there was no error and an underrun condition, then
* return the number of underrun bytes.
*/
- if (scp-request_bufflen != 0 qdonep-remain_bytes != 0
- qdonep-remain_bytes = scp-request_bufflen) {
+ if (scsi_bufflen(scp) != 0 qdonep-remain_bytes != 0
+ qdonep-remain_bytes = scsi_bufflen(scp)) {
ASC_DBG1(1,
asc_isr_callback: underrun condition %u
bytes\n,
(unsigned)qdonep-remain_bytes);
- scp-resid = qdonep-remain_bytes;
+ scsi_set_resid(scp, qdonep-remain_bytes);
}
break;
@@ -10147,6 +10139,8 @@ static int advansys_slave_configure(struct scsi_device
*sdev)
static int asc_build_req(asc_board_t *boardp, struct scsi_cmnd *scp,
struct asc_scsi_q *asc_scsi_q)
{
+ int use_sg;
+
memset(asc_scsi_q, 0, sizeof(*asc_scsi_q));
/*
@@ -10189,40 +10183,27 @@ static int asc_build_req(asc_board_t *boardp, struct
scsi_cmnd *scp,
* Build ASC_SCSI_Q for a contiguous buffer or a scatter-gather
* buffer command.
*/
- if (scp-use_sg == 0) {
+ use_sg = scsi_dma_map(scp);
+ if (use_sg == 0) {
/*
* CDB request of single contiguous buffer.
*/
ASC_STATS(scp-device-host, cont_cnt);
- scp-SCp.dma_handle = scp-request_bufflen ?
- dma_map_single(boardp-dev, scp-request_buffer,
- scp-request_bufflen,
- scp-sc_data_direction) : 0;
- asc_scsi_q-q1.data_addr = cpu_to_le32(scp-SCp.dma_handle);
- asc_scsi_q-q1.data_cnt = cpu_to_le32(scp-request_bufflen);
- ASC_STATS_ADD(scp-device-host, cont_xfer,
- ASC_CEILING(scp
Re: 2.6.23-rc4-mm1
error on device sda1, logical block 0
Buffer I/O error on device sda1, logical block 1
Buffer I/O error on device sda1, logical block 2
Buffer I/O error on device sda1, logical block 3
mount: fs type devfs not supported by kernel
ext3: No journal on filesystem on sda1
umount: devfs: not mounted
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 28010831
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 31080815
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 31080855
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 31080919
Buffer I/O error on device sda1, logical block 3885107
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 28411047
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 31135687
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 31138007
sd 0:0:0:0: [sda] 6sd 0:0:0:0: [sda] Result: hostbyte=0x07
driverbyte=0x00
The only patch which touches qla1280 is git-block.patch. From a quick
squizz the change looks OK, although it's tricky and something might have
broken.
Can you try this patch (against 2.6.23-rc4-mm1)?
From 592bd2049cb3e6e1f1dde7cf631879f26ddffeaa Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Mon, 10 Sep 2007 04:17:13 +0100
Subject: [PATCH] qla1280: sg chaining fixes
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/qla1280.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/qla1280.c b/drivers/scsi/qla1280.c
index bd805ec..7c1eaec 100644
--- a/drivers/scsi/qla1280.c
+++ b/drivers/scsi/qla1280.c
@@ -2977,8 +2977,8 @@ qla1280_64bit_start_scsi(struct scsi_qla_host *ha, struct
srb * sp)
cpu_to_le32(pci_dma_hi32(dma_handle)),
cpu_to_le32(pci_dma_lo32(dma_handle)),
cpu_to_le32(sg_dma_len(s)));
- remseg--;
}
+ remseg -= cnt;
dprintk(5, qla1280_64bit_start_scsi:
continuation packet data - b %i, t
%i, l %i \n, SCSI_BUS_32(cmd),
@@ -3250,6 +3250,8 @@ qla1280_32bit_start_scsi(struct scsi_qla_host *ha, struct
srb * sp)
/* Load continuation entry data segments. */
for_each_sg(sg, s, remseg, cnt) {
+ if (cnt == 7)
+ break;
*dword_ptr++ =
cpu_to_le32(pci_dma_lo32(sg_dma_address(s)));
*dword_ptr++ =
@@ -3260,6 +3262,7 @@ qla1280_32bit_start_scsi(struct scsi_qla_host *ha, struct
srb * sp)
cpu_to_le32(pci_dma_lo32(sg_dma_address(s))),
cpu_to_le32(sg_dma_len(s)));
}
+ remseg -= cnt;
dprintk(5, qla1280_32bit_start_scsi:
continuation packet data -
scsi(%i:%i:%i)\n, SCSI_BUS_32(cmd),
--
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 0/9] scsi_data_buffer structure (in preparation for bidi)
On Sun, 09 Sep 2007 11:25:57 +0300
Boaz Harrosh [EMAIL PROTECTED] wrote:
On Fri, Sep 07 2007 at 0:50 +0300, FUJITA Tomonori [EMAIL PROTECTED] wrote:
This patchset, which I submitted before, adds a new data structure,
scsi_data_buffer, including everything for data transfer:
struct scsi_data_buffer { unsigned length; int resid; short sg_count;
short __sg_count; struct scatterlist *sglist; };
One scsi_data_buffer structure is embedded in struct scsi_cmnd for
uni-directional transfer. All the members are just moved from
scsi_cmnd structure to scsi_data_buffer structure. So nothing is
added to scsi_cmnd structure.
After applying this patchset, llds must use the scsi data accessors.
This patchset includes some conversation patches (most of them are
patches that Boaz submitted before), however there is still some code
that is needed to be converted.
Boaz, if you still have other conversation patches, please submit
them.
I suspect that nobody cares about some of unconverted llds, which
will be not compilable after this patchset. I'll fix ldds that people
complain about.
It's difficult to test this patchset in -mm via scsi-misc. Jens,
please send this to -mm via the block tree.
Sorry for the late response. Just am back from vacation.
Tomo please hold with these patches a bit longer the
Tree is not ready for it.
Then we have no chance to merge scsi_data_buffer into 2.6.24.
Mainly you will totally break USB storage mid-layer.
There is one converted USB driver - microtek.c - that is
currently broken. This is because usb mid-layer still issues
a synchronous REQUEST_SENSE with use_sg == 0.
(And still bangs all over scsi_cmnd members) I have a
complete and somewhat tested solution for the USB stack
and all the drivers. as well as lots of other drivers
(see list below). I will submit them group by group during
this week and next week. The reason I did not release them
yet is because I did not want to do this before the vacation
and not be available for debugging.
Some of the files I have patches for are:
git-diff --stat
drivers/fc4/fc.c| 40 ++---
I think that I fixed fc4 (the patch is in scsi-misc).
drivers/scsi/NCR5380.c | 39 ++--
drivers/scsi/NCR5380.h |7 +
drivers/scsi/NCR53C9x.c | 40 ++---
drivers/scsi/NCR53C9x.h |2 -
drivers/scsi/a2091.c| 36 +---
drivers/scsi/a3000.c| 15 +--
drivers/scsi/aha1542.c | 54 ++
drivers/scsi/arm/acornscsi.c| 14 +-
drivers/scsi/arm/fas216.c |5 +-
drivers/scsi/arm/fas216.h |3 +
drivers/scsi/arm/scsi.h | 34 +---
drivers/scsi/atari_NCR5380.c| 47 ++---
drivers/scsi/atp870u.c | 102 ++-
drivers/scsi/dec_esp.c | 17 --
drivers/scsi/eata_pio.c | 12 +-
drivers/scsi/fd_mcs.c | 36 +---
drivers/scsi/gdth.c |2 +-
drivers/scsi/imm.c | 13 +-
drivers/scsi/in2000.c | 10 +-
drivers/scsi/oktagon_esp.c | 14 --
drivers/scsi/pluto.c|2 +-
drivers/scsi/ppa.c | 12 +-
drivers/scsi/qla1280.c | 348
+++
The patchset includes qla1280 conversion.
drivers/scsi/qlogicpti.c| 54 +-
drivers/scsi/scsi_error.c | 114
The patchset includes your patch to convert scsi_error.c. What else do
you want to change?
drivers/scsi/seagate.c | 17 +-
drivers/scsi/sun3_NCR5380.c | 42 ++---
drivers/scsi/sun3x_esp.c| 21 +--
drivers/scsi/wd33c93.c | 10 +-
drivers/usb/storage/freecom.c | 14 +-
drivers/usb/storage/isd200.c|6 +-
drivers/usb/storage/protocol.c | 120 +---
drivers/usb/storage/sddr09.c|9 +-
drivers/usb/storage/shuttle_usbat.c | 54 +++---
drivers/usb/storage/transport.c | 95 --
drivers/usb/storage/transport.h |2 +
include/scsi/scsi_eh.h | 17 ++-
38 files changed, 574 insertions(+), 905 deletions(-)
If any of these are obsolete and should be removed please
say so. Save me the work to submit them.
I think that nobody cares about some of these drivers and they might
be even broken. We need to merge the patchset to -mm and then we can
see what drivers people still care about. And if necessary, we can
blindly just convert drivers.
-
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 6/9] tgt: convert ibmvstgt and libsrp to use scsi_data_buffer
On Sun, 09 Sep 2007 17:28:41 +0300 Boaz Harrosh [EMAIL PROTECTED] wrote: On Sun, Sep 09 2007 at 16:47 +0300, FUJITA Tomonori [EMAIL PROTECTED] wrote: On Sun, 09 Sep 2007 13:12:03 +0300 Boaz Harrosh [EMAIL PROTECTED] wrote: On Fri, Sep 07 2007 at 0:50 +0300, FUJITA Tomonori [EMAIL PROTECTED] wrote: Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- ... @@ -425,8 +426,8 @@ int srp_cmd_queue(struct Scsi_Host *shost, struct srp_cmd *cmd, void *info, sc-SCp.ptr = info; memcpy(sc-cmnd, cmd-cdb, MAX_COMMAND_SIZE); - sc-request_bufflen = len; - sc-request_buffer = (void *) (unsigned long) addr; + sc-sdb.length = len; + sc-sdb.sglist = (void *) (unsigned long) addr; sc-tag = tag; err = scsi_tgt_queue_command(sc, (struct scsi_lun *) cmd-lun, cmd-tag); if (err) What is done here in srp_cmd_queue() looks scary to me. even today. What is that u64 addr that gets truncated to unsigned long and put on sglist? What data-buffer len is suppose to describe? And dir is for what data? No trancated since it's used for an address. addr, data length, and data transfer direction though they are not used now. I wish you could maybe clean up the unused stuff, Well, I put them for Xen scsiback driver though now I could remove it. and/or give addr its proper type. If it's a pointer than make it a pointer. You need to read the SRP spec. Also you are implying a use_sg==0 here which is not allowed. It is made to look like addr is a linear pointer with a use_sg==0 issued command, which is no longer allowed. Only we know it is not, because of the (void *)(unsigned long) addr; which is a bug in 64-bit. If this is a totally private message sent threw the scsi-ml. I would rather it was done with DMA_NONE,bufflen=0,sglist=NULL and put all the user-info into scsi_cmnd.SCp like above void* info. tgt doesn't queue a command to scsi-ml. It queues it to user space. Even though. Please don't misuse scsi_cmnd members in this way. If you are not using any of scsi-ml functions on these commands and they do not carry sg-lists than why use a scsi_cmnd at all? We try to use scsi-ml and transport class as much as possible. You can just use a tgt private structure. And we don't try to do this. If these commands do go through some scsi-ml functions than banging scsi_cmnd.sdb.sglist this way is dangerous. As I said, these commands will not go to scsi-ml in a way as you think. - 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 6/9] tgt: convert ibmvstgt and libsrp to use scsi_data_buffer
On Sun, 9 Sep 2007 23:38:55 +0900 FUJITA Tomonori [EMAIL PROTECTED] wrote: On Sun, 09 Sep 2007 17:28:41 +0300 Boaz Harrosh [EMAIL PROTECTED] wrote: On Sun, Sep 09 2007 at 16:47 +0300, FUJITA Tomonori [EMAIL PROTECTED] wrote: On Sun, 09 Sep 2007 13:12:03 +0300 Boaz Harrosh [EMAIL PROTECTED] wrote: On Fri, Sep 07 2007 at 0:50 +0300, FUJITA Tomonori [EMAIL PROTECTED] wrote: Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- ... @@ -425,8 +426,8 @@ int srp_cmd_queue(struct Scsi_Host *shost, struct srp_cmd *cmd, void *info, sc-SCp.ptr = info; memcpy(sc-cmnd, cmd-cdb, MAX_COMMAND_SIZE); - sc-request_bufflen = len; - sc-request_buffer = (void *) (unsigned long) addr; + sc-sdb.length = len; + sc-sdb.sglist = (void *) (unsigned long) addr; sc-tag = tag; err = scsi_tgt_queue_command(sc, (struct scsi_lun *) cmd-lun, cmd-tag); if (err) What is done here in srp_cmd_queue() looks scary to me. even today. What is that u64 addr that gets truncated to unsigned long and put on sglist? What data-buffer len is suppose to describe? And dir is for what data? No trancated since it's used for an address. addr, data length, and data transfer direction though they are not used now. I wish you could maybe clean up the unused stuff, Well, I put them for Xen scsiback driver though now I could remove it. and/or give addr its proper type. If it's a pointer than make it a pointer. You need to read the SRP spec. Also you are implying a use_sg==0 here which is not allowed. It is made to look like addr is a linear pointer with a use_sg==0 issued command, which is no longer allowed. Only we know it is not, because of the (void *)(unsigned long) addr; which is a bug in 64-bit. If this is a totally private message sent threw the scsi-ml. I would rather it was done with DMA_NONE,bufflen=0,sglist=NULL and put all the user-info into scsi_cmnd.SCp like above void* info. tgt doesn't queue a command to scsi-ml. It queues it to user space. Even though. Please don't misuse scsi_cmnd members in this way. If you are not using any of scsi-ml functions on these commands and they do not carry sg-lists than why use a scsi_cmnd at all? We try to use scsi-ml and transport class as much as possible. You can just use a tgt private structure. And we don't try to do this. Oops, we try not to do this. - 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/9] scsi_data_buffer structure (in preparation for bidi)
On Sun, 09 Sep 2007 17:09:15 +0300
Boaz Harrosh [EMAIL PROTECTED] wrote:
On Sun, Sep 09 2007 at 16:47 +0300, FUJITA Tomonori [EMAIL PROTECTED] wrote:
On Sun, 09 Sep 2007 11:25:57 +0300
Boaz Harrosh [EMAIL PROTECTED] wrote:
On Fri, Sep 07 2007 at 0:50 +0300, FUJITA Tomonori [EMAIL PROTECTED]
wrote:
This patchset, which I submitted before, adds a new data structure,
scsi_data_buffer, including everything for data transfer:
struct scsi_data_buffer { unsigned length; int resid; short sg_count;
short __sg_count; struct scatterlist *sglist; };
One scsi_data_buffer structure is embedded in struct scsi_cmnd for
uni-directional transfer. All the members are just moved from
scsi_cmnd structure to scsi_data_buffer structure. So nothing is
added to scsi_cmnd structure.
After applying this patchset, llds must use the scsi data accessors.
This patchset includes some conversation patches (most of them are
patches that Boaz submitted before), however there is still some code
that is needed to be converted.
Boaz, if you still have other conversation patches, please submit
them.
I suspect that nobody cares about some of unconverted llds, which
will be not compilable after this patchset. I'll fix ldds that people
complain about.
It's difficult to test this patchset in -mm via scsi-misc. Jens,
please send this to -mm via the block tree.
Sorry for the late response. Just am back from vacation.
Tomo please hold with these patches a bit longer the
Tree is not ready for it.
Then we have no chance to merge scsi_data_buffer into 2.6.24.
I hope to submit all/most of the work this week. If we miss the window
for 2.6.24 than I'm very sorry for that. But I don't think we are
aloud to break USB storage subsystem.
I'll send patches for USB (in a 'search and replace' way) if you don't
soon. Except for USB, I suspect that nobody cares about most of the
unconverted drivers.
-
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] remove sglist_len
This is against Jens' sg chaining branch.
http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commitdiff;h=d6beb57f48231f5c012fb7d55b369bc0af6b0c41
The sg chaining patchset adds __use_sg to save the length of sg list
before dma mapping. The sg chaining patchset also uses sglist_len but
we can live without it. So let's remove sglist_len since we can add
something to scsi_cmnd structure only when we definitely need to do.
Now the sg chaining provides a way to decrease memory consumption and
doesn't add anything to scsi_cmnd structure.
James, do you want to change more about the sg chaining's scsi_lib.c?
--
From b887de7c48a674ace622544addd70ebc8ae31fd2 Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Thu, 6 Sep 2007 08:41:33 +0100
Subject: [PATCH] remove sglist_len
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/scsi_lib.c | 11 ---
include/scsi/scsi_cmnd.h |1 -
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 2fc2380..1e0f691 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -774,10 +774,8 @@ struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd
*cmd, gfp_t gfp_mask)
/*
* first loop through, set initial index and return value
*/
- if (!ret) {
- cmd-sglist_len = index;
+ if (!ret)
ret = sgl;
- }
/*
* chain previous sglist, if any. we know the previous
@@ -830,8 +828,6 @@ void scsi_free_sgtable(struct scsi_cmnd *cmd)
struct scatterlist *sgl = cmd-request_buffer;
struct scsi_host_sg_pool *sgp;
- BUG_ON(cmd-sglist_len = SG_MEMPOOL_NR);
-
/*
* if this is the biggest size sglist, check if we have
* chained parts we need to free
@@ -866,9 +862,10 @@ void scsi_free_sgtable(struct scsi_cmnd *cmd)
* Restore original, will be freed below
*/
sgl = cmd-request_buffer;
- }
+ sgp = scsi_sg_pools + SG_MEMPOOL_NR - 1;
+ } else
+ sgp = scsi_sg_pools + scsi_sgtable_index(cmd-__use_sg);
- sgp = scsi_sg_pools + cmd-sglist_len;
mempool_free(sgl, sgp-pool);
}
diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
index 6263c4e..bb6358a 100644
--- a/include/scsi/scsi_cmnd.h
+++ b/include/scsi/scsi_cmnd.h
@@ -72,7 +72,6 @@ struct scsi_cmnd {
/* These elements define the operation we ultimately want to perform */
unsigned short use_sg; /* Number of pieces of scatter-gather */
- unsigned short sglist_len; /* size of malloc'd scatter-gather list
*/
unsigned short __use_sg;
unsigned underflow; /* Return error if less than
--
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
[PATCH 9/9] libata-scsi: convert to use the data buffer accessors
From: Boaz Harrosh [EMAIL PROTECTED]
This is a minimal patch needed if we want to use the new
scsi_data_buffer implementation, by useing of the new data
accessors. But it is not a complete clean up of the !use_sg path.
Libata-core still has the qc-flags ATA_QCFLAG_SG and !qc-n_elem
code paths. Perhaps an ata maintainer would have a go at it.
- use of new data accessors.
- clean some of the more obvious !use_sg path
- TODO: farther cleanup of qc-flags ATA_QCFLAG_SG
and !qc-n_elem code paths in libata-core
- TODO: Use of new scsi_dma_{map,unmap} if applicable.
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/ata/libata-scsi.c | 39 +--
1 files changed, 13 insertions(+), 26 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 5194f3d..01a0197 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -450,13 +450,8 @@ static struct ata_queued_cmd *ata_scsi_qc_new(struct
ata_device *dev,
qc-scsicmd = cmd;
qc-scsidone = done;
- if (cmd-use_sg) {
- qc-__sg = (struct scatterlist *) cmd-request_buffer;
- qc-n_elem = cmd-use_sg;
- } else if (cmd-request_bufflen) {
- qc-__sg = qc-sgent;
- qc-n_elem = 1;
- }
+ qc-__sg = scsi_sglist(cmd);
+ qc-n_elem = scsi_sg_count(cmd);
} else {
cmd-result = (DID_OK 16) | (QUEUE_FULL 1);
done(cmd);
@@ -1496,17 +1491,13 @@ static int ata_scsi_translate(struct ata_device *dev,
struct scsi_cmnd *cmd,
/* data is present; dma-map it */
if (cmd-sc_data_direction == DMA_FROM_DEVICE ||
cmd-sc_data_direction == DMA_TO_DEVICE) {
- if (unlikely(cmd-request_bufflen 1)) {
+ if (unlikely(scsi_bufflen(cmd) 1)) {
ata_dev_printk(dev, KERN_WARNING,
WARNING: zero len r/w req\n);
goto err_did;
}
- if (cmd-use_sg)
- ata_sg_init(qc, cmd-request_buffer, cmd-use_sg);
- else
- ata_sg_init_one(qc, cmd-request_buffer,
- cmd-request_bufflen);
+ ata_sg_init(qc, scsi_sglist(cmd), scsi_sg_count(cmd));
qc-dma_dir = cmd-sc_data_direction;
}
@@ -1560,15 +1551,14 @@ static unsigned int ata_scsi_rbuf_get(struct scsi_cmnd
*cmd, u8 **buf_out)
u8 *buf;
unsigned int buflen;
- if (cmd-use_sg) {
- struct scatterlist *sg;
+ struct scatterlist *sg = scsi_sglist(cmd);
- sg = (struct scatterlist *) cmd-request_buffer;
+ if (sg) {
buf = kmap_atomic(sg-page, KM_IRQ0) + sg-offset;
buflen = sg-length;
} else {
- buf = cmd-request_buffer;
- buflen = cmd-request_bufflen;
+ buf = NULL;
+ buflen = 0;
}
*buf_out = buf;
@@ -1588,12 +1578,9 @@ static unsigned int ata_scsi_rbuf_get(struct scsi_cmnd
*cmd, u8 **buf_out)
static inline void ata_scsi_rbuf_put(struct scsi_cmnd *cmd, u8 *buf)
{
- if (cmd-use_sg) {
- struct scatterlist *sg;
-
- sg = (struct scatterlist *) cmd-request_buffer;
+ struct scatterlist *sg = scsi_sglist(cmd);
+ if (sg)
kunmap_atomic(buf - sg-offset, KM_IRQ0);
- }
}
/**
@@ -2394,7 +2381,7 @@ static unsigned int atapi_xlat(struct ata_queued_cmd *qc)
}
qc-tf.command = ATA_CMD_PACKET;
- qc-nbytes = scmd-request_bufflen;
+ qc-nbytes = scsi_bufflen(scmd);
/* check whether ATAPI DMA is safe */
if (!using_pio ata_check_atapi_dma(qc))
@@ -2629,7 +2616,7 @@ static unsigned int ata_scsi_pass_thru(struct
ata_queued_cmd *qc)
case ATA_CMD_WRITE_LONG_ONCE:
if (tf-protocol != ATA_PROT_PIO || tf-nsect != 1)
goto invalid_fld;
- qc-sect_size = scmd-request_bufflen;
+ qc-sect_size = scsi_bufflen(scmd);
}
/*
@@ -2659,7 +2646,7 @@ static unsigned int ata_scsi_pass_thru(struct
ata_queued_cmd *qc)
* TODO: find out if we need to do more here to
* cover scatter/gather case.
*/
- qc-nbytes = scmd-request_bufflen;
+ qc-nbytes = scsi_bufflen(scmd);
/* request result TF */
qc-flags |= ATA_QCFLAG_RESULT_TF;
--
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
[PATCH 2/9] convert sd and sr to use scsi_data_buffer
From: Boaz Harrosh [EMAIL PROTECTED]
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/scsi/sd.c |6 +++---
drivers/scsi/sr.c | 25 +
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 2c6116f..aba9e34 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -337,7 +337,7 @@ static int sd_init_command(struct scsi_cmnd * SCpnt)
struct request *rq = SCpnt-request;
struct gendisk *disk = rq-rq_disk;
sector_t block = rq-sector;
- unsigned int this_count = SCpnt-request_bufflen 9;
+ unsigned int this_count = scsi_bufflen(SCpnt) 9;
unsigned int timeout = sdp-timeout;
SCSI_LOG_HLQUEUE(1, scmd_printk(KERN_INFO, SCpnt,
@@ -479,7 +479,7 @@ static int sd_init_command(struct scsi_cmnd * SCpnt)
SCpnt-cmnd[4] = (unsigned char) this_count;
SCpnt-cmnd[5] = 0;
}
- SCpnt-request_bufflen = this_count * sdp-sector_size;
+ SCpnt-sdb.length = this_count * sdp-sector_size;
/*
* We shouldn't disconnect in the middle of a sector, so with a dumb
@@ -898,7 +898,7 @@ static struct block_device_operations sd_fops = {
static void sd_rw_intr(struct scsi_cmnd * SCpnt)
{
int result = SCpnt-result;
- unsigned int xfer_size = SCpnt-request_bufflen;
+ unsigned int xfer_size = scsi_bufflen(SCpnt);
unsigned int good_bytes = result ? 0 : xfer_size;
u64 start_lba = SCpnt-request-sector;
u64 bad_lba;
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 902eb11..67bb542 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -218,7 +218,7 @@ static int sr_media_change(struct cdrom_device_info *cdi,
int slot)
static void rw_intr(struct scsi_cmnd * SCpnt)
{
int result = SCpnt-result;
- int this_count = SCpnt-request_bufflen;
+ int this_count = scsi_bufflen(SCpnt);
int good_bytes = (result == 0 ? this_count : 0);
int block_sectors = 0;
long error_sector;
@@ -351,17 +351,18 @@ static int sr_init_command(struct scsi_cmnd * SCpnt)
}
{
- struct scatterlist *sg = SCpnt-request_buffer;
+ struct scatterlist *sg;
int i, size = 0;
- for (i = 0; i SCpnt-use_sg; i++)
- size += sg[i].length;
- if (size != SCpnt-request_bufflen SCpnt-use_sg) {
+ scsi_for_each_sg(SCpnt, sg, scsi_sg_count(SCpnt), i)
+ size += sg-length;
+
+ if (size != scsi_bufflen(SCpnt)) {
scmd_printk(KERN_ERR, SCpnt,
- mismatch count %d, bytes %d\n,
- size, SCpnt-request_bufflen);
- if (SCpnt-request_bufflen size)
- SCpnt-request_bufflen = size;
+ mismatch count %d, bytes %d\n,
+ size, scsi_bufflen(SCpnt));
+ if (scsi_bufflen(SCpnt) size)
+ SCpnt-sdb.length = size;
}
}
@@ -369,12 +370,12 @@ static int sr_init_command(struct scsi_cmnd * SCpnt)
* request doesn't start on hw block boundary, add scatter pads
*/
if (((unsigned int)SCpnt-request-sector % (s_size 9)) ||
- (SCpnt-request_bufflen % s_size)) {
+ (scsi_bufflen(SCpnt) % s_size)) {
scmd_printk(KERN_NOTICE, SCpnt, unaligned transfer\n);
return 0;
}
- this_count = (SCpnt-request_bufflen 9) / (s_size 9);
+ this_count = (scsi_bufflen(SCpnt) 9) / (s_size 9);
SCSI_LOG_HLQUEUE(2, printk(%s : %s %d/%ld 512 byte blocks.\n,
@@ -388,7 +389,7 @@ static int sr_init_command(struct scsi_cmnd * SCpnt)
if (this_count 0x) {
this_count = 0x;
- SCpnt-request_bufflen = this_count * s_size;
+ SCpnt-sdb.length = this_count * s_size;
}
SCpnt-cmnd[2] = (unsigned char) (block 24) 0xff;
--
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
[PATCH 7/9] qla1280: convert to use the data buffer accessors
- remove the unnecessary map_single path.
- convert to use the new accessors for the sg lists and the parameters.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/qla1280.c | 369
1 files changed, 154 insertions(+), 215 deletions(-)
diff --git a/drivers/scsi/qla1280.c b/drivers/scsi/qla1280.c
index bd805ec..25ba0bd 100644
--- a/drivers/scsi/qla1280.c
+++ b/drivers/scsi/qla1280.c
@@ -1310,14 +1310,7 @@ qla1280_done(struct scsi_qla_host *ha)
}
/* Release memory used for this I/O */
- if (cmd-use_sg) {
- pci_unmap_sg(ha-pdev, cmd-request_buffer,
- cmd-use_sg, cmd-sc_data_direction);
- } else if (cmd-request_bufflen) {
- pci_unmap_single(ha-pdev, sp-saved_dma_handle,
- cmd-request_bufflen,
- cmd-sc_data_direction);
- }
+ scsi_dma_unmap(cmd);
/* Call the mid-level driver interrupt handler */
CMD_HANDLE(sp-cmd) = (unsigned char *)INVALID_HANDLE;
@@ -1406,14 +1399,14 @@ qla1280_return_status(struct response * sts, struct
scsi_cmnd *cp)
break;
case CS_DATA_UNDERRUN:
- if ((cp-request_bufflen - residual_length)
+ if ((scsi_bufflen(cp) - residual_length)
cp-underflow) {
printk(KERN_WARNING
scsi: Underflow detected - retrying
command.\n);
host_status = DID_ERROR;
} else {
- cp-resid = residual_length;
+ scsi_set_resid(cp, residual_length);
host_status = DID_OK;
}
break;
@@ -2781,27 +2774,23 @@ qla1280_64bit_start_scsi(struct scsi_qla_host *ha,
struct srb * sp)
int status = 0;
int cnt;
int req_cnt;
- u16 seg_cnt;
+ int seg_cnt;
u8 dir;
ENTER(qla1280_64bit_start_scsi:);
/* Calculate number of entries and segments required. */
req_cnt = 1;
- if (cmd-use_sg) {
- sg = (struct scatterlist *) cmd-request_buffer;
- seg_cnt = pci_map_sg(ha-pdev, sg, cmd-use_sg,
-cmd-sc_data_direction);
-
+ seg_cnt = scsi_dma_map(cmd);
+ if (seg_cnt 0) {
if (seg_cnt 2) {
req_cnt += (seg_cnt - 2) / 5;
if ((seg_cnt - 2) % 5)
req_cnt++;
}
- } else if (cmd-request_bufflen) { /* If data transfer. */
- seg_cnt = 1;
- } else {
- seg_cnt = 0;
+ } else if (seg_cnt 0) {
+ status = 1;
+ goto out;
}
if ((req_cnt + 2) = ha-req_q_cnt) {
@@ -2893,120 +2882,95 @@ qla1280_64bit_start_scsi(struct scsi_qla_host *ha,
struct srb * sp)
/* Setup packet address segment pointer. */
dword_ptr = (u32 *)pkt-dseg_0_address;
- if (cmd-use_sg) { /* If scatter gather */
- /* Load command entry data segments. */
- for_each_sg(sg, s, seg_cnt, cnt) {
- if (cnt == 2)
+ /* Load command entry data segments. */
+ for_each_sg(sg, s, seg_cnt, cnt) {
+ if (cnt == 2)
+ break;
+ dma_handle = sg_dma_address(s);
+#if defined(CONFIG_IA64_GENERIC) || defined(CONFIG_IA64_SGI_SN2)
+ if (ha-flags.use_pci_vchannel)
+ sn_pci_set_vchan(ha-pdev,
+(unsigned long *)dma_handle,
+SCSI_BUS_32(cmd));
+#endif
+ *dword_ptr++ =
+ cpu_to_le32(pci_dma_lo32(dma_handle));
+ *dword_ptr++ =
+ cpu_to_le32(pci_dma_hi32(dma_handle));
+ *dword_ptr++ = cpu_to_le32(sg_dma_len(s));
+ dprintk(3, S/G Segment phys_addr=%x %x, len=0x%x\n,
+ cpu_to_le32(pci_dma_hi32(dma_handle)),
+ cpu_to_le32(pci_dma_lo32(dma_handle)),
+ cpu_to_le32(sg_dma_len(sg_next(s;
+ remseg--;
+ }
+ dprintk(5, qla1280_64bit_start_scsi: Scatter/gather
+ command packet data - b %i, t %i, l %i \n,
+ SCSI_BUS_32(cmd), SCSI_TCN_32(cmd),
+ SCSI_LUN_32(cmd));
+ qla1280_dump_buffer(5, (char *)pkt
[PATCH 4/9] scsi_debug: convert to use the data buffer accessors
From: Boaz Harrosh [EMAIL PROTECTED]
- remove the unnecessary map_single path.
- convert to use the new accessors for the sg lists and the
parameters.
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/scsi/scsi_debug.c | 36 ++--
1 files changed, 10 insertions(+), 26 deletions(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 72ee4c9..c08ebf4 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -329,7 +329,7 @@ int scsi_debug_queuecommand(struct scsi_cmnd * SCpnt,
done_funct_t done)
if (done == NULL)
return 0; /* assume mid level reprocessing command */
- SCpnt-resid = 0;
+ scsi_set_resid(SCpnt, 0);
if ((SCSI_DEBUG_OPT_NOISE scsi_debug_opts) cmd) {
printk(KERN_INFO scsi_debug: cmd );
for (k = 0, len = SCpnt-cmd_len; k len; ++k)
@@ -603,26 +603,16 @@ static int fill_from_dev_buffer(struct scsi_cmnd * scp,
unsigned char * arr,
void * kaddr_off;
struct scatterlist * sg;
- if (0 == scp-request_bufflen)
+ if (0 == scsi_bufflen(scp))
return 0;
- if (NULL == scp-request_buffer)
+ if (NULL == scsi_sglist(scp))
return (DID_ERROR 16);
if (! ((scp-sc_data_direction == DMA_BIDIRECTIONAL) ||
(scp-sc_data_direction == DMA_FROM_DEVICE)))
return (DID_ERROR 16);
- if (0 == scp-use_sg) {
- req_len = scp-request_bufflen;
- act_len = (req_len arr_len) ? req_len : arr_len;
- memcpy(scp-request_buffer, arr, act_len);
- if (scp-resid)
- scp-resid -= act_len;
- else
- scp-resid = req_len - act_len;
- return 0;
- }
active = 1;
req_len = act_len = 0;
- scsi_for_each_sg(scp, sg, scp-use_sg, k) {
+ scsi_for_each_sg(scp, sg, scsi_sg_count(scp), k) {
if (active) {
kaddr = (unsigned char *)
kmap_atomic(sg-page, KM_USER0);
@@ -640,10 +630,10 @@ static int fill_from_dev_buffer(struct scsi_cmnd * scp,
unsigned char * arr,
}
req_len += sg-length;
}
- if (scp-resid)
- scp-resid -= act_len;
+ if (scsi_get_resid(scp))
+ scsi_set_resid(scp, scsi_get_resid(scp) - act_len);
else
- scp-resid = req_len - act_len;
+ scsi_set_resid(scp, req_len - act_len);
return 0;
}
@@ -656,22 +646,16 @@ static int fetch_to_dev_buffer(struct scsi_cmnd * scp,
unsigned char * arr,
void * kaddr_off;
struct scatterlist * sg;
- if (0 == scp-request_bufflen)
+ if (0 == scsi_bufflen(scp))
return 0;
- if (NULL == scp-request_buffer)
+ if (NULL == scsi_sglist(scp))
return -1;
if (! ((scp-sc_data_direction == DMA_BIDIRECTIONAL) ||
(scp-sc_data_direction == DMA_TO_DEVICE)))
return -1;
- if (0 == scp-use_sg) {
- req_len = scp-request_bufflen;
- len = (req_len max_arr_len) ? req_len : max_arr_len;
- memcpy(arr, scp-request_buffer, len);
- return len;
- }
sg = scsi_sglist(scp);
req_len = fin = 0;
- for (k = 0; k scp-use_sg; ++k, sg = sg_next(sg)) {
+ for (k = 0; k scsi_sg_count(scp); ++k, sg = sg_next(sg)) {
kaddr = (unsigned char *)kmap_atomic(sg-page, KM_USER0);
if (NULL == kaddr)
return -1;
--
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
[PATCH 8/9] ide-scsi: convert to use the data buffer accessors
This just blindly converts ide-scsi to use the new accessors for the
sg lists and the parameters.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/ide-scsi.c | 23 ---
1 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/ide-scsi.c b/drivers/scsi/ide-scsi.c
index c05b291..42e821a 100644
--- a/drivers/scsi/ide-scsi.c
+++ b/drivers/scsi/ide-scsi.c
@@ -294,7 +294,7 @@ static inline void idescsi_transform_pc2 (ide_drive_t
*drive, idescsi_pc_t *pc)
{
u8 *atapi_buf = pc-buffer;
u8 *sc = pc-scsi_cmd-cmnd;
- u8 *scsi_buf = pc-scsi_cmd-request_buffer;
+ u8 *scsi_buf = (u8 *)scsi_sglist(pc-scsi_cmd);
if (!test_bit(PC_TRANSFORM, pc-flags))
return;
@@ -444,8 +444,9 @@ static int idescsi_end_request (ide_drive_t *drive, int
uptodate, int nrsecs)
printk (ide-scsi: %s: suc %lu, drive-name,
pc-scsi_cmd-serial_number);
if (!test_bit(PC_WRITING, pc-flags)
pc-actually_transferred pc-actually_transferred = 1024 pc-buffer) {
printk(, rst = );
- scsi_buf = pc-scsi_cmd-request_buffer;
- hexdump(scsi_buf, min_t(unsigned, 16,
pc-scsi_cmd-request_bufflen));
+ scsi_buf = (u8 *)scsi_sglist(pc-scsi_cmd);
+ hexdump(scsi_buf, min_t(unsigned, 16,
+
scsi_bufflen(pc-scsi_cmd)));
} else printk(\n);
}
}
@@ -642,15 +643,15 @@ static int idescsi_map_sg(ide_drive_t *drive,
idescsi_pc_t *pc)
return 1;
sg = hwif-sg_table;
- scsi_sg = pc-scsi_cmd-request_buffer;
- segments = pc-scsi_cmd-use_sg;
+ scsi_sg = scsi_sglist(pc-scsi_cmd);
+ segments = scsi_sg_count(pc-scsi_cmd);
if (segments hwif-sg_max_nents)
return 1;
if (!segments) {
hwif-sg_nents = 1;
- sg_init_one(sg, pc-scsi_cmd-request_buffer,
pc-request_transfer);
+ sg_init_one(sg, scsi_sglist(pc-scsi_cmd),
pc-request_transfer);
} else {
hwif-sg_nents = segments;
memcpy(sg, scsi_sg, sizeof(*sg) * segments);
@@ -910,17 +911,17 @@ static int idescsi_queue (struct scsi_cmnd *cmd,
pc-flags = 0;
pc-rq = rq;
memcpy (pc-c, cmd-cmnd, cmd-cmd_len);
- if (cmd-use_sg) {
+ if (scsi_sg_count(cmd)) {
pc-buffer = NULL;
- pc-sg = cmd-request_buffer;
- pc-last_sg = sg_last(pc-sg, cmd-use_sg);
+ pc-sg = scsi_sglist(cmd);
+ pc-last_sg = sg_last(pc-sg, scsi_sg_count(cmd));
} else {
- pc-buffer = cmd-request_buffer;
+ pc-buffer = (u8 *)scsi_sglist(cmd);
pc-sg = NULL;
pc-last_sg = NULL;
}
pc-b_count = 0;
- pc-request_transfer = pc-buffer_size = cmd-request_bufflen;
+ pc-request_transfer = pc-buffer_size = scsi_bufflen(cmd);
pc-scsi_cmd = cmd;
pc-done = done;
pc-timeout = jiffies + cmd-timeout_per_command;
--
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
[PATCH 3/9] convert scsi_error.c to use scsi_data_buffer
From: Boaz Harrosh [EMAIL PROTECTED]
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/scsi/scsi_error.c | 29 +++--
1 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 8a525ab..af39a39 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -614,13 +614,11 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
DECLARE_COMPLETION_ONSTACK(done);
unsigned long timeleft;
unsigned long flags;
- struct scatterlist sgl;
unsigned char old_cmnd[MAX_COMMAND_SIZE];
enum dma_data_direction old_data_direction;
- unsigned short old_use_sg;
unsigned char old_cmd_len;
- unsigned old_bufflen;
- void *old_buffer;
+ struct scsi_data_buffer old_sdb;
+ struct scatterlist sgl;
int rtn;
/*
@@ -630,12 +628,10 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
* we will need to restore these values prior to running the actual
* command.
*/
- old_buffer = scmd-request_buffer;
- old_bufflen = scmd-request_bufflen;
+ old_sdb = scmd-sdb;
memcpy(old_cmnd, scmd-cmnd, sizeof(scmd-cmnd));
old_data_direction = scmd-sc_data_direction;
old_cmd_len = scmd-cmd_len;
- old_use_sg = scmd-use_sg;
memset(scmd-cmnd, 0, sizeof(scmd-cmnd));
memcpy(scmd-cmnd, cmnd, cmnd_size);
@@ -645,14 +641,13 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
sizeof(scmd-sense_buffer));
scmd-sc_data_direction = DMA_FROM_DEVICE;
- scmd-request_bufflen = sgl.length;
- scmd-request_buffer = sgl;
- scmd-use_sg = 1;
+ scmd-sdb.sglist = sgl;
+
+ scmd-sdb.length = sgl.length;
+ scmd-sdb.resid = 0;
+ scmd-sdb.sg_count = 1;
} else {
- scmd-request_buffer = NULL;
- scmd-request_bufflen = 0;
scmd-sc_data_direction = DMA_NONE;
- scmd-use_sg = 0;
}
scmd-underflow = 0;
@@ -715,13 +710,12 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
/*
* Restore original data
*/
- scmd-request_buffer = old_buffer;
- scmd-request_bufflen = old_bufflen;
+ scmd-sdb = old_sdb;
memcpy(scmd-cmnd, old_cmnd, sizeof(scmd-cmnd));
scmd-sc_data_direction = old_data_direction;
scmd-cmd_len = old_cmd_len;
- scmd-use_sg = old_use_sg;
scmd-result = old_result;
+
return rtn;
}
@@ -1672,8 +1666,7 @@ scsi_reset_provider(struct scsi_device *dev, int flag)
scmd-scsi_done = scsi_reset_provider_done_command;
scmd-done = NULL;
- scmd-request_buffer= NULL;
- scmd-request_bufflen = 0;
+ memset(scmd-sdb, 0, sizeof(scmd-sdb));
scmd-cmd_len = 0;
--
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
[PATCH 0/9] scsi_data_buffer structure (in preparation for bidi)
This patchset, which I submitted before, adds a new data structure,
scsi_data_buffer, including everything for data transfer:
struct scsi_data_buffer {
unsigned length;
int resid;
short sg_count;
short __sg_count;
struct scatterlist *sglist;
};
One scsi_data_buffer structure is embedded in struct scsi_cmnd for
uni-directional transfer. All the members are just moved from
scsi_cmnd structure to scsi_data_buffer structure. So nothing is added
to scsi_cmnd structure.
After applying this patchset, llds must use the scsi data
accessors. This patchset includes some conversation patches (most of
them are patches that Boaz submitted before), however there is still
some code that is needed to be converted.
Boaz, if you still have other conversation patches, please submit
them.
I suspect that nobody cares about some of unconverted llds, which will
be not compilable after this patchset. I'll fix ldds that people
complain about.
It's difficult to test this patchset in -mm via scsi-misc. Jens,
please send this to -mm via the block tree.
-
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 5/9] tgt: convert to use scsi_data_buffer
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/scsi_tgt_if.c |2 +-
drivers/scsi/scsi_tgt_lib.c | 27 ++-
2 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/scsi_tgt_if.c b/drivers/scsi/scsi_tgt_if.c
index ca22ddf..bdfc9b0 100644
--- a/drivers/scsi/scsi_tgt_if.c
+++ b/drivers/scsi/scsi_tgt_if.c
@@ -110,7 +110,7 @@ int scsi_tgt_uspace_send_cmd(struct scsi_cmnd *cmd, struct
scsi_lun *lun, u64 ta
memset(ev, 0, sizeof(ev));
ev.p.cmd_req.host_no = shost-host_no;
- ev.p.cmd_req.data_len = cmd-request_bufflen;
+ ev.p.cmd_req.data_len = scsi_bufflen(cmd);
memcpy(ev.p.cmd_req.scb, cmd-cmnd, sizeof(ev.p.cmd_req.scb));
memcpy(ev.p.cmd_req.lun, lun, sizeof(ev.p.cmd_req.lun));
ev.p.cmd_req.attribute = cmd-tag;
diff --git a/drivers/scsi/scsi_tgt_lib.c b/drivers/scsi/scsi_tgt_lib.c
index 2ee7b5a..30c8ec1 100644
--- a/drivers/scsi/scsi_tgt_lib.c
+++ b/drivers/scsi/scsi_tgt_lib.c
@@ -328,8 +328,8 @@ static void scsi_tgt_cmd_done(struct scsi_cmnd *cmd)
scsi_tgt_uspace_send_status(cmd, tcmd-tag);
- if (cmd-request_buffer)
- scsi_free_sgtable(cmd);
+ if (cmd-sdb.sglist)
+ scsi_free_sgtable(cmd-sdb);
queue_work(scsi_tgtd, tcmd-work);
}
@@ -353,24 +353,25 @@ static int scsi_tgt_transfer_response(struct scsi_cmnd
*cmd)
static int scsi_tgt_init_cmd(struct scsi_cmnd *cmd, gfp_t gfp_mask)
{
struct request *rq = cmd-request;
+ struct scsi_data_buffer *sdb = cmd-sdb;
int count;
+ int ret;
- cmd-use_sg = rq-nr_phys_segments;
- cmd-request_buffer = scsi_alloc_sgtable(cmd, gfp_mask);
- if (!cmd-request_buffer)
- return -ENOMEM;
+ ret = scsi_alloc_sgtable(sdb, gfp_mask, rq-nr_phys_segments);
+ if (ret)
+ return ret;
- cmd-request_bufflen = rq-data_len;
+ sdb-length = rq-data_len;
- dprintk(cmd %p cnt %d %lu\n, cmd, cmd-use_sg, rq_data_dir(rq));
- count = blk_rq_map_sg(rq-q, rq, cmd-request_buffer);
- if (likely(count = cmd-use_sg)) {
- cmd-use_sg = count;
+ dprintk(cmd %p cnt %d %lu\n, cmd, scsi_sg_count(cmd),
rq_data_dir(rq));
+ count = blk_rq_map_sg(rq-q, rq, sdb-sglist);
+ if (likely(count = sdb-sg_count)) {
+ sdb-sg_count = count;
return 0;
}
- eprintk(cmd %p cnt %d\n, cmd, cmd-use_sg);
- scsi_free_sgtable(cmd);
+ eprintk(cmd %p cnt %d\n, cmd, scsi_sg_count(cmd));
+ scsi_free_sgtable(cmd-sdb);
return -EINVAL;
}
--
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
[PATCH 1/9] add scsi_data_buffer structure
This adds a new data structure, scsi_data_buffer, including scsi data
transfer. One scsi_data_buffer structure is embedded in struct
scsi_cmnd for uni-directional transfer.
This is a preparation for bidirectional support.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/scsi_lib.c | 85 ++---
include/scsi/scsi_cmnd.h | 38 ++--
2 files changed, 69 insertions(+), 54 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 1e0f691..3adce94 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -742,16 +742,22 @@ static inline unsigned int scsi_sgtable_index(unsigned
short nents)
return index;
}
-struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd *cmd, gfp_t gfp_mask)
+int scsi_alloc_sgtable(struct scsi_data_buffer *sdb, gfp_t gfp_mask,
+ int sg_count)
{
struct scsi_host_sg_pool *sgp;
struct scatterlist *sgl, *prev, *ret;
unsigned int index;
int this, left;
- BUG_ON(!cmd-use_sg);
+ /*
+* don't allow subsequent mempool allocs to sleep, it would
+* violate the mempool principle.
+*/
+ gfp_mask = ~__GFP_WAIT;
+ gfp_mask |= __GFP_HIGH;
- left = cmd-use_sg;
+ left = sg_count;
ret = prev = NULL;
do {
this = left;
@@ -785,21 +791,17 @@ struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd
*cmd, gfp_t gfp_mask)
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
+* -sg_count 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;
+ sdb-sg_count = sg_count;
+ sdb-__sg_count = sg_count;
+ sdb-sglist = ret;
+ return 0;
enomem:
if (ret) {
/*
@@ -818,26 +820,26 @@ enomem:
mempool_free(prev, sgp-pool);
}
- return NULL;
+ return -ENOMEM;
}
EXPORT_SYMBOL(scsi_alloc_sgtable);
-void scsi_free_sgtable(struct scsi_cmnd *cmd)
+void scsi_free_sgtable(struct scsi_data_buffer *sdb)
{
- struct scatterlist *sgl = cmd-request_buffer;
+ struct scatterlist *sgl = sdb-sglist;
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) {
+ if (sdb-__sg_count SCSI_MAX_SG_SEGMENTS) {
unsigned short this, left;
struct scatterlist *next;
unsigned int index;
- left = cmd-__use_sg - (SCSI_MAX_SG_SEGMENTS - 1);
+ left = sdb-__sg_count - (SCSI_MAX_SG_SEGMENTS - 1);
next = sg_chain_ptr(sgl[SCSI_MAX_SG_SEGMENTS - 1]);
while (left next) {
sgl = next;
@@ -861,10 +863,10 @@ void scsi_free_sgtable(struct scsi_cmnd *cmd)
/*
* Restore original, will be freed below
*/
- sgl = cmd-request_buffer;
+ sgl = sdb-sglist;
sgp = scsi_sg_pools + SG_MEMPOOL_NR - 1;
} else
- sgp = scsi_sg_pools + scsi_sgtable_index(cmd-__use_sg);
+ sgp = scsi_sg_pools + scsi_sgtable_index(sdb-__sg_count);
mempool_free(sgl, sgp-pool);
}
@@ -890,15 +892,14 @@ EXPORT_SYMBOL(scsi_free_sgtable);
*/
static void scsi_release_buffers(struct scsi_cmnd *cmd)
{
- if (cmd-use_sg)
- scsi_free_sgtable(cmd);
+ if (cmd-sdb.sglist)
+ scsi_free_sgtable(cmd-sdb);
/*
* Zero these out. They now point to freed memory, and it is
* dangerous to hang onto the pointers.
*/
- cmd-request_buffer = NULL;
- cmd-request_bufflen = 0;
+ cmd-sdb.sglist = NULL;
}
/*
@@ -932,7 +933,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);
struct request_queue *q = cmd-device-request_queue;
struct request *req = cmd-request;
int clear_errors = 1;
@@ -940,8 +941,6 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int
good_bytes)
int sense_valid = 0;
int sense_deferred = 0
Re: [PATCH 4/5] qla2xxx: add target mode support
On Wed, 5 Sep 2007 08:05:34 -0700 Andrew Vasquez [EMAIL PROTECTED] wrote: On Sat, 01 Sep 2007, FUJITA Tomonori wrote: This adds target mode support to qla2xxx. With set ql2enable_target_mode module parameter to 1, the driver runs in target mode. By default, ql2enable_target_mode is set to 0, and the driver should work in initiator mode as before. The driver could support dual-mode in the future but it doesn't at the moment (we need to add dual-mode support tgt first). It is based on scst qla2xxx target mode driver. Mike converted the driver to use tgt long ago. I changed it to use the latest (mainline) version of qla2xxx driver and tgt, and also converted it to use fc transport class. Thanks for doing this. Some initial comments before a full review is complete, As was seen from the initiator updates needed for 24xx support, there are comparable changes needed in the area of target-mode support for 4gb and 8gb parts. I see, thanks. I heard that 24xx firmware doesn't support target mode and I thought that I should not touch 24xx code. Not true? Also, which ISPs and firmwares were exercised with this code? qla2xxx :0a:02.0: QLogic Fibre Channel HBA Driver: 8.02.00-k2 QLogic QLA2340 - 133MHz PCI-X to 2Gb FC, Single Channel ISP2312: PCI-X (133 MHz) @ :0a:02.0 hdma-, host#=3, fw=3.03.20 IPX - 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/2] revert sg segment size ifdefs
The patchset is against Jens' sg chaining branch.
Jens removed old SCSI_MAX_PHYS_SEGMENTS hack and the maximum is always
128:
http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commit;h=d6beb57f48231f5c012fb7d55b369bc0af6b0c41
I talked to James at linuxconf.eu and he likes to provide a way to
reduce sgpool memory consumption because with libata everyone
(including small machines) uses the mid layer.
This patch reverts sg segment size ifdefs that the current mid layer
has. Later we might do something better like relating
SCSI_MAX_SG_SEGMENTS with other config options like CONFIG_EMBEDDED or
just having SCSI_MAX_SG_SEGMENTS in menuconfig.
Now we have sg chaining code in -mm. As discussed before, it would be
nice to test sg chaining code in -mm with a small SCSI_MAX_SG_SEGMENTS
value like 32.
---
From 4692956cdc3db1d0cfb3f26dc7aa3925f591d392 Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Sat, 18 Aug 2007 19:00:47 +0900
Subject: [PATCH 1/2] revert sg segment size ifdefs
This reverts sg segment size ifdefs that the current code has in order
to provide a way to reduce sgpool memory consumption.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/scsi_lib.c | 28
1 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index f05f006..2fc2380 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -34,6 +34,13 @@
#define SG_MEMPOOL_NR ARRAY_SIZE(scsi_sg_pools)
#define SG_MEMPOOL_SIZE2
+/*
+ * The maximum number of SG segments that we will put inside a scatterlist
+ * (unless chaining is used). Should ideally fit inside a single page, to
+ * avoid a higher order allocation.
+ */
+#define SCSI_MAX_SG_SEGMENTS 128
+
struct scsi_host_sg_pool {
size_t size;
char*name;
@@ -45,9 +52,15 @@ struct scsi_host_sg_pool {
static struct scsi_host_sg_pool scsi_sg_pools[] = {
SP(8),
SP(16),
+#if (SCSI_MAX_SG_SEGMENTS 16)
SP(32),
+#if (SCSI_MAX_SG_SEGMENTS 32)
SP(64),
+#if (SCSI_MAX_SG_SEGMENTS 64)
SP(128),
+#endif
+#endif
+#endif
};
#undef SP
@@ -690,13 +703,6 @@ static struct scsi_cmnd *scsi_end_request(struct scsi_cmnd
*cmd, int uptodate,
}
/*
- * The maximum number of SG segments that we will put inside a scatterlist
- * (unless chaining is used). Should ideally fit inside a single page, to
- * avoid a higher order allocation.
- */
-#define SCSI_MAX_SG_SEGMENTS 128
-
-/*
* Like SCSI_MAX_SG_SEGMENTS, but for archs that have sg chaining. This limit
* is totally arbitrary, a setting of 2048 will get you at least 8mb ios.
*/
@@ -713,15 +719,21 @@ static inline unsigned int scsi_sgtable_index(unsigned
short nents)
case 9 ... 16:
index = 1;
break;
+#if (SCSI_MAX_SG_SEGMENTS 16)
case 17 ... 32:
index = 2;
break;
+#if (SCSI_MAX_SG_SEGMENTS 32)
case 33 ... 64:
index = 3;
break;
- case 65 ... SCSI_MAX_SG_SEGMENTS:
+#if (SCSI_MAX_SG_SEGMENTS 64)
+ case 65 ... 128:
index = 4;
break;
+#endif
+#endif
+#endif
default:
printk(KERN_ERR scsi: bad segment count=%d\n, nents);
BUG();
--
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
[PATCH 2/2] libata: remove blk_queue_max_phys_segments
Jeff, can I get your ACK on this patch? Whatever in a request queue we set, iommu code ignores all the sg list limitations. --- From 703d5158361bb6a4ecdc5cd9a6961a8cfb419f73 Mon Sep 17 00:00:00 2001 From: FUJITA Tomonori [EMAIL PROTECTED] Date: Mon, 3 Sep 2007 06:49:11 +0100 Subject: [PATCH 2/2] remove blk_queue_max_phys_segments in libata LIBATA_MAX_PRD is the maximum number of DMA scatter/gather elements permitted by the HBA's DMA engine. It's properly set to q-max_hw_segments via the sg_tablesize parameter. libata shouldn't call blk_queue_max_phys_segments. Now LIBATA_MAX_PRD is equal to SCSI_MAX_PHYS_SEGMENTS by default (both is 128), so everything is fine. But if they are changed, some code (like the scsi mid layer, sg chaining, etc) might not work properly. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- drivers/ata/libata-scsi.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index e836476..5194f3d 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -800,8 +800,6 @@ int ata_scsi_slave_config(struct scsi_device *sdev) ata_scsi_sdev_config(sdev); - blk_queue_max_phys_segments(sdev-request_queue, LIBATA_MAX_PRD); - sdev-manage_start_stop = 1; if (dev) -- 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: Fw: data disclosure in ioctl sg inquiry
On Mon, 03 Sep 2007 13:00:43 -0400
Douglas Gilbert [EMAIL PROTECTED] wrote:
FUJITA Tomonori wrote:
On Sun, 2 Sep 2007 04:56:01 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
Begin forwarded message:
Date: Mon, 27 Aug 2007 15:01:33 +0100
From: Luciano Rocha [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: data disclosure in ioctl sg inquiry
(Please keep me CC'ed. Thanks.)
Hello,
While testing the SG INQUIRY command to a locked hard drive, connected
with USB, I noted that the command result included garbage that seemed
part of some other's process memory. Like bash functions, command
arguments, etc..
I make sure to memset the buffers before running the ioctl, so this seem
to be data leaked from the kernel.
Most of the code is verbatim from the example in the SCSI Generic HOWTO
(http://tldp.org/HOWTO/SCSI-Generic-HOWTO/pexample.html).
I include the code I used and sample output with data from running
processes (or files?).
I can't reproduce this on a firewire connected HDD, but I can with
another USB connecte one (not locked).
$ ./keytool /dev/sdb
Some of the INQUIRY command's response:
00 00 00 00 1f 00 00 00 4d 41 58 54 4f 52 20 53 MAXTOR S
54 4d 33 32 35 30 38 32 30 41 20 20 20 20 20 20 TM3250820A
33 2e 41 41 11 00 00 00 23 31 31 38 38 32 32 32 3.AA#1188222
33 34 30 00 11 00 00 00 48 00 12 08 28 00 12 08 340.H...(...
00 00 00 00 59 00 00 00 64 69 66 66 20 2d 75 72 Y...diff -ur
20 2d 2d 65 78 63 6c 75 64 65 20 2e 73 76 6e 20 --exclude .svn
INQUIRY duration=3 millisecs, resid=60
Note that resid is 60. So, in your case, only the first 36 bytes are
valid. But I guess that it's not good to leak random kernel data to
user-space.
Can you try this patch?
---
From 2529dbda52ac2302eab9838910d59e13dedeb3bd Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Sun, 2 Sep 2007 13:32:33 +0100
Subject: [PATCH] bio_copy_user use zeroed pages
bio_uncopy_user copies garbage to user-space buffer when the actual
transferred length is shorter than dxfer_len.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
fs/bio.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/fs/bio.c b/fs/bio.c
index 29a44c1..26a7669 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -550,11 +550,16 @@ struct bio *bio_copy_user(struct request_queue *q,
unsigned long uaddr,
ret = 0;
while (len) {
unsigned int bytes = PAGE_SIZE;
+ gfp_t mask;
if (bytes len)
bytes = len;
- page = alloc_page(q-bounce_gfp | GFP_KERNEL);
+ mask = q-bounce_gfp | GFP_KERNEL;
+ if (write_to_vm)
+ mask |= __GFP_ZERO;
+
+ page = alloc_page(mask);
if (!page) {
ret = -ENOMEM;
break;
Hello folks. This has been known about (or variations of
it) for some time. The design approach has been:
- if the uid of the app is 0 (i.e. root) then we take
the fast approach (i.e. don't zero intermediate buffers)
as root can see the whole of ram anyway
- if the uid of the app is !=0 (i.e. a non-root user) then
zero intermediate buffers (and slow things down a bit)
It's tree for your sg, but I think that he uses block sg code and it
doesn't do such thing.
-
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: Fw: data disclosure in ioctl sg inquiry
On Sun, 2 Sep 2007 04:56:01 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
Begin forwarded message:
Date: Mon, 27 Aug 2007 15:01:33 +0100
From: Luciano Rocha [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: data disclosure in ioctl sg inquiry
(Please keep me CC'ed. Thanks.)
Hello,
While testing the SG INQUIRY command to a locked hard drive, connected
with USB, I noted that the command result included garbage that seemed
part of some other's process memory. Like bash functions, command
arguments, etc..
I make sure to memset the buffers before running the ioctl, so this seem
to be data leaked from the kernel.
Most of the code is verbatim from the example in the SCSI Generic HOWTO
(http://tldp.org/HOWTO/SCSI-Generic-HOWTO/pexample.html).
I include the code I used and sample output with data from running
processes (or files?).
I can't reproduce this on a firewire connected HDD, but I can with
another USB connecte one (not locked).
$ ./keytool /dev/sdb
Some of the INQUIRY command's response:
00 00 00 00 1f 00 00 00 4d 41 58 54 4f 52 20 53 MAXTOR S
54 4d 33 32 35 30 38 32 30 41 20 20 20 20 20 20 TM3250820A
33 2e 41 41 11 00 00 00 23 31 31 38 38 32 32 32 3.AA#1188222
33 34 30 00 11 00 00 00 48 00 12 08 28 00 12 08 340.H...(...
00 00 00 00 59 00 00 00 64 69 66 66 20 2d 75 72 Y...diff -ur
20 2d 2d 65 78 63 6c 75 64 65 20 2e 73 76 6e 20 --exclude .svn
INQUIRY duration=3 millisecs, resid=60
Note that resid is 60. So, in your case, only the first 36 bytes are
valid. But I guess that it's not good to leak random kernel data to
user-space.
Can you try this patch?
---
From 2529dbda52ac2302eab9838910d59e13dedeb3bd Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Sun, 2 Sep 2007 13:32:33 +0100
Subject: [PATCH] bio_copy_user use zeroed pages
bio_uncopy_user copies garbage to user-space buffer when the actual
transferred length is shorter than dxfer_len.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
fs/bio.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/fs/bio.c b/fs/bio.c
index 29a44c1..26a7669 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -550,11 +550,16 @@ struct bio *bio_copy_user(struct request_queue *q,
unsigned long uaddr,
ret = 0;
while (len) {
unsigned int bytes = PAGE_SIZE;
+ gfp_t mask;
if (bytes len)
bytes = len;
- page = alloc_page(q-bounce_gfp | GFP_KERNEL);
+ mask = q-bounce_gfp | GFP_KERNEL;
+ if (write_to_vm)
+ mask |= __GFP_ZERO;
+
+ page = alloc_page(mask);
if (!page) {
ret = -ENOMEM;
break;
--
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
[PATCH 0/5] tgt: add target mode support to fc transport and qla2xxx
This patchset adds target mode support to fc transport class and
qla2xxx driver. The pathset is against scsi-misc.
The target mode support for fc transport class works in the same way
as srp transport class. fc_remote_port_{rolechg,delete} calls
scsi_tgt_it_nexus_{create,destroy} for target drivers.
This patchset includes one major change to the mid layer. srp
initiator-mode drivers don't find initiator remote ports (i.e. it
finds only target ports) so srp transport class always creates tgt's
I_T nexus when it finds an initiator remoto port. However, both
initiator-mode and target-mode fc drivers find initiator remote ports
so fc transport class needs to know which mode the driver runs in (or
a driver can run in dual mode too). That is, fc transport class
creates tgt's I_T nexus only when target-mode-enabled drivers find an
initiator remote port.
To solve the above issue, the second patch adds supported_mode and
active_mode attributes to /sys/class/sys_host/hostX/ for specifying
the mode that a lld supports and the currently activated mode. The
supported_mode attribute looks at a scsi_host_template and the
active_mode attribute looks at a scsi_host. We would add a hook to a
scsi_host_template to change the active_mode attribute
dynamically. But now there is no hook since no lld supports that
feature.
-
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] tgt: fix can_queue bug
should use host-can_queue instead of host-hostt-can_queue. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] Signed-off-by: Mike Christie [EMAIL PROTECTED] --- drivers/scsi/scsi_tgt_lib.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/scsi_tgt_lib.c b/drivers/scsi/scsi_tgt_lib.c index 5851c8e..66c692f 100644 --- a/drivers/scsi/scsi_tgt_lib.c +++ b/drivers/scsi/scsi_tgt_lib.c @@ -237,7 +237,7 @@ int scsi_tgt_alloc_queue(struct Scsi_Host *shost) * command as is recvd to userspace. uspace can then make * sure we do not overload the HBA */ - q-nr_requests = shost-hostt-can_queue; + q-nr_requests = shost-can_queue; /* * We currently only support software LLDs so this does * not matter for now. Do we need this for the cards we support? -- 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
[PATCH 2/5] add supported_mode and active_mode attributes
This adds supported_mode and active_mode attributes to
/sys/class/sys_host/hostX/ for specifying the mode that a lld supports
and the currently activated mode. The output format is similar to fc
rport roles:
luce:/sys/class/scsi_host/host0$ cat supported_mode
Initiator
luce:/sys/class/scsi_host/host0$ cat active_mode
Initiator
The mode values uses bitmap since we would support dual-mode llds in
the future like this:
luce:/sys/class/scsi_host/host0$ cat supported_mode
Initiator, Target
The supported_mode attribute looks at a scsi_host_template and the
active_mode attribute looks at a scsi_host. We would add a hook to a
scsi_host_template to change the active_mode attribute
dynamically. But now there is no hook since no lld supports that
feature.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
Signed-off-by: Mike Christie [EMAIL PROTECTED]
---
drivers/scsi/hosts.c |1 +
drivers/scsi/scsi_sysfs.c | 42 ++
include/scsi/scsi_host.h |9 +
3 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index 96bc312..adc9559 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -342,6 +342,7 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template
*sht, int privsize)
shost-unchecked_isa_dma = sht-unchecked_isa_dma;
shost-use_clustering = sht-use_clustering;
shost-ordered_tag = sht-ordered_tag;
+ shost-active_mode = sht-supported_mode;
if (sht-max_host_blocked)
shost-max_host_blocked = sht-max_host_blocked;
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 34cdce6..a3d227f 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -190,6 +190,46 @@ show_shost_state(struct class_device *class_dev, char *buf)
static CLASS_DEVICE_ATTR(state, S_IRUGO | S_IWUSR, show_shost_state,
store_shost_state);
+static ssize_t
+show_shost_mode(unsigned int mode, char *buf)
+{
+ ssize_t len = 0;
+
+ if (mode MODE_INITIATOR)
+ len = sprintf(buf, %s, Initiator);
+
+ if (mode MODE_TARGET)
+ len += sprintf(buf + len, %s%s, len ? , : , Target);
+
+ len += sprintf(buf + len, \n);
+
+ return len;
+}
+
+static ssize_t show_shost_supported_mode(struct class_device *class_dev, char
*buf)
+{
+ struct Scsi_Host *shost = class_to_shost(class_dev);
+
+ if (shost-hostt-supported_mode == MODE_UNKNOWN)
+ return snprintf(buf, 20, unknown\n);
+ else
+ return show_shost_mode(shost-hostt-supported_mode, buf);
+}
+
+static CLASS_DEVICE_ATTR(supported_mode, S_IRUGO | S_IWUSR,
show_shost_supported_mode, NULL);
+
+static ssize_t show_shost_active_mode(struct class_device *class_dev, char
*buf)
+{
+ struct Scsi_Host *shost = class_to_shost(class_dev);
+
+ if (shost-active_mode == MODE_UNKNOWN)
+ return snprintf(buf, 20, unknown\n);
+ else
+ return show_shost_mode(shost-active_mode, buf);
+}
+
+static CLASS_DEVICE_ATTR(active_mode, S_IRUGO | S_IWUSR,
show_shost_active_mode, NULL);
+
shost_rd_attr(unique_id, %u\n);
shost_rd_attr(host_busy, %hu\n);
shost_rd_attr(cmd_per_lun, %hd\n);
@@ -208,6 +248,8 @@ static struct class_device_attribute
*scsi_sysfs_shost_attrs[] = {
class_device_attr_proc_name,
class_device_attr_scan,
class_device_attr_state,
+ class_device_attr_supported_mode,
+ class_device_attr_active_mode,
NULL
};
diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
index 88f6871..5b79697 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -32,6 +32,9 @@ struct blk_queue_tags;
#define SG_NONE 0
#define SG_ALL 0xff
+#define MODE_UNKNOWN 0x00
+#define MODE_INITIATOR 0x01
+#define MODE_TARGET 0x02
#define DISABLE_CLUSTERING 0
#define ENABLE_CLUSTERING 1
@@ -405,6 +408,11 @@ struct scsi_host_template {
unsigned char present;
/*
+* This specifies the mode that a LLD supports.
+*/
+ unsigned supported_mode:2;
+
+ /*
* true if this host adapter uses unchecked DMA onto an ISA bus.
*/
unsigned unchecked_isa_dma:1;
@@ -574,6 +582,7 @@ struct Scsi_Host {
*/
unsigned long cmd_serial_number, cmd_pid;
+ unsigned active_mode:2;
unsigned unchecked_isa_dma:1;
unsigned use_clustering:1;
unsigned use_blk_tcq:1;
--
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
[PATCH 3/5] fc_transport: add target driver support
This adds minimum target driver support like the srp transport does:
- fc_remote_port_{rolechg,delete} calls
scsi_tgt_it_nexus_{create,destroy} for target drivers.
- add callbacks to notify target drivers of the nexus and tmf
operation results to fc_function_template.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
Signed-off-by: Mike Christie [EMAIL PROTECTED]
---
drivers/scsi/Kconfig |7 +++
drivers/scsi/scsi_transport_fc.c | 29 +
drivers/scsi/scsi_transport_fc_internal.h | 26 ++
include/scsi/scsi_transport_fc.h |4
4 files changed, 66 insertions(+), 0 deletions(-)
create mode 100644 drivers/scsi/scsi_transport_fc_internal.h
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 7877dfd..e1efa0e 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -272,6 +272,13 @@ config SCSI_FC_ATTRS
each attached FiberChannel device to sysfs, say Y.
Otherwise, say N.
+config SCSI_FC_TGT_ATTRS
+ bool SCSI target support for FiberChannel Transport Attributes
+ depends on SCSI_FC_ATTRS
+ depends on SCSI_TGT = y || SCSI_TGT = SCSI_FC_ATTRS
+ help
+ If you want to use SCSI target mode drivers enable this option.
+
config SCSI_ISCSI_ATTRS
tristate iSCSI Transport Attributes
depends on SCSI NET
diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
index 4705725..1605a80 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -36,6 +36,7 @@
#include net/netlink.h
#include scsi/scsi_netlink_fc.h
#include scsi_priv.h
+#include scsi_transport_fc_internal.h
static int fc_queue_work(struct Scsi_Host *, struct work_struct *);
static void fc_vport_sched_delete(struct work_struct *work);
@@ -1956,6 +1957,19 @@ static int fc_user_scan(struct Scsi_Host *shost, uint
channel,
return 0;
}
+static int fc_tsk_mgmt_response(struct Scsi_Host *shost, u64 nexus, u64 tm_id,
+ int result)
+{
+ struct fc_internal *i = to_fc_internal(shost-transportt);
+ return i-f-tsk_mgmt_response(shost, nexus, tm_id, result);
+}
+
+static int fc_it_nexus_response(struct Scsi_Host *shost, u64 nexus, int result)
+{
+ struct fc_internal *i = to_fc_internal(shost-transportt);
+ return i-f-it_nexus_response(shost, nexus, result);
+}
+
struct scsi_transport_template *
fc_attach_transport(struct fc_function_template *ft)
{
@@ -1999,6 +2013,10 @@ fc_attach_transport(struct fc_function_template *ft)
i-t.user_scan = fc_user_scan;
+ /* target-mode drivers' functions */
+ i-t.tsk_mgmt_response = fc_tsk_mgmt_response;
+ i-t.it_nexus_response = fc_it_nexus_response;
+
/*
* Setup SCSI Target Attributes.
*/
@@ -2756,6 +2774,10 @@ fc_remote_port_delete(struct fc_rport *rport)
spin_unlock_irqrestore(shost-host_lock, flags);
+ if (rport-roles FC_PORT_ROLE_FCP_INITIATOR
+ shost-active_mode MODE_TARGET)
+ fc_tgt_it_nexus_destroy(shost, (unsigned long)rport);
+
scsi_target_block(rport-dev);
/* see if we need to kill io faster than waiting for device loss */
@@ -2796,6 +2818,7 @@ fc_remote_port_rolechg(struct fc_rport *rport, u32 roles)
struct fc_host_attrs *fc_host = shost_to_fc_host(shost);
unsigned long flags;
int create = 0;
+ int ret;
spin_lock_irqsave(shost-host_lock, flags);
if (roles FC_PORT_ROLE_FCP_TARGET) {
@@ -2804,6 +2827,12 @@ fc_remote_port_rolechg(struct fc_rport *rport, u32
roles)
create = 1;
} else if (!(rport-roles FC_PORT_ROLE_FCP_TARGET))
create = 1;
+ } else if (shost-active_mode MODE_TARGET) {
+ ret = fc_tgt_it_nexus_create(shost, (unsigned long)rport,
+(char *)rport-node_name);
+ if (ret)
+ printk(KERN_ERR FC Remore Port tgt nexus failed %d\n,
+ ret);
}
rport-roles = roles;
diff --git a/drivers/scsi/scsi_transport_fc_internal.h
b/drivers/scsi/scsi_transport_fc_internal.h
new file mode 100644
index 000..e7bfbe7
--- /dev/null
+++ b/drivers/scsi/scsi_transport_fc_internal.h
@@ -0,0 +1,26 @@
+#include scsi/scsi_tgt.h
+
+#ifdef CONFIG_SCSI_FC_TGT_ATTRS
+static inline int fc_tgt_it_nexus_create(struct Scsi_Host *shost, u64 itn_id,
+char *initiator)
+{
+ return scsi_tgt_it_nexus_create(shost, itn_id, initiator);
+}
+
+static inline int fc_tgt_it_nexus_destroy(struct Scsi_Host *shost, u64 itn_id)
+{
+ return scsi_tgt_it_nexus_destroy(shost, itn_id);
+}
+#else
+static inline int fc_tgt_it_nexus_create(struct Scsi_Host *shost, u64 itn_id,
+char
[PATCH 5/5] srp_transport: convert to use supported_mode attribute
srp transport works for target drivers without supported_mode
attribute but it would be better to use it explicitly.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/ibmvscsi/ibmvstgt.c |1 +
drivers/scsi/scsi_transport_srp.c | 10 ++
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvstgt.c b/drivers/scsi/ibmvscsi/ibmvstgt.c
index 3db03dd..82bcab6 100644
--- a/drivers/scsi/ibmvscsi/ibmvstgt.c
+++ b/drivers/scsi/ibmvscsi/ibmvstgt.c
@@ -820,6 +820,7 @@ static struct scsi_host_template ibmvstgt_sht = {
.eh_abort_handler = ibmvstgt_eh_abort_handler,
.shost_attrs= ibmvstgt_attrs,
.proc_name = TGT_NAME,
+ .supported_mode = MODE_TARGET,
};
static int ibmvstgt_probe(struct vio_dev *dev, const struct vio_device_id *id)
diff --git a/drivers/scsi/scsi_transport_srp.c
b/drivers/scsi/scsi_transport_srp.c
index 430501e..44a340b 100644
--- a/drivers/scsi/scsi_transport_srp.c
+++ b/drivers/scsi/scsi_transport_srp.c
@@ -222,7 +222,8 @@ struct srp_rport *srp_rport_add(struct Scsi_Host *shost,
return ERR_PTR(ret);
}
- if (ids-roles == SRP_RPORT_ROLE_INITIATOR) {
+ if (shost-active_mode MODE_TARGET
+ ids-roles == SRP_RPORT_ROLE_INITIATOR) {
ret = srp_tgt_it_nexus_create(shost, (unsigned long)rport,
rport-port_id);
if (ret) {
@@ -249,10 +250,11 @@ EXPORT_SYMBOL_GPL(srp_rport_add);
void srp_rport_del(struct srp_rport *rport)
{
struct device *dev = rport-dev;
+ struct Scsi_Host *shost = dev_to_shost(dev-parent);
- if (rport-roles == SRP_RPORT_ROLE_INITIATOR)
- srp_tgt_it_nexus_destroy(dev_to_shost(dev-parent),
-(unsigned long)rport);
+ if (shost-active_mode MODE_TARGET
+ rport-roles == SRP_RPORT_ROLE_INITIATOR)
+ srp_tgt_it_nexus_destroy(shost, (unsigned long)rport);
transport_remove_device(dev);
device_del(dev);
--
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] add use_sg_chaining option to scsi_host_template
On Mon, 20 Aug 2007 09:10:31 +0200 Jens Axboe [EMAIL PROTECTED] wrote: On Sat, Aug 18 2007, FUJITA Tomonori wrote: On Fri, 17 Aug 2007 01:47:59 +0900 FUJITA Tomonori [EMAIL PROTECTED] wrote: This is for Jens' sglist branch in the block git tree. It enables sg chaining support for the LLDs that use scsi_for_each_sg accessor properly. --- From a6e50a3b476bc193de103e8c1d95877ced38918e Mon Sep 17 00:00:00 2001 From: FUJITA Tomonori [EMAIL PROTECTED] Date: Fri, 17 Aug 2007 01:35:41 +0900 Subject: [PATCH] add use_sg_chaining option to scsi_host_template This option is true if a low-level driver can support sg chaining. This will be removed eventually when all the drivers are converted to support sg chaining. q-max_phys_segments is set to SCSI_MAX_SG_SEGMENTS if false. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- arch/ia64/hp/sim/simscsi.c|1 + drivers/scsi/3w-9xxx.c|1 + drivers/scsi/3w-.c|1 + drivers/scsi/BusLogic.c |1 + drivers/scsi/NCR53c406a.c |3 ++- drivers/scsi/a100u2w.c|1 + drivers/scsi/aacraid/linit.c |1 + drivers/scsi/aha1740.c|1 + drivers/scsi/aic7xxx/aic79xx_osm.c|1 + drivers/scsi/aic7xxx/aic7xxx_osm.c|1 + drivers/scsi/aic7xxx_old.c|1 + drivers/scsi/arcmsr/arcmsr_hba.c |1 + drivers/scsi/dc395x.c |1 + drivers/scsi/dpt_i2o.c|1 + drivers/scsi/eata.c |3 ++- drivers/scsi/hosts.c |1 + drivers/scsi/hptiop.c |1 + drivers/scsi/ibmmca.c |1 + drivers/scsi/ibmvscsi/ibmvscsi.c |1 + drivers/scsi/initio.c |1 + drivers/scsi/ipr.c|1 + I should have dropped ipr since we haven't converted libata yet. But we have, are there still bits missing? I'm just a bit nervous about possible bugs. Probably we need to remove blk_queue_max_phys_segments() in libata for a possible lower sg list size ( 128). BTW, I think that it would be good to test the sglist with a lower sg list size (like 32) to test all the llds. diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index d23a181..01a0197 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -795,8 +795,6 @@ int ata_scsi_slave_config(struct scsi_device *sdev) ata_scsi_sdev_config(sdev); - blk_queue_max_phys_segments(sdev-request_queue, LIBATA_MAX_PRD); - sdev-manage_start_stop = 1; if (dev) - 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] add use_sg_chaining option to scsi_host_template
On Mon, 20 Aug 2007 15:05:22 +0200 Jens Axboe [EMAIL PROTECTED] wrote: On Mon, Aug 20 2007, FUJITA Tomonori wrote: On Mon, 20 Aug 2007 09:10:31 +0200 Jens Axboe [EMAIL PROTECTED] wrote: On Sat, Aug 18 2007, FUJITA Tomonori wrote: On Fri, 17 Aug 2007 01:47:59 +0900 FUJITA Tomonori [EMAIL PROTECTED] wrote: This is for Jens' sglist branch in the block git tree. It enables sg chaining support for the LLDs that use scsi_for_each_sg accessor properly. --- From a6e50a3b476bc193de103e8c1d95877ced38918e Mon Sep 17 00:00:00 2001 From: FUJITA Tomonori [EMAIL PROTECTED] Date: Fri, 17 Aug 2007 01:35:41 +0900 Subject: [PATCH] add use_sg_chaining option to scsi_host_template This option is true if a low-level driver can support sg chaining. This will be removed eventually when all the drivers are converted to support sg chaining. q-max_phys_segments is set to SCSI_MAX_SG_SEGMENTS if false. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- arch/ia64/hp/sim/simscsi.c|1 + drivers/scsi/3w-9xxx.c|1 + drivers/scsi/3w-.c|1 + drivers/scsi/BusLogic.c |1 + drivers/scsi/NCR53c406a.c |3 ++- drivers/scsi/a100u2w.c|1 + drivers/scsi/aacraid/linit.c |1 + drivers/scsi/aha1740.c|1 + drivers/scsi/aic7xxx/aic79xx_osm.c|1 + drivers/scsi/aic7xxx/aic7xxx_osm.c|1 + drivers/scsi/aic7xxx_old.c|1 + drivers/scsi/arcmsr/arcmsr_hba.c |1 + drivers/scsi/dc395x.c |1 + drivers/scsi/dpt_i2o.c|1 + drivers/scsi/eata.c |3 ++- drivers/scsi/hosts.c |1 + drivers/scsi/hptiop.c |1 + drivers/scsi/ibmmca.c |1 + drivers/scsi/ibmvscsi/ibmvscsi.c |1 + drivers/scsi/initio.c |1 + drivers/scsi/ipr.c|1 + I should have dropped ipr since we haven't converted libata yet. But we have, are there still bits missing? I'm just a bit nervous about possible bugs. I hope there aren't any left in libata :-) Probably we need to remove blk_queue_max_phys_segments() in libata for a possible lower sg list size ( 128). Indeed, that should go, even in mainline now. BTW, I think that it would be good to test the sglist with a lower sg list size (like 32) to test all the llds. That's a good idea, then we'll get the chaining stuff exercised much more easily! Yeah, if you push sglist with setting SCSI_MAX_SG_SEGMENTS to 32, sglist can get tons of tests. I didn't found the ppc sglist bugs and didn't lose my data until I tried a small sg list size. :) - 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] add use_sg_chaining option to scsi_host_template
On Fri, 17 Aug 2007 01:47:59 +0900 FUJITA Tomonori [EMAIL PROTECTED] wrote: This is for Jens' sglist branch in the block git tree. It enables sg chaining support for the LLDs that use scsi_for_each_sg accessor properly. --- From a6e50a3b476bc193de103e8c1d95877ced38918e Mon Sep 17 00:00:00 2001 From: FUJITA Tomonori [EMAIL PROTECTED] Date: Fri, 17 Aug 2007 01:35:41 +0900 Subject: [PATCH] add use_sg_chaining option to scsi_host_template This option is true if a low-level driver can support sg chaining. This will be removed eventually when all the drivers are converted to support sg chaining. q-max_phys_segments is set to SCSI_MAX_SG_SEGMENTS if false. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- arch/ia64/hp/sim/simscsi.c|1 + drivers/scsi/3w-9xxx.c|1 + drivers/scsi/3w-.c|1 + drivers/scsi/BusLogic.c |1 + drivers/scsi/NCR53c406a.c |3 ++- drivers/scsi/a100u2w.c|1 + drivers/scsi/aacraid/linit.c |1 + drivers/scsi/aha1740.c|1 + drivers/scsi/aic7xxx/aic79xx_osm.c|1 + drivers/scsi/aic7xxx/aic7xxx_osm.c|1 + drivers/scsi/aic7xxx_old.c|1 + drivers/scsi/arcmsr/arcmsr_hba.c |1 + drivers/scsi/dc395x.c |1 + drivers/scsi/dpt_i2o.c|1 + drivers/scsi/eata.c |3 ++- drivers/scsi/hosts.c |1 + drivers/scsi/hptiop.c |1 + drivers/scsi/ibmmca.c |1 + drivers/scsi/ibmvscsi/ibmvscsi.c |1 + drivers/scsi/initio.c |1 + drivers/scsi/ipr.c|1 + I should have dropped ipr since we haven't converted libata yet. - 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] add use_sg_chaining option to scsi_host_template
This is for Jens' sglist branch in the block git tree.
It enables sg chaining support for the LLDs that use scsi_for_each_sg
accessor properly.
---
From a6e50a3b476bc193de103e8c1d95877ced38918e Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Fri, 17 Aug 2007 01:35:41 +0900
Subject: [PATCH] add use_sg_chaining option to scsi_host_template
This option is true if a low-level driver can support sg
chaining. This will be removed eventually when all the drivers are
converted to support sg chaining. q-max_phys_segments is set to
SCSI_MAX_SG_SEGMENTS if false.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
arch/ia64/hp/sim/simscsi.c|1 +
drivers/scsi/3w-9xxx.c|1 +
drivers/scsi/3w-.c|1 +
drivers/scsi/BusLogic.c |1 +
drivers/scsi/NCR53c406a.c |3 ++-
drivers/scsi/a100u2w.c|1 +
drivers/scsi/aacraid/linit.c |1 +
drivers/scsi/aha1740.c|1 +
drivers/scsi/aic7xxx/aic79xx_osm.c|1 +
drivers/scsi/aic7xxx/aic7xxx_osm.c|1 +
drivers/scsi/aic7xxx_old.c|1 +
drivers/scsi/arcmsr/arcmsr_hba.c |1 +
drivers/scsi/dc395x.c |1 +
drivers/scsi/dpt_i2o.c|1 +
drivers/scsi/eata.c |3 ++-
drivers/scsi/hosts.c |1 +
drivers/scsi/hptiop.c |1 +
drivers/scsi/ibmmca.c |1 +
drivers/scsi/ibmvscsi/ibmvscsi.c |1 +
drivers/scsi/initio.c |1 +
drivers/scsi/ipr.c|1 +
drivers/scsi/lpfc/lpfc_scsi.c |2 ++
drivers/scsi/mac53c94.c |1 +
drivers/scsi/megaraid.c |1 +
drivers/scsi/megaraid/megaraid_mbox.c |1 +
drivers/scsi/megaraid/megaraid_sas.c |1 +
drivers/scsi/mesh.c |1 +
drivers/scsi/nsp32.c |1 +
drivers/scsi/pcmcia/sym53c500_cs.c|1 +
drivers/scsi/qla2xxx/qla_os.c |2 ++
drivers/scsi/qla4xxx/ql4_os.c |1 +
drivers/scsi/qlogicfas.c |1 +
drivers/scsi/scsi_lib.c |5 -
drivers/scsi/stex.c |1 +
drivers/scsi/sym53c416.c |1 +
drivers/scsi/sym53c8xx_2/sym_glue.c |1 +
drivers/scsi/u14-34f.c|1 +
drivers/scsi/ultrastor.c |1 +
drivers/scsi/wd7000.c |1 +
include/scsi/scsi_host.h | 13 +
40 files changed, 59 insertions(+), 3 deletions(-)
diff --git a/arch/ia64/hp/sim/simscsi.c b/arch/ia64/hp/sim/simscsi.c
index e62694f..6fc2cba 100644
--- a/arch/ia64/hp/sim/simscsi.c
+++ b/arch/ia64/hp/sim/simscsi.c
@@ -361,6 +361,7 @@ static struct scsi_host_template driver_template = {
.max_sectors= 1024,
.cmd_per_lun= SIMSCSI_REQ_QUEUE_LEN,
.use_clustering = DISABLE_CLUSTERING,
+ .use_sg_chaining= ENABLE_SG_CHAINING,
};
static int __init
diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
index efd9d8d..fb14014 100644
--- a/drivers/scsi/3w-9xxx.c
+++ b/drivers/scsi/3w-9xxx.c
@@ -1990,6 +1990,7 @@ static struct scsi_host_template driver_template = {
.max_sectors= TW_MAX_SECTORS,
.cmd_per_lun= TW_MAX_CMDS_PER_LUN,
.use_clustering = ENABLE_CLUSTERING,
+ .use_sg_chaining= ENABLE_SG_CHAINING,
.shost_attrs= twa_host_attrs,
.emulated = 1
};
diff --git a/drivers/scsi/3w-.c b/drivers/scsi/3w-.c
index c7995fc..a64153b 100644
--- a/drivers/scsi/3w-.c
+++ b/drivers/scsi/3w-.c
@@ -2261,6 +2261,7 @@ static struct scsi_host_template driver_template = {
.max_sectors= TW_MAX_SECTORS,
.cmd_per_lun= TW_MAX_CMDS_PER_LUN,
.use_clustering = ENABLE_CLUSTERING,
+ .use_sg_chaining= ENABLE_SG_CHAINING,
.shost_attrs= tw_host_attrs,
.emulated = 1
};
diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index 9b20617..49e1ffa 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -3575,6 +3575,7 @@ static struct scsi_host_template Bus_Logic_template = {
.unchecked_isa_dma = 1,
.max_sectors = 128,
.use_clustering = ENABLE_CLUSTERING,
+ .use_sg_chaining = ENABLE_SG_CHAINING,
};
/*
diff --git a/drivers/scsi/NCR53c406a.c b/drivers/scsi/NCR53c406a.c
index eda8c48..3168a17 100644
--- a/drivers/scsi/NCR53c406a.c
+++ b/drivers/scsi/NCR53c406a.c
@@ -1066,7 +1066,8 @@ static struct scsi_host_template driver_template =
.sg_tablesize = 32/*SG_ALL*/ /*SG_NONE*/,
.cmd_per_lun = 1 /* commands per lun */,
.unchecked_isa_dma= 1
[PATCH] ppc sg chaining support fixes
This is for the sglist branch in Jens' block git tree.
---
From 445923d1a8ff272293af3aadb6e58f82e6439e98 Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Thu, 16 Aug 2007 02:25:32 +0900
Subject: [PATCH] ppc sg chaining support fixes
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
arch/powerpc/kernel/iommu.c |5 +++--
include/asm-powerpc/dma-mapping.h | 15 +--
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index a146856..324bbc1 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -342,7 +342,8 @@ int iommu_map_sg(struct iommu_table *tbl, struct
scatterlist *sglist,
if (novmerge || (dma_addr != dma_next)) {
/* Can't merge: create a new segment */
segstart = s;
- outcount++; outs++;
+ outcount++;
+ outs = sg_next(outs);
DBG(can't merge, new segment.\n);
} else {
outs-dma_length += s-length;
@@ -375,7 +376,7 @@ int iommu_map_sg(struct iommu_table *tbl, struct
scatterlist *sglist,
* next entry of the sglist if we didn't fill the list completely
*/
if (outcount incount) {
- outs++;
+ outs = sg_next(outs);
outs-dma_address = DMA_ERROR_CODE;
outs-dma_length = 0;
}
diff --git a/include/asm-powerpc/dma-mapping.h
b/include/asm-powerpc/dma-mapping.h
index 8e57c18..8ffc759 100644
--- a/include/asm-powerpc/dma-mapping.h
+++ b/include/asm-powerpc/dma-mapping.h
@@ -268,14 +268,15 @@ dma_map_page(struct device *dev, struct page *page,
#define dma_unmap_page(dev, handle, size, dir) ((void)0)
static inline int
-dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
+dma_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
enum dma_data_direction direction)
{
+ struct scatterlist *sg;
int i;
BUG_ON(direction == DMA_NONE);
- for (i = 0; i nents; i++, sg++) {
+ for_each_sg(sgl, sg, nents, i) {
BUG_ON(!sg-page);
__dma_sync_page(sg-page, sg-offset, sg-length, direction);
sg-dma_address = page_to_bus(sg-page) + sg-offset;
@@ -306,26 +307,28 @@ static inline void dma_sync_single_for_device(struct
device *dev,
}
static inline void dma_sync_sg_for_cpu(struct device *dev,
- struct scatterlist *sg, int nents,
+ struct scatterlist *sgl, int nents,
enum dma_data_direction direction)
{
+ struct scatterlist *sg;
int i;
BUG_ON(direction == DMA_NONE);
- for (i = 0; i nents; i++, sg++)
+ for_each_sg(sgl, sg, nents, i)
__dma_sync_page(sg-page, sg-offset, sg-length, direction);
}
static inline void dma_sync_sg_for_device(struct device *dev,
- struct scatterlist *sg, int nents,
+ struct scatterlist *sgl, int nents,
enum dma_data_direction direction)
{
+ struct scatterlist *sg;
int i;
BUG_ON(direction == DMA_NONE);
- for (i = 0; i nents; i++, sg++)
+ for_each_sg(sgl, sg, nents, i)
__dma_sync_page(sg-page, sg-offset, sg-length, direction);
}
--
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
[PATCH] microtek: convert to use the data buffer accessors
The patch is only compile tested.
---
From d5ad824bce0e5e3894a102fee74f1f7c36d639b7 Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Sun, 12 Aug 2007 15:33:23 +0900
Subject: [PATCH] microtek: convert to use the data buffer accessors
- remove the unnecessary map_single path.
- convert to use the new accessors for the sg lists and the
parameters.
TODO: sg chaining support
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/usb/image/microtek.c | 32 +---
1 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/image/microtek.c b/drivers/usb/image/microtek.c
index 768b2c1..59b57c3 100644
--- a/drivers/usb/image/microtek.c
+++ b/drivers/usb/image/microtek.c
@@ -446,7 +446,8 @@ static void mts_data_done( struct urb* transfer )
MTS_INT_INIT();
if ( context-data_length != transfer-actual_length ) {
- context-srb-resid = context-data_length -
transfer-actual_length;
+ scsi_set_resid(context-srb,
+ context-data_length - transfer-actual_length);
} else if ( unlikely(status) ) {
context-srb-result = (status == -ENOENT ? DID_ABORT :
DID_ERROR)16;
}
@@ -490,7 +491,7 @@ static void mts_command_done( struct urb *transfer )
context-data_pipe,
context-data,
context-data_length,
- context-srb-use_sg 1 ? mts_do_sg
: mts_data_done);
+ scsi_sg_count(context-srb) 1 ?
mts_do_sg : mts_data_done);
} else {
mts_get_status(transfer);
}
@@ -505,21 +506,22 @@ static void mts_do_sg (struct urb* transfer)
int status = transfer-status;
MTS_INT_INIT();
- MTS_DEBUG(Processing fragment %d of %d\n,
context-fragment,context-srb-use_sg);
+ MTS_DEBUG(Processing fragment %d of %d\n, context-fragment,
+ scsi_sg_count(context-srb));
if (unlikely(status)) {
context-srb-result = (status == -ENOENT ? DID_ABORT :
DID_ERROR)16;
mts_transfer_cleanup(transfer);
}
- sg = context-srb-request_buffer;
+ sg = scsi_sglist(context-srb);
context-fragment++;
mts_int_submit_urb(transfer,
context-data_pipe,
page_address(sg[context-fragment].page) +
sg[context-fragment].offset,
sg[context-fragment].length,
- context-fragment + 1 == context-srb-use_sg ?
mts_data_done : mts_do_sg);
+ context-fragment + 1 == scsi_sg_count(context-srb)
? mts_data_done : mts_do_sg);
return;
}
@@ -547,25 +549,17 @@ mts_build_transfer_context(struct scsi_cmnd *srb, struct
mts_desc* desc)
desc-context.srb = srb;
desc-context.fragment = 0;
- if (!srb-use_sg) {
- if ( !srb-request_bufflen ){
- desc-context.data = NULL;
- desc-context.data_length = 0;
- return;
- } else {
- desc-context.data = srb-request_buffer;
- desc-context.data_length = srb-request_bufflen;
- MTS_DEBUG(length = %d or %d\n,
- srb-request_bufflen, srb-bufflen);
- }
- } else {
+ if (scsi_sg_count(srb)) {
MTS_DEBUG(Using scatter/gather\n);
- sg = srb-request_buffer;
+ sg = scsi_sglist(srb);
desc-context.data = page_address(sg[0].page) + sg[0].offset;
desc-context.data_length = sg[0].length;
+ } else {
+ desc-context.data = NULL;
+ desc-context.data_length = 0;
+ return;
}
-
/* can't rely on srb-sc_data_direction */
/* Brutally ripped from usb-storage */
--
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] microtek: convert to use the data buffer accessors
On Sun, 12 Aug 2007 11:01:20 -0400 Harrosh, Boaz [EMAIL PROTECTED] wrote: FUJITA Tomonori wrote ... Subject: [PATCH] microtek: convert to use the data buffer accessors - remove the unnecessary map_single path. - convert to use the new accessors for the sg lists and the parameters. TODO: sg chaining support Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] Is this not the same as the patch I sent at 2007-07-12 http://marc.info/?l=linux-scsim=118424592500438w=4 And was ACKed by one of the maintainers: http://marc.info/?l=linux-scsim=118426360825803w=4 Oops, I didn't realized that. Isn't the patch in scsi-misc, scsi-pending, or scsi-fixes? - 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] sg: increase sglist_len of the sg_scatter_hold structure
On Wed, 08 Aug 2007 11:58:14 -0500 Mike Christie [EMAIL PROTECTED] wrote: FUJITA Tomonori wrote: On Tue, 07 Aug 2007 12:13:41 -0500 Mike Christie [EMAIL PROTECTED] wrote: FUJITA Tomonori wrote: Allocating 64K contiguous memory is not good so the next thing to do is converting sg to use the sg chaining support fully. Or it might be For LLDs like aic7xxx, I think we are stuck with a small scsi_host_template-sg_tablesize, so to continue to get large requests like before will we have to still allocate large segments? No. sg.c has: sizeof(struct scatterlist) * min(q-max_hw_segments, q-max_phys_segments) If a lld has small max_hw_segments, it doesn't allocate big contiguous memory. Are we talking about the same thing? Are you saying that it does not allocate big continuous memory for the scatterlist right? I was asking about continuous memory for the buffer sg.c copies data to/from for the IO operation. I was saying that currently for something like aic if we want to continue to support 8 MB commands (or whatever it was) like before, then because its sg_tablesize/max_hw_segments is so small we have to continue allocating large IO buffers. That did not change right? If so let me know because you save me :) Oops, sorry. I think that nothing changes about large IO buffers. You have to contiunue to allocate large IO buffers like before. - 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] sg: increase sglist_len of the sg_scatter_hold structure
On Wed, 08 Aug 2007 12:20:43 -0500 Mike Christie [EMAIL PROTECTED] wrote: Mike Christie wrote: For drivers like sg and st, do mean the the sg list that is passed to functions like scsi_execute_async? If we kill that argument, and instead have sg.c and other scsi_execute_async callers just call blk helpers like blk_rq_map_user then we would not have to worry about drivers like sg needing to know about chaining right? I mean sg.c would not every interact with a scatterlist. It would just interact with a request and the blk helpers map data for it. There should be a return there. The scatterlist that sg and st interact with is bogus. It gets thrown away in scsi_execute_async and is only used for book keeping. I mean currently the scatterlist that sg and st use is bogus and gets thrown away. If we convert sg and st to use blk_rq_map_user then those drivers will not have to interact with a scatterlist at all. Yeah, we should kill scsi_execute_async. sg should not be the consumer even if the block layer has functions to allocate chaining sg. Right now I'm happy as long as scsi-ml has the simple routine to allocate chaining sg like Jens's branch. So we might easily move it to the block layer or the block layer might just take care of the sg list for scsi-ml, etc in the future. - 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] fc4: convert to use the data buffer accessors
- remove the unnecessary map_single path.
- convert to use the new accessors for the sg lists and the
parameters.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/fc4/fc.c | 41 +++--
1 files changed, 15 insertions(+), 26 deletions(-)
diff --git a/drivers/fc4/fc.c b/drivers/fc4/fc.c
index 22b62b3..82de9e1 100644
--- a/drivers/fc4/fc.c
+++ b/drivers/fc4/fc.c
@@ -427,15 +427,10 @@ static inline void fcp_scsi_receive(fc_channel *fc, int
token, int status, fc_hd
memcpy(SCpnt-sense_buffer, ((char *)(rsp+1)),
sense_len);
}
- if (fcmd-data) {
- if (SCpnt-use_sg)
- dma_unmap_sg(fc-dev, (struct scatterlist
*)SCpnt-request_buffer,
- SCpnt-use_sg,
- SCpnt-sc_data_direction);
- else
- dma_unmap_single(fc-dev, fcmd-data,
SCpnt-request_bufflen,
-SCpnt-sc_data_direction);
- }
+ if (fcmd-data)
+ dma_unmap_sg(fc-dev, scsi_sglist(SCpnt),
+scsi_sg_count(SCpnt),
+SCpnt-sc_data_direction);
break;
default:
host_status=DID_ERROR; /* FIXME */
@@ -793,10 +788,14 @@ static int fcp_scsi_queue_it(fc_channel *fc, struct
scsi_cmnd *SCpnt,
fcp_cntl = FCP_CNTL_QTYPE_SIMPLE;
} else
fcp_cntl = FCP_CNTL_QTYPE_UNTAGGED;
- if (!SCpnt-request_bufflen !SCpnt-use_sg) {
+
+ if (!scsi_bufflen(SCpnt)) {
cmd-fcp_cntl = fcp_cntl;
fcmd-data = (dma_addr_t)NULL;
} else {
+ struct scatterlist *sg;
+ int nents;
+
switch (SCpnt-cmnd[0]) {
case WRITE_6:
case WRITE_10:
@@ -805,22 +804,12 @@ static int fcp_scsi_queue_it(fc_channel *fc, struct
scsi_cmnd *SCpnt,
default:
cmd-fcp_cntl = (FCP_CNTL_READ | fcp_cntl);
break;
}
- if (!SCpnt-use_sg) {
- cmd-fcp_data_len = SCpnt-request_bufflen;
- fcmd-data = dma_map_single (fc-dev, (char
*)SCpnt-request_buffer,
-
SCpnt-request_bufflen,
-
SCpnt-sc_data_direction);
- } else {
- struct scatterlist *sg = (struct scatterlist
*)SCpnt-request_buffer;
- int nents;
-
- FCD((XXX: Use_sg %d %d\n, SCpnt-use_sg,
sg-length))
- nents = dma_map_sg (fc-dev, sg, SCpnt-use_sg,
- SCpnt-sc_data_direction);
- if (nents 1) printk (%s: SG for nents %d
(use_sg %d) not handled yet\n, fc-name, nents, SCpnt-use_sg);
- fcmd-data = sg_dma_address(sg);
- cmd-fcp_data_len = sg_dma_len(sg);
- }
+
+ sg = scsi_sglist(SCpnt);
+ nents = dma_map_sg(fc-dev, sg, scsi_sg_count(SCpnt),
+ SCpnt-sc_data_direction);
+ fcmd-data = sg_dma_address(sg);
+ cmd-fcp_data_len = sg_dma_len(sg);
}
memcpy (cmd-fcp_cdb, SCpnt-cmnd, SCpnt-cmd_len);
memset (cmd-fcp_cdb+SCpnt-cmd_len, 0,
sizeof(cmd-fcp_cdb)-SCpnt-cmd_len);
--
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: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining
On Tue, 7 Aug 2007 08:55:49 +0200
Jens Axboe [EMAIL PROTECTED] wrote:
On Mon, Aug 06 2007, FUJITA Tomonori wrote:
On Tue, 31 Jul 2007 23:12:26 +0300
Boaz Harrosh [EMAIL PROTECTED] wrote:
The tested Kernels:
1. Jens's sglist-arch
I was not able to pass all tests with this Kernel. For some reason when
bigger than 256 pages commands are queued the Machine will run out
of memory and will kill the test. After the test is killed the system
is left with 10M of memory and can hardly reboot.
I have done some prints at the queuecommand entry in scsi_debug.c
and I can see that I receive the expected large sg_count and bufflen
but unlike other tests I get a different pointer at scsi_sglist().
In other tests since nothing is happening at this machine while in
the test, the sglist pointer is always the same. commands comes in,
allocates memory, do nothing in scsi_debug, freed, and returns.
I suspect sglist leak or allocation bug.
Ok, I found the leak.
From 011c05c2e514d1db4834147ed83526473711b0a3 Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Mon, 6 Aug 2007 16:16:24 +0900
Subject: [PATCH] fix sg chaining leak
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/scsi_lib.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 5884b1b..25988b9 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -48,7 +48,6 @@ static struct scsi_host_sg_pool scsi_sg_pools[] = {
SP(32),
SP(64),
SP(128),
- SP(256),
};
#undef SP
Thanks Tomo! Trying to catch up with mails, will apply this one right
away.
You can add the following patch to your sglist branches:
From abd73c05d5f08ee307776150e1deecac7a709b60 Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Mon, 30 Jul 2007 23:01:32 +0900
Subject: [PATCH] zfcp: sg chaining support
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/s390/scsi/zfcp_def.h |1 +
drivers/s390/scsi/zfcp_qdio.c |6 ++
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/s390/scsi/zfcp_def.h b/drivers/s390/scsi/zfcp_def.h
index b36dfc4..0d80150 100644
--- a/drivers/s390/scsi/zfcp_def.h
+++ b/drivers/s390/scsi/zfcp_def.h
@@ -34,6 +34,7 @@
#include linux/slab.h
#include linux/mempool.h
#include linux/syscalls.h
+#include linux/scatterlist.h
#include linux/ioctl.h
#include scsi/scsi.h
#include scsi/scsi_tcq.h
diff --git a/drivers/s390/scsi/zfcp_qdio.c b/drivers/s390/scsi/zfcp_qdio.c
index 81daa82..60bc269 100644
--- a/drivers/s390/scsi/zfcp_qdio.c
+++ b/drivers/s390/scsi/zfcp_qdio.c
@@ -591,7 +591,7 @@ zfcp_qdio_sbals_from_segment(struct zfcp_fsf_req *fsf_req,
unsigned long sbtype,
*/
int
zfcp_qdio_sbals_from_sg(struct zfcp_fsf_req *fsf_req, unsigned long sbtype,
-struct scatterlist *sg,int sg_count, int
max_sbals)
+struct scatterlist *sgl, int sg_count, int max_sbals)
{
int sg_index;
struct scatterlist *sg_segment;
@@ -607,9 +607,7 @@ zfcp_qdio_sbals_from_sg(struct zfcp_fsf_req *fsf_req,
unsigned long sbtype,
sbale-flags |= sbtype;
/* process all segements of scatter-gather list */
- for (sg_index = 0, sg_segment = sg, bytes = 0;
-sg_index sg_count;
-sg_index++, sg_segment++) {
+ for_each_sg(sgl, sg_segment, sg_count, sg_index) {
retval = zfcp_qdio_sbals_from_segment(
fsf_req,
sbtype,
--
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: [GIT PATCH] scsi bug fixes for 2.6.23-rc2
On Tue, 7 Aug 2007 00:14:29 -0700 Andrew Morton [EMAIL PROTECTED] wrote: On Mon, 06 Aug 2007 22:55:41 -0500 James Bottomley [EMAIL PROTECTED] wrote: The real root cause of all of this is that there's no tree I can persuade all the interested parties to test that includes all of these features. In spite of the fact they've all been incubating in -mm for at least 3 months, no-one apparently tested all the features together until 2.6.23-rc1 was released, so then we're scrambling to address the issues as they arise. I pulled git-scsi-misc on July 19 and there was no bsg code in there at all. I pulled again on July 20 and all the bsg code was in mainline. So it appears that the bsg code went mailing-list - mainline in less than 24 hours, so there wasn't a lot of opportunity for -mm testing there. bsg was merged via Jens' branch. After that, I asked James to send some fixes via the scsi-rc-fixes. A lot of the stupid it-doesn't-compile stuff would have been fixed in -mm, but more substantial problems might not have been picked up. But one can say that about anything. My mistake. I should have sent bsg to -mm. Sorry about that. - 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] sg: increase sglist_len of the sg_scatter_hold structure
On Tue, 07 Aug 2007 12:13:41 -0500 Mike Christie [EMAIL PROTECTED] wrote: FUJITA Tomonori wrote: Allocating 64K contiguous memory is not good so the next thing to do is converting sg to use the sg chaining support fully. Or it might be For LLDs like aic7xxx, I think we are stuck with a small scsi_host_template-sg_tablesize, so to continue to get large requests like before will we have to still allocate large segments? No. sg.c has: sizeof(struct scatterlist) * min(q-max_hw_segments, q-max_phys_segments) If a lld has small max_hw_segments, it doesn't allocate big contiguous memory. Is block/scsi_ioctl.c converted to sg chaining in any tree yet? Is that in your tree or one of Jen's branches. block/scsi_ioctl.c uses the standard block layer functions, there is nothing to convert in it. sglist doesn't change the standard block layer functions much since it doesn't allocate sg list. It changes only blk_rq_map_sg. Now only scsi-ml is changed to allocate chaining sg list properly. Others like cciss are not converted yet, I think. It might make sense to have the standard block layer functions to allocate chaining sg list properly. So we could convert to potential consumers (scsi-ml, sg, ccisss, etc) use them though I'm not sure how many non scsi-ml needs chaining sg list. - 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, 31 Jul 2007 23:12:26 +0300
Boaz Harrosh [EMAIL PROTECTED] wrote:
The tested Kernels:
1. Jens's sglist-arch
I was not able to pass all tests with this Kernel. For some reason when
bigger than 256 pages commands are queued the Machine will run out
of memory and will kill the test. After the test is killed the system
is left with 10M of memory and can hardly reboot.
I have done some prints at the queuecommand entry in scsi_debug.c
and I can see that I receive the expected large sg_count and bufflen
but unlike other tests I get a different pointer at scsi_sglist().
In other tests since nothing is happening at this machine while in
the test, the sglist pointer is always the same. commands comes in,
allocates memory, do nothing in scsi_debug, freed, and returns.
I suspect sglist leak or allocation bug.
Ok, I found the leak.
From 011c05c2e514d1db4834147ed83526473711b0a3 Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Mon, 6 Aug 2007 16:16:24 +0900
Subject: [PATCH] fix sg chaining leak
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/scsi_lib.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 5884b1b..25988b9 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -48,7 +48,6 @@ static struct scsi_host_sg_pool scsi_sg_pools[] = {
SP(32),
SP(64),
SP(128),
- SP(256),
};
#undef SP
--
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
[PATCH] sg: increase sglist_len of the sg_scatter_hold structure
unsigned short is too small for sizeof(struct scatterlist) *
min(q-max_hw_segments, q-max_phys_segments).
This fixes memory leak with 4096 segments since 16 (likely sg size
with x86) * 4096 sets sglist_len to zero.
This might not happen without sg chaining support.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/sg.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 2fc24e7..2c44bb0 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -114,7 +114,7 @@ static struct class_interface sg_interface = {
typedef struct sg_scatter_hold { /* holding area for scsi scatter gather info
*/
unsigned short k_use_sg; /* Count of kernel scatter-gather pieces */
- unsigned short sglist_len; /* size of malloc'd scatter-gather list ++ */
+ unsigned sglist_len; /* size of malloc'd scatter-gather list ++ */
unsigned bufflen; /* Size of (aggregate) data buffer */
unsigned b_malloc_len; /* actual len malloc'ed in buffer */
struct scatterlist *buffer;/* scatter list */
--
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: [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, 31 Jul 2007 23:12:26 +0300 Boaz Harrosh wrote: FUJITA Tomonori wrote: From: Benny Halevy [EMAIL PROTECTED] Subject: Re: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining Date: Wed, 25 Jul 2007 11:26:44 +0300 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. I agree. This isn't a catholic marriage :) We'll run some performance experiments comparing the sgtable chaining implementation vs. a scsi_data_buff implementation pointing at a possibly chained sglist and let's see if we can measure any difference. We'll send results as soon as we have them. I did some tests with your sgtable patchset and the approach to use separate buffer for sglists. As expected, there was no performance difference with small I/Os. I've not tried very large I/Os, which might give some difference. Next week I will try to mount lots of scsi_debug devices and use large parallel IO to try and find a difference. I will test Jens's sglist-arch tree against above sglist-arch+scsi_sgtable I was able to run some tests here are my results. The results: PPT - is Pages Per Transfer (sg_count) The numbers are accumulated time of 20 transfers of 32GB each, and the average of 4 such runs. (Lower time is better) Transfers are sg_dd into scsi_debug Kernel | total time 128-PPT | total time 2048-PPT ---||- sglist-arch| 47.26 | Test Failed scsi_data_buff | 41.68 | 35.05 scsi_sgtable | 42.42 | 36.45 The test: 1. scsi_debug I mounted the scsi_debug module which was converted and fixed for chaining with the following options: $ modprobe scsi_debug virtual_gb=32 delay=0 dev_size_mb=32 fake_rw=1 32 GB of virtual drive on 32M of memory with 0 delay and read/write do nothing with the fake_rw=1. After that I just enabled chained IO on the device So what I'm actually testing is only sg + scsi-ml request queuing and sglist allocation/deallocation. Which is what I want to test. 2. sg_dd In the test script (see prof_test_scsi_debug attached) I use sg_dd in direct io mode to send a direct scsi-command to above device. Your script is doing: sg_dd blk_sgio=1 dio=1 if=/dev/zero of=/dev/sdb ... dio works for SG_IO? Only sg suuports it, I think. And sd_read is more appropriate than sg_dd for performance tests. I'm not sure about the results. How can sglist-arch be slower than scsi_data_buff and scsi_sgtable. I did 2 tests, in both I transfer 32GB of data. 1st test with 128 (4K) pages IO size. 2nd test with 2048 pages IO size. The second test will successfully run only if chaining is enabled and working. Otherwise it will fail. The tested Kernels: 1. Jens's sglist-arch I was not able to pass all tests with this Kernel. For some reason when bigger than 256 pages commands are queued the Machine will run out of memory and will kill the test. After the test is killed the system is left with 10M of memory and can hardly reboot. sglist-arch works for me. I hit memory leak due to the sg (I used sg instead of SG_IO) bug though the bug happens even with scsi_data_buff and sgtable. 2. scsi_data_buff This tree is what I posted last. It is basically: 0. sglist-arch 1. revert of scsi-ml support for chaining. 2. sg-pools cleanup [PATCH AB1] I don't think this is the proper way. As I said, we can implement scsi_data_buffer stuff on the top of sglist cleanly. No need to revert something in sglist. I don't think that sg-pools cleanup is necessary. We can live without the sg segment size hack due to sglist. My scsi data buffer patch is at: git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git sdbuffer The differences are: I use 'scsi_data_buffer structure' instead of scsi_data_buff; it's on the top of sglist cleanly. I also put your scsi_data_buff and sgtable patchset: git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git boaz-sdbuff git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git boaz-sgtable - 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] sg: increase sglist_len of the sg_scatter_hold structure
On Sun, 05 Aug 2007 12:55:16 -0400
Douglas Gilbert [EMAIL PROTECTED] wrote:
FUJITA Tomonori wrote:
unsigned short is too small for sizeof(struct scatterlist) *
min(q-max_hw_segments, q-max_phys_segments).
This fixes memory leak with 4096 segments since 16 (likely sg size
with x86) * 4096 sets sglist_len to zero.
This might not happen without sg chaining support.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/sg.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 2fc24e7..2c44bb0 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -114,7 +114,7 @@ static struct class_interface sg_interface = {
typedef struct sg_scatter_hold { /* holding area for scsi scatter gather
info */
unsigned short k_use_sg; /* Count of kernel scatter-gather pieces */
- unsigned short sglist_len; /* size of malloc'd scatter-gather list ++ */
+ unsigned sglist_len; /* size of malloc'd scatter-gather list ++ */
unsigned bufflen; /* Size of (aggregate) data buffer */
unsigned b_malloc_len; /* actual len malloc'ed in buffer */
struct scatterlist *buffer;/* scatter list */
Tomo,
Thanks.
Signed-off-by: Douglas Gilbert [EMAIL PROTECTED]
Thanks for the quick reply.
Allocating 64K contiguous memory is not good so the next thing to do
is converting sg to use the sg chaining support fully. Or it might be
time to finish the overdue task, to convert sg to use the block layer
functions.
-
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] scsi_transport_srp: remove tgt dependencies
Hopefully, this works. Is there an easier way to remove tgt
dependencies in scsi_transport_srp?
---
From 00924b31df30e4ddcf9ba9b5082171e5e46b9eb0 Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Thu, 2 Aug 2007 00:03:11 +0900
Subject: [PATCH] scsi_transport_srp: remove tgt dependencies
it's better to remove tgt dependencies in srp transport class since
most people want only initiator support.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/Kconfig | 11 +--
drivers/scsi/scsi_transport_srp.c | 10 +-
drivers/scsi/scsi_transport_srp_internal.h | 25 +
3 files changed, 39 insertions(+), 7 deletions(-)
create mode 100644 drivers/scsi/scsi_transport_srp_internal.h
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 4562273..7877dfd 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -291,11 +291,18 @@ source drivers/scsi/libsas/Kconfig
config SCSI_SRP_ATTRS
tristate SRP Transport Attributes
- depends on SCSI SCSI_TGT
+ depends on SCSI
help
If you wish to export transport-specific information about
each attached SRP device to sysfs, say Y.
+config SCSI_SRP_TGT_ATTRS
+ bool SCSI target support for SRP Transport Attributes
+ depends on SCSI_SRP_ATTRS
+ depends on SCSI_TGT = y || SCSI_TGT = SCSI_SRP_ATTRS
+ help
+ If you want to use SCSI target mode drivers enable this option.
+
endmenu
menuconfig SCSI_LOWLEVEL
@@ -848,7 +855,7 @@ config SCSI_IBMVSCSI
config SCSI_IBMVSCSIS
tristate IBM Virtual SCSI Server support
- depends on PPC_PSERIES SCSI_TGT SCSI_SRP SCSI_SRP_ATTRS
+ depends on PPC_PSERIES SCSI_SRP SCSI_SRP_TGT_ATTRS
help
This is the SRP target driver for IBM pSeries virtual environments.
diff --git a/drivers/scsi/scsi_transport_srp.c
b/drivers/scsi/scsi_transport_srp.c
index cdd001a..430501e 100644
--- a/drivers/scsi/scsi_transport_srp.c
+++ b/drivers/scsi/scsi_transport_srp.c
@@ -30,7 +30,7 @@
#include scsi/scsi_host.h
#include scsi/scsi_transport.h
#include scsi/scsi_transport_srp.h
-#include scsi/scsi_tgt.h
+#include scsi_transport_srp_internal.h
struct srp_host_attrs {
atomic_t next_port_id;
@@ -223,8 +223,8 @@ struct srp_rport *srp_rport_add(struct Scsi_Host *shost,
}
if (ids-roles == SRP_RPORT_ROLE_INITIATOR) {
- ret = scsi_tgt_it_nexus_create(shost, (unsigned long)rport,
- rport-port_id);
+ ret = srp_tgt_it_nexus_create(shost, (unsigned long)rport,
+ rport-port_id);
if (ret) {
device_del(rport-dev);
transport_destroy_device(rport-dev);
@@ -251,8 +251,8 @@ void srp_rport_del(struct srp_rport *rport)
struct device *dev = rport-dev;
if (rport-roles == SRP_RPORT_ROLE_INITIATOR)
- scsi_tgt_it_nexus_destroy(dev_to_shost(dev-parent),
- (unsigned long)rport);
+ srp_tgt_it_nexus_destroy(dev_to_shost(dev-parent),
+(unsigned long)rport);
transport_remove_device(dev);
device_del(dev);
diff --git a/drivers/scsi/scsi_transport_srp_internal.h
b/drivers/scsi/scsi_transport_srp_internal.h
new file mode 100644
index 000..8a79747
--- /dev/null
+++ b/drivers/scsi/scsi_transport_srp_internal.h
@@ -0,0 +1,25 @@
+#include scsi/scsi_tgt.h
+
+#ifdef CONFIG_SCSI_SRP_TGT_ATTRS
+static inline int srp_tgt_it_nexus_create(struct Scsi_Host *shost, u64 itn_id,
+ char *initiator)
+{
+ return scsi_tgt_it_nexus_create(shost, itn_id, initiator);
+}
+
+static inline int srp_tgt_it_nexus_destroy(struct Scsi_Host *shost, u64 itn_id)
+{
+ return scsi_tgt_it_nexus_destroy(shost, itn_id);
+}
+
+#else
+static inline int srp_tgt_it_nexus_create(struct Scsi_Host *shost, u64 itn_id,
+ char *initiator)
+{
+ return 0;
+}
+static inline int srp_tgt_it_nexus_destroy(struct Scsi_Host *shost, u64 itn_id)
+{
+ return 0;
+}
+#endif
--
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 0/5] mpt fusion: Add logging support
On Tue, 31 Jul 2007 12:40:41 -0600 Moore, Eric [EMAIL PROTECTED] wrote: On Monday, July 30, 2007 4:32 PM, FUJITA Tomonori wrote: On another note, while unloading the driver, and I get an following opps from bsg in the context of scsi_remove_host. This is w/o the SMP passthrough patch, so why would fusion drivers be linked to bsg? Woudn't this break mptspi and mptfc, since they will not be working with bsg. Call Trace: [881f519c] :scsi_transport_sas:sas_bsg_remove+0x27/0x32 [881f6349] :scsi_transport_sas:sas_host_remove+0x30/0x34 [80375326] transport_remove_classdev+0x1d/0x4c [80375001] attribute_container_device_trigger+0x69/0xa7 [8803778b] :scsi_mod:scsi_remove_host+0xcd/0xfa [883461ac] :mptscsih:mptscsih_remove+0x32/0xae [8031416d] pci_device_remove+0x24/0x48 [803720ed] __device_release_driver+0x91/0xb3 [80372631] driver_detach+0xd6/0x115 [80371ba3] bus_remove_driver+0x6d/0x90 [803143f4] pci_unregister_driver+0x17/0x6b [88355044] :mptsas:mptsas_exit+0x10/0x5f [80252afb] sys_delete_module+0x1b1/0x1e0 [80307d9c] __up_write+0x21/0x10d [8020bc4e] system_call+0x7e/0x83 This patch fix the problem? --- From: FUJITA Tomonori [EMAIL PROTECTED] Subject: [PATCH] scsi_transport_sas: initialize sas_host_attrs-q fix the bug to call bsg_unregister_queue for an uninitialized queue. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] yes it does fix it. I'm not sure if this has already been posted to lsml@, but please apply to scsi-rc-fixes-2.6. The following patch should fix this problem: http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-rc-fixes-2.6.git;a=commit;h=c000c43cf12090972fad0fbb621d78c2100d0373 - 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: git-scsi-misc build error
On Tue, 31 Jul 2007 15:41:34 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 31 Jul 2007 17:30:52 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Tue, 2007-07-31 at 15:27 -0700, Andrew Morton wrote:
ERROR: scsi_tgt_it_nexus_create [drivers/scsi/scsi_transport_srp.ko]
undefined!
ERROR: scsi_tgt_it_nexus_destroy [drivers/scsi/scsi_transport_srp.ko]
undefined!
This bug was reported about seven times against 2.6.23-rc1-mm1's
git-scsi-target, and now it has been moved into git-scsi-misc.
Yes ... Tomo's on the hook for a better fix, which is promised.
mutter.
Please, nothing which uses Kconfig `select'. They regularly go wrong.
Please copy me on that fix so I know when to drop this one.
Really sorry about this issue that I should have fixed a long time
ago. The following patch was merged to scsi-misc. Hopefully it will
fix the issue.
---
From 00924b31df30e4ddcf9ba9b5082171e5e46b9eb0 Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Thu, 2 Aug 2007 00:03:11 +0900
Subject: [PATCH] scsi_transport_srp: remove tgt dependencies
it's better to remove tgt dependencies in srp transport class since
most people want only initiator support.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/Kconfig | 11 +--
drivers/scsi/scsi_transport_srp.c | 10 +-
drivers/scsi/scsi_transport_srp_internal.h | 25 +
3 files changed, 39 insertions(+), 7 deletions(-)
create mode 100644 drivers/scsi/scsi_transport_srp_internal.h
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 4562273..7877dfd 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -291,11 +291,18 @@ source drivers/scsi/libsas/Kconfig
config SCSI_SRP_ATTRS
tristate SRP Transport Attributes
- depends on SCSI SCSI_TGT
+ depends on SCSI
help
If you wish to export transport-specific information about
each attached SRP device to sysfs, say Y.
+config SCSI_SRP_TGT_ATTRS
+ bool SCSI target support for SRP Transport Attributes
+ depends on SCSI_SRP_ATTRS
+ depends on SCSI_TGT = y || SCSI_TGT = SCSI_SRP_ATTRS
+ help
+ If you want to use SCSI target mode drivers enable this option.
+
endmenu
menuconfig SCSI_LOWLEVEL
@@ -848,7 +855,7 @@ config SCSI_IBMVSCSI
config SCSI_IBMVSCSIS
tristate IBM Virtual SCSI Server support
- depends on PPC_PSERIES SCSI_TGT SCSI_SRP SCSI_SRP_ATTRS
+ depends on PPC_PSERIES SCSI_SRP SCSI_SRP_TGT_ATTRS
help
This is the SRP target driver for IBM pSeries virtual environments.
diff --git a/drivers/scsi/scsi_transport_srp.c
b/drivers/scsi/scsi_transport_srp.c
index cdd001a..430501e 100644
--- a/drivers/scsi/scsi_transport_srp.c
+++ b/drivers/scsi/scsi_transport_srp.c
@@ -30,7 +30,7 @@
#include scsi/scsi_host.h
#include scsi/scsi_transport.h
#include scsi/scsi_transport_srp.h
-#include scsi/scsi_tgt.h
+#include scsi_transport_srp_internal.h
struct srp_host_attrs {
atomic_t next_port_id;
@@ -223,8 +223,8 @@ struct srp_rport *srp_rport_add(struct Scsi_Host *shost,
}
if (ids-roles == SRP_RPORT_ROLE_INITIATOR) {
- ret = scsi_tgt_it_nexus_create(shost, (unsigned long)rport,
- rport-port_id);
+ ret = srp_tgt_it_nexus_create(shost, (unsigned long)rport,
+ rport-port_id);
if (ret) {
device_del(rport-dev);
transport_destroy_device(rport-dev);
@@ -251,8 +251,8 @@ void srp_rport_del(struct srp_rport *rport)
struct device *dev = rport-dev;
if (rport-roles == SRP_RPORT_ROLE_INITIATOR)
- scsi_tgt_it_nexus_destroy(dev_to_shost(dev-parent),
- (unsigned long)rport);
+ srp_tgt_it_nexus_destroy(dev_to_shost(dev-parent),
+(unsigned long)rport);
transport_remove_device(dev);
device_del(dev);
diff --git a/drivers/scsi/scsi_transport_srp_internal.h
b/drivers/scsi/scsi_transport_srp_internal.h
new file mode 100644
index 000..8a79747
--- /dev/null
+++ b/drivers/scsi/scsi_transport_srp_internal.h
@@ -0,0 +1,25 @@
+#include scsi/scsi_tgt.h
+
+#ifdef CONFIG_SCSI_SRP_TGT_ATTRS
+static inline int srp_tgt_it_nexus_create(struct Scsi_Host *shost, u64 itn_id,
+ char *initiator)
+{
+ return scsi_tgt_it_nexus_create(shost, itn_id, initiator);
+}
+
+static inline int srp_tgt_it_nexus_destroy(struct Scsi_Host *shost, u64 itn_id)
+{
+ return scsi_tgt_it_nexus_destroy(shost, itn_id);
+}
+
+#else
+static inline int srp_tgt_it_nexus_create(struct Scsi_Host *shost, u64 itn_id,
+ char *initiator)
+{
+ return 0
Re: [PATCH 1/1] scsi: Fix SRP_ATTRS Kconfig
From: Brian King [EMAIL PROTECTED] Subject: [PATCH 1/1] scsi: Fix SRP_ATTRS Kconfig Date: Mon, 30 Jul 2007 11:12:10 -0500 Since the srp transport class was added, if scsi tgt support is not selected, the current Kconfig allows for enabling a dependent device driver, such as ibmvscsi, which does a select of SCSI_SRP_ATTRS. This does not, however, enable SCSI_TGT also. This fixes this up to prevent the following build problem: ERROR: .scsi_tgt_it_nexus_create [drivers/scsi/scsi_transport_srp.ko] undefined! ERROR: .scsi_tgt_it_nexus_destroy [drivers/scsi/scsi_transport_srp.ko] undefined! Signed-off-by: Brian King [EMAIL PROTECTED] --- scsi-pending-2.6.git-bjking1/drivers/scsi/Kconfig |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN drivers/scsi/Kconfig~scsi_tgt_kconfig_fix drivers/scsi/Kconfig --- scsi-pending-2.6.git/drivers/scsi/Kconfig~scsi_tgt_kconfig_fix 2007-07-30 10:44:34.0 -0500 +++ scsi-pending-2.6.git-bjking1/drivers/scsi/Kconfig 2007-07-30 10:45:00.0 -0500 @@ -291,7 +291,8 @@ source drivers/scsi/libsas/Kconfig config SCSI_SRP_ATTRS tristate SRP Transport Attributes - depends on SCSI SCSI_TGT + depends on SCSI + select SCSI_TGT Thanks, but I guess that I should have made the srp transport class independent of tgt since most people want only initiator support. I'll send a patch to do that soon. - 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] initialize shost_data to zero
It's better to initialize host-shost_data to zero like target-starget_data and device-sdev_data. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- drivers/scsi/hosts.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c index bd8e7f3..96bc312 100644 --- a/drivers/scsi/hosts.c +++ b/drivers/scsi/hosts.c @@ -220,7 +220,7 @@ int scsi_add_host(struct Scsi_Host *shost, struct device *dev) get_device(shost-shost_gendev); if (shost-transportt-host_size - (shost-shost_data = kmalloc(shost-transportt-host_size, + (shost-shost_data = kzalloc(shost-transportt-host_size, GFP_KERNEL)) == NULL) goto out_del_classdev; -- 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 0/5] mpt fusion: Add logging support
From: Moore, Eric [EMAIL PROTECTED] Subject: RE: [PATCH 0/5] mpt fusion: Add logging support Date: Mon, 30 Jul 2007 12:33:00 -0600 On Saturday, July 28, 2007 11:40 AM, James Bottomley wrote: I tell you what, let me just show you the actual patch. This allows you to write to the /sys/module/mptbase/parameters/mpt_debug_level and have it take effect in every ioc. ACK, If possible, I would like this patch thrown in with the other fusion logging patchs you added over the weekend to the scsi-rc-fixes-2.6 stream. Thanks. On another note, while unloading the driver, and I get an following opps from bsg in the context of scsi_remove_host. This is w/o the SMP passthrough patch, so why would fusion drivers be linked to bsg? Woudn't this break mptspi and mptfc, since they will not be working with bsg. Call Trace: [881f519c] :scsi_transport_sas:sas_bsg_remove+0x27/0x32 [881f6349] :scsi_transport_sas:sas_host_remove+0x30/0x34 [80375326] transport_remove_classdev+0x1d/0x4c [80375001] attribute_container_device_trigger+0x69/0xa7 [8803778b] :scsi_mod:scsi_remove_host+0xcd/0xfa [883461ac] :mptscsih:mptscsih_remove+0x32/0xae [8031416d] pci_device_remove+0x24/0x48 [803720ed] __device_release_driver+0x91/0xb3 [80372631] driver_detach+0xd6/0x115 [80371ba3] bus_remove_driver+0x6d/0x90 [803143f4] pci_unregister_driver+0x17/0x6b [88355044] :mptsas:mptsas_exit+0x10/0x5f [80252afb] sys_delete_module+0x1b1/0x1e0 [80307d9c] __up_write+0x21/0x10d [8020bc4e] system_call+0x7e/0x83 This patch fix the problem? --- From: FUJITA Tomonori [EMAIL PROTECTED] Subject: [PATCH] scsi_transport_sas: initialize sas_host_attrs-q fix the bug to call bsg_unregister_queue for an uninitialized queue. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- drivers/scsi/scsi_transport_sas.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/scsi_transport_sas.c b/drivers/scsi/scsi_transport_sas.c index 3120f4b..b0a21a2 100644 --- a/drivers/scsi/scsi_transport_sas.c +++ b/drivers/scsi/scsi_transport_sas.c @@ -270,6 +270,7 @@ static int sas_host_setup(struct transport_container *tc, struct device *dev, sas_host-next_target_id = 0; sas_host-next_expander_id = 0; sas_host-next_port_id = 0; + sas_host-q = NULL; if (sas_bsg_initialize(shost, NULL)) dev_printk(KERN_ERR, dev, fail to a bsg device %d\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: Mon, 30 Jul 2007 11:10:07 -0600
On Sunday, July 29, 2007 1:37 AM, FUJITA Tomonori wrote:
Eric, can I get your ACK on this patch?
One comment on the the patch:
+ if (!(ioc-sas_mgmt.status MPT_IOCTL_STATUS_COMMAND_GOOD)) {
+ printk(KERN_ERR %s: smp response invalid!\n,
__FUNCTION__);
+ ret = -ENXIO;
+ }
We don't need this part since user-space can get mpt's reply, I think.
Correct, this should be removed. The processing of the mpt reply has
been pushed to user-space.On another note, according to the mpi
specification, its says there should always be a reply message frame
returned for every smp passthru. So I thinking this would be the best
way to close out the end of this function. What do you think?
+ if (ioc-sas_mgmt.status MPT_IOCTL_STATUS_RF_VALID) {
+ SmpPassthroughReply_t *smprep;
+
+ smprep = (SmpPassthroughReply_t *)ioc-sas_mgmt.reply;
+ memcpy(req-sense, smprep, sizeof(*smprep));
+ req-sense_len = sizeof(*smprep);
+ } else
+ printk(KERN_ERR %s: smp passthru reply failed to be
returned\n, __FUNCTION__);
+ ret = -ENXIO;
+ }
Looks good for me.
Here's an updated version. Can you add your signed-off or acked-by?
---
From: FUJITA Tomonori [EMAIL PROTECTED]
Subject: [PATCH] mptsas: add SAS management protocol handler
This patch adds support for SAS Management Protocol (SMP) passthrough
support via bsg.
Like libsas's smp support, user-space tools can send a smp request
frame via sg_io_v4's dout_xferp and get a smp response frame via
din_xferp. In addition, user-space tools can get the mpt reply via
sg_io_v4's response field too if necessary.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/message/fusion/mptsas.c | 126 +++
1 files changed, 126 insertions(+), 0 deletions(-)
diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
index 29add83..b9c69bf 100644
--- a/drivers/message/fusion/mptsas.c
+++ b/drivers/message/fusion/mptsas.c
@@ -1312,11 +1312,137 @@ mptsas_get_bay_identifier(struct sas_rphy *rphy)
return rc;
}
+static int mptsas_smp_handler(struct Scsi_Host *shost, struct sas_rphy *rphy,
+ struct request *req)
+{
+ MPT_ADAPTER *ioc = ((MPT_SCSI_HOST *) shost-hostdata)-ioc;
+ MPT_FRAME_HDR *mf;
+ SmpPassthroughRequest_t *smpreq;
+ struct request *rsp = req-next_rq;
+ int ret;
+ int flagsLength;
+ unsigned long timeleft;
+ char *psge;
+ dma_addr_t dma_addr_in = 0;
+ dma_addr_t dma_addr_out = 0;
+ u64 sas_address = 0;
+
+ if (!rsp) {
+ printk(KERN_ERR %s: the smp response space is missing\n,
+ __FUNCTION__);
+ return -EINVAL;
+ }
+
+ /* do we need to support multiple segments? */
+ if (req-bio-bi_vcnt 1 || rsp-bio-bi_vcnt 1) {
+ printk(KERN_ERR %s: multiple segments req %u %u, rsp %u %u\n,
+ __FUNCTION__, req-bio-bi_vcnt, req-data_len,
+ rsp-bio-bi_vcnt, rsp-data_len);
+ return -EINVAL;
+ }
+
+ ret = mutex_lock_interruptible(ioc-sas_mgmt.mutex);
+ if (ret)
+ goto out;
+
+ mf = mpt_get_msg_frame(mptsasMgmtCtx, ioc);
+ if (!mf) {
+ ret = -ENOMEM;
+ goto out_unlock;
+ }
+
+ smpreq = (SmpPassthroughRequest_t *)mf;
+ memset(smpreq, 0, sizeof(*smpreq));
+
+ smpreq-RequestDataLength = cpu_to_le16(req-data_len - 4);
+ smpreq-Function = MPI_FUNCTION_SMP_PASSTHROUGH;
+
+ if (rphy)
+ sas_address = rphy-identify.sas_address;
+ else {
+ struct mptsas_portinfo *port_info;
+
+ mutex_lock(ioc-sas_topology_mutex);
+ port_info = mptsas_find_portinfo_by_handle(ioc, ioc-handle);
+ if (port_info port_info-phy_info)
+ sas_address =
+
port_info-phy_info[0].phy-identify.sas_address;
+ mutex_unlock(ioc-sas_topology_mutex);
+ }
+
+ *((u64 *)smpreq-SASAddress) = cpu_to_le64(sas_address);
+
+ psge = (char *)
+ (((int *) mf) + (offsetof(SmpPassthroughRequest_t, SGL) / 4));
+
+ /* request */
+ flagsLength = (MPI_SGE_FLAGS_SIMPLE_ELEMENT |
+ MPI_SGE_FLAGS_END_OF_BUFFER |
+ MPI_SGE_FLAGS_DIRECTION |
+ mpt_addr_size()) MPI_SGE_FLAGS_SHIFT;
+ flagsLength |= (req-data_len - 4);
+
+ dma_addr_out = pci_map_single(ioc-pcidev, bio_data(req-bio),
+ req-data_len, PCI_DMA_BIDIRECTIONAL);
+ if (!dma_addr_out)
+ goto put_mf
RE: [PATCH 3/3] mptsas: add SMP passthrough support via bsg
From: FUJITA Tomonori [EMAIL PROTECTED]
Subject: RE: [PATCH 3/3] mptsas: add SMP passthrough support via bsg
Date: Sun, 29 Jul 2007 14:07:01 +0900
From: Moore, Eric [EMAIL PROTECTED]
Subject: RE: [PATCH 3/3] mptsas: add SMP passthrough support via bsg
Date: Fri, 27 Jul 2007 17:24:19 -0600
On Thursday, July 26, 2007 6:44 PM, FUJITA Tomonori wrote:
Does this work for you? Sorry, I'm not at the lab now and can't test
it. But I can do next week.
I also updated bsg's smp_rep_manufacturer to print the mpi's
replay. You can get it from the git tree.
yes this will work, and I pulled the updated sgv4, and saw your
inclusion of mptsas.h.
I confirmed that this patch sends mpi's unique reply back to user
space.
When I send a wrong smp frame, I got:
nice:/home/fujita# ./sgv4-tools/smp_rep_manufacturer /sys/class/bsg/sas_host0
IOCStatus=0x1 IOCLogInfo=0x0 SASStatus=0x2
expected SMP frame response type, got=0x10
Eric, can I get your ACK on this patch?
One comment on the the patch:
+ if (!(ioc-sas_mgmt.status MPT_IOCTL_STATUS_COMMAND_GOOD)) {
+ printk(KERN_ERR %s: smp response invalid!\n, __FUNCTION__);
+ ret = -ENXIO;
+ }
We don't need this part since user-space can get mpt's reply, I think.
-
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] zfcp: convert to use the data buffer accessors
The patch is only compile tested.
---
From: FUJITA Tomonori [EMAIL PROTECTED]
Subject: [PATCH] zfcp: convert to use the data buffer accessors
- remove the unnecessary map_single path.
- convert to use the new accessors for the sg lists and the
parameters.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/s390/scsi/zfcp_fsf.c |5 +++--
drivers/s390/scsi/zfcp_qdio.c | 41 ++---
2 files changed, 9 insertions(+), 37 deletions(-)
diff --git a/drivers/s390/scsi/zfcp_fsf.c b/drivers/s390/scsi/zfcp_fsf.c
index b240800..9929997 100644
--- a/drivers/s390/scsi/zfcp_fsf.c
+++ b/drivers/s390/scsi/zfcp_fsf.c
@@ -4154,8 +4154,9 @@ zfcp_fsf_send_fcp_command_task_handler(struct
zfcp_fsf_req *fsf_req)
fcp_rsp_iu-fcp_resid,
(int) zfcp_get_fcp_dl(fcp_cmnd_iu));
- scpnt-resid = fcp_rsp_iu-fcp_resid;
- if (scpnt-request_bufflen - scpnt-resid scpnt-underflow)
+ scsi_set_resid(scpnt, fcp_rsp_iu-fcp_resid);
+ if (scsi_bufflen(scpnt) - scsi_get_resid(scpnt)
+ scpnt-underflow)
set_host_byte(scpnt-result, DID_ERROR);
}
diff --git a/drivers/s390/scsi/zfcp_qdio.c b/drivers/s390/scsi/zfcp_qdio.c
index c408bad..81daa82 100644
--- a/drivers/s390/scsi/zfcp_qdio.c
+++ b/drivers/s390/scsi/zfcp_qdio.c
@@ -36,8 +36,6 @@ static void zfcp_qdio_sbale_fill
(struct zfcp_fsf_req *, unsigned long, void *, int);
static int zfcp_qdio_sbals_from_segment
(struct zfcp_fsf_req *, unsigned long, void *, unsigned long);
-static int zfcp_qdio_sbals_from_buffer
- (struct zfcp_fsf_req *, unsigned long, void *, unsigned long, int);
static qdio_handler_t zfcp_qdio_request_handler;
static qdio_handler_t zfcp_qdio_response_handler;
@@ -632,28 +630,6 @@ out:
/**
- * zfcp_qdio_sbals_from_buffer - fill SBALs from buffer
- * @fsf_req: request to be processed
- * @sbtype: SBALE flags
- * @buffer: data buffer
- * @length: length of buffer
- * @max_sbals: upper bound for number of SBALs to be used
- */
-static int
-zfcp_qdio_sbals_from_buffer(struct zfcp_fsf_req *fsf_req, unsigned long sbtype,
- void *buffer, unsigned long length, int max_sbals)
-{
- struct scatterlist sg_segment;
-
- zfcp_address_to_sg(buffer, sg_segment);
- sg_segment.length = length;
-
- return zfcp_qdio_sbals_from_sg(fsf_req, sbtype, sg_segment, 1,
- max_sbals);
-}
-
-
-/**
* zfcp_qdio_sbals_from_scsicmnd - fill SBALs from scsi command
* @fsf_req: request to be processed
* @sbtype: SBALE flags
@@ -664,18 +640,13 @@ int
zfcp_qdio_sbals_from_scsicmnd(struct zfcp_fsf_req *fsf_req,
unsigned long sbtype, struct scsi_cmnd *scsi_cmnd)
{
- if (scsi_cmnd-use_sg) {
+ if (scsi_sg_count(scsi_cmnd))
return zfcp_qdio_sbals_from_sg(fsf_req, sbtype,
- (struct scatterlist *)
- scsi_cmnd-request_buffer,
- scsi_cmnd-use_sg,
- ZFCP_MAX_SBALS_PER_REQ);
- } else {
-return zfcp_qdio_sbals_from_buffer(fsf_req, sbtype,
- scsi_cmnd-request_buffer,
- scsi_cmnd-request_bufflen,
- ZFCP_MAX_SBALS_PER_REQ);
- }
+ scsi_sglist(scsi_cmnd),
+ scsi_sg_count(scsi_cmnd),
+ ZFCP_MAX_SBALS_PER_REQ);
+ else
+ return 0;
}
/**
--
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
[PATCH] bsg: update sg_io_v4 structure
This updates sg_io_v4 structure (based on Doug's RFC, release 1.3).
The major changes are:
- add dout_resid field
- increase tag size to 64 bits to comply with SAM-4 and SRP
- add dout_iovec_count and din_iovec_count
dout_iovec_count and din_iovec_count aren't supported now. I'm not
sure whether they will be supported or not but they were added for the
possible future changes.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
block/bsg.c | 10 +++---
include/linux/bsg.h | 13 +
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/block/bsg.c b/block/bsg.c
index 12c287b..ccfa5f8 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -1,5 +1,5 @@
/*
- * bsg.c - block layer implementation of the sg v3 interface
+ * bsg.c - block layer implementation of the sg v4 interface
*
* Copyright (C) 2004 Jens Axboe [EMAIL PROTECTED] SUSE Labs
* Copyright (C) 2004 Peter M. Jones [EMAIL PROTECTED]
@@ -421,7 +421,6 @@ static int blk_complete_sgv4_hdr_rq(struct request *rq,
struct sg_io_v4 *hdr,
hdr-info = 0;
if (hdr-device_status || hdr-transport_status || hdr-driver_status)
hdr-info |= SG_INFO_CHECK;
- hdr-din_resid = rq-data_len;
hdr-response_len = 0;
if (rq-sense_len hdr-response) {
@@ -437,9 +436,14 @@ static int blk_complete_sgv4_hdr_rq(struct request *rq,
struct sg_io_v4 *hdr,
}
if (rq-next_rq) {
+ hdr-dout_resid = rq-data_len;
+ hdr-din_resid = rq-next_rq-data_len;
blk_rq_unmap_user(bidi_bio);
blk_put_request(rq-next_rq);
- }
+ } else if (rq_data_dir(rq) == READ)
+ hdr-din_resid = rq-data_len;
+ else
+ hdr-dout_resid = rq-data_len;
blk_rq_unmap_user(bio);
blk_put_request(rq);
diff --git a/include/linux/bsg.h b/include/linux/bsg.h
index 102dc09..60e377b 100644
--- a/include/linux/bsg.h
+++ b/include/linux/bsg.h
@@ -15,14 +15,18 @@ struct sg_io_v4 {
__u32 request_len; /* [i] in bytes */
__u64 request; /* [i], [*i] {SCSI: cdb} */
+ __u64 request_tag; /* [i] {SCSI: task tag (only if flagged)} */
__u32 request_attr; /* [i] {SCSI: task attribute} */
- __u32 request_tag; /* [i] {SCSI: task tag (only if flagged)} */
__u32 request_priority; /* [i] {SCSI: task priority} */
+ __u32 request_extra;/* [i] {spare, for padding} */
__u32 max_response_len; /* [i] in bytes */
__u64 response; /* [i], [*o] {SCSI: (auto)sense data} */
- /* din_ for data in (from device); dout_ for data out (to device) */
+/* dout_: data out (to device); din_: data in (from device) */
+ __u32 dout_iovec_count; /* [i] 0 - flat dout transfer else
+ dout_xfer points to array of iovec */
__u32 dout_xfer_len;/* [i] bytes to be transferred to device */
+ __u32 din_iovec_count; /* [i] 0 - flat din transfer */
__u32 din_xfer_len; /* [i] bytes to be transferred from device */
__u64 dout_xferp; /* [i], [*i] */
__u64 din_xferp;/* [i], [*o] */
@@ -39,8 +43,9 @@ struct sg_io_v4 {
__u32 info; /* [o] additional information */
__u32 duration; /* [o] time to complete, in milliseconds */
__u32 response_len; /* [o] bytes of response actually written */
- __s32 din_resid;/* [o] actual_din_xfer_len - din_xfer_len */
- __u32 generated_tag;/* [o] {SCSI: task tag that transport chose} */
+ __s32 din_resid;/* [o] din_xfer_len - actual_din_xfer_len */
+ __s32 dout_resid; /* [o] dout_xfer_len - actual_dout_xfer_len */
+ __u64 generated_tag;/* [o] {SCSI: transport generated task tag} */
__u32 spare_out;/* [o] */
__u32 padding;
--
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: BSG: BLK_DEV_BSG=y , BLOCK=n compile error
From: Gabriel C [EMAIL PROTECTED] Subject: BSG: BLK_DEV_BSG=y , BLOCK=n compile error Date: Sat, 28 Jul 2007 14:54:02 +0200 Hi, BSG does not compile without BLOCK set : Thanks, this has already been addressed. http://marc.info/?l=linux-kernelm=118534836402440w=2 James, could you add the patch to scsi-rc-fixes? Thanks. --- From: Paul Mundt [EMAIL PROTECTED] Subject: [PATCH] bsg: Fix build for CONFIG_BLOCK=n BLK_DEV_BSG was added outside of the if BLOCK check, which allows it to be enabled when CONFIG_BLOCK=n. This leads to many screenlengths of errors, starting with a parse error on the request_queue_t definition. Obviously this wasn't intended for CONFIG_BLOCK=n usage, so just move the option back in to the block. Caught with a randconfig on sh. Signed-off-by: Paul Mundt [EMAIL PROTECTED] Acked-by: Jens Axboe [EMAIL PROTECTED] Acked-by: FUJITA Tomonori [EMAIL PROTECTED] --- block/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/block/Kconfig b/block/Kconfig index ca2ef4e..2484e0e 100644 --- a/block/Kconfig +++ b/block/Kconfig @@ -49,8 +49,6 @@ config LSF If unsure, say Y. -endif # BLOCK - config BLK_DEV_BSG bool Block layer SG support v4 (EXPERIMENTAL) depends on EXPERIMENTAL @@ -64,4 +62,6 @@ config BLK_DEV_BSG protocols (e.g. Task Management Functions and SMP in Serial Attached SCSI). +endif # BLOCK + source block/Kconfig.iosched -- 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: Fri, 27 Jul 2007 17:24:19 -0600 On Thursday, July 26, 2007 6:44 PM, FUJITA Tomonori wrote: Does this work for you? Sorry, I'm not at the lab now and can't test it. But I can do next week. I also updated bsg's smp_rep_manufacturer to print the mpi's replay. You can get it from the git tree. yes this will work, and I pulled the updated sgv4, and saw your inclusion of mptsas.h. I confirmed that this patch sends mpi's unique reply back to user space. When I send a wrong smp frame, I got: nice:/home/fujita# ./sgv4-tools/smp_rep_manufacturer /sys/class/bsg/sas_host0 IOCStatus=0x1 IOCLogInfo=0x0 SASStatus=0x2 expected SMP frame response type, got=0x10 Eric, can I get your ACK on this patch? - 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-rc1-mm1: SCSI_SRP_ATTRS compile error
From: Adrian Bunk [EMAIL PROTECTED] Subject: 2.6.23-rc1-mm1: SCSI_SRP_ATTRS compile error Date: Wed, 25 Jul 2007 20:06:18 +0200 On Wed, Jul 25, 2007 at 05:36:56PM +0100, Andy Whitcroft wrote: Of the machines we test releases on automatically this only compiles on NUMA-Q and does not boot there (some PCI issue). ppc64 (beavis): drivers/built-in.o(.text+0xd2784): In function `.srp_rport_add': : undefined reference to `.scsi_tgt_it_nexus_create' drivers/built-in.o(.text+0xd2884): In function `.srp_rport_del': : undefined reference to `.scsi_tgt_it_nexus_destroy' make: *** [.tmp_vmlinux1] Error 1 x86_64 (bl6-13): ERROR: scsi_tgt_it_nexus_destroy [drivers/scsi/scsi_transport_srp.ko] undefined! ERROR: scsi_tgt_it_nexus_create [drivers/scsi/scsi_transport_srp.ko] undefined! make[1]: *** [__modpost] Error 1 ... Caused-By : git-scsi-target.patch Workaround : enable CONFIG_SCSI_TGT Sorry about this. Andrew, could you drop the scsi-target tree from -mm? I was surprised that the scsi-target tree is still in -mm (it had been tested in -mm before the mainline inclusion). I guess that it's the right way to push scsi-target stuff into -mm via James' scsi-misc. Is there any good reason why all the SCSI transport attributes options are user visible? No, I messed up the dependency somewhere. I'll fix it before it is merged into scsi-misc. 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: [RFC 7/8] sd.c and sr.c move to scsi_sgtable implementation
From: Boaz Harrosh [EMAIL PROTECTED]
Subject: [RFC 7/8] sd.c and sr.c move to scsi_sgtable implementation
Date: Thu, 05 Jul 2007 16:44:04 +0300
- sd and sr would adjust IO size to align on device's block
size. So code needs to change once we move to scsi_sgtable
implementation. (Not compatible with un-converted drivers)
- Convert code to use scsi_for_each_sg
- Use Data accessors wherever is appropriate.
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/scsi/sd.c | 10 --
drivers/scsi/sr.c | 27 ---
2 files changed, 16 insertions(+), 21 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 448d316..459fd23 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -338,7 +338,7 @@ static int sd_init_command(struct scsi_cmnd * SCpnt)
struct request *rq = SCpnt-request;
struct gendisk *disk = rq-rq_disk;
sector_t block = rq-sector;
- unsigned int this_count = SCpnt-request_bufflen 9;
+ unsigned int this_count = scsi_bufflen(SCpnt) 9;
unsigned int timeout = sdp-timeout;
SCSI_LOG_HLQUEUE(1, scmd_printk(KERN_INFO, SCpnt,
@@ -418,9 +418,6 @@ static int sd_init_command(struct scsi_cmnd * SCpnt)
} else if (rq_data_dir(rq) == READ) {
SCpnt-cmnd[0] = READ_6;
SCpnt-sc_data_direction = DMA_FROM_DEVICE;
- } else {
- scmd_printk(KERN_ERR, SCpnt, Unknown command %x\n,
rq-cmd_flags);
- return 0;
}
Why?
SCSI_LOG_HLQUEUE(2, scmd_printk(KERN_INFO, SCpnt,
@@ -480,7 +477,8 @@ static int sd_init_command(struct scsi_cmnd * SCpnt)
SCpnt-cmnd[4] = (unsigned char) this_count;
SCpnt-cmnd[5] = 0;
}
- SCpnt-request_bufflen = this_count * sdp-sector_size;
+ BUG_ON(!SCpnt-sgtable);
+ SCpnt-sgtable-length = this_count * sdp-sector_size;
/*
* We shouldn't disconnect in the middle of a sector, so with a dumb
@@ -892,7 +890,7 @@ static struct block_device_operations sd_fops = {
static void sd_rw_intr(struct scsi_cmnd * SCpnt)
{
int result = SCpnt-result;
- unsigned int xfer_size = SCpnt-request_bufflen;
+ unsigned int xfer_size = scsi_bufflen(SCpnt);
unsigned int good_bytes = result ? 0 : xfer_size;
u64 start_lba = SCpnt-request-sector;
u64 bad_lba;
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index f9a52af..ed61ca9 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -218,7 +218,7 @@ int sr_media_change(struct cdrom_device_info *cdi, int
slot)
static void rw_intr(struct scsi_cmnd * SCpnt)
{
int result = SCpnt-result;
- int this_count = SCpnt-request_bufflen;
+ int this_count = scsi_bufflen(SCpnt);
int good_bytes = (result == 0 ? this_count : 0);
int block_sectors = 0;
long error_sector;
@@ -345,23 +345,20 @@ static int sr_init_command(struct scsi_cmnd * SCpnt)
} else if (rq_data_dir(SCpnt-request) == READ) {
SCpnt-cmnd[0] = READ_10;
SCpnt-sc_data_direction = DMA_FROM_DEVICE;
- } else {
- blk_dump_rq_flags(SCpnt-request, Unknown sr command);
- return 0;
}
ditto.
-
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: Thu, 26 Jul 2007 10:32:45 -0600
On Thursday, July 26, 2007 4:09 AM, FUJITA Tomonori wrote:
The SMP response's function result wasn't set correctly? bsg's
smp_rep_manufacturer didn't check the result so it showed garbase, I
guess.
BTW, I took the code to check the result from Doug's smp_utils and put
bsg's smp_rep_manufacturer:
http://www.kernel.org/pub/linux/kernel/people/tomo/smp/
or
git://git.kernel.org/pub/scm/linux/kernel/git/tomo/sgv4-tools.git
Thanks.with Doug Gilberts help, I have solved the git dilema thru
firewall. I need a socks proxy, which I found from
http://tsocks.sourceforge.net/
Nice.
That's the reason why I said before, sense buffer is not used for smp
and using sense buffer would be the easiest way to push up the mpt
unique response to userspace.
do you suggest the scsi llds would would need to translate there own
codes (in my case iocstatus/loginfo/sasstatus) into common sense
sk/asc/ascq ?
No, I don't.
struct sg_io_v4 {
__s32 guard;/* [i] 'Q' to differentiate from v3 */
__u32 protocol; /* [i] 0 - SCSI , */
__u32 subprotocol; /* [i] 0 - SCSI command, 1 - SCSI task
management function, */
__u32 request_len; /* [i] in bytes */
__u64 request; /* [i], [*i] {SCSI: cdb} */
__u32 request_attr; /* [i] {SCSI: task attribute} */
__u32 request_tag; /* [i] {SCSI: task tag (only if flagged)} */
__u32 request_priority; /* [i] {SCSI: task priority} */
__u32 max_response_len; /* [i] in bytes */
__u64 response; /* [i], [*o] {SCSI: (auto)sense data} */
/* din_ for data in (from device); dout_ for data out (to device) */
__u32 dout_xfer_len;/* [i] bytes to be transferred to device */
__u32 din_xfer_len; /* [i] bytes to be transferred from device */
__u64 dout_xferp; /* [i], [*i] */
__u64 din_xferp;/* [i], [*o] */
...
__u32 response_len; /* [o] bytes of response actually written */
Use-space applications can put four memory addresses in the bsg (sg
v4) interface: request, response, dout_xferp, and din_xferp.
For scsi commands, we use:
request - pointer to a scsi command (cmdp in sgv3)
response - pointer to a sense buffer (sbp in sgv3)
dout_xferp - pointer to out data
din_xferp - pointer to in data
For smp request/response, we use:
request - not used
response - not used
dout_xferp - pointer to a smp request frame
din_xferp - pointer to a smp response frame
So we could use response field to send vendor's unique response to
user space.
bsg wrongly assues the response field is used for sense buffer so the
maxium length is SCSI_SENSE_BUFFERSIZE, 96 bytes. I think that it's a
bit small for mpt's unique response. But, I'll fix the length
limitation bug soon.
Here's an updated patch.
The patch looks good. It can be applied upstream. I tested on x86_64,
not big endian (I could try out on a ppc64 when I have time). Here is
the output from your latest tool with various expanders I have in my
lab.
# ./smp_rep_manufacturer /sys/class/bsg/sas_host2
SAS-1.1 format: 0
vendor identification: LSI
product identification: Virtual SMP Port
product revision level:
# ./smp_rep_manufacturer /sys/class/bsg/expander-3:0
SAS-1.1 format: 1
vendor identification: LSILOGIC
product identification: x36-00.00.06.00
product revision level:
component vendor identification: LSI
component id: 531
# ./smp_rep_manufacturer /sys/class/bsg/expander-3:1
SAS-1.1 format: 1
vendor identification: XYRATEX
product identification: SAS-01
product revision level: 03A
component vendor identification: LSI
component id: 517
# ./smp_rep_manufacturer /sys/class/bsg/expander-3:2
SAS-1.1 format: 1
vendor identification: HP
product identification: MSA 50-10D25G1
product revision level:
component vendor identification: LSI
component id: 512
component revision level: 1
# ./smp_rep_manufacturer /sys/class/bsg/expander-3:3
SAS-1.1 format: 0
vendor identification: LSILOGIC
product identification: SASx12 A.0
product revision level:
Looks great. 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: [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: Wed, 25 Jul 2007 22:22:20 +0300 FUJITA Tomonori wrote: From: Benny Halevy [EMAIL PROTECTED] Subject: Re: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining Date: Wed, 25 Jul 2007 11:26:44 +0300 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. I agree. This isn't a catholic marriage :) We'll run some performance experiments comparing the sgtable chaining implementation vs. a scsi_data_buff implementation pointing at a possibly chained sglist and let's see if we can measure any difference. We'll send results as soon as we have them. I did some tests with your sgtable patchset and the approach to use separate buffer for sglists. As expected, there was no performance difference with small I/Os. I've not tried very large I/Os, which might give some difference. The patchset to use separate buffer for sglists is available: git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git simple-sgtable Can you clean up your patchset and upload somewhere? Sorry sure. Here is scsi_sgtable complete work over linux-block: http://www.bhalevy.com/open-osd/download/scsi_sgtable/linux-block Here is just scsi_sgtable, no chaining, over scsi-misc + more drivers: http://www.bhalevy.com/open-osd/download/scsi_sgtable/scsi-misc Next week I will try to mount lots of scsi_debug devices and use large parallel IO to try and find a difference. I will test Jens's sglist-arch tree against above sglist-arch+scsi_sgtable I have lots of reservations about Tomo's last patches. For me they are a regression. They use 3 allocations per command instead of 2. They use an extra pointer and an extra global slab_pool. And for what, for grouping some scsi_cmnd members in a substructure. If we want to go the pointing way, keeping our extra scatterlist and our base_2 count on most ARCHs. Than we can just use the scsi_data_buff embedded inside scsi_cmnd. Yeah, I changed and tested the patch to embed one sgtable header structure in struct scsi_cmnd for uni-directional transfers. Somehow, I uploaded the old patchset to my bidi tree yesterday. The second scsi_data_buff for bidi can come either from an extra slab_pool like in Tomo's patch - bidi can pay - or in scsi.c at scsi_setup_command_freelist() the code can inspect Tomo's flag to the request_queue QUEUE_FLAG_BIDI and will than allocate a bigger scsi_cmnd in the free list. I have coded that approach and it is very simple: http://www.bhalevy.com/open-osd/download/scsi_data_buff They are over Jens's sglist-arch branch I have revised all scsi-ml places and it all compiles But is totally untested. This is similar to the patch that I tested. I will add this branch to the above tests, but I suspect that they are identical in every way to current code. With the large I/Os, there might be some difference. - 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: Benny Halevy [EMAIL PROTECTED] Subject: Re: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining Date: Wed, 25 Jul 2007 11:26:44 +0300 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. I agree. This isn't a catholic marriage :) We'll run some performance experiments comparing the sgtable chaining implementation vs. a scsi_data_buff implementation pointing at a possibly chained sglist and let's see if we can measure any difference. We'll send results as soon as we have them. I did some tests with your sgtable patchset and the approach to use separate buffer for sglists. As expected, there was no performance difference with small I/Os. I've not tried very large I/Os, which might give some difference. The patchset to use separate buffer for sglists is available: git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git simple-sgtable Can you clean up your patchset and upload somewhere? - 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: 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
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: [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
[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 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
[PATCH] sgtable over sglist (Re: [RFC 4/8] scsi-ml: scsi_sgtable implementation)
From: Jens Axboe [EMAIL PROTECTED]
Subject: Re: [RFC 4/8] scsi-ml: scsi_sgtable implementation
Date: Wed, 18 Jul 2007 22:17:10 +0200
On Wed, Jul 18 2007, Benny Halevy wrote:
Jens Axboe wrote:
On Wed, Jul 18 2007, Boaz Harrosh wrote:
Jens Axboe wrote:
On Wed, Jul 18 2007, Boaz Harrosh wrote:
FUJITA Tomonori wrote:
From: Mike Christie [EMAIL PROTECTED]
Subject: Re: [RFC 4/8] scsi-ml: scsi_sgtable implementation
Date: Thu, 12 Jul 2007 14:09:44 -0500
Boaz Harrosh wrote:
+/*
+ * Should fit within a single page.
+ */
+enum { SCSI_MAX_SG_SEGMENTS =
+ ((PAGE_SIZE - sizeof(struct scsi_sgtable)) /
+ sizeof(struct scatterlist)) };
+
+enum { SG_MEMPOOL_NR =
+ (SCSI_MAX_SG_SEGMENTS = 7) +
+ (SCSI_MAX_SG_SEGMENTS = 15) +
+ (SCSI_MAX_SG_SEGMENTS = 31) +
+ (SCSI_MAX_SG_SEGMENTS = 63) +
+ (SCSI_MAX_SG_SEGMENTS = 127) +
+ (SCSI_MAX_SG_SEGMENTS = 255) +
+ (SCSI_MAX_SG_SEGMENTS = 511)
+};
What does SCSI_MAX_SG_SEGMENTS end up being on x86 now? On x86_64 or
some other arch, we were going over a page when doing
SCSI_MAX_PHYS_SEGMENTS of 256 right?
Seems that 170 with x86 and 127 with x86_64.
with scsi_sgtable we get one less than now
Arch | SCSI_MAX_SG_SEGMENTS = | sizeof(struct
scatterlist)
--|-|---
x86_64| 127 |32
i386 CONFIG_HIGHMEM64G=y | 204 |20
i386 other| 255 |16
What's nice about this code is that now finally it is
automatically calculated in compile time. Arch people
don't have the headache did I break SCSI-ml?.
For example observe the current bug with i386
CONFIG_HIGHMEM64G=y.
The same should be done with BIO's. Than ARCHs with big
pages can gain even more.
What happened to Jens's scatter list chaining and how does this
relate
to it then?
With Jens' sglist, we can set SCSI_MAX_SG_SEGMENTS to whatever we
want. We can remove the above code.
We need to push this and Jens' sglist together in one merge window, I
think.
No Tomo the above does not go away. What goes away is maybe:
It does go away, since we can just set it to some safe value and use
chaining to get us where we want.
In my patches SCSI_MAX_PHYS_SEGMENTS has went away it does not exist
anymore.
Sure, I could just kill it as well. The point is that it's a parallel
development, there's nothing in your patch that helps the sg chaining
whatsoever. The only complex thing in the SCSI layer for sg chaining,
is chaining when allocating and walking that chain on freeing. That's
it!
It seems like having the pool index in the sgtable structure simplifies
the implementation a bit for allocation and freeing of linked sgtables.
Boaz will send an example tomorrow (hopefully) showing how the merged
code looks like.
The index stuff isn't complex, so I don't think you can call that a real
simplification. It's not for free either, there's a size cost to pay.
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.
I wrote my sgtable patch over Jens' sglist with the former way:
master.kernel.org:/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git sgtable
I also put Boaz's scsi_error, sd, and sr sgtable patches into the tree
so you can try it. I've tested this with only normal size I/Os (not
tested sglist code). I don't touch the sglist code much, so hopefully
it works.
I've attached the sgtable patch for review. It's against the
sglist-arch branch in Jens' tree.
---
From: FUJITA Tomonori [EMAIL PROTECTED]
Subject: [PATCH] move all the I/O descriptors to a new scsi_sgtable structure
based on Boaz Harrosh [EMAIL PROTECTED] scsi_sgtable patch.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/scsi_lib.c | 92 +++--
include/scsi/scsi_cmnd.h | 39 +--
2 files changed, 82 insertions(+), 49 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 5fb1048..2fa1852 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -52,6 +52,8 @@ static struct scsi_host_sg_pool scsi_sg_pools[] = {
};
#undef SP
+static struct kmem_cache *scsi_sgtable_cache;
+
static void scsi_run_queue(struct request_queue *q);
/*
@@ -731,16 +733,27 @@ static inline unsigned int scsi_sgtable_index(unsigned
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: Mon, 23 Jul 2007 18:11:34 -0600
Tomo - do you have any documentation on how to specify a bsg device?
Sorry, I don't. But it's not difficult.
With 2.6.23-rc1 + mptsas smp patch, you get directories /sys/class/bsg
like:
[EMAIL PROTECTED]:/sys/class/bsg$ ls
0:0:0:0 0:0:1:0 end_device-0:0 end_device-0:1 sas_host0
I don't have any expanders but if you have, you have a directory like
expander-0:1 under /sys/class/bsg.
I can run smp_rep_manufacturer against invisible SMP target in my
LSI SAS HBA like this:
nice:/home/fujita# ./sgv4-tools/smp_rep_manufacturer /sys/class/bsg/sas_host0
SAS-1.1 format: 0
vendor identification: LSI
product identification: Virtual SMP Port
product revision level:
Hopefully, you can do against expanders:
# ./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 was trying to run the smp_rep_manufacture from sgv4_tools, and I
got that error. Due to that, I have not able to test this patch.
What is the error message?
However, here are some feedback with regards to the patch:
Thanks.
On Sunday, July 08, 2007 9:52 PM, FUJITA Tomonori wrote:
+
+smpreq-RequestDataLength = req-data_len - 4;
Our firmware formats the data in little endian, so you'll need to
convert this inorder for it work under other endian formats, like sparc
and ppc. So this code should be:
smpreq-RequestDataLength = cpu_to_le16(req-data_len - 4);
I see. I'll fix it.
+smpreq-Function = MPI_FUNCTION_SMP_PASSTHROUGH;
+
+ if (rphy)
+ memcpy(smpreq-SASAddress, rphy-identify.sas_address,
+ sizeof(smpreq-SASAddress));
should be using cpu_to_le64 before the data is put into
smpreq-SASAddress
Thanks, I will fix it.
+ else {
+ struct mptsas_portinfo *port_info;
+
+ mutex_lock(ioc-sas_topology_mutex);
+ port_info = mptsas_find_portinfo_by_handle(ioc,
ioc-handle);
+ if (port_info port_info-phy_info)
+ memcpy(smpreq-SASAddress,
+
(port_info-phy_info[0].phy-identify.sas_address),
+ sizeof(smpreq-SASAddress));
+ mutex_unlock(ioc-sas_topology_mutex);
+ }
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 think it should be
deleted, and replaced with a return of ENXIO.The sas_topology is a
flat model, with the first object the intiatiator, and the other objects
in the list are expanders.What your your attempting to obtain is the
first port object connected to the initiator, which could be anything,
for instance it could be an end device, instead of expander.So I
think if your rphy object is not returning a valid sas_address, then
return instead of attempting to find something from the sas_topology.
I hope the API is making sure this is an expander before mptsas is even
called, is that handled?
+ /* a reply frame is expected */
+ if (!(ioc-sas_mgmt.status MPT_IOCTL_STATUS_RF_VALID)) {
+ printk(%s: the smp response invalid!\n, __FUNCTION__);
+ ret = -ENXIO;
+ }
+
I think in addition to having a valid reply, I think you should look at
the iocstatus to insure the reply itself was successfull, and that there
were no data underruns.
ioc_status = le16_to_cpu(smpReply-IOCStatus) MPI_IOCSTATUS_MASK;
if ((ioc_status != MPI_IOCSTATUS_SUCCESS)
(ioc_status != MPI_IOCSTATUS_SCSI_DATA_UNDERRUN)) {
return -ENXIO;
}
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.
-
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/2] ibmvscsi: use shost_priv
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/ibmvscsi/ibmvscsi.c | 34 +++---
1 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index 6735260..65f7fc1 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -702,8 +702,7 @@ static int ibmvscsi_queuecommand(struct scsi_cmnd *cmnd,
struct srp_cmd *srp_cmd;
struct srp_event_struct *evt_struct;
struct srp_indirect_buf *indirect;
- struct ibmvscsi_host_data *hostdata =
- (struct ibmvscsi_host_data *)cmnd-device-host-hostdata;
+ struct ibmvscsi_host_data *hostdata = shost_priv(cmnd-device-host);
u16 lun = lun_from_dev(cmnd-device);
u8 out_fmt, in_fmt;
@@ -954,8 +953,7 @@ static void sync_completion(struct srp_event_struct
*evt_struct)
*/
static int ibmvscsi_eh_abort_handler(struct scsi_cmnd *cmd)
{
- struct ibmvscsi_host_data *hostdata =
- (struct ibmvscsi_host_data *)cmd-device-host-hostdata;
+ struct ibmvscsi_host_data *hostdata = shost_priv(cmd-device-host);
struct srp_tsk_mgmt *tsk_mgmt;
struct srp_event_struct *evt;
struct srp_event_struct *tmp_evt, *found_evt;
@@ -1078,9 +1076,7 @@ static int ibmvscsi_eh_abort_handler(struct scsi_cmnd
*cmd)
*/
static int ibmvscsi_eh_device_reset_handler(struct scsi_cmnd *cmd)
{
- struct ibmvscsi_host_data *hostdata =
- (struct ibmvscsi_host_data *)cmd-device-host-hostdata;
-
+ struct ibmvscsi_host_data *hostdata = shost_priv(cmd-device-host);
struct srp_tsk_mgmt *tsk_mgmt;
struct srp_event_struct *evt;
struct srp_event_struct *tmp_evt, *pos;
@@ -1177,8 +1173,7 @@ static int ibmvscsi_eh_device_reset_handler(struct
scsi_cmnd *cmd)
static int ibmvscsi_eh_host_reset_handler(struct scsi_cmnd *cmd)
{
unsigned long wait_switch = 0;
- struct ibmvscsi_host_data *hostdata =
- (struct ibmvscsi_host_data *)cmd-device-host-hostdata;
+ struct ibmvscsi_host_data *hostdata = shost_priv(cmd-device-host);
dev_err(hostdata-dev, Resetting connection due to error recovery\n);
@@ -1406,8 +1401,7 @@ static int ibmvscsi_change_queue_depth(struct scsi_device
*sdev, int qdepth)
static ssize_t show_host_srp_version(struct class_device *class_dev, char *buf)
{
struct Scsi_Host *shost = class_to_shost(class_dev);
- struct ibmvscsi_host_data *hostdata =
- (struct ibmvscsi_host_data *)shost-hostdata;
+ struct ibmvscsi_host_data *hostdata = shost_priv(shost);
int len;
len = snprintf(buf, PAGE_SIZE, %s\n,
@@ -1427,8 +1421,7 @@ static ssize_t show_host_partition_name(struct
class_device *class_dev,
char *buf)
{
struct Scsi_Host *shost = class_to_shost(class_dev);
- struct ibmvscsi_host_data *hostdata =
- (struct ibmvscsi_host_data *)shost-hostdata;
+ struct ibmvscsi_host_data *hostdata = shost_priv(shost);
int len;
len = snprintf(buf, PAGE_SIZE, %s\n,
@@ -1448,8 +1441,7 @@ static ssize_t show_host_partition_number(struct
class_device *class_dev,
char *buf)
{
struct Scsi_Host *shost = class_to_shost(class_dev);
- struct ibmvscsi_host_data *hostdata =
- (struct ibmvscsi_host_data *)shost-hostdata;
+ struct ibmvscsi_host_data *hostdata = shost_priv(shost);
int len;
len = snprintf(buf, PAGE_SIZE, %d\n,
@@ -1468,8 +1460,7 @@ static struct class_device_attribute
ibmvscsi_host_partition_number = {
static ssize_t show_host_mad_version(struct class_device *class_dev, char *buf)
{
struct Scsi_Host *shost = class_to_shost(class_dev);
- struct ibmvscsi_host_data *hostdata =
- (struct ibmvscsi_host_data *)shost-hostdata;
+ struct ibmvscsi_host_data *hostdata = shost_priv(shost);
int len;
len = snprintf(buf, PAGE_SIZE, %d\n,
@@ -1488,8 +1479,7 @@ static struct class_device_attribute
ibmvscsi_host_mad_version = {
static ssize_t show_host_os_type(struct class_device *class_dev, char *buf)
{
struct Scsi_Host *shost = class_to_shost(class_dev);
- struct ibmvscsi_host_data *hostdata =
- (struct ibmvscsi_host_data *)shost-hostdata;
+ struct ibmvscsi_host_data *hostdata = shost_priv(shost);
int len;
len = snprintf(buf, PAGE_SIZE, %d\n, hostdata-madapter_info.os_type);
@@ -1507,8 +1497,7 @@ static struct class_device_attribute
ibmvscsi_host_os_type = {
static ssize_t show_host_config(struct class_device *class_dev, char *buf)
{
struct Scsi_Host *shost = class_to_shost(class_dev);
- struct ibmvscsi_host_data *hostdata =
- (struct ibmvscsi_host_data *)shost-hostdata;
+ struct ibmvscsi_host_data *hostdata = shost_priv(shost
[PATCH 1/2] ibmvscsi: remove unnecessary map_sg check
No need to check use_sg since sg_tablesize is set appropriately in the
scsi host template.
Brian King's patch (2a7309372fe56ae46c499b772d811ad31c501dd9) did this
cleanup but the data buffer accessors patch (written before the patch
and merged after it) restored the check.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/ibmvscsi/ibmvscsi.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index 5870866..6735260 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -393,12 +393,6 @@ static int map_sg_data(struct scsi_cmnd *cmd,
return 1;
else if (sg_mapped 0)
return 0;
- else if (sg_mapped SG_ALL) {
- printk(KERN_ERR
- ibmvscsi: More than %d mapped sg entries, got %d\n,
- SG_ALL, sg_mapped);
- return 0;
- }
set_srp_direction(cmd, srp_cmd, sg_mapped);
--
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
[PATCH 1/2] bsg: use lib/idr.c to find a unique minor number
This replaces the current linear search for a unique minor number with
lib/idr.c.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
block/bsg.c | 69 ++
include/linux/bsg.h |1 -
2 files changed, 30 insertions(+), 40 deletions(-)
diff --git a/block/bsg.c b/block/bsg.c
index 1ba9bc6..f0259c2 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -24,6 +24,7 @@
#include linux/cdev.h
#include linux/percpu.h
#include linux/uio.h
+#include linux/idr.h
#include linux/bsg.h
#include scsi/scsi.h
@@ -70,13 +71,12 @@ enum {
#endif
static DEFINE_MUTEX(bsg_mutex);
-static int bsg_device_nr, bsg_minor_idx;
+static DEFINE_IDR(bsg_minor_idr);
#define BSG_LIST_ARRAY_SIZE8
static struct hlist_head bsg_device_list[BSG_LIST_ARRAY_SIZE];
static struct class *bsg_class;
-static LIST_HEAD(bsg_class_list);
static int bsg_major;
static struct kmem_cache *bsg_cmd_cachep;
@@ -781,23 +781,18 @@ static struct bsg_device *__bsg_get_device(int minor)
static struct bsg_device *bsg_get_device(struct inode *inode, struct file
*file)
{
- struct bsg_device *bd = __bsg_get_device(iminor(inode));
- struct bsg_class_device *bcd, *__bcd;
+ struct bsg_device *bd;
+ struct bsg_class_device *bcd;
+ bd = __bsg_get_device(iminor(inode));
if (bd)
return bd;
/*
* find the class device
*/
- bcd = NULL;
mutex_lock(bsg_mutex);
- list_for_each_entry(__bcd, bsg_class_list, list) {
- if (__bcd-minor == iminor(inode)) {
- bcd = __bcd;
- break;
- }
- }
+ bcd = idr_find(bsg_minor_idr, iminor(inode));
mutex_unlock(bsg_mutex);
if (!bcd)
@@ -936,13 +931,12 @@ void bsg_unregister_queue(struct request_queue *q)
return;
mutex_lock(bsg_mutex);
+ idr_remove(bsg_minor_idr, bcd-minor);
sysfs_remove_link(q-kobj, bsg);
class_device_unregister(bcd-class_dev);
put_device(bcd-dev);
bcd-class_dev = NULL;
bcd-dev = NULL;
- list_del_init(bcd-list);
- bsg_device_nr--;
mutex_unlock(bsg_mutex);
}
EXPORT_SYMBOL_GPL(bsg_unregister_queue);
@@ -950,9 +944,9 @@ EXPORT_SYMBOL_GPL(bsg_unregister_queue);
int bsg_register_queue(struct request_queue *q, struct device *gdev,
const char *name)
{
- struct bsg_class_device *bcd, *__bcd;
+ struct bsg_class_device *bcd;
dev_t dev;
- int ret = -EMFILE;
+ int ret, minor;
struct class_device *class_dev = NULL;
const char *devname;
@@ -969,28 +963,26 @@ int bsg_register_queue(struct request_queue *q, struct
device *gdev,
bcd = q-bsg_dev;
memset(bcd, 0, sizeof(*bcd));
- INIT_LIST_HEAD(bcd-list);
mutex_lock(bsg_mutex);
- if (bsg_device_nr == BSG_MAX_DEVS) {
- printk(KERN_ERR bsg: too many bsg devices\n);
- goto err;
- }
-retry:
- list_for_each_entry(__bcd, bsg_class_list, list) {
- if (__bcd-minor == bsg_minor_idx) {
- bsg_minor_idx++;
- if (bsg_minor_idx == BSG_MAX_DEVS)
- bsg_minor_idx = 0;
- goto retry;
- }
+ ret = idr_pre_get(bsg_minor_idr, GFP_KERNEL);
+ if (!ret) {
+ ret = -ENOMEM;
+ goto unlock;
}
- bcd-minor = bsg_minor_idx++;
- if (bsg_minor_idx == BSG_MAX_DEVS)
- bsg_minor_idx = 0;
+ ret = idr_get_new(bsg_minor_idr, bcd, minor);
+ if (ret 0)
+ goto unlock;
+ if (minor = BSG_MAX_DEVS) {
+ printk(KERN_ERR bsg: too many bsg devices\n);
+ ret = -EINVAL;
+ goto remove_idr;
+ }
+
+ bcd-minor = minor;
bcd-queue = q;
bcd-dev = get_device(gdev);
dev = MKDEV(bsg_major, bcd-minor);
@@ -998,27 +990,26 @@ retry:
devname);
if (IS_ERR(class_dev)) {
ret = PTR_ERR(class_dev);
- goto err_put;
+ goto put_dev;
}
bcd-class_dev = class_dev;
if (q-kobj.sd) {
ret = sysfs_create_link(q-kobj, bcd-class_dev-kobj, bsg);
if (ret)
- goto err_unregister;
+ goto unregister_class_dev;
}
- list_add_tail(bcd-list, bsg_class_list);
- bsg_device_nr++;
-
mutex_unlock(bsg_mutex);
return 0;
-err_unregister:
+unregister_class_dev:
class_device_unregister(class_dev);
-err_put:
+put_dev:
put_device(gdev);
-err:
+remove_idr:
+ idr_remove(bsg_minor_idr, minor);
+unlock:
mutex_unlock(bsg_mutex);
return ret;
}
diff --git a/include/linux/bsg.h b/include/linux/bsg.h
index
[PATCH 2/2] bsg: remove unnecessary code and comments
- kill uhdr in bsg_command structure
- it's not necessary to put SG v4 stuff to block/scsi_ioctl.c
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
block/bsg.c |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/block/bsg.c b/block/bsg.c
index f0259c2..2b5e72b 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -9,13 +9,6 @@
* archive for more details.
*
*/
-/*
- * TODO
- * - Should this get merged, block/scsi_ioctl.c will be migrated into
- * this file. To keep maintenance down, it's easier to have them
- * seperated right now.
- *
- */
#include linux/module.h
#include linux/init.h
#include linux/file.h
@@ -92,7 +85,6 @@ struct bsg_command {
struct bio *bidi_bio;
int err;
struct sg_io_v4 hdr;
- struct sg_io_v4 __user *uhdr;
char sense[SCSI_SENSE_BUFFERSIZE];
};
@@ -620,7 +612,6 @@ static int __bsg_write(struct bsg_device *bd, const char
__user *buf,
break;
}
- bc-uhdr = (struct sg_io_v4 __user *) buf;
if (copy_from_user(bc-hdr, buf, sizeof(bc-hdr))) {
ret = -EFAULT;
break;
--
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
