date:20070507

Re: [PATCH 0/2] bidi support

2007-05-07 Thread Benny Halevy

Tomo,

Thanks for quickly crafting this patchset.
Please see my comments in-line below.

Putting aside the controversial design issues,
we need to carefully compare our patches against yours
to make sure no functional issues have been overlooked.

Benny

FUJITA Tomonori wrote:
 From: FUJITA Tomonori [EMAIL PROTECTED]
 Subject: [PATCH 0/2] bidi support
 Date: Sat, 05 May 2007 18:02:29 +0900
 
 This patchset add bidi support for block pc requests.
 
 Oh, this patchset is against Linus' tree.
 
 The first patch (the block layer changes) can be applied against Jens'
 tree.
 
 The second patch (the scsi mid-layer changes) has one minor reject
 against the scsi-misc tree. The following patch is against the
 scsi-misc.
 
 ---
 From 6a8c5375f1f6dbd574107920dd0a613527bd556b Mon Sep 17 00:00:00 2001
 From: FUJITA Tomonori [EMAIL PROTECTED]
 Date: Sat, 5 May 2007 18:11:42 +0900
 Subject: [PATCH] add bidi support for block pc requests
 
 This adds bidi support for block pc requests.
 
 A bidi request uses req-next_rq pointer for an in request.
 
 This patch introduces a new structure, scsi_data_buffer to hold the
 data buffer information. To avoid make scsi_cmnd structure fatter, the
 scsi mid-layer uses cmnd-request-next_rq-special pointer for
 a scsi_data_buffer structure. LLDs don't touch the second request
 (req-next_rq) so it's safe to use req-special.
 
 scsi_blk_pc_done() always completes the whole command so
 scsi_end_request() simply completes the bidi chunk too.
 
 A helper function, scsi_bidi_data_buffer() is for LLDs to access to
 the scsi_data_buffer structure easily.
 
 Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
 ---
  drivers/scsi/scsi_lib.c  |  120 +++--
  include/scsi/scsi_cmnd.h |   14 +
  2 files changed, 118 insertions(+), 16 deletions(-)
 
 diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
 index be8e655..8f7873a 100644
 --- a/drivers/scsi/scsi_lib.c
 +++ b/drivers/scsi/scsi_lib.c
 @@ -66,6 +66,12 @@ #undef SP
  
  static void scsi_run_queue(struct request_queue *q);
  
 +struct scsi_data_buffer *scsi_bidi_data_buffer(struct scsi_cmnd *cmd)
 +{
 + return blk_bidi_rq(cmd-request) ? cmd-request-next_rq-special : 
 NULL;
 +}
 +EXPORT_SYMBOL(scsi_bidi_data_buffer);
 +
  /*
   * Function: scsi_unprep_request()
   *
 @@ -85,6 +91,7 @@ static void scsi_unprep_request(struct r
   req-cmd_flags = ~REQ_DONTPREP;
   req-special = NULL;
  
 + kfree(scsi_bidi_data_buffer(cmd));
   scsi_put_command(cmd);
  }
  
 @@ -657,6 +664,7 @@ static struct scsi_cmnd *scsi_end_reques
   request_queue_t *q = cmd-device-request_queue;
   struct request *req = cmd-request;
   unsigned long flags;
 + struct scsi_data_buffer *sdb = scsi_bidi_data_buffer(cmd);
  
   /*
* If there are blocks left over at the end, set up the command
 @@ -685,6 +693,14 @@ static struct scsi_cmnd *scsi_end_reques
   }
   }
  
 + /*
 +  * a REQ_BLOCK_PC command is always completed fully so just do
 +  * end the bidi chunk.
 +  */
 + if (sdb)
 + end_that_request_chunk(req-next_rq, uptodate,
 +sdb-request_bufflen);

I think I agree you shouldn't call end_that_request_last(req-next_rq)
so sdb and req-next_rq should be freed here, no?

 +
   add_disk_randomness(req-rq_disk);
  
   spin_lock_irqsave(q-queue_lock, flags);
 @@ -701,34 +717,35 @@ static struct scsi_cmnd *scsi_end_reques
   return NULL;
  }
  
 -struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd *cmd, gfp_t gfp_mask)
 +static struct scatterlist *do_scsi_alloc_sgtable(unsigned short use_sg,
 +  unsigned short *sglist_len,
 +  gfp_t gfp_mask)
  {
   struct scsi_host_sg_pool *sgp;
 - struct scatterlist *sgl;
  
 - BUG_ON(!cmd-use_sg);
 + BUG_ON(!use_sg);
  
 - switch (cmd-use_sg) {
 + switch (use_sg) {
   case 1 ... 8:
 - cmd-sglist_len = 0;
 + *sglist_len = 0;
   break;
   case 9 ... 16:
 - cmd-sglist_len = 1;
 + *sglist_len = 1;
   break;
   case 17 ... 32:
 - cmd-sglist_len = 2;
 + *sglist_len = 2;
   break;
  #if (SCSI_MAX_PHYS_SEGMENTS  32)
   case 33 ... 64:
 - cmd-sglist_len = 3;
 + *sglist_len = 3;
   break;
  #if (SCSI_MAX_PHYS_SEGMENTS  64)
   case 65 ... 128:
 - cmd-sglist_len = 4;
 + *sglist_len = 4;
   break;
  #if (SCSI_MAX_PHYS_SEGMENTS   128)
   case 129 ... 256:
 - cmd-sglist_len = 5;
 + *sglist_len = 5;
   break;
  #endif
  #endif
 @@ -737,11 +754,14 @@ #endif
   return NULL;
   }
  
 - sgp = scsi_sg_pools + cmd-sglist_len;
 - sgl = mempool_alloc(sgp-pool, gfp_mask);
 - return sgl;
 + sgp =

Re: [PATCH 0/2] bidi support

2007-05-07 Thread FUJITA Tomonori

From: Benny Halevy [EMAIL PROTECTED]
Subject: Re: [PATCH 0/2] bidi support
Date: Mon, 07 May 2007 09:05:37 +0300

 Tomo,

 Thanks for quickly crafting this patchset.
 Please see my comments in-line below.

 Putting aside the controversial design issues,
 we need to carefully compare our patches against yours
 to make sure no functional issues have been overlooked.

(snip)

  @@ -685,6 +693,14 @@ static struct scsi_cmnd *scsi_end_reques
  }
  }

  +   /*
  +* a REQ_BLOCK_PC command is always completed fully so just do
  +* end the bidi chunk.
  +*/
  +   if (sdb)
  +   end_that_request_chunk(req-next_rq, uptodate,
  +  sdb-request_bufflen);

 I think I agree you shouldn't call end_that_request_last(req-next_rq)
 so sdb and req-next_rq should be freed here, no?

I think that bidi requests are en-queued via blk_execute_rq (or
blk_execute_rq_nowait). The caller frees req and req-next_rq.

  +static int scsi_data_buffer_init(struct scsi_cmnd *cmd)
  +{
  +   struct scatterlist *sgpnt;
  +   struct scsi_data_buffer *sdb = scsi_bidi_data_buffer(cmd);
  +   struct request *req = cmd-request;
  +   int count;
  +
  +   sdb-use_sg = req-next_rq-nr_phys_segments;
  +   sgpnt = do_scsi_alloc_sgtable(sdb-use_sg, sdb-sglist_len,
  + GFP_ATOMIC);
  +   if (unlikely(!sgpnt)) {
  +   scsi_free_sgtable(cmd-request_buffer, cmd-sglist_len);
  +   scsi_unprep_request(req);
  +   return BLKPREP_DEFER;
  +   }
  +
  +   req-buffer = NULL;

 req-next_rq-buffer = NULL;

 no?

Yes, but maybe we can remove this.

  +   sdb-request_buffer = (char *) sgpnt;
  +   sdb-request_bufflen = req-next_rq-data_len;
  +
  +   count = blk_rq_map_sg(req-q, req-next_rq, sgpnt);
  +   if (likely(count = sdb-use_sg)) {
  +   sdb-use_sg = count;
  +   return BLKPREP_OK;
  +   }
  +
  +   scsi_release_buffers(cmd);

 either kfree(sbd) and blk_put_request(req-next_rq) here, or
 should that be done in scsi_put_command?
 who does that on the error-free path? (see comment above in scsi_end_request)

Yeah, I think that scsi_release_buffers() should free sbd.

  +   scsi_put_command(cmd);
  +
  +   return BLKPREP_KILL;
  +}
  +
   static void scsi_blk_pc_done(struct scsi_cmnd *cmd)
   {
  BUG_ON(!blk_pc_request(cmd-request));
  @@ -1090,10 +1154,21 @@ static void scsi_blk_pc_done(struct scsi
   static int scsi_setup_blk_pc_cmnd(struct scsi_device *sdev, struct request 
  *req)
   {
  struct scsi_cmnd *cmd;
  +   struct scsi_data_buffer *sdb = NULL;
  +
  +   if (blk_bidi_rq(req)) {
  +   sdb = kzalloc(sizeof(*sdb), GFP_ATOMIC);
  +   if (unlikely(!sdb))
  +   return BLKPREP_DEFER;
  +   req-next_rq-special = sdb;
  +   }

  cmd = scsi_get_cmd_from_req(sdev, req);
  -   if (unlikely(!cmd))
  +   if (unlikely(!cmd)) {
  +   req-next_rq-special = NULL;

 req-next_rq can be NULL

Opps, thanks.

Thanks, I'll fix them and update the git tree shortly.
-
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: Stop system after memory corruption

2007-05-07 Thread Swen Schillig

From: Christof Schmitt [EMAIL PROTECTED]

For each request that is sent to the FCP adapter, zfcp allocates
memory. Status information and data that is being read from the
device is written to this memory by the hardware. After that,
the hardware signals this via the response queue and zfcp
continues processing.

Now, if zfcp detects that there is a signal for an incoming
response from the hardware, but there is no outstanding request
for that request id, then some memory that can be in use anywhere
in the system has just been overwritten. This should never happen,
but if it does, stop the system with a panic.


Signed-off-by: Christof Schmitt [EMAIL PROTECTED]
Signed-off-by: Swen Schillig [EMAIL PROTECTED]
---

 drivers/s390/scsi/zfcp_qdio.c |   32 +---
 1 files changed, 5 insertions(+), 27 deletions(-)

diff -urpN linux-2.6/drivers/s390/scsi/zfcp_qdio.c 
linux-2.6-patched/drivers/s390/scsi/zfcp_qdio.c
--- linux-2.6/drivers/s390/scsi/zfcp_qdio.c 2007-05-07 12:47:16.0 
+0200
+++ linux-2.6-patched/drivers/s390/scsi/zfcp_qdio.c 2007-05-07 
12:47:26.0 +0200
@@ -285,8 +285,8 @@ zfcp_qdio_request_handler(struct ccw_dev
 /**
  * zfcp_qdio_reqid_check - checks for valid reqids or unsolicited status
  */
-static int zfcp_qdio_reqid_check(struct zfcp_adapter *adapter, 
-unsigned long req_id)
+static void zfcp_qdio_reqid_check(struct zfcp_adapter *adapter, 
+ unsigned long req_id)
 {
struct zfcp_fsf_req *fsf_req;
unsigned long flags;
@@ -298,9 +298,7 @@ static int zfcp_qdio_reqid_check(struct 

if (!fsf_req) {
spin_unlock_irqrestore(adapter-req_list_lock, flags);
-   ZFCP_LOG_NORMAL(error: unknown request id (%ld).\n, req_id);
-   zfcp_erp_adapter_reopen(adapter, 0);
-   return -EINVAL;
+   panic(error: unknown request id (%ld).\n, req_id);
}

zfcp_reqlist_remove(adapter, req_id);
@@ -309,8 +307,6 @@ static int zfcp_qdio_reqid_check(struct 

/* finish the FSF request */
zfcp_fsf_req_complete(fsf_req);
-
-   return 0;
 }

 /*
@@ -374,27 +370,9 @@ zfcp_qdio_response_handler(struct ccw_de

/* look for QDIO request identifiers in SB */
buffere = buffer-element[buffere_index];
-   retval = zfcp_qdio_reqid_check(adapter,
-   (unsigned long) buffere-addr);
+   zfcp_qdio_reqid_check(adapter,
+ (unsigned long) buffere-addr);

-   if (retval) {
-   ZFCP_LOG_NORMAL(bug: unexpected inbound 
-   packet on adapter %s 
-   (reqid=0x%lx, 
-   first_element=%d, 
-   elements_processed=%d)\n,
-   
zfcp_get_busid_by_adapter(adapter),
-   (unsigned long) buffere-addr,
-   first_element,
-   elements_processed);
-   ZFCP_LOG_NORMAL(hex dump of inbound buffer 
-   at address %p 
-   (buffer_index=%d, 
-   buffere_index=%d)\n, buffer,
-   buffer_index, buffere_index);
-   ZFCP_HEX_DUMP(ZFCP_LOG_LEVEL_NORMAL,
- (char *) buffer, SBAL_SIZE);
-   }
/*
 * A single used SBALE per inbound SBALE has been
 * implemented by QDIO so far. Hope they will


---
-
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/6] qla2xxx: updates for 2.6.22 [8.01.07-k7].

2007-05-07 Thread Andrew Vasquez

This patchset updates the qla2xxx driver to 8.01.07-k7.

 drivers/scsi/qla2xxx/qla_init.c|   33 -
 drivers/scsi/qla2xxx/qla_isr.c |   15 ++-
 drivers/scsi/qla2xxx/qla_os.c  |6 ++
 drivers/scsi/qla2xxx/qla_version.h |2 +-
 4 files changed, 33 insertions(+), 23 deletions(-)

here's the commits:

- Error-out during probe() if we're unable to complete HBA initialization.
- Honor NVRAM port-down-retry-count settings.
- Attempt to stop firmware only if it had been previously executed.
- Correct pci_set_msi() usage semantics.
- Add MSI support.
- Update version number to 8.01.07-k7.

Regards,
Andrew Vasquez
QLogic Corporation
-
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/6] qla2xxx: Error-out during probe() if we're unable to complete HBA initialization.

2007-05-07 Thread Andrew Vasquez

Remove a stale check against ha-device_flags
(DFLG_NO_CABLE) as topology scanning is performed within the
DPC-thread context.

Signed-off-by: Andrew Vasquez [EMAIL PROTECTED]
---
 drivers/scsi/qla2xxx/qla_os.c |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index b78919a..0a36912 100644
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -1577,9 +1577,7 @@ qla2x00_probe_one(struct pci_dev *pdev, const struct 
pci_device_id *id)
goto probe_failed;
}
 
-   if (qla2x00_initialize_adapter(ha) 
-   !(ha-device_flags  DFLG_NO_CABLE)) {
-
+   if (qla2x00_initialize_adapter(ha)) {
qla_printk(KERN_WARNING, ha,
Failed to initialize adapter\n);
 
-- 
1.5.2.rc1.9.g6644

-
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/6] qla2xxx: Honor NVRAM port-down-retry-count settings.

2007-05-07 Thread Andrew Vasquez

Hardcoding the qlport_down_retry module-parameter
effectively disallowed any user-defined NVRAM setting to go
into effect.

Signed-off-by: Andrew Vasquez [EMAIL PROTECTED]
---
 drivers/scsi/qla2xxx/qla_os.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index 0a36912..dd076da 100644
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -36,7 +36,7 @@ module_param(ql2xlogintimeout, int, S_IRUGO|S_IRUSR);
 MODULE_PARM_DESC(ql2xlogintimeout,
Login timeout value in seconds.);
 
-int qlport_down_retry = 30;
+int qlport_down_retry;
 module_param(qlport_down_retry, int, S_IRUGO|S_IRUSR);
 MODULE_PARM_DESC(qlport_down_retry,
Maximum number of command retries to a port that returns 
-- 
1.5.2.rc1.9.g6644

-
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/6] qla2xxx: Attempt to stop firmware only if it had been previously executed.

2007-05-07 Thread Andrew Vasquez

Signed-off-by: Andrew Vasquez [EMAIL PROTECTED]
---
 drivers/scsi/qla2xxx/qla_init.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 3e296ab..6ad1588 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -3931,6 +3931,8 @@ qla2x00_try_to_stop_firmware(scsi_qla_host_t *ha)
 
if (!IS_QLA24XX(ha)  !IS_QLA54XX(ha))
return;
+   if (!ha-fw_major_version)
+   return;
 
ret = qla2x00_stop_firmware(ha);
for (retries = 5; ret != QLA_SUCCESS  retries ; retries--) {
-- 
1.5.2.rc1.9.g6644

-
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/6] qla2xxx: Correct pci_set_msi() usage semantics.

2007-05-07 Thread Andrew Vasquez

Signed-off-by: Andrew Vasquez [EMAIL PROTECTED]
---
 drivers/scsi/qla2xxx/qla_init.c |   31 ++-
 1 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 6ad1588..db998d8 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -130,18 +130,17 @@ qla2x00_initialize_adapter(scsi_qla_host_t *ha)
 int
 qla2100_pci_config(scsi_qla_host_t *ha)
 {
-   uint16_t w, mwi;
+   int ret;
+   uint16_t w;
uint32_t d;
unsigned long flags;
struct device_reg_2xxx __iomem *reg = ha-iobase-isp;
 
pci_set_master(ha-pdev);
-   mwi = 0;
-   if (pci_set_mwi(ha-pdev))
-   mwi = PCI_COMMAND_INVALIDATE;
+   ret = pci_set_mwi(ha-pdev);
 
pci_read_config_word(ha-pdev, PCI_COMMAND, w);
-   w |= mwi | (PCI_COMMAND_PARITY | PCI_COMMAND_SERR);
+   w |= (PCI_COMMAND_PARITY | PCI_COMMAND_SERR);
pci_write_config_word(ha-pdev, PCI_COMMAND, w);
 
/* Reset expansion ROM address decode enable */
@@ -166,22 +165,22 @@ qla2100_pci_config(scsi_qla_host_t *ha)
 int
 qla2300_pci_config(scsi_qla_host_t *ha)
 {
-   uint16_tw, mwi;
+   int ret;
+   uint16_tw;
uint32_td;
unsigned long   flags = 0;
uint32_tcnt;
struct device_reg_2xxx __iomem *reg = ha-iobase-isp;
 
pci_set_master(ha-pdev);
-   mwi = 0;
-   if (pci_set_mwi(ha-pdev))
-   mwi = PCI_COMMAND_INVALIDATE;
+   ret = pci_set_mwi(ha-pdev);
 
pci_read_config_word(ha-pdev, PCI_COMMAND, w);
-   w |= mwi | (PCI_COMMAND_PARITY | PCI_COMMAND_SERR);
+   w |= (PCI_COMMAND_PARITY | PCI_COMMAND_SERR);
 
if (IS_QLA2322(ha) || IS_QLA6322(ha))
w = ~PCI_COMMAND_INTX_DISABLE;
+   pci_write_config_word(ha-pdev, PCI_COMMAND, w);
 
/*
 * If this is a 2300 card and not 2312, reset the
@@ -210,7 +209,7 @@ qla2300_pci_config(scsi_qla_host_t *ha)
ha-fb_rev = RD_FB_CMD_REG(ha, reg);
 
if (ha-fb_rev == FPM_2300)
-   w = ~PCI_COMMAND_INVALIDATE;
+   pci_clear_mwi(ha-pdev);
 
/* Deselect FPM registers. */
WRT_REG_WORD(reg-ctrl_status, 0x0);
@@ -227,7 +226,6 @@ qla2300_pci_config(scsi_qla_host_t *ha)
 
spin_unlock_irqrestore(ha-hardware_lock, flags);
}
-   pci_write_config_word(ha-pdev, PCI_COMMAND, w);
 
pci_write_config_byte(ha-pdev, PCI_LATENCY_TIMER, 0x80);
 
@@ -253,19 +251,18 @@ qla2300_pci_config(scsi_qla_host_t *ha)
 int
 qla24xx_pci_config(scsi_qla_host_t *ha)
 {
-   uint16_t w, mwi;
+   int ret;
+   uint16_t w;
uint32_t d;
unsigned long flags = 0;
struct device_reg_24xx __iomem *reg = ha-iobase-isp24;
int pcix_cmd_reg, pcie_dctl_reg;
 
pci_set_master(ha-pdev);
-   mwi = 0;
-   if (pci_set_mwi(ha-pdev))
-   mwi = PCI_COMMAND_INVALIDATE;
+   ret = pci_set_mwi(ha-pdev);
 
pci_read_config_word(ha-pdev, PCI_COMMAND, w);
-   w |= mwi | (PCI_COMMAND_PARITY | PCI_COMMAND_SERR);
+   w |= (PCI_COMMAND_PARITY | PCI_COMMAND_SERR);
w = ~PCI_COMMAND_INTX_DISABLE;
pci_write_config_word(ha-pdev, PCI_COMMAND, w);
 
-- 
1.5.2.rc1.9.g6644

-
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 6/6] qla2xxx: Update version number to 8.01.07-k7.

2007-05-07 Thread Andrew Vasquez

Signed-off-by: Andrew Vasquez [EMAIL PROTECTED]
---
 drivers/scsi/qla2xxx/qla_version.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_version.h 
b/drivers/scsi/qla2xxx/qla_version.h
index dc85495..c375a4e 100644
--- a/drivers/scsi/qla2xxx/qla_version.h
+++ b/drivers/scsi/qla2xxx/qla_version.h
@@ -7,7 +7,7 @@
 /*
  * Driver version
  */
-#define QLA2XXX_VERSION  8.01.07-k6
+#define QLA2XXX_VERSION  8.01.07-k7
 
 #define QLA_DRIVER_MAJOR_VER   8
 #define QLA_DRIVER_MINOR_VER   1
-- 
1.5.2.rc1.9.g6644

-
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/6] qla2xxx: Add MSI support.

2007-05-07 Thread Andrew Vasquez

Supported ISP types include ISP2422 and revision-2 type
ISP2432 chips.

Signed-off-by: Andrew Vasquez [EMAIL PROTECTED]
---
 drivers/scsi/qla2xxx/qla_isr.c |   15 ++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index d488561..ca46346 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -1726,6 +1726,17 @@ qla2x00_request_irqs(scsi_qla_host_t *ha)
qla_printk(KERN_WARNING, ha,
MSI-X: Falling back-to INTa mode -- %d.\n, ret);
 skip_msix:
+
+   if (!IS_QLA24XX(ha))
+   goto skip_msi;
+
+   ret = pci_enable_msi(ha-pdev);
+   if (!ret) {
+   DEBUG2(qla_printk(KERN_INFO, ha, MSI: Enabled.\n));
+   ha-flags.msi_enabled = 1;
+   }
+skip_msi:
+
ret = request_irq(ha-pdev-irq, ha-isp_ops.intr_handler,
IRQF_DISABLED|IRQF_SHARED, QLA2XXX_DRIVER_NAME, ha);
if (!ret) {
@@ -1746,6 +1757,8 @@ qla2x00_free_irqs(scsi_qla_host_t *ha)
 
if (ha-flags.msix_enabled)
qla24xx_disable_msix(ha);
-   else if (ha-flags.inta_enabled)
+   else if (ha-flags.inta_enabled) {
free_irq(ha-host-irq, ha);
+   pci_disable_msi(ha-pdev);
+   }
 }
-- 
1.5.2.rc1.9.g6644

-
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: [Stgt-devel] Question for pass-through target design

2007-05-07 Thread Vladislav Bolkhovitin


FUJITA Tomonori wrote:

It looks like the pass-through target support is currently broken, at
least as I've checked for ibmvstgt, but I think it's a general problem.
I wanted to check my assumptions and get ideas.


Yeah, unfortunately, it works only with the iSCSI target driver (which
runs in user space).




The code isn't allocating any memory to pass along to the sg code to store
the result of a read or data for a write.  Currently, dxferp for sg_io_hdr
or dout_xferp/din_xferp for sg_io_v4 are assigned to the value of uaddr,
which is set to 0 in kern_queue_cmd.  With the pointer set to NULL,
the pass-through target isn't going to function.  Even if we had memory
allocated, there isn't a means of getting data to be written via sg down
this code path.

What ideas are there as to how the data will get to user-space so that
we can use sg?


For kernel-space drivers, we don't need to go to user-space. We can do
the pass-through in kernel space. I talked with James about this last
year and he said that if the code is implemented cleanly, he would
merges it into mainline.


We already have a pass-through in the kernel space for
kernel space drivers. It is the scsi_tgt* code.



Could you elaborate more?

What I meant that is that the kernel tgt code (scsi_tgt*) receives
SCSI commands from one lld and send them to another lld instead of
sending them to user space.


Although the approach of passing SCSI commands from a target LLD to an
initiator one without any significant interventions from the target
software looks to be nice and simple, you should realize how limited,
unsafe and illegal it is, since it badly violates SCSI specs.

Before I elaborate, let's have the following terminology in addition to
one described in SAM:

 - Target system - the overall system containing target and initiator
devices (and their LDDs). Target system exports one or more initiator
devices via the target device(s).

 - Target device - a SCSI device on the target system in the target mode.

 - Initiator device - a SCSI device on the target system in the
initiator mode. It actually serves commands that come from remote
initiators via target device(s).

 - Remote initiator - a SCSI initiator device connected to the target
device on the target system and uses (i.e. sends SCSI commands) exported
by it devices.

 - Target software - software that runs on the target system and
implements the necessary pass-through functionality

Let's consider a simplest case when a target system has one target
device, one initiator device and it exports the initiator device via the
target device as pass-through. The problem is that then the target
system creates a new SCSI target device, which is not the same as the
exported initiator device. Particularly, the new device could have 1
nexuses with remote initiators connected to it, while the initiator
device has no glue about them, it sees a single nexus with the target
system and only it.

And so? All the event notifications, which should be seen by all remote
initiators will be delivered to only one of them or not generated at
all, since some events are generated only for I_T nexuses other, than
one on which the command causing the event is received. The most common
example of such events is Unit Attentions. For example, after MODE
SELECT command, all remote initiators, except one, who sent the command,
shall receive MODE PARAMETERS CHANGED Unit Attention. Otherwise a bad
and quiet data corruption could happen.

More complicated example is SCSI reservations, doesn't matter persistent
or SPC-2 ones. Since the initiator device knows only about one nexus,
instead of actual many of them, the reservation commands should be
completely handled by target software on the target system. Having
delivery of Unit Attentions to all remote initiators especially
important for reservations, since they could mean that a reservation was
revoked by another initiator via, e.g., some task management function.

Things get even worse if we realize that (1) the initiator device could
report about its capabilities (like ACA support), which aren't supported
by the target software, hence misinform the remote initiators and again
could provoke a quiet data corruption, and (2) accesses to the initiator
devices from local programs on the target systems create another I_T
nexus, which needs to be handled as well.

(I suppose it is obvious that if the target system exports 1 initiator
devices via a single target device, since the initiator devices don't
know about each other, the target software in any case needs to
implement its own LUN addressing as well as own REPORT LUNS command
handler).

Thus, such in-kernel pass-through mode could be used only for limited
set of SCSI commands and SCSI device types with a big caution and
complete comprehension what's going on and how it should be. The latter
isn't true in the absolute majority of uses and users, so such approach
will give users a perfect weapon to shoot themselfs.

If you

Re: [Stgt-devel] Question for pass-through target design

2007-05-07 Thread FUJITA Tomonori

From: Vladislav Bolkhovitin [EMAIL PROTECTED]
Subject: Re: [Stgt-devel] Question for pass-through target design
Date: Mon, 07 May 2007 18:24:44 +0400

 FUJITA Tomonori wrote:
 It looks like the pass-through target support is currently broken, at
 least as I've checked for ibmvstgt, but I think it's a general problem.
 I wanted to check my assumptions and get ideas.

 Yeah, unfortunately, it works only with the iSCSI target driver (which
 runs in user space).

 The code isn't allocating any memory to pass along to the sg code to store
 the result of a read or data for a write.  Currently, dxferp for sg_io_hdr
 or dout_xferp/din_xferp for sg_io_v4 are assigned to the value of uaddr,
 which is set to 0 in kern_queue_cmd.  With the pointer set to NULL,
 the pass-through target isn't going to function.  Even if we had memory
 allocated, there isn't a means of getting data to be written via sg down
 this code path.

 What ideas are there as to how the data will get to user-space so that
 we can use sg?

 For kernel-space drivers, we don't need to go to user-space. We can do
 the pass-through in kernel space. I talked with James about this last
 year and he said that if the code is implemented cleanly, he would
 merges it into mainline.

 We already have a pass-through in the kernel space for
 kernel space drivers. It is the scsi_tgt* code.

  Could you elaborate more?

  What I meant that is that the kernel tgt code (scsi_tgt*) receives
  SCSI commands from one lld and send them to another lld instead of
  sending them to user space.

 Although the approach of passing SCSI commands from a target LLD to an
 initiator one without any significant interventions from the target
 software looks to be nice and simple, you should realize how limited,
 unsafe and illegal it is, since it badly violates SCSI specs.

I think that 'implemented cleanly' means that one scsi_host is assigned
to only one initiator.
-
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: [Stgt-devel] Question for pass-through target design

2007-05-07 Thread Vladislav Bolkhovitin

FUJITA Tomonori wrote:

From: Vladislav Bolkhovitin [EMAIL PROTECTED]
Subject: Re: [Stgt-devel] Question for pass-through target design
Date: Mon, 07 May 2007 18:24:44 +0400

FUJITA Tomonori wrote:

It looks like the pass-through target support is currently broken, at
least as I've checked for ibmvstgt, but I think it's a general problem.
I wanted to check my assumptions and get ideas.

Yeah, unfortunately, it works only with the iSCSI target driver (which
runs in user space).

The code isn't allocating any memory to pass along to the sg code to store
the result of a read or data for a write.  Currently, dxferp for sg_io_hdr
or dout_xferp/din_xferp for sg_io_v4 are assigned to the value of uaddr,
which is set to 0 in kern_queue_cmd.  With the pointer set to NULL,
the pass-through target isn't going to function.  Even if we had memory
allocated, there isn't a means of getting data to be written via sg down
this code path.

What ideas are there as to how the data will get to user-space so that
we can use sg?

For kernel-space drivers, we don't need to go to user-space. We can do
the pass-through in kernel space. I talked with James about this last
year and he said that if the code is implemented cleanly, he would
merges it into mainline.

We already have a pass-through in the kernel space for
kernel space drivers. It is the scsi_tgt* code.

Could you elaborate more?

What I meant that is that the kernel tgt code (scsi_tgt*) receives
SCSI commands from one lld and send them to another lld instead of
sending them to user space.

Although the approach of passing SCSI commands from a target LLD to an
initiator one without any significant interventions from the target
software looks to be nice and simple, you should realize how limited,
unsafe and illegal it is, since it badly violates SCSI specs.

I think that 'implemented cleanly' means that one scsi_host is assigned
to only one initiator.

Sorry, I don't fully understand you. If you mean you are going to limit 
only one remote initiator per-target device, then, well, is it even more 
limited (and limiting) or not?

___
Stgt-devel mailing list
[EMAIL PROTECTED]
https://lists.berlios.de/mailman/listinfo/stgt-devel

-
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/7] SCSI: save disk in scsi_device - resend

2007-05-07 Thread Kristen Carlson Accardi

On Fri, 04 May 2007 15:30:48 -0500
James Bottomley [EMAIL PROTECTED] wrote:

 On Fri, 2007-05-04 at 11:17 -0700, Kristen Carlson Accardi wrote:
  Give anyone who has access to scsi_device access to the genhd struct as 
  well.
  
  Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
  Index: 2.6-git/drivers/scsi/sd.c
  ===
  --- 2.6-git.orig/drivers/scsi/sd.c
  +++ 2.6-git/drivers/scsi/sd.c
  @@ -1711,6 +1711,7 @@ static int sd_probe(struct device *dev)
   
  dev_set_drvdata(dev, sdkp);
  add_disk(gd);
  +   sdp-disk = gd;
   
  sdev_printk(KERN_NOTICE, sdp, Attached scsi %sdisk %s\n,
  sdp-removable ? removable  : , gd-disk_name);
  Index: 2.6-git/drivers/scsi/sr.c
  ===
  --- 2.6-git.orig/drivers/scsi/sr.c
  +++ 2.6-git/drivers/scsi/sr.c
  @@ -604,6 +604,7 @@ static int sr_probe(struct device *dev)
  if (sdev-media_change_notify)
  disk-flags |= GENHD_FL_MEDIA_CHANGE_NOTIFY;
  add_disk(disk);
  +   sdev-disk = disk;
   
  sdev_printk(KERN_DEBUG, sdev,
  Attached scsi CD-ROM %s\n, cd-cdi.name);
  Index: 2.6-git/include/scsi/scsi_device.h
  ===
  --- 2.6-git.orig/include/scsi/scsi_device.h
  +++ 2.6-git/include/scsi/scsi_device.h
  @@ -138,7 +138,7 @@ struct scsi_device {
   
  struct device   sdev_gendev;
  struct class_device sdev_classdev;
  -
  +   struct gendisk  *disk;
  struct execute_work ew; /* used to get process context on put */
   
  enum scsi_device_state sdev_state;
 
 If you're going to do this, you need to take on board removing the
 struct gendisk from all the ULD structures (since it's now become
 generic).
 
 James
 

Ok - I can send that as a separate patch series, or I can include it
in this one.  Which is preferred?
-
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: [Stgt-devel] Question for pass-through target design

2007-05-07 Thread FUJITA Tomonori

From: Vladislav Bolkhovitin [EMAIL PROTECTED]
Subject: Re: [Stgt-devel] Question for pass-through target design
Date: Mon, 07 May 2007 19:27:23 +0400

 FUJITA Tomonori wrote:
  From: Vladislav Bolkhovitin [EMAIL PROTECTED]
  Subject: Re: [Stgt-devel] Question for pass-through target design
  Date: Mon, 07 May 2007 18:24:44 +0400

 FUJITA Tomonori wrote:

 It looks like the pass-through target support is currently broken, at
 least as I've checked for ibmvstgt, but I think it's a general problem.
 I wanted to check my assumptions and get ideas.

 Yeah, unfortunately, it works only with the iSCSI target driver (which
 runs in user space).

 The code isn't allocating any memory to pass along to the sg code to 
 store
 the result of a read or data for a write.  Currently, dxferp for 
 sg_io_hdr
 or dout_xferp/din_xferp for sg_io_v4 are assigned to the value of uaddr,
 which is set to 0 in kern_queue_cmd.  With the pointer set to NULL,
 the pass-through target isn't going to function.  Even if we had memory
 allocated, there isn't a means of getting data to be written via sg down
 this code path.

 What ideas are there as to how the data will get to user-space so that
 we can use sg?

 For kernel-space drivers, we don't need to go to user-space. We can do
 the pass-through in kernel space. I talked with James about this last
 year and he said that if the code is implemented cleanly, he would
 merges it into mainline.

 We already have a pass-through in the kernel space for
 kernel space drivers. It is the scsi_tgt* code.

 Could you elaborate more?

 What I meant that is that the kernel tgt code (scsi_tgt*) receives
 SCSI commands from one lld and send them to another lld instead of
 sending them to user space.

 Although the approach of passing SCSI commands from a target LLD to an
 initiator one without any significant interventions from the target
 software looks to be nice and simple, you should realize how limited,
 unsafe and illegal it is, since it badly violates SCSI specs.

  I think that 'implemented cleanly' means that one scsi_host is assigned
  to only one initiator.

 Sorry, I don't fully understand you. If you mean you are going to limit 
 only one remote initiator per-target device, then, well, is it even more 
 limited (and limiting) or not?

The target software assigns one scsi_host to only one remote
initiator. For FC, NPIV works nicely.
-
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

bidi bsg is non-blocking

2007-05-07 Thread Daniel . E . Messinger


Greetings to all,

I'm attempting to use the bidi variant of bsg to talk to an OSD target
device. I've run into an undesirable situation.

My application has a free-running receive loop (doing a read() on the bsg
device) waiting for responses to commands sent to bsg by another thread.
The problem is that the receive thread is getting ENODATA from the read()
when there are no commands pending.  I have NOT set non-blocking.

Note that the old sg driver was quite willing to block until there was a
response available. I find this scenario greatly preferable.

Could bsg be fixed so that read() blocks when there is nothing to return?



Dan Messinger
Seagate Technology Research


-
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: [Stgt-devel] Question for pass-through target design

2007-05-07 Thread Vladislav Bolkhovitin

FUJITA Tomonori wrote:

From: Vladislav Bolkhovitin [EMAIL PROTECTED]
Subject: Re: [Stgt-devel] Question for pass-through target design
Date: Mon, 07 May 2007 19:27:23 +0400

FUJITA Tomonori wrote:

From: Vladislav Bolkhovitin [EMAIL PROTECTED]
Subject: Re: [Stgt-devel] Question for pass-through target design
Date: Mon, 07 May 2007 18:24:44 +0400

FUJITA Tomonori wrote:

It looks like the pass-through target support is currently broken, at
least as I've checked for ibmvstgt, but I think it's a general problem.
I wanted to check my assumptions and get ideas.

Yeah, unfortunately, it works only with the iSCSI target driver (which
runs in user space).

The code isn't allocating any memory to pass along to the sg code to store
the result of a read or data for a write.  Currently, dxferp for sg_io_hdr
or dout_xferp/din_xferp for sg_io_v4 are assigned to the value of uaddr,
which is set to 0 in kern_queue_cmd.  With the pointer set to NULL,
the pass-through target isn't going to function.  Even if we had memory
allocated, there isn't a means of getting data to be written via sg down
this code path.

What ideas are there as to how the data will get to user-space so that
we can use sg?

For kernel-space drivers, we don't need to go to user-space. We can do
the pass-through in kernel space. I talked with James about this last
year and he said that if the code is implemented cleanly, he would
merges it into mainline.

We already have a pass-through in the kernel space for
kernel space drivers. It is the scsi_tgt* code.

Could you elaborate more?

What I meant that is that the kernel tgt code (scsi_tgt*) receives
SCSI commands from one lld and send them to another lld instead of
sending them to user space.

Although the approach of passing SCSI commands from a target LLD to an
initiator one without any significant interventions from the target
software looks to be nice and simple, you should realize how limited,
unsafe and illegal it is, since it badly violates SCSI specs.

I think that 'implemented cleanly' means that one scsi_host is assigned
to only one initiator.

Sorry, I don't fully understand you. If you mean you are going to limit 
only one remote initiator per-target device, then, well, is it even more 
limited (and limiting) or not?

The target software assigns one scsi_host to only one remote
initiator. For FC, NPIV works nicely.

OK, if such limitation is OK for your users, then I'm happy for you.

___
Stgt-devel mailing list
[EMAIL PROTECTED]
https://lists.berlios.de/mailman/listinfo/stgt-devel

-
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 05/30] scsi: remove unnecessary check in drivers/scsi/sg.c

2007-05-07 Thread James Bottomley

On Thu, 2007-04-26 at 00:35 -0700, [EMAIL PROTECTED] wrote:
 From: Eric Sesterhenn [EMAIL PROTECTED]
 
 coverity spotted this (cid #758).  All callers dereference sfp, so we dont
 need this check.  In addition to this, we dereference it earlier in the
 function.

Awaiting ACK from dougg

James


-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 04/30] megaraid: fix warnings when CONFIG_PROC_FS=n

2007-05-07 Thread James Bottomley

On Thu, 2007-04-26 at 00:35 -0700, [EMAIL PROTECTED] wrote:
 From: walter harms [EMAIL PROTECTED]
 
 Signed-off-by: walter harms [EMAIL PROTECTED]
 Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
 Cc: Adrian Bunk [EMAIL PROTECTED]
 Signed-off-by: Andrew Morton [EMAIL PROTECTED]

Need ack from maintainer (cc'd) ... and possibly need maintainer.

James


-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fill in scsi_host_template module owner

2007-05-07 Thread Mike Christie

Olaf Kirch wrote:
 I recently ran into an oops that happens because you
 can shut down all of iSCSI even though you still have
 iSCSI targets mounted. It turned out that iscsi's
 scsi_host_template missed a THIS_MODULE, so
 reference counting wasn't done properly. Brief
 inspection showed that this seems to be a rather
 wide-spread problem. Here's a patch to address this.
 

I did not see this in scsi-misc so I am not sure if it matters or you
need a ack or signed off for iscsi, but the iscsi and iser parts look ok

Signed-off-by: Mike Christie [EMAIL PROTECTED]

 Index: linux-2.6/drivers/scsi/iscsi_tcp.c
 ===
 --- linux-2.6.orig/drivers/scsi/iscsi_tcp.c
 +++ linux-2.6/drivers/scsi/iscsi_tcp.c
 @@ -2133,6 +2133,7 @@ static void iscsi_tcp_session_destroy(st
  }
  
  static struct scsi_host_template iscsi_sht = {
 + .module = THIS_MODULE,
   .name   = iSCSI Initiator over TCP/IP,
   .queuecommand   = iscsi_queuecommand,
   .change_queue_depth = iscsi_change_queue_depth,


 Index: linux-2.6/drivers/infiniband/ulp/iser/iscsi_iser.c
 ===
 --- linux-2.6.orig/drivers/infiniband/ulp/iser/iscsi_iser.c
 +++ linux-2.6/drivers/infiniband/ulp/iser/iscsi_iser.c
 @@ -543,6 +543,7 @@ iscsi_iser_ep_disconnect(__u64 ep_handle
  }
  
  static struct scsi_host_template iscsi_iser_sht = {
 + .module = THIS_MODULE,
   .name   = iSCSI Initiator over iSER, v. DRV_VER,
   .queuecommand   = iscsi_queuecommand,
   .can_queue  = ISCSI_XMIT_CMDS_MAX - 1,
 

-
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] [PATCH 4/5] qla4xxx: Add IPv6 support and misc

2007-05-07 Thread Mike Christie

David C Somayajulu wrote:
 Signed-off-by: David Somayajulu [EMAIL PROTECTED]
 
 ---
  drivers/scsi/qla4xxx/ql4_mbx.c |  190 ++--
 
 diff --git a/drivers/scsi/qla4xxx/ql4_mbx.c b/drivers/scsi/qla4xxx/ql4_mbx.c
 index 7f28657..0ef777a 100644
 --- a/drivers/scsi/qla4xxx/ql4_mbx.c
 +++ b/drivers/scsi/qla4xxx/ql4_mbx.c
 @@ -6,6 +6,10 @@
   */
  
  #include ql4_def.h
 +#include ql4_version.h
 +#include ql4_glbl.h
 +#include ql4_dbg.h
 +#include ql4_inline.h

Did you need to bring in all of these? You did not need version did you?

  
 - memset((void *)fw_ddb_entry-iSCSIAlias, 0,
 -sizeof(fw_ddb_entry-iSCSIAlias));
 + memset((void *)fw_ddb_entry-iscsi_alias, 0,
 +sizeof(fw_ddb_entry-iscsi_alias));
  
 - memset((void *)fw_ddb_entry-iscsiName, 0,
 -sizeof(fw_ddb_entry-iscsiName));
 + memset((void *)fw_ddb_entry-iscsi_name, 0,
 +sizeof(fw_ddb_entry-iscsi_name));
  
 - memset((void *)fw_ddb_entry-ipAddr, 0, sizeof(fw_ddb_entry-ipAddr));
 - memset((void *)fw_ddb_entry-targetAddr, 0,
 -sizeof(fw_ddb_entry-targetAddr));
 + memset((void *)fw_ddb_entry-ip_addr, 0, sizeof(fw_ddb_entry-ip_addr));
 + memset((void *)fw_ddb_entry-tgt_addr, 0,
 +sizeof(fw_ddb_entry-tgt_addr));
  

I am not sure if it is a big deal or if it clutters the code, but I do
not think you need the void * casts in there.
-
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] [PATCH 1/5] qla4xxx: Add IPv6 support and misc

2007-05-07 Thread Mike Christie

David C Somayajulu wrote:
 Signed-off-by: David Somayajulu [EMAIL PROTECTED]
 
 ---
  drivers/scsi/qla4xxx/ql4_def.h |   84 ---
  drivers/scsi/qla4xxx/ql4_fw.h  |  426 
 +++-
 
 diff --git a/drivers/scsi/qla4xxx/ql4_def.h b/drivers/scsi/qla4xxx/ql4_def.h
 index 6f4cf2d..7bbc2ab 100644
 --- a/drivers/scsi/qla4xxx/ql4_def.h
 +++ b/drivers/scsi/qla4xxx/ql4_def.h
 @@ -122,8 +122,7 @@ #define MAX_REQS_SERVICED_PER_INTR16
  
  #define ISCSI_IPADDR_SIZE4   /* IP address size */
  #define ISCSI_ALIAS_SIZE 32  /* ISCSI Alais name size */
 -#define ISCSI_NAME_SIZE  255 /* ISCSI Name size -
 -  * usually a string */
 +#define ISCSI_NAME_SIZE  0xE0/* ISCSI Name size */
  
  #define LSDW(x) ((u32)((u64)(x)))
  #define MSDW(x) ((u32)u64)(x))  16)  16))
 @@ -159,6 +158,7 @@ struct srb {
   struct ddb_entry*ddb;
   uint16_t flags; /* (1) Status flags. */
  
 +#define SRB_SCSI_PASSTHRUBIT_2   /* for scsi passthru cmds */


Is this ever set or is the passthrough code in these patches ever used
or hit in upstream code or is it going to be used? It is doing the same
thing as sg io or is it different?
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [Bugme-new] [Bug 8426] New: massive slowdown on SCSI CD/DVDdrive connected to mptspi driver

2007-05-07 Thread Doug Chapman

On Fri, 2007-05-04 at 17:58 -0500, James Bottomley wrote:
 On Fri, 2007-05-04 at 17:56 -0400, Doug Chapman wrote:
  I am applying/removing _only_ your patch and the problem goes away with
  just removing it.
 
 What id and channel is this DVD drive on?  There is a potential bug in
 the move:
 
 -mptscsih_writeIOCPage4(MPT_SCSI_HOST *hd, int channel, int id)
 +mptspi_writeIOCPage4(MPT_SCSI_HOST *hd, u8 channel , u8 id)
 

I manually changed channel and id back to int and it does not seem to
have any affect.

It is looking like the issue is related to the order in how things are
called.  That is the only real change in functionality.  Perhaps there
is something that used to get initialized before mpt*_initTarget that is
now called after?  I don't see anything obvious but I am unfamiliar with
the code and have not had the time to study it all that much.

- Doug


-
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] [PATCH 4/5] qla4xxx: Add IPv6 support and misc

2007-05-07 Thread David Somayajulu

 From: Mike Christie [mailto:[EMAIL PROTECTED]
 Sent: Monday, May 07, 2007 11:31 AM
 David C Somayajulu wrote:
  Signed-off-by: David Somayajulu [EMAIL PROTECTED]
 
  ---
   drivers/scsi/qla4xxx/ql4_mbx.c |  190 ++--
 
  diff --git a/drivers/scsi/qla4xxx/ql4_mbx.c
b/drivers/scsi/qla4xxx/ql4_mbx.c
  index 7f28657..0ef777a 100644
  --- a/drivers/scsi/qla4xxx/ql4_mbx.c
  +++ b/drivers/scsi/qla4xxx/ql4_mbx.c
  @@ -6,6 +6,10 @@
*/
 
   #include ql4_def.h
  +#include ql4_version.h
  +#include ql4_glbl.h
  +#include ql4_dbg.h
  +#include ql4_inline.h
 
 Did you need to bring in all of these? You did not need version did
you?
Thanks for pointing it out. In fact it is needed only in ql4_os.c. I
think I will get rid of the ql4_version.h and simply place the version#
in ql4_os.c

 
 
  -   memset((void *)fw_ddb_entry-iSCSIAlias, 0,
  -  sizeof(fw_ddb_entry-iSCSIAlias));
  +   memset((void *)fw_ddb_entry-iscsi_alias, 0,
  +  sizeof(fw_ddb_entry-iscsi_alias));
 
  -   memset((void *)fw_ddb_entry-iscsiName, 0,
  -  sizeof(fw_ddb_entry-iscsiName));
  +   memset((void *)fw_ddb_entry-iscsi_name, 0,
  +  sizeof(fw_ddb_entry-iscsi_name));
 
  -   memset((void *)fw_ddb_entry-ipAddr, 0,
sizeof(fw_ddb_entry-ipAddr));
  -   memset((void *)fw_ddb_entry-targetAddr, 0,
  -  sizeof(fw_ddb_entry-targetAddr));
  +   memset((void *)fw_ddb_entry-ip_addr, 0,
sizeof(fw_ddb_entry-ip_addr));
  +   memset((void *)fw_ddb_entry-tgt_addr, 0,
  +  sizeof(fw_ddb_entry-tgt_addr));
 
 
 I am not sure if it is a big deal or if it clutters the code, but I do
 not think you need the void * casts in there.
Will clean it as well.
-david S.
-
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] bug fix: SCSI async scan sysfs -EEXIST problem

2007-05-07 Thread James Smart

This corrects the kobject_add -EEXIST failure reported in 
http://marc.info/?l=linux-scsim=117699334422336w=2

Basically, there was a collision between async scsi scan's
scsi_sysfs_add_devices() and asynchronous scanning kicked off by the
fc transport's rport code.  Both called scsi_sysfs_add_sdev() for the
same sdev.

The problem was that async scsi scan's call did not hold the scan_mutex
when making the call to scsi_sysfs_add_sdev().  Additionally, looking at
the shost-async_scan flag, which is critical for whether the sdev gets
enumerated or not, many uses were fuzzy. As a bit flag, it should have
been under the scsi_host lock, but via the way it's used within
scsi_scan.c, it should have been under the scan_mutex. It was positioned
within the async scan semaphore, which didn't help anything. Key to its
change, is that is done prior to releasing the scan_mutex after around
the scsi_sysfs_add_sdev() calls.  To avoid all the lock repositioning,
I simply converted it to an atomic. A little overkill, but has the
coherency it needs.

Confirmed by Josef that it corrected his problems.

-- james s


Signed-off-by: James Smart [EMAIL PROTECTED]



diff -upNr a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
--- a/drivers/scsi/scsi_scan.c  2007-04-25 23:08:32.0 -0400
+++ b/drivers/scsi/scsi_scan.c  2007-05-04 18:35:58.0 -0400
@@ -1081,7 +1081,8 @@ static int scsi_probe_and_add_lun(struct
goto out_free_result;
}
 
-   res = scsi_add_lun(sdev, result, bflags, shost-async_scan);
+   res = scsi_add_lun(sdev, result, bflags,
+   atomic_read(shost-async_scan));
if (res == SCSI_SCAN_LUN_PRESENT) {
if (bflags  BLIST_KEY) {
sdev-lockable = 0;
@@ -1470,7 +1471,7 @@ struct scsi_device *__scsi_add_device(st
if (strncmp(scsi_scan_type, none, 4) == 0)
return ERR_PTR(-ENODEV);
 
-   if (!shost-async_scan)
+   if (!atomic_read(shost-async_scan))
scsi_complete_async_scans();
 
starget = scsi_alloc_target(parent, channel, id);
@@ -1590,7 +1591,7 @@ void scsi_scan_target(struct device *par
if (strncmp(scsi_scan_type, none, 4) == 0)
return;
 
-   if (!shost-async_scan)
+   if (!atomic_read(shost-async_scan))
scsi_complete_async_scans();
 
mutex_lock(shost-scan_mutex);
@@ -1638,7 +1639,7 @@ int scsi_scan_host_selected(struct Scsi_
%s: %u:%u:%u\n,
__FUNCTION__, channel, id, lun));
 
-   if (!shost-async_scan)
+   if (!atomic_read(shost-async_scan))
scsi_complete_async_scans();
 
if (((channel != SCAN_WILD_CARD)  (channel  shost-max_channel)) ||
@@ -1687,7 +1688,7 @@ static struct async_scan_data *scsi_prep
if (strncmp(scsi_scan_type, sync, 4) == 0)
return NULL;
 
-   if (shost-async_scan) {
+   if (atomic_read(shost-async_scan)) {
printk(%s called twice for host %d, __FUNCTION__,
shost-host_no);
dump_stack();
@@ -1702,8 +1703,9 @@ static struct async_scan_data *scsi_prep
goto err;
init_completion(data-prev_finished);
 
+   atomic_set(shost-async_scan, 1);
+
spin_lock(async_scan_lock);
-   shost-async_scan = 1;
if (list_empty(scanning_hosts))
complete(data-prev_finished);
list_add_tail(data-list, scanning_hosts);
@@ -1732,7 +1734,7 @@ static void scsi_finish_async_scan(struc
return;
 
shost = data-shost;
-   if (!shost-async_scan) {
+   if (!atomic_read(shost-async_scan)) {
printk(%s called twice for host %d, __FUNCTION__,
shost-host_no);
dump_stack();
@@ -1741,10 +1743,12 @@ static void scsi_finish_async_scan(struc
 
wait_for_completion(data-prev_finished);
 
+   mutex_lock(shost-scan_mutex);
scsi_sysfs_add_devices(shost);
+   atomic_set(shost-async_scan, 0);
+   mutex_unlock(shost-scan_mutex);
 
spin_lock(async_scan_lock);
-   shost-async_scan = 0;
list_del(data-list);
if (!list_empty(scanning_hosts)) {
struct async_scan_data *next = list_entry(scanning_hosts.next,
diff -upNr a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
--- a/include/scsi/scsi_host.h  2007-04-25 23:08:32.0 -0400
+++ b/include/scsi/scsi_host.h  2007-05-04 17:48:48.0 -0400
@@ -6,6 +6,7 @@
 #include linux/types.h
 #include linux/workqueue.h
 #include linux/mutex.h
+#include asm/atomic.h
 
 struct request_queue;
 struct block_device;
@@ -605,7 +606,7 @@ struct Scsi_Host {
unsigned tmf_in_progress:1;
 
/* Asynchronous scan in progress */
-   unsigned async_scan:1;
+   atomic_t async_scan;
 
/*
 * Optional work queue to be utilized by the transport




-
To unsubscribe from this

Re: [patch 08/30] drivers/scsi/megaraid.c: Replacing yield() with a better alternative

2007-05-07 Thread James Bottomley

On Thu, 2007-04-26 at 00:35 -0700, [EMAIL PROTECTED] wrote:
 From: Amol Lad [EMAIL PROTECTED]
 
 For this driver cond_resched() seems to be a better alternative
 
 Signed-off-by: Amol Lad [EMAIL PROTECTED]
 Signed-off-by: Andrew Morton [EMAIL PROTECTED]

Needs ack by maintainer ... cc'd

James


-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [patch 08/30] drivers/scsi/megaraid.c: Replacing yield() with a better alternative

2007-05-07 Thread Patro, Sumant

Ack.

Thanks.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 12:35 AM
To: [EMAIL PROTECTED]
Cc: linux-scsi@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: [patch 08/30] drivers/scsi/megaraid.c: Replacing yield() with a
better alternative

From: Amol Lad [EMAIL PROTECTED]

For this driver cond_resched() seems to be a better alternative

Signed-off-by: Amol Lad [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 drivers/scsi/megaraid.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff -puN
drivers/scsi/megaraid.c~drivers-scsi-megaraidc-replacing-yield-with-a
drivers/scsi/megaraid.c
---
a/drivers/scsi/megaraid.c~drivers-scsi-megaraidc-replacing-yield-with-a
+++ a/drivers/scsi/megaraid.c
@@ -1754,7 +1754,8 @@ __mega_busywait_mbox (adapter_t *adapter
for (counter = 0; counter  1; counter++) {
if (!mbox-m_in.busy)
return 0;
-   udelay(100); yield();
+   udelay(100);
+   cond_resched();
}
return -1;  /* give up after 1 second */
 }
_
-
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: [Bugme-new] [Bug 8426] New: massive slowdown on SCSI CD/DVDdrive connected to mptspi driver

2007-05-07 Thread Doug Chapman

Found the problem.  Sending a patch to linux-scsi under a [PATCH]
subject line.

- Doug

On Fri, 2007-05-04 at 17:58 -0500, James Bottomley wrote:
 On Fri, 2007-05-04 at 17:56 -0400, Doug Chapman wrote:
  I am applying/removing _only_ your patch and the problem goes away with
  just removing it.
 
 What id and channel is this DVD drive on?  There is a potential bug in
 the move:
 
 -mptscsih_writeIOCPage4(MPT_SCSI_HOST *hd, int channel, int id)
 +mptspi_writeIOCPage4(MPT_SCSI_HOST *hd, u8 channel , u8 id)
 
 Note int became u8, but later we have:
 
 
   pReq-PageAddress = cpu_to_le32(id | (channel  8 ));
 
 channel  8 is always zero as a u8 entity (unless something promotes
 the arithmetic beyond u8).  So if the DVD is on a non-zero channel, we
 might have our cause.
 
 James
 
 

-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [patch 04/30] megaraid: fix warnings when CONFIG_PROC_FS=n

2007-05-07 Thread Patro, Sumant

Ack.

Thanks,

Sumant

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 12:35 AM
To: [EMAIL PROTECTED]
Cc: linux-scsi@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [patch 04/30] megaraid: fix warnings when CONFIG_PROC_FS=n

From: walter harms [EMAIL PROTECTED]

Signed-off-by: walter harms [EMAIL PROTECTED]
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
Cc: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 drivers/scsi/megaraid.c |   17 +++--
 drivers/scsi/megaraid.h |4 ++--
 2 files changed, 13 insertions(+), 8 deletions(-)

diff -puN
drivers/scsi/megaraid.c~megaraid-fix-warnings-when-config_proc_fs=n
drivers/scsi/megaraid.c
---
a/drivers/scsi/megaraid.c~megaraid-fix-warnings-when-config_proc_fs=n
+++ a/drivers/scsi/megaraid.c
@@ -3177,7 +3177,10 @@ proc_rdrv(adapter_t *adapter, char *page
 
return len;
 }
-
+#else
+static inline void mega_create_proc_entry(int index, struct
proc_dir_entry *parent)
+{
+}
 #endif
 
 
@@ -4342,7 +4345,7 @@ mega_support_cluster(adapter_t *adapter)
return 0;
 }
 
-
+#ifdef CONFIG_PROC_FS
 /**
  * mega_adapinq()
  * @adapter - pointer to our soft state
@@ -4447,7 +4450,7 @@ mega_internal_dev_inquiry(adapter_t *ada
 
return rval;
 }
-
+#endif
 
 /**
  * mega_internal_command()
@@ -4965,7 +4968,6 @@ megaraid_remove_one(struct pci_dev *pdev
 {
struct Scsi_Host *host = pci_get_drvdata(pdev);
adapter_t *adapter = (adapter_t *)host-hostdata;
-   charbuf[12] = { 0 };
 
scsi_remove_host(host);
 
@@ -5011,8 +5013,11 @@ megaraid_remove_one(struct pci_dev *pdev
remove_proc_entry(raiddrives-30-39,
adapter-controller_proc_dir_entry);
 #endif
-   sprintf(buf, hba%d, adapter-host-host_no);
-   remove_proc_entry(buf, mega_proc_dir_entry);
+   {
+   charbuf[12] = { 0 };
+   sprintf(buf, hba%d, adapter-host-host_no);
+   remove_proc_entry(buf, mega_proc_dir_entry);
+   }
}
 #endif
 
diff -puN
drivers/scsi/megaraid.h~megaraid-fix-warnings-when-config_proc_fs=n
drivers/scsi/megaraid.h
---
a/drivers/scsi/megaraid.h~megaraid-fix-warnings-when-config_proc_fs=n
+++ a/drivers/scsi/megaraid.h
@@ -1002,7 +1002,6 @@ static int megaraid_reset(Scsi_Cmnd *);
 static int megaraid_abort_and_reset(adapter_t *, Scsi_Cmnd *, int);
 static int megaraid_biosparam(struct scsi_device *, struct block_device
*,
sector_t, int []);
-static int mega_print_inquiry(char *, char *);
 
 static int mega_build_sglist (adapter_t *adapter, scb_t *scb,
  u32 *buffer, u32 *length);
@@ -1024,6 +1023,7 @@ static int mega_init_scb (adapter_t *);
 static int mega_is_bios_enabled (adapter_t *);
 
 #ifdef CONFIG_PROC_FS
+static int mega_print_inquiry(char *, char *);
 static void mega_create_proc_entry(int, struct proc_dir_entry *);
 static int proc_read_config(char *, char **, off_t, int, int *, void
*);
 static int proc_read_stat(char *, char **, off_t, int, int *, void *);
@@ -1040,10 +1040,10 @@ static int proc_rdrv_20(char *, char **,
 static int proc_rdrv_30(char *, char **, off_t, int, int *, void *);
 static int proc_rdrv_40(char *, char **, off_t, int, int *, void *);
 static int proc_rdrv(adapter_t *, char *, int, int);
-#endif
 
 static int mega_adapinq(adapter_t *, dma_addr_t);
 static int mega_internal_dev_inquiry(adapter_t *, u8, u8, dma_addr_t);
+#endif
 
 static int mega_support_ext_cdb(adapter_t *);
 static mega_passthru* mega_prepare_passthru(adapter_t *, scb_t *,
_
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 29/30] PCI Error Recovery: Symbios SCSI base support

2007-05-07 Thread James Bottomley

On Thu, 2007-04-26 at 00:35 -0700, [EMAIL PROTECTED] wrote:
 From: Linas Vepstas [EMAIL PROTECTED]
 
 Various PCI bus errors can be signaled by newer PCI controllers.  This
 patch adds the PCI error recovery callbacks to the Symbios SCSI device
 driver.  The patch has been tested, and appears to work well.

awaiting maintainer ACK.

James


-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 25/30] scsi: fix CONFIG_SCSI_WAIT_SCAN=m

2007-05-07 Thread James Bottomley

On Thu, 2007-04-26 at 00:35 -0700, [EMAIL PROTECTED] wrote:
 From: Hugh Dickins [EMAIL PROTECTED]
 
 CONFIG_MODULES=y
 CONFIG_SCSI=y
 CONFIG_SCSI_SCAN_ASYNC=y
 CONFIG_SCSI_WAIT_SCAN=m
 
 2.6.21-rc5-mm2 VFS panics unable to find my root on /dev/sda2, but boots
 okay if I change drivers/scsi/Kconfig to default y instead of default m
 for SCSI_WAIT_SCAN.
 
 Make sure there's a late_initcall to scsi_complete_async_scans when it's
 built in, so a monolithic SCSI_SCAN_ASYNC kernel can rely on the scans
 being completed before trying to mount root, even if they're slow.

This isn't the right fix ... this has to be invoked last in the call
sequence ... I can't see another way of doing this except yet another
file added as a final component to the link.

James


-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 16/30] drivers/scsi/aic7xxx_old: Convert to generic boolean-values

2007-05-07 Thread James Bottomley

On Thu, 2007-04-26 at 00:35 -0700, [EMAIL PROTECTED] wrote:
 From: Richard Knutsson [EMAIL PROTECTED]
 
 Convert:
 FALSE - false
 TRUE  - true

NAK'd by maintainer.

James


-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 18/30] Fix |/|| confusion in fusion driver

2007-05-07 Thread James Bottomley

On Thu, 2007-04-26 at 00:35 -0700, [EMAIL PROTECTED] wrote:
 From: Dirk Mueller [EMAIL PROTECTED]
 
 This patch corrects a |/|| confusion in mptscsih_copy_sense_data.  Using ||
 means that the data that ends up being written is (almost always) 1,
 instead of being bit-wise or'ed.

Needs ack by maintainer.

James


-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 09/30] drivers/scsi/mca_53c9x.c : save_flags()/cli() removal

2007-05-07 Thread James Bottomley

On Thu, 2007-04-26 at 00:35 -0700, [EMAIL PROTECTED] wrote:
 From: Amol Lad [EMAIL PROTECTED]
 
 Replaced save_flags()/cli() with spin_lock alternatives

This one, there's not much point to ... the driver now needs to be
converted correctly over to esp_scsi.

James


-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVD drive connected to mptspi driver

2007-05-07 Thread Doug Chapman

Patch for: http://bugzilla.kernel.org/show_bug.cgi?id=8426

A recent code cleanup that moved code from mptscsih to mptspi
inadvertently change the order some code was called.  This caused
a massive slowdown (of 150x to 300x) on the CD/DVD drive on the
high-end HP Integrity servers.

Signed-off-by: Doug Chapman [EMAIL PROTECTED]




diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
index 85f21b5..2eb5741 100644
--- a/drivers/message/fusion/mptspi.c
+++ b/drivers/message/fusion/mptspi.c
@@ -726,13 +726,15 @@ static int mptspi_slave_configure(struct scsi_device 
*sdev)
struct _MPT_SCSI_HOST *hd =
(struct _MPT_SCSI_HOST *)sdev-host-hostdata;
VirtTarget *vtarget = scsi_target(sdev)-hostdata;
-   int ret = mptscsih_slave_configure(sdev);
+   int ret;
+
+   mptspi_initTarget(hd, vtarget, sdev);
+
+   ret = mptscsih_slave_configure(sdev);
 
if (ret)
return ret;
 
-   mptspi_initTarget(hd, vtarget, sdev);
-
ddvprintk((MYIOC_s_INFO_FMT id=%d min_period=0x%02x
 max_offset=0x%02x max_width=%d\n, hd-ioc-name,
sdev-id, spi_min_period(scsi_target(sdev)),


-
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 04/30] megaraid: fix warnings when CONFIG_PROC_FS=n

2007-05-07 Thread Andrew Morton

On Mon, 7 May 2007 13:40:54 -0600
Patro, Sumant [EMAIL PROTECTED] wrote:

 Ack.

Thanks.  Please consider raising a patch adding yourself to ./MAINTAINERS?
-
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/30] drivers/scsi/aic7xxx_old: Convert to generic boolean-values

2007-05-07 Thread Andrew Morton

On Mon, 7 May 2007 14:06:56 -0700
Andrew Morton [EMAIL PROTECTED] wrote:

 so I'll drop it on those grounds, not on the bogus ones.

However it will come back again.  All subsystem-private implementations
of TRUE and FALSE are in the firing line now.
-
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/1] ipr: Use PCI-E reset API for new ipr adapter

2007-05-07 Thread Brian King


Use a newly added PCI API to issue a PCI Fundamental reset
(warm reset) to a new ipr PCI-E adapter. Typically, the
ipr adapter uses the start BIST bit in config space to reset
an adapter. Issuing start BIST on this particular adapter
results in the PCI-E logic on the card losing sync, which
causes PCI-E errors, making the card unusable. The only reset
mechanism that exists on this hardware that does not have this
problem is PCI Fundamental reset (warm reset).

Signed-off-by: Brian King [EMAIL PROTECTED]
---

James,

This patch was waiting for a generic PCI layer change to get merged,
which has now happened. This patch can now be merged. This is my last
ipr patch for 2.6.22.

Thanks,

Brian
---

 linux-2.6-bjking1/drivers/scsi/ipr.c |   70 ---
 linux-2.6-bjking1/drivers/scsi/ipr.h |8 +++-
 2 files changed, 72 insertions(+), 6 deletions(-)

diff -puN drivers/scsi/ipr.h~ipr_pci_reset6 drivers/scsi/ipr.h
--- linux-2.6/drivers/scsi/ipr.h~ipr_pci_reset6 2007-05-07 17:04:09.0 
-0500
+++ linux-2.6-bjking1/drivers/scsi/ipr.h2007-05-07 17:04:09.0 
-0500
@@ -37,7 +37,7 @@
 /*
  * Literals
  */
-#define IPR_DRIVER_VERSION 2.4.0
+#define IPR_DRIVER_VERSION 2.4.1
 #define IPR_DRIVER_DATE (April 24, 2007)
 
 /*
@@ -112,6 +112,7 @@
 
 /* Driver data flags */
 #define IPR_USE_LONG_TRANSOP_TIMEOUT   0x0001
+#define IPR_USE_PCI_WARM_RESET 0x0002
 
 #define IPR_DEFAULT_MAX_ERROR_DUMP 984
 #define IPR_NUM_LOG_HCAMS  2
@@ -193,6 +194,7 @@
 #define IPR_WAIT_FOR_RESET_TIMEOUT (2 * HZ)
 #define IPR_CHECK_FOR_RESET_TIMEOUT(HZ / 10)
 #define IPR_WAIT_FOR_BIST_TIMEOUT  (2 * HZ)
+#define IPR_PCI_RESET_TIMEOUT  (HZ / 2)
 #define IPR_DUMP_TIMEOUT   (15 * HZ)
 
 /*
@@ -1091,6 +1093,9 @@ struct ipr_ioa_cfg {
u8 allow_ml_add_del:1;
u8 needs_hard_reset:1;
u8 dual_raid:1;
+   u8 needs_warm_reset:1;
+
+   u8 revid;
 
enum ipr_cache_state cache_state;
u16 type; /* CCIN of the card */
@@ -1184,6 +1189,7 @@ struct ipr_ioa_cfg {
struct pci_pool *ipr_cmd_pool;
 
struct ipr_cmnd *reset_cmd;
+   int (*reset) (struct ipr_cmnd *);
 
struct ata_host ata_host;
char ipr_cmd_label[8];
diff -puN drivers/scsi/ipr.c~ipr_pci_reset6 drivers/scsi/ipr.c
--- linux-2.6/drivers/scsi/ipr.c~ipr_pci_reset6 2007-05-07 17:04:09.0 
-0500
+++ linux-2.6-bjking1/drivers/scsi/ipr.c2007-05-07 17:04:09.0 
-0500
@@ -6647,6 +6647,48 @@ static int ipr_reset_start_bist(struct i
 }
 
 /**
+ * ipr_reset_slot_reset_done - Clear PCI reset to the adapter
+ * @ipr_cmd:   ipr command struct
+ *
+ * Description: This clears PCI reset to the adapter and delays two seconds.
+ *
+ * Return value:
+ * IPR_RC_JOB_RETURN
+ **/
+static int ipr_reset_slot_reset_done(struct ipr_cmnd *ipr_cmd)
+{
+   ENTER;
+   pci_set_pcie_reset_state(ipr_cmd-ioa_cfg-pdev, pcie_deassert_reset);
+   ipr_cmd-job_step = ipr_reset_bist_done;
+   ipr_reset_start_timer(ipr_cmd, IPR_WAIT_FOR_BIST_TIMEOUT);
+   LEAVE;
+   return IPR_RC_JOB_RETURN;
+}
+
+/**
+ * ipr_reset_slot_reset - Reset the PCI slot of the adapter.
+ * @ipr_cmd:   ipr command struct
+ *
+ * Description: This asserts PCI reset to the adapter.
+ *
+ * Return value:
+ * IPR_RC_JOB_RETURN
+ **/
+static int ipr_reset_slot_reset(struct ipr_cmnd *ipr_cmd)
+{
+   struct ipr_ioa_cfg *ioa_cfg = ipr_cmd-ioa_cfg;
+   struct pci_dev *pdev = ioa_cfg-pdev;
+
+   ENTER;
+   pci_block_user_cfg_access(pdev);
+   pci_set_pcie_reset_state(pdev, pcie_warm_reset);
+   ipr_cmd-job_step = ipr_reset_slot_reset_done;
+   ipr_reset_start_timer(ipr_cmd, IPR_PCI_RESET_TIMEOUT);
+   LEAVE;
+   return IPR_RC_JOB_RETURN;
+}
+
+/**
  * ipr_reset_allowed - Query whether or not IOA can be reset
  * @ioa_cfg:   ioa config struct
  *
@@ -6685,7 +6727,7 @@ static int ipr_reset_wait_to_start_bist(
ipr_cmd-u.time_left -= IPR_CHECK_FOR_RESET_TIMEOUT;
ipr_reset_start_timer(ipr_cmd, IPR_CHECK_FOR_RESET_TIMEOUT);
} else {
-   ipr_cmd-job_step = ipr_reset_start_bist;
+   ipr_cmd-job_step = ioa_cfg-reset;
rc = IPR_RC_JOB_CONTINUE;
}
 
@@ -6718,7 +6760,7 @@ static int ipr_reset_alert(struct ipr_cm
writel(IPR_UPROCI_RESET_ALERT, 
ioa_cfg-regs.set_uproc_interrupt_reg);
ipr_cmd-job_step = ipr_reset_wait_to_start_bist;
} else {
-   ipr_cmd-job_step = ipr_reset_start_bist;
+   ipr_cmd-job_step = ioa_cfg-reset;
}
 
ipr_cmd-u.time_left = IPR_WAIT_FOR_RESET_TIMEOUT;
@@ -7000,8 +7042,11 @@ static pci_ers_result_t ipr_pci_slot_res
struct ipr_ioa_cfg *ioa_cfg = pci_get_drvdata(pdev);
 
spin_lock_irqsave(ioa_cfg-host-host_lock, flags);
-

[PATCH v2] add bidi support for block pc requests

2007-05-07 Thread FUJITA Tomonori

Here is an updated version of the patch to add bidi support to block
pc requests. Bugs spotted by Benny were fixed.

This patch can be applied cleanly to the scsi-misc git tree and is on
the top of the following patch to add linked request support:

http://marc.info/?l=linux-scsim=117835587615642w=2

---
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Mon, 7 May 2007 16:42:24 +0900
Subject: [PATCH] add bidi support to scsi pc commands

This adds bidi support to block pc requests.

A bidi request uses req-next_rq pointer for an in request.

This patch introduces a new structure, scsi_data_buffer to hold the
data buffer information. To avoid make scsi_cmnd structure fatter, the
scsi mid-layer uses cmnd-request-next_rq-special pointer for
a scsi_data_buffer structure. LLDs don't touch the second request
(req-next_rq) so it's safe to use req-special.

scsi_blk_pc_done() always completes the whole command so
scsi_end_request() simply completes the bidi chunk too.

A helper function, scsi_bidi_data_buffer() is for LLDs to access to
the scsi_data_buffer structure easily.

Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
 drivers/scsi/scsi_lib.c  |  128 +++--
 include/scsi/scsi_cmnd.h |   14 +
 2 files changed, 125 insertions(+), 17 deletions(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 61fbcdc..ba874a6 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -66,6 +66,12 @@ static struct scsi_host_sg_pool scsi_sg_pools[] = {
 
 static void scsi_run_queue(struct request_queue *q);
 
+struct scsi_data_buffer *scsi_bidi_data_buffer(struct scsi_cmnd *cmd)
+{
+   return blk_bidi_rq(cmd-request) ? cmd-request-next_rq-special : 
NULL;
+}
+EXPORT_SYMBOL(scsi_bidi_data_buffer);
+
 /*
  * Function:   scsi_unprep_request()
  *
@@ -81,10 +87,14 @@ static void scsi_run_queue(struct request_queue *q);
 static void scsi_unprep_request(struct request *req)
 {
struct scsi_cmnd *cmd = req-special;
+   struct scsi_data_buffer *sdb = scsi_bidi_data_buffer(cmd);
 
req-cmd_flags = ~REQ_DONTPREP;
req-special = NULL;
-
+   if (sdb) {
+   kfree(sdb);
+   req-next_rq-special = NULL;
+   }
scsi_put_command(cmd);
 }
 
@@ -657,6 +667,7 @@ static struct scsi_cmnd *scsi_end_request(struct scsi_cmnd 
*cmd, int uptodate,
request_queue_t *q = cmd-device-request_queue;
struct request *req = cmd-request;
unsigned long flags;
+   struct scsi_data_buffer *sdb = scsi_bidi_data_buffer(cmd);
 
/*
 * If there are blocks left over at the end, set up the command
@@ -685,6 +696,14 @@ static struct scsi_cmnd *scsi_end_request(struct scsi_cmnd 
*cmd, int uptodate,
}
}
 
+   /*
+* a REQ_BLOCK_PC command is always completed fully so just do
+* end the bidi chunk.
+*/
+   if (sdb)
+   end_that_request_chunk(req-next_rq, uptodate,
+  sdb-request_bufflen);
+
add_disk_randomness(req-rq_disk);
 
spin_lock_irqsave(q-queue_lock, flags);
@@ -701,34 +720,35 @@ static struct scsi_cmnd *scsi_end_request(struct 
scsi_cmnd *cmd, int uptodate,
return NULL;
 }
 
-struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd *cmd, gfp_t gfp_mask)
+static struct scatterlist *do_scsi_alloc_sgtable(unsigned short use_sg,
+unsigned short *sglist_len,
+gfp_t gfp_mask)
 {
struct scsi_host_sg_pool *sgp;
-   struct scatterlist *sgl;
 
-   BUG_ON(!cmd-use_sg);
+   BUG_ON(!use_sg);
 
-   switch (cmd-use_sg) {
+   switch (use_sg) {
case 1 ... 8:
-   cmd-sglist_len = 0;
+   *sglist_len = 0;
break;
case 9 ... 16:
-   cmd-sglist_len = 1;
+   *sglist_len = 1;
break;
case 17 ... 32:
-   cmd-sglist_len = 2;
+   *sglist_len = 2;
break;
 #if (SCSI_MAX_PHYS_SEGMENTS  32)
case 33 ... 64:
-   cmd-sglist_len = 3;
+   *sglist_len = 3;
break;
 #if (SCSI_MAX_PHYS_SEGMENTS  64)
case 65 ... 128:
-   cmd-sglist_len = 4;
+   *sglist_len = 4;
break;
 #if (SCSI_MAX_PHYS_SEGMENTS   128)
case 129 ... 256:
-   cmd-sglist_len = 5;
+   *sglist_len = 5;
break;
 #endif
 #endif
@@ -737,11 +757,14 @@ struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd 
*cmd, gfp_t gfp_mask)
return NULL;
}
 
-   sgp = scsi_sg_pools + cmd-sglist_len;
-   sgl = mempool_alloc(sgp-pool, gfp_mask);
-   return sgl;
+   sgp = scsi_sg_pools + *sglist_len;
+   return mempool_alloc(sgp-pool, gfp_mask);
 }
 
+struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd *cmd,

Re: [patch 16/30] drivers/scsi/aic7xxx_old: Convert to generic boolean-values

2007-05-07 Thread Richard Knutsson


Andrew Morton wrote:

On Mon, 7 May 2007 14:06:56 -0700
Andrew Morton [EMAIL PROTECTED] wrote:

  

so I'll drop it on those grounds, not on the bogus ones.



However it will come back again.  All subsystem-private implementations
of TRUE and FALSE are in the firing line now.
  

Amen.
But should we let it rest until most of the other (boolean) conversions 
are done (as with CIFS and XFS (iirc)), otherwise I can take a new stab 
at it this weekend.


Btw Andrew, do you want me to Cc: you all the patches or should I 
continue to first send them to (hopefully the correct) maintainer(s)/ML, 
and send them your way if they are not picked up (is one week enough, or 
should it be longer?)


Regards
Richard Knutsson

-
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: [Stgt-devel] Question for pass-through target design

2007-05-07 Thread Vladislav Bolkhovitin

Vladislav Bolkhovitin wrote:

FUJITA Tomonori wrote:

From: Vladislav Bolkhovitin [EMAIL PROTECTED]
Subject: Re: [Stgt-devel] Question for pass-through target design
Date: Mon, 07 May 2007 19:27:23 +0400

FUJITA Tomonori wrote:

From: Vladislav Bolkhovitin [EMAIL PROTECTED]
Subject: Re: [Stgt-devel] Question for pass-through target design
Date: Mon, 07 May 2007 18:24:44 +0400

FUJITA Tomonori wrote:

It looks like the pass-through target support is currently 
broken, at
least as I've checked for ibmvstgt, but I think it's a general 
problem.

I wanted to check my assumptions and get ideas.

Yeah, unfortunately, it works only with the iSCSI target driver 
(which

runs in user space).

The code isn't allocating any memory to pass along to the sg 
code to store
the result of a read or data for a write.  Currently, dxferp 
for sg_io_hdr
or dout_xferp/din_xferp for sg_io_v4 are assigned to the value 
of uaddr,
which is set to 0 in kern_queue_cmd.  With the pointer set to 
NULL,
the pass-through target isn't going to function.  Even if we 
had memory
allocated, there isn't a means of getting data to be written 
via sg down

this code path.

What ideas are there as to how the data will get to user-space 
so that

we can use sg?

For kernel-space drivers, we don't need to go to user-space. We 
can do
the pass-through in kernel space. I talked with James about this 
last

year and he said that if the code is implemented cleanly, he would
merges it into mainline.

We already have a pass-through in the kernel space for
kernel space drivers. It is the scsi_tgt* code.

Could you elaborate more?

What I meant that is that the kernel tgt code (scsi_tgt*) receives
SCSI commands from one lld and send them to another lld instead of
sending them to user space.

Although the approach of passing SCSI commands from a target LLD to an
initiator one without any significant interventions from the target
software looks to be nice and simple, you should realize how limited,
unsafe and illegal it is, since it badly violates SCSI specs.

I think that 'implemented cleanly' means that one scsi_host is assigned
to only one initiator.

Sorry, I don't fully understand you. If you mean you are going to 
limit only one remote initiator per-target device, then, well, is it 
even more limited (and limiting) or not?

The target software assigns one scsi_host to only one remote
initiator. For FC, NPIV works nicely.

OK, if such limitation is OK for your users, then I'm happy for you.

And don't forget to tell them that they must not touch the exported 
devices locally ;)

___
Stgt-devel mailing list
[EMAIL PROTECTED]
https://lists.berlios.de/mailman/listinfo/stgt-devel

-
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

41 matches

Mail list logo