RE: [PATCH 1/2] stex: stex_direct_copy shouldn't call dma_map_sg

[Ed Lin]

-Original Message-
From: fujita [mailto:[EMAIL PROTECTED] On Behalf Of FUJITA Tomonori
Sent: Friday, February 22, 2008 6:11 AM
To: linux-scsi@vger.kernel.org
Cc: FUJITA Tomonori; Ed Lin; James Bottomley
Subject: [PATCH 1/2] stex: stex_direct_copy shouldn't call dma_map_sg


stex_direct_copy copies an in-kernel buffer to a sg list in order to
spoof some SCSI commands. stex_direct_copy calls dma_map_sg and then
stex_internal_copy with the value that dma_map_sg returned. It calls
scsi_kmap_atomic_sg to copy data.

scsi_kmap_atomic_sg doesn't see sg-dma_length so if dma_map_sg merges
sg entries, stex_internal_copy gets the smaller number of sg entries
than the acutual number, which means it wrongly think that the data
length in the sg list is shorter than the actual length.

stex_direct_copy shouldn't call dma_map_sg and it doesn't need since
this code path doesn't involve dma transfers. This patch removes
stex_direct_copy and simply calls stex_internal_copy with the actual
number of sg entries.

Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
Cc: Ed Lin [EMAIL PROTECTED]
Cc: James Bottomley [EMAIL PROTECTED]
---
 drivers/scsi/stex.c |   34 --
 1 files changed, 12 insertions(+), 22 deletions(-)

diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 72f6d80..4b6861c 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -461,23 +461,6 @@ static void stex_internal_copy(struct 
scsi_cmnd *cmd,
   }
 }
 
-static int stex_direct_copy(struct scsi_cmnd *cmd,
-  const void *src, size_t count)
-{
-  size_t cp_len = count;
-  int n_elem = 0;
-
-  n_elem = scsi_dma_map(cmd);
-  if (n_elem  0)
-  return 0;
-
-  stex_internal_copy(cmd, src, cp_len, n_elem, ST_TO_CMD);
-
-  scsi_dma_unmap(cmd);
-
-  return cp_len == count;
-}
-
 static void stex_controller_info(struct st_hba *hba, struct 
st_ccb *ccb)
 {
   struct st_frame *p;
@@ -569,8 +552,10 @@ stex_queuecommand(struct scsi_cmnd *cmd, 
void (* done)(struct scsi_cmnd *))
   unsigned char page;
   page = cmd-cmnd[2]  0x3f;
   if (page == 0x8 || page == 0x3f) {
-  stex_direct_copy(cmd, ms10_caching_page,
-  sizeof(ms10_caching_page));
+  size_t cp_len = sizeof(ms10_caching_page);
+  stex_internal_copy(cmd, ms10_caching_page,
+ cp_len, scsi_sg_count(cmd),
+ ST_TO_CMD);
   cmd-result = DID_OK  16 | 
COMMAND_COMPLETE  8;
   done(cmd);
   } else
@@ -599,8 +584,10 @@ stex_queuecommand(struct scsi_cmnd *cmd, 
void (* done)(struct scsi_cmnd *))
   if (id != host-max_id - 1)
   break;
   if (lun == 0  (cmd-cmnd[1]  INQUIRY_EVPD) == 0) {
-  stex_direct_copy(cmd, console_inq_page,
-  sizeof(console_inq_page));
+  size_t cp_len = sizeof(console_inq_page);
+  stex_internal_copy(cmd, console_inq_page,
+ cp_len, scsi_sg_count(cmd),
+ ST_TO_CMD);
   cmd-result = DID_OK  16 | 
COMMAND_COMPLETE  8;
   done(cmd);
   } else
@@ -609,6 +596,7 @@ stex_queuecommand(struct scsi_cmnd *cmd, 
void (* done)(struct scsi_cmnd *))
   case PASSTHRU_CMD:
   if (cmd-cmnd[1] == PASSTHRU_GET_DRVVER) {
   struct st_drvver ver;
+  size_t cp_len = sizeof(ver);
   ver.major = ST_VER_MAJOR;
   ver.minor = ST_VER_MINOR;
   ver.oem = ST_OEM;
@@ -616,7 +604,9 @@ stex_queuecommand(struct scsi_cmnd *cmd, 
void (* done)(struct scsi_cmnd *))
   ver.signature[0] = PASSTHRU_SIGNATURE;
   ver.console_id = host-max_id - 1;
   ver.host_no = hba-host-host_no;
-  cmd-result = stex_direct_copy(cmd, 
ver, sizeof(ver)) ?
+  stex_internal_copy(cmd, ver, cp_len,
+ scsi_sg_count(cmd), 
ST_TO_CMD);
+  cmd-result = sizeof(ver) == cp_len ?
   DID_OK  16 | COMMAND_COMPLETE  8 :
   DID_ERROR  16 | COMMAND_COMPLETE  8;
   done(cmd);
-- 
1.5.3.4



ACK patches 1-2.
I didn't think dma_map_sg could change the sg count. And clearly
it's unneeded if we can get sg count by scsi_sg_count. Thanks
for the patches.


Ed Lin
-
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: stex driver panic in kernel 2.6.23

[Ed Lin]

On Wed, Oct 24 2007, James Bottomley wrote:
 On Wed, 2007-10-24 at 12:17 -0700, Andrew Morton wrote:
  On Wed, 24 Oct 2007 11:59:30 -0700 Ed Lin [EMAIL PROTECTED] wrote:
  
   The shared tag issue was not fixed yet. Kernel panic
   happened while running I/O test in kernel 2.6.23
   (information attached). After applying the patch I posted
   (or the version James modified), panic disappeared.
   Switch back to standard kernel, panic again.
  
  Did either of those patches get merged in 2.6.24-rc1?
 
 No ... Jens did one instead (commit
 f3da54ba140c6427fa4a32913e1bf406f41b5dda), which now looks like it might
 not have fixed the issue.

I think there's one more bug there, for shared maps. For the locking to
work, only the tag map and tag bit map may be shared (incidentally, I
was just explaining this to Nick yesterday, but I apparently didn't
review the code well enough myself). But we also share the busy list!
The busy_list must be queue private, or we need a block_queue_tag
covering lock as well.

So we have to move the busy_list to the queue. This'll work fine, and
it'll actually also fix a problem with blk_queue_invalidate_tags() which
will invalidate tags across all shared queues. This is a bit confusing,
the low level driver should call it for each queue seperately since
otherwise you cannot kill tags on just a single queue for eg a hard
drive that stops responding. Since the function has no callers
currently, it's not an issue.

Please test.


With this patch the stex driver passed I/O test. So maybe this problem is
fixed finally. Thanks. Please apply.

Ed Lin


-
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

stex driver panic in kernel 2.6.23

[Ed Lin]

The shared tag issue was not fixed yet. Kernel panic
happened while running I/O test in kernel 2.6.23
(information attached). After applying the patch I posted
(or the version James modified), panic disappeared.
Switch back to standard kernel, panic again.

Please reconsider this issue. Thanks.

Ed Lin


Panic 1

Unable to handle kernel NULL pointer dereference at 0038 RIP: 
 [80356f09] cfq_remove_request+0x18/0x1ac
PGD 1545f067 PUD 233d9067 PMD 0 
Oops:  [1] SMP 
CPU 1 
Modules linked in: e1000 stex ata_piix libata
Pid: 80, comm: kblockd/1 Not tainted 2.6.23 #2
RIP: 0010:[80356f09]  [80356f09] 
cfq_remove_request+0x18/0x1ac
RSP: 0018:810037cd1d20  EFLAGS: 00010082
RAX: 81003e823ec0 RBX: 8100227b2068 RCX: 81003e860c00
RDX: 000101042821 RSI: 8100227b2068 RDI: 8100227b2068
RBP: 8100227b2068 R08: 810037cd R09: 
R10:  R11: 804296cb R12: 
R13: 81003e99e148 R14: 0004 R15: 8100329d9290
FS:  () GS:810037e9ccc0() knlGS:
CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 0038 CR3: 1cc28000 CR4: 06e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process kblockd/1 (pid: 80, threadinfo 810037cd, task 810037c1f860)
Stack:  8100010097d0 8100227b2068 81003e860c00 
 81003e99e148 0004 8100329d9290 803570c4
  8100329d9238 8100227b2068 81003e860c00
Call Trace:
 [803570c4] cfq_dispatch_insert+0x27/0x52
 [803578d1] cfq_dispatch_requests+0x1cb/0x3bf
 [8034e130] elv_next_request+0x3f/0x13f
 [804246e5] scsi_dispatch_cmd+0x18f/0x273
 [80429734] scsi_request_fn+0x69/0x352
 [80356ab7] cfq_kick_queue+0x0/0x38
 [80356ad9] cfq_kick_queue+0x22/0x38
 [8023ee06] run_workqueue+0xca/0x160
 [8023f71f] worker_thread+0x0/0xa5
 [8023f71f] worker_thread+0x0/0xa5
 [8023f78c] worker_thread+0x6d/0xa5
 [8024283d] autoremove_wake_function+0x0/0x2e
 [8023f71f] worker_thread+0x0/0xa5
 [8023f71f] worker_thread+0x0/0xa5
 [802424c4] kthread+0x3d/0x61
 [8020c6b8] child_rip+0xa/0x12
 [80242487] kthread+0x0/0x61
 [8020c6ae] child_rip+0x0/0x12


Code: 49 39 7c 24 38 0f 84 d6 00 00 00 48 8b 55 00 48 8b 45 08 48 
RIP  [80356f09] cfq_remove_request+0x18/0x1ac
 RSP 810037cd1d20
CR2: 0038


Panic 2

Unable to handle kernel NULL pointer dereference at 0038 RIP: 
 [80356f09] cfq_remove_request+0x18/0x1ac
PGD 50c6067 PUD 16b13067 PMD 0 
Oops:  [1] SMP 
CPU 1 
Modules linked in: e1000 stex ata_piix libata
Pid: 5811, comm: cmp Not tainted 2.6.23 #5
RIP: 0010:[80356f09]  [80356f09] 
cfq_remove_request+0x18/0x1ac
RSP: 0018:81002532f748  EFLAGS: 00010096
RAX: 81003ea14a80 RBX: 810026f5c188 RCX: 81003e67da00
RDX: 0001000fc8b4 RSI: 810026f5c188 RDI: 810026f5c188
RBP: 810026f5c188 R08: 0143d37f R09: 0003
R10: 0003 R11: 804296cb R12: 
R13: 81003ea01848 R14: 0004 R15: 81003ead7180
FS:  2b6b5ebceb00() GS:810037e9ccc0() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 0038 CR3: 07c4c000 CR4: 06e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process cmp (pid: 5811, threadinfo 81002532e000, task 8100347dd180)
Stack:  00287817 810026f5c188 81003e67da00 
 81003ea01848 0004 81003ead7180 803570c4
 81000b367cd8 81003ead7128 810026f5c188 81003e67da00
Call Trace:
 [803570c4] cfq_dispatch_insert+0x27/0x52
 [803578d1] cfq_dispatch_requests+0x1cb/0x3bf
 [8034e130] elv_next_request+0x3f/0x13f
 [80429734] scsi_request_fn+0x69/0x352
 [8034e2da] elv_insert+0xaa/0x1b5
 [803524b0] __make_request+0xd2/0x5a1
 [80306618] ext2_get_block+0x0/0x705
 [80350294] generic_make_request+0x183/0x221
 [80352a24] submit_bio+0x59/0xce
 [80306618] ext2_get_block+0x0/0x705
 [8025cc6c] __pagevec_lru_add+0xd1/0xe4
 [802a451a] mpage_bio_submit+0x22/0x29
 [802a530c] mpage_readpages+0x11b/0x15f
 [80306618] ext2_get_block+0x0/0x705
 [8025a6f7] __alloc_pages+0xaa/0x372
 [8025c33d] __do_page_cache_readahead+0x1c6/0x2cb
 [802554df] sync_page+0x0/0x4b
 [8055b611] io_schedule+0x28/0x36
 [80234847] current_fs_time+0x1e/0x24
 [8025c67b] ondemand_readahead+0xb9/0x137
 [80255a80

[PATCH] stex: use resid for xfer len information

[Ed Lin]

The original implementation in stex_ys_commands() is inappropriate.
For xfer len information, we should use resid instead.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index adda296..72f6d80 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -719,8 +719,8 @@ static void stex_ys_commands(struct st_h
 
if (ccb-cmd-cmnd[0] == MGT_CMD 
resp-scsi_status != SAM_STAT_CHECK_CONDITION) {
-   scsi_bufflen(ccb-cmd) =
-   le32_to_cpu(*(__le32 *)resp-variable[0]);
+   scsi_set_resid(ccb-cmd, scsi_bufflen(ccb-cmd) -
+   le32_to_cpu(*(__le32 *)resp-variable[0]));
return;
}
 


-
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] Farther clean up of stex.c driver

[Ed Lin]

 -Original Message-
 From: Boaz Harrosh [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, June 14, 2007 9:34 AM
 To: FUJITA Tomonori; Ed Lin; Guennadi Liakhovetski
 Cc: linux-scsi@vger.kernel.org
 Subject: Re: [PATCH 3/3] Farther clean up of stex.c driver
 
 
 From 2b82909202cab8dc35184daef45b4b388f93112a Mon Sep 17 00:00:00 2001
 From: Boaz Harrosh [EMAIL PROTECTED](none)
 Date: Thu, 14 Jun 2007 19:14:40 +0300
 Subject: [PATCH] Farther clean up of stex.c driver
 
  - now that scsi-ml accessors do not allow modifying of 
 sg_count bufflen and
sglist. The code in question is open coded to directly 
 hack the scsi_cmnd
structure. When implementation changes the driver will 
 need to change with it.
 
  - Maintainer of this driver should please review again if we 
 absolutely need this
read-sense length fixing. What if less bytes are read and 
 0 are left at the end.
Also no check is made if the buffer is large enough.
 ---
  drivers/scsi/stex.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
 index adda296..d784b58 100644
 --- a/drivers/scsi/stex.c
 +++ b/drivers/scsi/stex.c
 @@ -719,7 +719,7 @@ static void stex_ys_commands(struct st_hba *hba,
 
   if (ccb-cmd-cmnd[0] == MGT_CMD 
   resp-scsi_status != SAM_STAT_CHECK_CONDITION) {
 - scsi_bufflen(ccb-cmd) =
 + ccb-cmd-request_bufflen =
   le32_to_cpu(*(__le32 *)resp-variable[0]);
   return;
   }
 -- 
 1.5.0.4.402.g8035
 
 
 

The software allocates a big enough buffer(so don't worry about this),
and it trims the data size based on returned length. So it needs the
actual data length. So this length fix is necessary if software doesn't
change policy. The whole thing is guaranteed by both software and
firmware, software will do a check, firmware will do a check, so a check
in driver is not necessary.

I wonder whether the following will go upstream:
#define scsi_sg_count(cmd) ((cmd)-sg_table ? (cmd)-sg_table-sg_count
: 0)
#define scsi_sglist(cmd) ((cmd)-sg_table ? (cmd)-sg_table-sglist :
NULL)
#define scsi_bufflen(cmd) ((cmd)-sg_table ? (cmd)-sg_table-length :
0)

For this particular case, because there is data exchange, so
(cmd)-sg_table is not NULL, so we can have something like:
ccb-cmd-sg_table-length =
le32_to_cpu(*(__le32 *)resp-variable[0]);
Although I am not sure whether the software can work without change
after the scsi_sgtable approach becomes upstream. But I just wonder why
we use some code that is known to be temporary even before its
introduction.

--Ed Lin
-
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] Farther clean up of stex.c driver

[Ed Lin]

 -Original Message-
 From: FUJITA Tomonori [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, June 14, 2007 3:21 PM
 To: Ed Lin
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
 [EMAIL PROTECTED]; linux-scsi@vger.kernel.org
 Subject: RE: [PATCH 3/3] Farther clean up of stex.c driver
 
 
 From: Ed Lin [EMAIL PROTECTED]
 Subject: RE: [PATCH 3/3] Farther clean up of stex.c driver
 Date: Thu, 14 Jun 2007 12:29:05 -0700
 
  
  
   -Original Message-
   From: Boaz Harrosh [mailto:[EMAIL PROTECTED] 
   Sent: Thursday, June 14, 2007 9:34 AM
   To: FUJITA Tomonori; Ed Lin; Guennadi Liakhovetski
   Cc: linux-scsi@vger.kernel.org
   Subject: Re: [PATCH 3/3] Farther clean up of stex.c driver
   
   
   From 2b82909202cab8dc35184daef45b4b388f93112a Mon Sep 17 
 00:00:00 2001
   From: Boaz Harrosh [EMAIL PROTECTED](none)
   Date: Thu, 14 Jun 2007 19:14:40 +0300
   Subject: [PATCH] Farther clean up of stex.c driver
   
- now that scsi-ml accessors do not allow modifying of 
   sg_count bufflen and
  sglist. The code in question is open coded to directly 
   hack the scsi_cmnd
  structure. When implementation changes the driver will 
   need to change with it.
   
- Maintainer of this driver should please review again if we 
   absolutely need this
  read-sense length fixing. What if less bytes are read and 
   0 are left at the end.
  Also no check is made if the buffer is large enough.
   ---
drivers/scsi/stex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
   
   diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
   index adda296..d784b58 100644
   --- a/drivers/scsi/stex.c
   +++ b/drivers/scsi/stex.c
   @@ -719,7 +719,7 @@ static void stex_ys_commands(struct 
 st_hba *hba,
   
 if (ccb-cmd-cmnd[0] == MGT_CMD 
 resp-scsi_status != SAM_STAT_CHECK_CONDITION) {
   - scsi_bufflen(ccb-cmd) =
   + ccb-cmd-request_bufflen =
 le32_to_cpu(*(__le32 *)resp-variable[0]);
 return;
 }
   -- 
   1.5.0.4.402.g8035
   
   
   
  
  The software allocates a big enough buffer(so don't worry 
 about this),
  and it trims the data size based on returned length. So it needs the
  actual data length.
 
 What's the software? I mean that who trims the data size based on
 returned length?
 

The management software provided by Promise.

  So this length fix is necessary if software doesn't
  change policy. The whole thing is guaranteed by both software and
  firmware, software will do a check, firmware will do a 
 check, so a check
  in driver is not necessary.
 
 
  I wonder whether the following will go upstream:
  #define scsi_sg_count(cmd) ((cmd)-sg_table ? 
 (cmd)-sg_table-sg_count
  : 0)
  #define scsi_sglist(cmd) ((cmd)-sg_table ? 
 (cmd)-sg_table-sglist :
  NULL)
  #define scsi_bufflen(cmd) ((cmd)-sg_table ? 
 (cmd)-sg_table-length :
  0)
  
  For this particular case, because there is data exchange, so
  (cmd)-sg_table is not NULL, so we can have something like:
  ccb-cmd-sg_table-length =
  le32_to_cpu(*(__le32 *)resp-variable[0]);
  Although I am not sure whether the software can work without change
  after the scsi_sgtable approach becomes upstream. But I 
 just wonder why
  we use some code that is known to be temporary even before its
  introduction.
 
 I think that it would be better to apply Boaz patchset with scsi-bidi
 support (not now). Then you can avoid adding temporary hack.
 

Does the scsi_sgtable above belong to the scsi-bidi patchset? If it
does, then this patch is just a temporary hack. The code needs to be
changed again at that time. This is stated in the comment of this patch.

--Ed Lin
-
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/4] stex: fix id mapping issue

[Ed Lin]

The correct internal mapping of stex controllers should be:
id:0~15, lun:0~7 (st_shasta)
id:0, lun:0~127 (st_yosemite)
id:0~127, lun:0 (st_vsc and st_vsc1)

This patch reports the internal mapping to scsi mid layer,  eliminating
the translation between scsi mid layer and firmware. To achieve this
goal, we also need to:
-- fail the REPORT_LUNS command for st_shasta because the
   firmware is known to not report all actual luns
-- add an entry in scsi_devindo.c to force sequential lun scan
   (for st_shasta controllers)
-- fail the REPORT_LUNS command for console device
-- remove special handling of REPORT_LUNS command for
   st_yosemite, as there is no translation mapping now

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index ce63044..18dd5cc 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -209,6 +209,7 @@ static struct {
{PIONEER, CD-ROM DRM-602X, NULL, BLIST_FORCELUN | BLIST_SINGLELUN},
{PIONEER, CD-ROM DRM-604X, NULL, BLIST_FORCELUN | BLIST_SINGLELUN},
{PIONEER, CD-ROM DRM-624X, NULL, BLIST_FORCELUN | BLIST_SINGLELUN},
+   {Promise, , NULL, BLIST_SPARSELUN},
{REGAL, CDC-4X, NULL, BLIST_MAX5LUN | BLIST_SINGLELUN},
{SanDisk, ImageMate CF-SD1, NULL, BLIST_FORCELUN},
{SEAGATE, ST34555N, 0930, BLIST_NOTQ},/* Chokes on tagged 
INQUIRY */
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 69be132..96dcbac 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -113,10 +113,6 @@ enum {
SG_CF_64B   = 0x40, /* 64 bit item */
SG_CF_HOST  = 0x20, /* sg in host memory */
 
-   ST_MAX_ARRAY_SUPPORTED  = 16,
-   ST_MAX_TARGET_NUM   = (ST_MAX_ARRAY_SUPPORTED+1),
-   ST_MAX_LUN_PER_TARGET   = 16,
-
st_shasta   = 0,
st_vsc  = 1,
st_vsc1 = 2,
@@ -586,7 +582,7 @@ stex_queuecommand(struct scsi_cmnd *cmd,
u16 tag;
host = cmd-device-host;
id = cmd-device-id;
-   lun = cmd-device-channel; /* firmware lun issue work around */
+   lun = cmd-device-lun;
hba = (struct st_hba *) host-hostdata[0];
 
switch (cmd-cmnd[0]) {
@@ -605,8 +601,19 @@ stex_queuecommand(struct scsi_cmnd *cmd,
stex_invalid_field(cmd, done);
return 0;
}
+   case REPORT_LUNS:
+   /*
+* The shasta firmware does not report actual luns in the
+* target, so fail the command to force sequential lun scan.
+* Also, the console device does not support this command.
+*/
+   if (hba-cardtype == st_shasta || id == host-max_id - 1) {
+   stex_invalid_field(cmd, done);
+   return 0;
+   }
+   break;
case INQUIRY:
-   if (id != ST_MAX_ARRAY_SUPPORTED)
+   if (id != host-max_id - 1)
break;
if (lun == 0  (cmd-cmnd[1]  INQUIRY_EVPD) == 0) {
stex_direct_copy(cmd, console_inq_page,
@@ -624,7 +631,7 @@ stex_queuecommand(struct scsi_cmnd *cmd,
ver.oem = ST_OEM;
ver.build = ST_BUILD_VER;
ver.signature[0] = PASSTHRU_SIGNATURE;
-   ver.console_id = ST_MAX_ARRAY_SUPPORTED;
+   ver.console_id = host-max_id - 1;
ver.host_no = hba-host-host_no;
cmd-result = stex_direct_copy(cmd, ver, sizeof(ver)) ?
DID_OK  16 | COMMAND_COMPLETE  8 :
@@ -645,13 +652,8 @@ stex_queuecommand(struct scsi_cmnd *cmd,
 
req = stex_alloc_req(hba);
 
-   if (hba-cardtype == st_yosemite) {
-   req-lun = lun * (ST_MAX_TARGET_NUM - 1) + id;
-   req-target = 0;
-   } else {
-   req-lun = lun;
-   req-target = id;
-   }
+   req-lun = lun;
+   req-target = id;
 
/* cdb */
memcpy(req-cdb, cmd-cmnd, STEX_CDB_LENGTH);
@@ -767,18 +769,6 @@ static void stex_ys_commands(struct st_h
ccb-srb_status = SRB_STATUS_SELECTION_TIMEOUT;
else
ccb-srb_status = SRB_STATUS_SUCCESS;
-   } else if (ccb-cmd-cmnd[0] == REPORT_LUNS) {
-   u8 *report_lun_data = (u8 *)hba-copy_buffer;
-
-   count = STEX_EXTRA_SIZE;
-   stex_internal_copy(ccb-cmd, report_lun_data,
-   count, ccb-sg_count, ST_FROM_CMD);
-   if (report_lun_data[2] || report_lun_data[3]) {
-   report_lun_data[2] = 0x00;
-   report_lun_data[3] = 0x08

[PATCH 2/4] stex: extend hard reset wait time

[Ed Lin]

During hard bus reset of st_shasta controllers, 1 ms is not enough for
16-port controllers, although it's good for 8-port controllers.  Extend the
wait time to 100  ms to allow bus resets finish successfully.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 96dcbac..81dd3b7 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -1041,7 +1041,12 @@ static void stex_hard_reset(struct st_hb
pci_read_config_byte(bus-self, PCI_BRIDGE_CONTROL, pci_bctl);
pci_bctl |= PCI_BRIDGE_CTL_BUS_RESET;
pci_write_config_byte(bus-self, PCI_BRIDGE_CONTROL, pci_bctl);
-   msleep(1);
+
+   /*
+* 1 ms may be enough for 8-port controllers. But 16-port controllers
+* require more time to finish bus reset. Use 100 ms here for safety
+*/
+   msleep(100);
pci_bctl = ~PCI_BRIDGE_CTL_BUS_RESET;
pci_write_config_byte(bus-self, PCI_BRIDGE_CONTROL, pci_bctl);
 


-
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/4] stex: fix reset recovery for console device

[Ed Lin]

After reset completed, the scsi error handler sends out TEST_UNIT_READY
to the device. For 'normal' devices the command will be handled by firmware.
However, because the RAID console only interfaces to scsi mid layer, the
firmware will not process the command for it. This will make the console to
be offlined right after reset. Add the handling in driver to fix this problem.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 81dd3b7..47c2ef9 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -612,6 +612,13 @@ stex_queuecommand(struct scsi_cmnd *cmd,
return 0;
}
break;
+   case TEST_UNIT_READY:
+   if (id == host-max_id - 1) {
+   cmd-result = DID_OK  16 | COMMAND_COMPLETE  8;
+   done(cmd);
+   return 0;
+   }
+   break;
case INQUIRY:
if (id != host-max_id - 1)
break;


-
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/4] stex: minor cleanup and version update

[Ed Lin]

Add debug information into abort and host_reset routine.
Change ioremap to ioremap_nocache.
Version updated to 3.6..1.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 47c2ef9..9ac83ab 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -32,11 +32,12 @@ #include scsi/scsi_device.h
 #include scsi/scsi_cmnd.h
 #include scsi/scsi_host.h
 #include scsi/scsi_tcq.h
+#include scsi/scsi_dbg.h
 
 #define DRV_NAME stex
-#define ST_DRIVER_VERSION 3.1.0.1
+#define ST_DRIVER_VERSION 3.6..1
 #define ST_VER_MAJOR   3
-#define ST_VER_MINOR   1
+#define ST_VER_MINOR   6
 #define ST_OEM 0
 #define ST_BUILD_VER   1
 
@@ -992,6 +993,11 @@ static int stex_abort(struct scsi_cmnd *
u32 data;
int result = SUCCESS;
unsigned long flags;
+
+   printk(KERN_INFO DRV_NAME
+   (%s): aborting command\n, pci_name(hba-pdev));
+   scsi_print_command(cmd);
+
base = hba-mmio_base;
spin_lock_irqsave(host-host_lock, flags);
if (tag  host-can_queue  hba-ccb[tag].cmd == cmd)
@@ -1077,6 +1083,10 @@ static int stex_reset(struct scsi_cmnd *
unsigned long before;
hba = (struct st_hba *) cmd-device-host-hostdata[0];
 
+   printk(KERN_INFO DRV_NAME
+   (%s): resetting host\n, pci_name(hba-pdev));
+   scsi_print_command(cmd);
+
hba-mu_status = MU_STATE_RESETTING;
 
if (hba-cardtype == st_shasta)
@@ -1196,7 +1206,7 @@ stex_probe(struct pci_dev *pdev, const s
goto out_scsi_host_put;
}
 
-   hba-mmio_base = ioremap(pci_resource_start(pdev, 0),
+   hba-mmio_base = ioremap_nocache(pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0));
if ( !hba-mmio_base) {
printk(KERN_ERR DRV_NAME (%s): memory map failed\n,


-
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/4] [SCSI]stex: fix reset recovery for console device

[Ed Lin]

 -Original Message-
 From: Ed Lin 
 Sent: Monday, April 02, 2007 4:02 PM
 To: James Bottomley
 Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
 Subject: RE: [PATCH 3/4] [SCSI]stex: fix reset recovery for 
 console device
 
 
 
 
  -Original Message-
  From: James Bottomley [mailto:[EMAIL PROTECTED] 
  Sent: Monday, April 02, 2007 11:28 AM
  To: Ed Lin
  Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
  Subject: RE: [PATCH 3/4] [SCSI]stex: fix reset recovery for 
  console device
  
  
  On Mon, 2007-04-02 at 11:14 -0700, Ed Lin wrote:
   I just saw the routine name scsi_eh_try_stu, and didn't notice the
   allow_restart (partly because I thought it was not harmful...).
   But the TEST_UNIT_READY must stay.
  
  Sure ... I was just checking since your change log implied 
 you'd seen
  the problem from the error handler ... however, we can add it ...
  there's a possibility of getting spin up on init from sd anyway.
  
 
 You make the decision. But after reconsideration, I think it's better
 to remove unused code. It also needs change since the patch about
 id mapping is modified in another mail.
 
 How about the attachment here?


Sorry. I think the mail server has problem with attachment. The patch
is here in plain text. Sorry for the inconvenience. I have problem with
linux-scsi mail list, if you have comment please cc me. Thanks.
--Ed Lin




After reset completed, the scsi error handler sends out TEST_UNIT_READY
to
the device. For 'normal' devices this command will be handled by
firmware.
However, because the RAID console only interfaces to scsi mid layer, the
firmware will not process this command for it. This will make the
console
to be offlined right after reset. Add the handling in driver to fix this
problem.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 4c6ce6a..85c779b 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -601,6 +601,13 @@ stex_queuecommand(struct scsi_cmnd *cmd,
stex_invalid_field(cmd, done);
return 0;
}
+   case TEST_UNIT_READY:
+   if (id == host-max_id - 1) {
+   cmd-result = DID_OK  16 | COMMAND_COMPLETE 
8;
+   done(cmd);
+   return 0;
+   }
+   break;
case INQUIRY:
if (id != host-max_id - 1)
break; 
-
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/4] [SCSI]stex: fix id mapping issue

[Ed Lin]

 -Original Message-
 From: James Bottomley [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, April 04, 2007 10:36 AM
 To: Ed Lin
 Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
 Subject: RE: [PATCH 1/4] [SCSI]stex: fix id mapping issue
 
 
 On Wed, 2007-04-04 at 10:31 -0700, Ed Lin wrote:
 
  Sorry. It seems the mail server has problem. The patch is 
 here in plain
  text. I hope this time it does not mess up. I have problem with
  linux-scsi
  mail list, if you have comment please cc me. Thanks.
  --Ed Lin
 
 The lines are still broken, I'm afraid ... you can just resend as an
 attachement git-applypatch copes fine with that ... inline is 
 just good
 for quoting and replying.
  +   if (hba-cardtype == st_shasta) {
  +   host-max_channel = 7;
  +   host-max_id = 16 + 1;
  +   } else if (hba-cardtype == st_yosemite) {
  +   host-max_channel = 127;
  +   host-max_id = 1 + 1;
  +   } else {
  +   /* st_vsc and st_vsc1 */
  +   host-max_channel = 0;
  +   host-max_id = 128 + 1;
 
 This is OK.  The use of -channel is still a bit strange ... could we
 not simply use lun instead of channel (i.e. map the adapter id/lun to
 the mid-layer id/lun instead of using id/channel)?
 

This is because there is a CONFIG_SCSI_MULTI_LUN option.
If this option is not selected, max_scsi_luns will be set to 1 and
the RAID arrays with lun0 will disappear(because they are not
scanned). That is unacceptable from a user's view point.  I have
also explained this in the code comment:

/*
 * firmware uses id/lun pair for a logical drive, but lun would be
 * always 0 if CONFIG_SCSI_MULTI_LUN not configured, so we use
 * channel to map lun here
 */

If it is not allowed to map channel to lun, then maybe I have to
report 128 targets and do the mapping in queuecommand...
After all there must be a mapping somewhere so I don't see
much difference here...

I paste the patch again, is the format ok?



The internal id/lun mapping of st_vsc and st_vsc1 controllers is different
from st_shasta. The original driver code can only  map first 16 'entities'
for st_vsc and st_vsc1 while there are actually 128 available.

The correct mapping should be:
channel:0~7, id:0~15 (st_shasta, console is channel:0, id:16, lun:0)
channel:0~127, id:0 (st_yosemite, console is channel:0, id:1, lun:0)
channel:0, id:0~127 (st_vsc and st_vsc1, console is channel:0, id:128, lun:0)

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 69be132..29a7b61 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -113,10 +113,6 @@ enum {
SG_CF_64B   = 0x40, /* 64 bit item */
SG_CF_HOST  = 0x20, /* sg in host memory */
 
-   ST_MAX_ARRAY_SUPPORTED  = 16,
-   ST_MAX_TARGET_NUM   = (ST_MAX_ARRAY_SUPPORTED+1),
-   ST_MAX_LUN_PER_TARGET   = 16,
-
st_shasta   = 0,
st_vsc  = 1,
st_vsc1 = 2,
@@ -606,7 +602,7 @@ stex_queuecommand(struct scsi_cmnd *cmd,
return 0;
}
case INQUIRY:
-   if (id != ST_MAX_ARRAY_SUPPORTED)
+   if (id != host-max_id - 1)
break;
if (lun == 0  (cmd-cmnd[1]  INQUIRY_EVPD) == 0) {
stex_direct_copy(cmd, console_inq_page,
@@ -624,7 +620,7 @@ stex_queuecommand(struct scsi_cmnd *cmd,
ver.oem = ST_OEM;
ver.build = ST_BUILD_VER;
ver.signature[0] = PASSTHRU_SIGNATURE;
-   ver.console_id = ST_MAX_ARRAY_SUPPORTED;
+   ver.console_id = host-max_id - 1;
ver.host_no = hba-host-host_no;
cmd-result = stex_direct_copy(cmd, ver, sizeof(ver)) ?
DID_OK  16 | COMMAND_COMPLETE  8 :
@@ -645,13 +641,8 @@ stex_queuecommand(struct scsi_cmnd *cmd,
 
req = stex_alloc_req(hba);
 
-   if (hba-cardtype == st_yosemite) {
-   req-lun = lun * (ST_MAX_TARGET_NUM - 1) + id;
-   req-target = 0;
-   } else {
-   req-lun = lun;
-   req-target = id;
-   }
+   req-lun = lun;
+   req-target = id;
 
/* cdb */
memcpy(req-cdb, cmd-cmnd, STEX_CDB_LENGTH);
@@ -1229,11 +1220,22 @@ stex_probe(struct pci_dev *pdev, const s
hba-copy_buffer = hba-dma_mem + MU_BUFFER_SIZE;
hba-mu_status = MU_STATE_STARTING;
 
-   /* firmware uses id/lun pair for a logical drive, but lun would be
-  always 0 if CONFIG_SCSI_MULTI_LUN not configured, so we use
-  channel to map lun here */
-   host-max_channel = ST_MAX_LUN_PER_TARGET - 1;
-   host-max_id = ST_MAX_TARGET_NUM

[PATCH 1/4] stex: fix id mapping issue(v3)

[Ed Lin]

The correct internal mapping of stex controllers should be:
id:0~15, lun:0~7 (st_shasta)
id:0, lun:0~127 (st_yosemite)
id:0~127, lun:0 (st_vsc and st_vsc1)

Unfortunately we can not use the internal id/lun as scsi
mid layer id/lun. The Linux kernel has a config option
CONFIG_SCSI_MULTI_LUN. This option is not selected
in some major Linux releases. If it is not selected,
then st_shasta can expose 16 LDs(logical drive)
at most, while st_yosemite can expose only one LD.
This is clearly unacceptable.

This patch is a workaround for this issue.  Since every
LD is 'normal', and should be ignored/skipped in no
circumstances, we report that the max_id for LD is
128, then when commands are sent out by scsi
mid layer, we map id/lun pair based on controller type.

Please consider the situation, and apply the patch.
Thanks.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 69be132..d114e4c 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -113,10 +113,6 @@ enum {
SG_CF_64B   = 0x40, /* 64 bit item */
SG_CF_HOST  = 0x20, /* sg in host memory */
 
-   ST_MAX_ARRAY_SUPPORTED  = 16,
-   ST_MAX_TARGET_NUM   = (ST_MAX_ARRAY_SUPPORTED+1),
-   ST_MAX_LUN_PER_TARGET   = 16,
-
st_shasta   = 0,
st_vsc  = 1,
st_vsc1 = 2,
@@ -581,12 +577,11 @@ stex_queuecommand(struct scsi_cmnd *cmd,
 {
struct st_hba *hba;
struct Scsi_Host *host;
-   unsigned int id,lun;
+   unsigned int id;
struct req_msg *req;
u16 tag;
host = cmd-device-host;
id = cmd-device-id;
-   lun = cmd-device-channel; /* firmware lun issue work around */
hba = (struct st_hba *) host-hostdata[0];
 
switch (cmd-cmnd[0]) {
@@ -606,9 +601,9 @@ stex_queuecommand(struct scsi_cmnd *cmd,
return 0;
}
case INQUIRY:
-   if (id != ST_MAX_ARRAY_SUPPORTED)
+   if (id != host-max_id - 1)
break;
-   if (lun == 0  (cmd-cmnd[1]  INQUIRY_EVPD) == 0) {
+   if ((cmd-cmnd[1]  INQUIRY_EVPD) == 0) {
stex_direct_copy(cmd, console_inq_page,
sizeof(console_inq_page));
cmd-result = DID_OK  16 | COMMAND_COMPLETE  8;
@@ -624,7 +619,7 @@ stex_queuecommand(struct scsi_cmnd *cmd,
ver.oem = ST_OEM;
ver.build = ST_BUILD_VER;
ver.signature[0] = PASSTHRU_SIGNATURE;
-   ver.console_id = ST_MAX_ARRAY_SUPPORTED;
+   ver.console_id = host-max_id - 1;
ver.host_no = hba-host-host_no;
cmd-result = stex_direct_copy(cmd, ver, sizeof(ver)) ?
DID_OK  16 | COMMAND_COMPLETE  8 :
@@ -645,11 +640,15 @@ stex_queuecommand(struct scsi_cmnd *cmd,
 
req = stex_alloc_req(hba);
 
-   if (hba-cardtype == st_yosemite) {
-   req-lun = lun * (ST_MAX_TARGET_NUM - 1) + id;
+   if (hba-cardtype == st_shasta) {
+   req-lun = id % 8;
+   req-target = id / 8;
+   } else if (hba-cardtype == st_yosemite){
+   req-lun = id;
req-target = 0;
} else {
-   req-lun = lun;
+   /* st_vsc and st_vsc1 */
+   req-lun = 0;
req-target = id;
}
 
@@ -1229,11 +1228,8 @@ stex_probe(struct pci_dev *pdev, const s
hba-copy_buffer = hba-dma_mem + MU_BUFFER_SIZE;
hba-mu_status = MU_STATE_STARTING;
 
-   /* firmware uses id/lun pair for a logical drive, but lun would be
-  always 0 if CONFIG_SCSI_MULTI_LUN not configured, so we use
-  channel to map lun here */
-   host-max_channel = ST_MAX_LUN_PER_TARGET - 1;
-   host-max_id = ST_MAX_TARGET_NUM;
+   host-max_channel = 0;
+   host-max_id = 128 + 1;
host-max_lun = 1;
host-unique_id = host-host_no;
host-max_cmd_len = STEX_CDB_LENGTH;


-
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/4] [SCSI]stex: fix id mapping issue

[Ed Lin]

 -Original Message-
 From: Christoph Hellwig [mailto:[EMAIL PROTECTED] 
 Sent: Saturday, March 31, 2007 2:27 AM
 To: Ed Lin
 Cc: linux-scsi; linux-kernel; james.Bottomley; jeff; Promise_Linux
 Subject: Re: [PATCH 1/4] [SCSI]stex: fix id mapping issue
 
 
 On Fri, Mar 30, 2007 at 03:21:33PM -0700, Ed Lin wrote:
  +   if (hba-cardtype == st_shasta) {
  req-lun = lun;
  req-target = id;
  +   } else if (hba-cardtype == st_yosemite){
  +   req-lun = id * ST_MAX_LUN_PER_TARGET + lun;
  +   req-target = 0;
  +   } else {
  +   /* st_vsc and st_vsc1 */
  +   req-lun = 0;
  +   req-target = id * ST_MAX_LUN_PER_TARGET + lun;
 
 I don't get why you can't export id as targer and lun as lun for
 the !st_shasta types.  Could you explain in detail what the problem
 with that approach would be?
 


Of course I can do that. That will result in 1 target and 128 lun
for st_yosemite and 128 target and 1 lun for st_vsc. That seems
a little weird and I am afraid it will be turned down. Also
I can keep a same mapping for the console in the original code.

If you think it's ok, that's really better, because it makes the
hot path a bit faster. Also because of the CONFIG_SCSI_MULTI_LUN
option, I have to map lun to channel otherwise many entities
will disappear when that option is not selected. Plus I have to
reserve a slot for the RAID console, so the final mapping may be:

channel:0~7, id:0~16(st_shasta, channel 0,id 16 is reserved for console)
channel:0~127, id:0~1(st_yosemite, channel 0,id 1 is reserved for
console)
channel:0, id:0~128(st_vsc, channel 0,id 128 is reserved for console)

I don't know whether this is acceptable. 
-
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 4/4] [SCSI]stex: minor cleanup and version update

[Ed Lin]

 -Original Message-
 From: Brian King [mailto:[EMAIL PROTECTED] 
 Sent: Monday, April 02, 2007 9:05 AM
 To: Ed Lin
 Cc: linux-scsi; linux-kernel; james.Bottomley; jeff; Promise_Linux
 Subject: Re: [PATCH 4/4] [SCSI]stex: minor cleanup and version update
 
 
 Ed Lin wrote:
  @@ -1007,6 +1008,11 @@ static int stex_abort(struct scsi_cmnd *
  u32 data;
  int result = SUCCESS;
  unsigned long flags;
  +
  +   printk(KERN_INFO DRV_NAME
  +   (%s): aborting command\n, pci_name(hba-pdev));
  +   scsi_print_command(cmd);
  +
 
 scmd_printk is probably what you want here rather than just a printk.
 
 scmd_printk(KERN_ERR, cmd, aborting command\n);
 
 
  @@ -1092,6 +1098,10 @@ static int stex_reset(struct scsi_cmnd *
  unsigned long before;
  hba = (struct st_hba *) cmd-device-host-hostdata[0];
  
  +   printk(KERN_INFO DRV_NAME
  +   (%s): resetting host\n, pci_name(hba-pdev));
  +   scsi_print_command(cmd);
  +
 
 Same here.

Well it's just because printk with pci_name stuff is used across
the driver, and I didn't want to break the rule... 
-
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/4] [SCSI]stex: fix id mapping issue

[Ed Lin]

 -Original Message-
 From: James Bottomley [mailto:[EMAIL PROTECTED] 
 Sent: Saturday, March 31, 2007 7:22 AM
 To: Ed Lin
 Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
 Subject: Re: [PATCH 1/4] [SCSI]stex: fix id mapping issue
 
 
 On Fri, 2007-03-30 at 15:21 -0700, Ed Lin wrote:
  The internal id/lun mapping of st_vsc and st_vsc1 
 controllers is different
  from st_shasta. The original driver code can only  map 
 first 16 'entities'
  for st_vsc and st_vsc1 while there are actually 128 available.
  
  Also the  ST_MAX_LUN_PER_TARGET should be 8, although this can do
  no harm because inquiries beyond boundary are discarded by firmware.
  
  The correct internal mapping should be:
  id:0~15, lun:0~7 (st_shasta)
  id:0, lun:0~127 (st_yosemite)
  id:0~127, lun:0 (st_vsc and st_vsc1)
  To scsi mid layer they are all channel:0~7, id:0~15, lun:0, 
 with a maximun
  'entity' number of 128. The RAID console only interfaces to 
 scsi mid layer
  and is always mapped at channel:0, id:16, lun:0.
 
 I'm with Christoph here ... if we're going to break the backwards
 compatibility of the mappings (which your code does) then we 
 could just
 dump channel and use the SCSI id and lun directly.
 
 Understanding this code is predicated on this quirky definition in
 stex_queuecommand:
 
   id = cmd-device-id;
   lun = cmd-device-channel; /* firmware lun issue work around */
^^^
 
  @ -645,12 +645,16 @@ stex_queuecommand(struct scsi_cmnd *cmd,
   
  req = stex_alloc_req(hba);
   
  -   if (hba-cardtype == st_yosemite) {
  -   req-lun = lun * (ST_MAX_TARGET_NUM - 1) + id;
 
 This looks to be correct, it goes up id 0 to ST_MAX_TARGET_NUM -1 then
 takes the next channel.
 
  -   req-target = 0;
  -   } else {
  +   if (hba-cardtype == st_shasta) {
  req-lun = lun;
  req-target = id;
  +   } else if (hba-cardtype == st_yosemite){
  +   req-lun = id * ST_MAX_LUN_PER_TARGET + lun;
  +   req-target = 0;
  +   } else {
  +   /* st_vsc and st_vsc1 */
  +   req-lun = 0;
  +   req-target = id * ST_MAX_LUN_PER_TARGET + lun;
 
 These both look to be wrong.  You're taking the channel as the lowest
 common denominator, so your first target is on channel 1 id 
 0, your next
 on channel 2, id 0 and so on.  That's really going to mess with the
 ordering (which will be user visible) is that really what you want?
 

How about the attached one? 


s1
Description: s1

RE: [PATCH 3/4] [SCSI]stex: fix reset recovery for console device

[Ed Lin]

 -Original Message-
 From: James Bottomley [mailto:[EMAIL PROTECTED] 
 Sent: Monday, April 02, 2007 11:28 AM
 To: Ed Lin
 Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
 Subject: RE: [PATCH 3/4] [SCSI]stex: fix reset recovery for 
 console device
 
 
 On Mon, 2007-04-02 at 11:14 -0700, Ed Lin wrote:
  I just saw the routine name scsi_eh_try_stu, and didn't notice the
  allow_restart (partly because I thought it was not harmful...).
  But the TEST_UNIT_READY must stay.
 
 Sure ... I was just checking since your change log implied you'd seen
 the problem from the error handler ... however, we can add it ...
 there's a possibility of getting spin up on init from sd anyway.
 

You make the decision. But after reconsideration, I think it's better
to remove unused code. It also needs change since the patch about
id mapping is modified in another mail.

How about the attachment here?


s3
Description: s3

[PATCH 1/4] [SCSI]stex: fix id mapping issue

[Ed Lin]

The internal id/lun mapping of st_vsc and st_vsc1 controllers is different
from st_shasta. The original driver code can only  map first 16 'entities'
for st_vsc and st_vsc1 while there are actually 128 available.

Also the  ST_MAX_LUN_PER_TARGET should be 8, although this can do
no harm because inquiries beyond boundary are discarded by firmware.

The correct internal mapping should be:
id:0~15, lun:0~7 (st_shasta)
id:0, lun:0~127 (st_yosemite)
id:0~127, lun:0 (st_vsc and st_vsc1)
To scsi mid layer they are all channel:0~7, id:0~15, lun:0, with a maximun
'entity' number of 128. The RAID console only interfaces to scsi mid layer
and is always mapped at channel:0, id:16, lun:0.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 69be132..4d68533 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -115,7 +115,7 @@ enum {
 
ST_MAX_ARRAY_SUPPORTED  = 16,
ST_MAX_TARGET_NUM   = (ST_MAX_ARRAY_SUPPORTED+1),
-   ST_MAX_LUN_PER_TARGET   = 16,
+   ST_MAX_LUN_PER_TARGET   = 8,
 
st_shasta   = 0,
st_vsc  = 1,
@@ -645,12 +645,16 @@ stex_queuecommand(struct scsi_cmnd *cmd,
 
req = stex_alloc_req(hba);
 
-   if (hba-cardtype == st_yosemite) {
-   req-lun = lun * (ST_MAX_TARGET_NUM - 1) + id;
-   req-target = 0;
-   } else {
+   if (hba-cardtype == st_shasta) {
req-lun = lun;
req-target = id;
+   } else if (hba-cardtype == st_yosemite){
+   req-lun = id * ST_MAX_LUN_PER_TARGET + lun;
+   req-target = 0;
+   } else {
+   /* st_vsc and st_vsc1 */
+   req-lun = 0;
+   req-target = id * ST_MAX_LUN_PER_TARGET + lun;
}
 
/* cdb */


-
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/4] [SCSI]stex: fix reset recovery for console device

[Ed Lin]

After reset completed, the scsi error handler sends out START_STOP
and TEST_UNIT_READY to the device. For 'normal' devices these
commands will be handled by firmware. However, because the RAID
console only interfaces to scsi mid layer, the firmware will not process
these commands for it. This will make the console to be offlined right
after reset. Add the handling in driver to fix this problem.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 1e8d7ac..9465f35 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -605,6 +605,14 @@ stex_queuecommand(struct scsi_cmnd *cmd,
stex_invalid_field(cmd, done);
return 0;
}
+   case TEST_UNIT_READY:
+   case START_STOP:
+   if (id == ST_MAX_ARRAY_SUPPORTED) {
+   cmd-result = DID_OK  16 | COMMAND_COMPLETE  8;
+   done(cmd);
+   return 0;
+   }
+   break;
case INQUIRY:
if (id != ST_MAX_ARRAY_SUPPORTED)
break;


-
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/4] [SCSI]stex: extend hard reset wait time

[Ed Lin]

During hard bus reset of st_shasta controllers, 1 ms is not enough for
16-port controllers, although it's good for 8-port controllers.  Extend the
wait time to 100  ms to allow bus resets finish successfully.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 4d68533..1e8d7ac 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -1055,7 +1055,12 @@ static void stex_hard_reset(struct st_hb
pci_read_config_byte(bus-self, PCI_BRIDGE_CONTROL, pci_bctl);
pci_bctl |= PCI_BRIDGE_CTL_BUS_RESET;
pci_write_config_byte(bus-self, PCI_BRIDGE_CONTROL, pci_bctl);
-   msleep(1);
+
+   /*
+* 1 ms may be enough for 8-port controllers. But 16-port controllers
+* require more time to finish bus reset. Use 100 ms here for safety
+*/
+   msleep(100);
pci_bctl = ~PCI_BRIDGE_CTL_BUS_RESET;
pci_write_config_byte(bus-self, PCI_BRIDGE_CONTROL, pci_bctl);
 


-
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/4] [SCSI]stex: minor cleanup and version update

[Ed Lin]

Add debug information into abort and host_reset routine.
Change ioremap to ioremap_nocache.
Version updated to 3.6..1.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 9465f35..5a10cfa 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -32,11 +32,12 @@ #include scsi/scsi_device.h
 #include scsi/scsi_cmnd.h
 #include scsi/scsi_host.h
 #include scsi/scsi_tcq.h
+#include scsi/scsi_dbg.h
 
 #define DRV_NAME stex
-#define ST_DRIVER_VERSION 3.1.0.1
+#define ST_DRIVER_VERSION 3.6..1
 #define ST_VER_MAJOR   3
-#define ST_VER_MINOR   1
+#define ST_VER_MINOR   6
 #define ST_OEM 0
 #define ST_BUILD_VER   1
 
@@ -1007,6 +1008,11 @@ static int stex_abort(struct scsi_cmnd *
u32 data;
int result = SUCCESS;
unsigned long flags;
+
+   printk(KERN_INFO DRV_NAME
+   (%s): aborting command\n, pci_name(hba-pdev));
+   scsi_print_command(cmd);
+
base = hba-mmio_base;
spin_lock_irqsave(host-host_lock, flags);
if (tag  host-can_queue  hba-ccb[tag].cmd == cmd)
@@ -1092,6 +1098,10 @@ static int stex_reset(struct scsi_cmnd *
unsigned long before;
hba = (struct st_hba *) cmd-device-host-hostdata[0];
 
+   printk(KERN_INFO DRV_NAME
+   (%s): resetting host\n, pci_name(hba-pdev));
+   scsi_print_command(cmd);
+
hba-mu_status = MU_STATE_RESETTING;
 
if (hba-cardtype == st_shasta)
@@ -1211,7 +1221,7 @@ stex_probe(struct pci_dev *pdev, const s
goto out_scsi_host_put;
}
 
-   hba-mmio_base = ioremap(pci_resource_start(pdev, 0),
+   hba-mmio_base = ioremap_nocache(pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0));
if ( !hba-mmio_base) {
printk(KERN_ERR DRV_NAME (%s): memory map failed\n,


-
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] scsi: use lock per host instead of per device for shared queue tag host

[Ed Lin]

 -Original Message-
 From: Jens Axboe [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, January 25, 2007 7:48 AM
 To: Ed Lin
 Cc: David Somayajulu; Michael Reed; linux-scsi; linux-kernel; 
 james.Bottomley; jeff; Promise_Linux
 Subject: Re: [patch] scsi: use lock per host instead of per 
 device for shared queue tag host
 
 
 On Thu, Jan 25 2007, Jens Axboe wrote:
  On Wed, Jan 24 2007, Ed Lin wrote:
   
   
-Original Message-
From: David Somayajulu [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, January 24, 2007 5:03 PM
To: Ed Lin; Michael Reed
Cc: linux-scsi; linux-kernel; james.Bottomley; jeff; 
Promise_Linux; Jens Axboe
Subject: RE: [patch] scsi: use lock per host instead of per 
device for shared queue tag host


 It seems another driver(qla4xxx) is also using shared 
 queue tag.
 It is natural to imagine there might be same symptom in that
 driver. But I don't know the driver and have no hardware so I
 can not say anything certain about it.

qla4xxx implements slightly differently, in the sense we 
don't have the
equivalent of 
struct st_ccb ccb[MU_MAX_REQUEST]; 
which is in struct st_hba. In other words we don't have 
 a local array
which like stex to keep track of the outstanding 
 commands to the hba.

We had a discussion on this one while implementing 
 block-layer tagging
in qla4xxx and Jens Axboe added the test_and_set_bit() in the 
following
code in blk_queue_start_tag() to take care of it.
do {
tag = find_first_zero_bit(bqt-tag_map, 
 bqt-max_depth);
if (tag = bqt-max_depth)
return 1;
} while (test_and_set_bit(tag, bqt-tag_map));
Please see the following link for the discussion
http://marc.theaimsgroup.com/?l=linux-scsim=115886351206726w=2

Cheers
David Somayajulu
QLogic Corporation
   
   
   Yes, this piece of code of allocating tag, in itself, is safe.
   But the following
   
 if (unlikely(!__test_and_clear_bit(tag, bqt-tag_map))) {
 printk(KERN_ERR %s: attempt to clear non-busy tag
   (%d)\n,
__FUNCTION__, tag);
 return;
 }
   
   code of freeing tag (in blk_queue_end_tag())seems to be using
   unsafe __test_and_clear_bit instead of test_and_clear_bit.
   I once changed it to test_and_clear_bit and thought it was fixed.
   But the panic happened thereafter nonetheless(using gcc 3.4.6.
   gcc 4.1.0 is better but still with kernel errors). bqt also needs
   to be protected in this case. Replacing queue lock per device with
   a host lock is a simple but logical fix for it. To introduce a
   more refined lock is possible, but seems too tedious and elaborate
   for this issue, since a queue lock is already out there, and a
   hostwide lock is needed anyway.
  
  Does this fix it? There really should be no need to add 
 extra locking
  for this, it would be a shame.
  
  diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
  index fb67897..e752e5d 100644
  --- a/block/ll_rw_blk.c
  +++ b/block/ll_rw_blk.c
  @@ -1072,12 +1072,16 @@ void 
 blk_queue_end_tag(request_queue_t *q, struct request *rq)
   */
  return;
   
  -   if (unlikely(!__test_and_clear_bit(tag, bqt-tag_map))) {
  +   smp_mb__before_clear_bit();
  +
  +   if (unlikely(!test_and_clear_bit(tag, bqt-tag_map))) {
  printk(KERN_ERR %s: attempt to clear non-busy 
 tag (%d)\n,
 __FUNCTION__, tag);
  return;
  }
   
  +   smp_mb__after_clear_bit();
  +
  list_del_init(rq-queuelist);
  rq-cmd_flags = ~REQ_QUEUED;
  rq-tag = -1;
  
 
 Double checking the actual implementation, the smp_mb__* should not be
 needed with the test_and_*_bit operations. The __test_and_clear_bit()
 change is needed, though. What kind of crash did you see when you did
 that? It should not crash, but you could see the attempt to clear
 non-busy tag error though.

Besides the test_and_clear_bit, I think the bqt code(refer to last mail)
also needs protection, like:

list_del_init(rq-queuelist);
...
if (unlikely(bqt-tag_index[tag] == NULL))
printk(KERN_ERR %s: tag %d is missing\n,
   __FUNCTION__, tag);

bqt-tag_index[tag] = NULL;
bqt-busy--;

and

bqt-tag_index[tag] = rq;
...
list_add(rq-queuelist, bqt-busy_list);
bqt-busy++;

because bqt is also globally shared within all devices in the host in
this case. (q-queue_tags was assigned as host-bqt in scsi_activate_tcq
)

With a gcc 4.1.0 compiled kernel, I did not get kernel panic, but
still got kernel errors: tag  is missing. I guess a possible race
scenario could be:

cpu a:__test_and_clear_bit
cpu b:test_and_set_bit, allocate a tag just freed by cpu a
cpu b:bqt-tag_index[tag] = rq; 
cpu a:bqt-tag_index[tag] = NULL;

Next time, when the request

RE: [patch] scsi: use lock per host instead of per device for shared queue tag host

[Ed Lin]

 -Original Message-
 From: Michael Reed [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, January 24, 2007 7:59 AM
 To: Ed Lin
 Cc: linux-scsi; linux-kernel; james.Bottomley; jeff; Promise_Linux
 Subject: Re: [patch] scsi: use lock per host instead of per 
 device for shared queue tag host
 
 
 How 'bout a comment in scsh_host.h indicating that the 
 pointer will be NULL unless
 initialized by the driver?
 
 Protect shared block queue tag is unique to stex.  Perhaps 
 have no comment on
 the variable declaration in scsi_host.h and explain why you 
 use it in stex.
 
 Mike
 
 

Thanks for commenting. I agree more detailed explaination should
be better.

It seems another driver(qla4xxx) is also using shared queue tag.
It is natural to imagine there might be same symptom in that
driver. But I don't know the driver and have no hardware so I
can not say anything certain about it.

Ed Lin
-
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] scsi: use lock per host instead of per device for shared queue tag host

[Ed Lin]

 -Original Message-
 From: David Somayajulu [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, January 24, 2007 5:03 PM
 To: Ed Lin; Michael Reed
 Cc: linux-scsi; linux-kernel; james.Bottomley; jeff; 
 Promise_Linux; Jens Axboe
 Subject: RE: [patch] scsi: use lock per host instead of per 
 device for shared queue tag host
 
 
  It seems another driver(qla4xxx) is also using shared queue tag.
  It is natural to imagine there might be same symptom in that
  driver. But I don't know the driver and have no hardware so I
  can not say anything certain about it.
 
 qla4xxx implements slightly differently, in the sense we 
 don't have the
 equivalent of 
 struct st_ccb ccb[MU_MAX_REQUEST]; 
 which is in struct st_hba. In other words we don't have a local array
 which like stex to keep track of the outstanding commands to the hba.
 
 We had a discussion on this one while implementing block-layer tagging
 in qla4xxx and Jens Axboe added the test_and_set_bit() in the 
 following
 code in blk_queue_start_tag() to take care of it.
   do {
   tag = find_first_zero_bit(bqt-tag_map, bqt-max_depth);
   if (tag = bqt-max_depth)
   return 1;
   } while (test_and_set_bit(tag, bqt-tag_map));
 Please see the following link for the discussion
 http://marc.theaimsgroup.com/?l=linux-scsim=115886351206726w=2
 
 Cheers
 David Somayajulu
 QLogic Corporation


Yes, this piece of code of allocating tag, in itself, is safe.
But the following

if (unlikely(!__test_and_clear_bit(tag, bqt-tag_map))) {
printk(KERN_ERR %s: attempt to clear non-busy tag
(%d)\n,
   __FUNCTION__, tag);
return;
}

code of freeing tag (in blk_queue_end_tag())seems to be using
unsafe __test_and_clear_bit instead of test_and_clear_bit.
I once changed it to test_and_clear_bit and thought it was fixed.
But the panic happened thereafter nonetheless(using gcc 3.4.6.
gcc 4.1.0 is better but still with kernel errors). bqt also needs
to be protected in this case. Replacing queue lock per device with
a host lock is a simple but logical fix for it. To introduce a
more refined lock is possible, but seems too tedious and elaborate
for this issue, since a queue lock is already out there, and a
hostwide lock is needed anyway.

Thanks,

Ed Lin
-
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] scsi: use lock per host instead of per device forshared queue tag host

[Ed Lin]

 -Original Message-
 From: James Bottomley [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, January 24, 2007 9:00 AM
 To: Ed Lin
 Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
 Subject: Re: [patch] scsi: use lock per host instead of per 
 device forshared queue tag host
 
...
 
 This patch looks OK in principle.
 
 However, are you sure you're not using a sledgehammer to crack a nut?
 If the only reason you're doing this is because of the shared tag map,
 then probably that should be the area you protect with a per-tag-map
 lock.   The net effect of what you've done will be to serialise all
 accesses to your storage devices.  For a small number of devices, this
 probably won't matter than much, but for large numbers of devices,
 you're probably going to introduce artificial performance 
 degredation in
 the I/O scheduler.
 
 James
 

Thanks.
Maybe this issue needs more discussion. I'll follow up.

Ed Lin
-
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: use lock per host instead of per device for shared queue tag host

[Ed Lin]

The block layer uses lock to protect request queue. Every scsi device
has a unique request queue, and queue lock is the default lock in struct
request_queue. This is good for normal cases. But for a  host with
shared queue tag (e.g. stex controllers), a queue lock per device means
the shared queue tag is not protected when multiple devices are accessed
at a same time.  This patch is a simple fix for this situation by introducing
a host queue lock to protect shared queue tag. Without this patch we will
see various kernel panics (including the BUG() and kernel errors in
blk_queue_start_tag and blk_queue_end_tag of ll_rw_blk.c) when accessing
different devices simultaneously (e.g. copying big file from one device to
another in smp kernels).

This is against kernel 2.6.20-rc5.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
 drivers/scsi/scsi_lib.c  |2 +-
 drivers/scsi/stex.c  |2 ++
 include/scsi/scsi_host.h |3 +++
 3 files changed, 6 insertions(+), 1 deletion(-)

diff -purN a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
--- a/drivers/scsi/scsi_lib.c   2007-01-23 14:40:28.0 -0800
+++ b/drivers/scsi/scsi_lib.c   2007-01-23 14:46:43.0 -0800
@@ -1574,7 +1574,7 @@ struct request_queue *__scsi_alloc_queue
 {
struct request_queue *q;
 
-   q = blk_init_queue(request_fn, NULL);
+   q = blk_init_queue(request_fn, shost-req_q_lock);
if (!q)
return NULL;
 
diff -purN a/drivers/scsi/stex.c b/drivers/scsi/stex.c
--- a/drivers/scsi/stex.c   2007-01-23 14:40:28.0 -0800
+++ b/drivers/scsi/stex.c   2007-01-23 14:48:59.0 -0800
@@ -1254,6 +1254,8 @@ stex_probe(struct pci_dev *pdev, const s
if (err)
goto out_free_irq;
 
+   spin_lock_init(host-__req_q_lock);
+   host-req_q_lock = host-__req_q_lock;
err = scsi_init_shared_tag_map(host, host-can_queue);
if (err) {
printk(KERN_ERR DRV_NAME (%s): init shared queue failed\n,
diff -purN a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
--- a/include/scsi/scsi_host.h  2007-01-23 14:40:29.0 -0800
+++ b/include/scsi/scsi_host.h  2007-01-23 14:57:04.0 -0800
@@ -508,6 +508,9 @@ struct Scsi_Host {
spinlock_t  default_lock;
spinlock_t  *host_lock;
 
+   spinlock_t  __req_q_lock;
+   spinlock_t  *req_q_lock;/* protect shared block queue tag */
+
struct mutexscan_mutex;/* serialize scanning activity */
 
struct list_headeh_cmd_q;



-
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

[repost][PATCH 2/8] stex: fix controller_info command handling

[Ed Lin]

This command needs information from both firmware and driver. First copy
information from firmware to buffer, then fill in driver information.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 91d484c..ea0d824 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -507,6 +507,7 @@ static void stex_controller_info(struct 
size_t count = sizeof(struct st_frame);
 
p = hba-copy_buffer;
+   stex_internal_copy(ccb-cmd, p, count, ccb-sg_count, ST_FROM_CMD);
memset(p-base, 0, sizeof(u32)*6);
*(unsigned long *)(p-base) = pci_resource_start(hba-pdev, 0);
p-rom_addr = 0;


-
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

[repost][PATCH 6/8] stex: add new device type support

[Ed Lin]

Add support for st_vsc1 type device (st_vsc is ok because it does not
require extra buffer).

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 0fd115c..bfd7983 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -121,7 +121,8 @@ enum {
 
st_shasta   = 0,
st_vsc  = 1,
-   st_yosemite = 2,
+   st_vsc1 = 2,
+   st_yosemite = 3,
 
PASSTHRU_REQ_TYPE   = 0x0001,
PASSTHRU_REQ_NO_WAKEUP  = 0x0100,
@@ -151,6 +152,8 @@ enum {
MGT_CMD_SIGNATURE   = 0xba,
 
INQUIRY_EVPD= 0x01,
+
+   ST_ADDITIONAL_MEM   = 0x20,
 };
 
 /* SCSI inquiry data */
@@ -212,7 +215,9 @@ struct handshake_frame {
__le32 partner_ver_minor;
__le32 partner_ver_oem;
__le32 partner_ver_build;
-   u32 reserved1[4];
+   __le32 extra_offset;/* NEW */
+   __le32 extra_size;  /* NEW */
+   u32 reserved1[2];
 };
 
 struct req_msg {
@@ -303,6 +308,7 @@ struct st_hba {
void __iomem *mmio_base;/* iomapped PCI memory space */
void *dma_mem;
dma_addr_t dma_handle;
+   size_t dma_size;
 
struct Scsi_Host *host;
struct pci_dev *pdev;
@@ -941,6 +947,11 @@ static int stex_handshake(struct st_hba 
h-status_cnt = cpu_to_le16(MU_STATUS_COUNT);
stex_gettime(h-hosttime);
h-partner_type = HMU_PARTNER_TYPE;
+   if (hba-dma_size  STEX_BUFFER_SIZE) {
+   h-extra_offset = cpu_to_le32(STEX_BUFFER_SIZE);
+   h-extra_size = cpu_to_le32(ST_ADDITIONAL_MEM);
+   } else
+   h-extra_offset = h-extra_size = 0;
 
status_phys = hba-dma_handle + MU_REQ_BUFFER_SIZE;
writel(status_phys, base + IMR0);
@@ -1203,8 +1214,13 @@ stex_probe(struct pci_dev *pdev, const s
goto out_iounmap;
}
 
+   hba-cardtype = (unsigned int) id-driver_data;
+   if (hba-cardtype == st_vsc  (pdev-subsystem_device  0xf) == 0x1)
+   hba-cardtype = st_vsc1;
+   hba-dma_size = (hba-cardtype == st_vsc1) ?
+   (STEX_BUFFER_SIZE + ST_ADDITIONAL_MEM) : (STEX_BUFFER_SIZE);
hba-dma_mem = dma_alloc_coherent(pdev-dev,
-   STEX_BUFFER_SIZE, hba-dma_handle, GFP_KERNEL);
+   hba-dma_size, hba-dma_handle, GFP_KERNEL);
if (!hba-dma_mem) {
err = -ENOMEM;
printk(KERN_ERR DRV_NAME (%s): dma mem alloc failed\n,
@@ -1217,8 +1233,6 @@ stex_probe(struct pci_dev *pdev, const s
hba-copy_buffer = hba-dma_mem + MU_BUFFER_SIZE;
hba-mu_status = MU_STATE_STARTING;
 
-   hba-cardtype = (unsigned int) id-driver_data;
-
/* firmware uses id/lun pair for a logical drive, but lun would be
   always 0 if CONFIG_SCSI_MULTI_LUN not configured, so we use
   channel to map lun here */
@@ -1266,7 +1280,7 @@ stex_probe(struct pci_dev *pdev, const s
 out_free_irq:
free_irq(pdev-irq, hba);
 out_pci_free:
-   dma_free_coherent(pdev-dev, STEX_BUFFER_SIZE,
+   dma_free_coherent(pdev-dev, hba-dma_size,
  hba-dma_mem, hba-dma_handle);
 out_iounmap:
iounmap(hba-mmio_base);
@@ -1327,7 +1341,7 @@ static void stex_hba_free(struct st_hba 
 
pci_release_regions(hba-pdev);
 
-   dma_free_coherent(hba-pdev-dev, STEX_BUFFER_SIZE,
+   dma_free_coherent(hba-pdev-dev, hba-dma_size,
  hba-dma_mem, hba-dma_handle);
 }
 


-
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

[repost][PATCH 4/8] stex: adjust default queue length

[Ed Lin]

Firmware of new version may adjust default queue length. It is
backward compatible.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 92dbac0..a20cbd9 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -78,6 +78,7 @@ enum {
 
MU_MAX_DELAY_TIME   = 24,
MU_HANDSHAKE_SIGNATURE  = 0x5555,
+   MU_HANDSHAKE_SIGNATURE_HALF = 0x5a5a,
HMU_PARTNER_TYPE= 2,
 
/* firmware returned values */
@@ -902,6 +903,7 @@ static int stex_handshake(struct st_hba 
void __iomem *base = hba-mmio_base;
struct handshake_frame *h;
dma_addr_t status_phys;
+   u32 data;
int i;
 
if (readl(base + OMR0) != MU_HANDSHAKE_SIGNATURE) {
@@ -923,6 +925,13 @@ static int stex_handshake(struct st_hba 
 
udelay(10);
 
+   data = readl(base + OMR1);
+   if ((data  0x) == MU_HANDSHAKE_SIGNATURE_HALF) {
+   data = 0x;
+   if (hba-host-can_queue  data)
+   hba-host-can_queue = data;
+   }
+
h = (struct handshake_frame *)(hba-dma_mem + MU_REQ_BUFFER_SIZE);
h-rb_phy = cpu_to_le32(hba-dma_handle);
h-rb_phy_hi = cpu_to_le32((hba-dma_handle  16)  16);
@@ -1234,7 +1243,7 @@ stex_probe(struct pci_dev *pdev, const s
if (err)
goto out_free_irq;
 
-   err = scsi_init_shared_tag_map(host, ST_CAN_QUEUE);
+   err = scsi_init_shared_tag_map(host, host-can_queue);
if (err) {
printk(KERN_ERR DRV_NAME (%s): init shared queue failed\n,
pci_name(pdev));


-
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

[repost][PATCH 3/8] stex: add value check in hard reset routine

[Ed Lin]

During hard reset, an all-1 value from PCI_COMMAND should be invalid.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index ea0d824..92dbac0 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -1041,7 +1041,7 @@ static void stex_hard_reset(struct st_hb
 
for (i = 0; i  MU_MAX_DELAY_TIME; i++) {
pci_read_config_word(hba-pdev, PCI_COMMAND, pci_cmd);
-   if (pci_cmd  PCI_COMMAND_MASTER)
+   if (pci_cmd != 0x  (pci_cmd  PCI_COMMAND_MASTER))
break;
msleep(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

[repost][PATCH 1/8] stex: fix biosparam calculation

[Ed Lin]

Fix biosparam calculation.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 185c270..91d484c 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -1100,18 +1100,18 @@ static int stex_reset(struct scsi_cmnd *
 static int stex_biosparam(struct scsi_device *sdev,
struct block_device *bdev, sector_t capacity, int geom[])
 {
-   int heads = 255, sectors = 63, cylinders;
+   int heads = 255, sectors = 63;
 
if (capacity  0x20) {
heads = 64;
sectors = 32;
}
 
-   cylinders = sector_div(capacity, heads * sectors);
+   sector_div(capacity, heads * sectors);
 
geom[0] = heads;
geom[1] = sectors;
-   geom[2] = cylinders;
+   geom[2] = capacity;
 
return 0;
 }


-
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

[repost][PATCH 5/8] stex: update device id info

[Ed Lin]

- add comments for various devices
- remove unused device ids(0xf350, 0x4301, 0x8301, 0x8302)
- add new device id(0xe350)
- fix vendor id of st_vsc
- modify Kconfig help info

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 1b4bfaa..6956909 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -982,8 +982,13 @@ config SCSI_STEX
tristate Promise SuperTrak EX Series support
depends on PCI  SCSI
---help---
- This driver supports Promise SuperTrak EX8350/8300/16350/16300
- Storage controllers.
+ This driver supports Promise SuperTrak EX series storage controllers.
+
+ Promise provides Linux RAID configuration utility for these
+ controllers. Please visit http://www.promise.com to download.
+
+ To compile this driver as a module, choose M here: the
+ module will be called stex.
 
 config SCSI_SYM53C8XX_2
tristate SYM53C8XX Version 2 SCSI support
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index a20cbd9..0fd115c 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -1356,15 +1356,32 @@ static void stex_shutdown(struct pci_dev
 }
 
 static struct pci_device_id stex_pci_tbl[] = {
-   { 0x105a, 0x8350, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_shasta },
-   { 0x105a, 0xc350, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_shasta },
-   { 0x105a, 0xf350, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_shasta },
-   { 0x105a, 0x4301, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_shasta },
-   { 0x105a, 0x4302, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_shasta },
-   { 0x105a, 0x8301, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_shasta },
-   { 0x105a, 0x8302, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_shasta },
-   { 0x1725, 0x7250, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_vsc },
-   { 0x105a, 0x8650, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_yosemite },
+   /* st_shasta */
+   { 0x105a, 0x8350, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+   st_shasta }, /* SuperTrak EX8350/8300/16350/16300 */
+   { 0x105a, 0xc350, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+   st_shasta }, /* SuperTrak EX12350 */
+   { 0x105a, 0x4302, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+   st_shasta }, /* SuperTrak EX4350 */
+   { 0x105a, 0xe350, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+   st_shasta }, /* SuperTrak EX24350 */
+
+   /* st_vsc */
+   { 0x105a, 0x7250, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_vsc },
+
+   /* st_yosemite */
+   { 0x105a, 0x8650, PCI_ANY_ID, 0x4600, 0, 0,
+   st_yosemite }, /* SuperTrak EX4650 */
+   { 0x105a, 0x8650, PCI_ANY_ID, 0x4610, 0, 0,
+   st_yosemite }, /* SuperTrak EX4650o */
+   { 0x105a, 0x8650, PCI_ANY_ID, 0x8600, 0, 0,
+   st_yosemite }, /* SuperTrak EX8650EL */
+   { 0x105a, 0x8650, PCI_ANY_ID, 0x8601, 0, 0,
+   st_yosemite }, /* SuperTrak EX8650 */
+   { 0x105a, 0x8650, PCI_ANY_ID, 0x8602, 0, 0,
+   st_yosemite }, /* SuperTrak EX8654 */
+   { 0x105a, 0x8650, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+   st_yosemite }, /* generic st_yosemite */
{ } /* terminate list */
 };
 MODULE_DEVICE_TABLE(pci, stex_pci_tbl);


-
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

[repost][PATCH 8/8] stex: version update

[Ed Lin]

Update version to 3.1.0.1

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 7edbcc9..ba6bcda 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -11,8 +11,6 @@
  * Written By:
  * Ed Lin [EMAIL PROTECTED]
  *
- * Version: 3.0.0.1
- *
  */
 
 #include linux/init.h
@@ -37,9 +35,9 @@ #include scsi/scsi_host.h
 #include scsi/scsi_tcq.h
 
 #define DRV_NAME stex
-#define ST_DRIVER_VERSION 3.0.0.1
+#define ST_DRIVER_VERSION 3.1.0.1
 #define ST_VER_MAJOR   3
-#define ST_VER_MINOR   0
+#define ST_VER_MINOR   1
 #define ST_OEM 0
 #define ST_BUILD_VER   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

[repost][PATCH 7/8] stex: change wait loop code

[Ed Lin]

The original wait loop may be much longer than intended time.
Use more accurate timer_after for it. Also adjust wait value to
avoid unnecessary long waiting.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index bfd7983..7edbcc9 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -76,9 +76,10 @@ enum {
MU_STATE_STARTED= 4,
MU_STATE_RESETTING  = 5,
 
-   MU_MAX_DELAY_TIME   = 24,
+   MU_MAX_DELAY= 120,
MU_HANDSHAKE_SIGNATURE  = 0x5555,
MU_HANDSHAKE_SIGNATURE_HALF = 0x5a5a,
+   MU_HARD_RESET_WAIT  = 3,
HMU_PARTNER_TYPE= 2,
 
/* firmware returned values */
@@ -910,23 +911,22 @@ static int stex_handshake(struct st_hba 
struct handshake_frame *h;
dma_addr_t status_phys;
u32 data;
-   int i;
+   unsigned long before;
 
if (readl(base + OMR0) != MU_HANDSHAKE_SIGNATURE) {
writel(MU_INBOUND_DOORBELL_HANDSHAKE, base + IDBL);
readl(base + IDBL);
-   for (i = 0; readl(base + OMR0) != MU_HANDSHAKE_SIGNATURE
-i  MU_MAX_DELAY_TIME; i++) {
+   before = jiffies;
+   while (readl(base + OMR0) != MU_HANDSHAKE_SIGNATURE) {
+   if (time_after(jiffies, before + MU_MAX_DELAY * HZ)) {
+   printk(KERN_ERR DRV_NAME
+   (%s): no handshake signature\n,
+   pci_name(hba-pdev));
+   return -1;
+   }
rmb();
msleep(1);
}
-
-   if (i == MU_MAX_DELAY_TIME) {
-   printk(KERN_ERR DRV_NAME
-   (%s): no handshake signature\n,
-   pci_name(hba-pdev));
-   return -1;
-   }
}
 
udelay(10);
@@ -965,19 +965,18 @@ static int stex_handshake(struct st_hba 
readl(base + IDBL); /* flush */
 
udelay(10);
-   for (i = 0; readl(base + OMR0) != MU_HANDSHAKE_SIGNATURE
-i  MU_MAX_DELAY_TIME; i++) {
+   before = jiffies;
+   while (readl(base + OMR0) != MU_HANDSHAKE_SIGNATURE) {
+   if (time_after(jiffies, before + MU_MAX_DELAY * HZ)) {
+   printk(KERN_ERR DRV_NAME
+   (%s): no signature after handshake frame\n,
+   pci_name(hba-pdev));
+   return -1;
+   }
rmb();
msleep(1);
}
 
-   if (i == MU_MAX_DELAY_TIME) {
-   printk(KERN_ERR DRV_NAME
-   (%s): no signature after handshake frame\n,
-   pci_name(hba-pdev));
-   return -1;
-   }
-
writel(0, base + IMR0);
readl(base + IMR0);
writel(0, base + OMR0);
@@ -1059,7 +1058,7 @@ static void stex_hard_reset(struct st_hb
pci_bctl = ~PCI_BRIDGE_CTL_BUS_RESET;
pci_write_config_byte(bus-self, PCI_BRIDGE_CONTROL, pci_bctl);
 
-   for (i = 0; i  MU_MAX_DELAY_TIME; i++) {
+   for (i = 0; i  MU_HARD_RESET_WAIT; i++) {
pci_read_config_word(hba-pdev, PCI_COMMAND, pci_cmd);
if (pci_cmd != 0x  (pci_cmd  PCI_COMMAND_MASTER))
break;


-
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/8] stex: update device id info

[Ed Lin]

Update pci device id and Kconfig help information.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 1301d52..fb55373 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -968,8 +968,16 @@ config SCSI_STEX
tristate Promise SuperTrak EX Series support
depends on PCI  SCSI
---help---
- This driver supports Promise SuperTrak EX8350/8300/16350/16300
- Storage controllers.
+ This driver supports Promise SuperTrak EX series storage controllers.
+ These include SuperTrak EX8350, EX8300, EX16350, EX16300, EX12350,
+ EX4350, EX24350; SuperTrak EX4650, EX4650o, EX8650EL, EX8650, EX8654;
+ and VSC7250 series.
+
+ Promise provides Linux RAID configuration utility for these
+ controllers. Please visit http://www.promise.com to download.
+
+ To compile this driver as a module, choose M here: the
+ module will be called stex.
 
 config SCSI_SYM53C8XX_2
tristate SYM53C8XX Version 2 SCSI support
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index a20cbd9..c4ee038 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -120,8 +120,9 @@ enum {
ST_MAX_LUN_PER_TARGET   = 16,
 
st_shasta   = 0,
-   st_vsc  = 1,
-   st_yosemite = 2,
+   st_vsc0 = 1,
+   st_vsc1 = 2,
+   st_yosemite = 3,
 
PASSTHRU_REQ_TYPE   = 0x0001,
PASSTHRU_REQ_NO_WAKEUP  = 0x0100,
@@ -1356,15 +1357,41 @@ static void stex_shutdown(struct pci_dev
 }
 
 static struct pci_device_id stex_pci_tbl[] = {
-   { 0x105a, 0x8350, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_shasta },
-   { 0x105a, 0xc350, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_shasta },
-   { 0x105a, 0xf350, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_shasta },
-   { 0x105a, 0x4301, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_shasta },
-   { 0x105a, 0x4302, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_shasta },
-   { 0x105a, 0x8301, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_shasta },
-   { 0x105a, 0x8302, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_shasta },
-   { 0x1725, 0x7250, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_vsc },
-   { 0x105a, 0x8650, PCI_ANY_ID, PCI_ANY_ID, 0, 0, st_yosemite },
+   /* st_shasta */
+   { 0x105a, 0x8350, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+   st_shasta }, /* SuperTrak EX8350/8300/16350/16300 */
+   { 0x105a, 0xc350, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+   st_shasta }, /* SuperTrak EX12350 */
+   { 0x105a, 0x4302, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+   st_shasta }, /* SuperTrak EX4350 */
+   { 0x105a, 0xe350, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+   st_shasta }, /* SuperTrak EX24350 */
+
+   /* st_vsc */
+   { 0x105a, 0x7250, 0x105a, 0x1000, 0, 0, st_vsc0 },
+   { 0x105a, 0x7250, 0x105a, 0x2500, 0, 0, st_vsc0 },
+   { 0x105a, 0x7250, 0x105a, 0x2510, 0, 0, st_vsc0 },
+   { 0x105a, 0x7250, 0x105a, 0x2520, 0, 0, st_vsc0 },
+   { 0x105a, 0x7250, 0x105a, 0x2530, 0, 0, st_vsc0 },
+   { 0x105a, 0x7250, 0x105a, 0x1001, 0, 0, st_vsc1 },
+   { 0x105a, 0x7250, 0x105a, 0x2501, 0, 0, st_vsc1 },
+   { 0x105a, 0x7250, 0x105a, 0x2511, 0, 0, st_vsc1 },
+   { 0x105a, 0x7250, 0x105a, 0x2521, 0, 0, st_vsc1 },
+   { 0x105a, 0x7250, 0x105a, 0x2531, 0, 0, st_vsc1 },
+
+   /* st_yosemite */
+   { 0x105a, 0x8650, PCI_ANY_ID, 0x4600, 0, 0,
+   st_yosemite }, /* SuperTrak EX4650 */
+   { 0x105a, 0x8650, PCI_ANY_ID, 0x4610, 0, 0,
+   st_yosemite }, /* SuperTrak EX4650o */
+   { 0x105a, 0x8650, PCI_ANY_ID, 0x8600, 0, 0,
+   st_yosemite }, /* SuperTrak EX8650EL */
+   { 0x105a, 0x8650, PCI_ANY_ID, 0x8601, 0, 0,
+   st_yosemite }, /* SuperTrak EX8650 */
+   { 0x105a, 0x8650, PCI_ANY_ID, 0x8602, 0, 0,
+   st_yosemite }, /* SuperTrak EX8654 */
+   { 0x105a, 0x8650, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+   st_yosemite }, /* generic st_yosemite */
{ } /* terminate list */
 };
 MODULE_DEVICE_TABLE(pci, stex_pci_tbl);


-
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/8] stex: adjust default queue length

[Ed Lin]

Firmware of new version may adjust default queue length. It is
backward compatible.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 92dbac0..a20cbd9 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -78,6 +78,7 @@ enum {
 
MU_MAX_DELAY_TIME   = 24,
MU_HANDSHAKE_SIGNATURE  = 0x5555,
+   MU_HANDSHAKE_SIGNATURE_HALF = 0x5a5a,
HMU_PARTNER_TYPE= 2,
 
/* firmware returned values */
@@ -902,6 +903,7 @@ static int stex_handshake(struct st_hba 
void __iomem *base = hba-mmio_base;
struct handshake_frame *h;
dma_addr_t status_phys;
+   u32 data;
int i;
 
if (readl(base + OMR0) != MU_HANDSHAKE_SIGNATURE) {
@@ -923,6 +925,13 @@ static int stex_handshake(struct st_hba 
 
udelay(10);
 
+   data = readl(base + OMR1);
+   if ((data  0x) == MU_HANDSHAKE_SIGNATURE_HALF) {
+   data = 0x;
+   if (hba-host-can_queue  data)
+   hba-host-can_queue = data;
+   }
+
h = (struct handshake_frame *)(hba-dma_mem + MU_REQ_BUFFER_SIZE);
h-rb_phy = cpu_to_le32(hba-dma_handle);
h-rb_phy_hi = cpu_to_le32((hba-dma_handle  16)  16);
@@ -1234,7 +1243,7 @@ stex_probe(struct pci_dev *pdev, const s
if (err)
goto out_free_irq;
 
-   err = scsi_init_shared_tag_map(host, ST_CAN_QUEUE);
+   err = scsi_init_shared_tag_map(host, host-can_queue);
if (err) {
printk(KERN_ERR DRV_NAME (%s): init shared queue failed\n,
pci_name(pdev));


-
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/8] stex: version update

[Ed Lin]

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index ce7edf5..9cbc047 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -11,8 +11,6 @@
  * Written By:
  * Ed Lin [EMAIL PROTECTED]
  *
- * Version: 3.0.0.1
- *
  */
 
 #include linux/init.h
@@ -37,9 +35,9 @@ #include scsi/scsi_host.h
 #include scsi/scsi_tcq.h
 
 #define DRV_NAME stex
-#define ST_DRIVER_VERSION 3.0.0.1
+#define ST_DRIVER_VERSION 3.1.0.1
 #define ST_VER_MAJOR   3
-#define ST_VER_MINOR   0
+#define ST_VER_MINOR   1
 #define ST_OEM 0
 #define ST_BUILD_VER   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

[PATCH 1/8] stex: fix biosparam calculation

[Ed Lin]

Fix biosparam calculation.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 185c270..91d484c 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -1100,18 +1100,18 @@ static int stex_reset(struct scsi_cmnd *
 static int stex_biosparam(struct scsi_device *sdev,
struct block_device *bdev, sector_t capacity, int geom[])
 {
-   int heads = 255, sectors = 63, cylinders;
+   int heads = 255, sectors = 63;
 
if (capacity  0x20) {
heads = 64;
sectors = 32;
}
 
-   cylinders = sector_div(capacity, heads * sectors);
+   sector_div(capacity, heads * sectors);
 
geom[0] = heads;
geom[1] = sectors;
-   geom[2] = cylinders;
+   geom[2] = capacity;
 
return 0;
 }


-
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/8] stex: change wait loop code

[Ed Lin]

The original wait loop may be much longer than intended time.
Use more accurate timer_after for it. Also adjust wait value to
avoid unnecessary long waiting.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 9cbc047..df35e91 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -74,9 +74,10 @@ enum {
MU_STATE_STARTED= 4,
MU_STATE_RESETTING  = 5,
 
-   MU_MAX_DELAY_TIME   = 24,
+   MU_MAX_DELAY= 120,
MU_HANDSHAKE_SIGNATURE  = 0x5555,
MU_HANDSHAKE_SIGNATURE_HALF = 0x5a5a,
+   MU_HARD_RESET_WAIT  = 3,
HMU_PARTNER_TYPE= 2,
 
/* firmware returned values */
@@ -908,23 +909,22 @@ static int stex_handshake(struct st_hba 
struct handshake_frame *h;
dma_addr_t status_phys;
u32 data;
-   int i;
+   unsigned long before;
 
if (readl(base + OMR0) != MU_HANDSHAKE_SIGNATURE) {
writel(MU_INBOUND_DOORBELL_HANDSHAKE, base + IDBL);
readl(base + IDBL);
-   for (i = 0; readl(base + OMR0) != MU_HANDSHAKE_SIGNATURE
-i  MU_MAX_DELAY_TIME; i++) {
+   before = jiffies;
+   while (readl(base + OMR0) != MU_HANDSHAKE_SIGNATURE) {
+   if (time_after(jiffies, before + MU_MAX_DELAY * HZ)) {
+   printk(KERN_ERR DRV_NAME
+   (%s): no handshake signature\n,
+   pci_name(hba-pdev));
+   return -1;
+   }
rmb();
msleep(1);
}
-
-   if (i == MU_MAX_DELAY_TIME) {
-   printk(KERN_ERR DRV_NAME
-   (%s): no handshake signature\n,
-   pci_name(hba-pdev));
-   return -1;
-   }
}
 
udelay(10);
@@ -963,19 +963,18 @@ static int stex_handshake(struct st_hba 
readl(base + IDBL); /* flush */
 
udelay(10);
-   for (i = 0; readl(base + OMR0) != MU_HANDSHAKE_SIGNATURE
-i  MU_MAX_DELAY_TIME; i++) {
+   before = jiffies;
+   while (readl(base + OMR0) != MU_HANDSHAKE_SIGNATURE) {
+   if (time_after(jiffies, before + MU_MAX_DELAY * HZ)) {
+   printk(KERN_ERR DRV_NAME
+   (%s): no signature after handshake frame\n,
+   pci_name(hba-pdev));
+   return -1;
+   }
rmb();
msleep(1);
}
 
-   if (i == MU_MAX_DELAY_TIME) {
-   printk(KERN_ERR DRV_NAME
-   (%s): no signature after handshake frame\n,
-   pci_name(hba-pdev));
-   return -1;
-   }
-
writel(0, base + IMR0);
readl(base + IMR0);
writel(0, base + OMR0);
@@ -1057,7 +1056,7 @@ static void stex_hard_reset(struct st_hb
pci_bctl = ~PCI_BRIDGE_CTL_BUS_RESET;
pci_write_config_byte(bus-self, PCI_BRIDGE_CONTROL, pci_bctl);
 
-   for (i = 0; i  MU_MAX_DELAY_TIME; i++) {
+   for (i = 0; i  MU_HARD_RESET_WAIT; i++) {
pci_read_config_word(hba-pdev, PCI_COMMAND, pci_cmd);
if (pci_cmd != 0x  (pci_cmd  PCI_COMMAND_MASTER))
break;


-
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/8] stex: add new device type support

[Ed Lin]

Add support for st_vsc1 type device (st_vsc0 is ok because it does not
require extra buffer).

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index c4ee038..ce7edf5 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -152,6 +152,8 @@ enum {
MGT_CMD_SIGNATURE   = 0xba,
 
INQUIRY_EVPD= 0x01,
+
+   ST_ADDITIONAL_MEM   = 0x20,
 };
 
 /* SCSI inquiry data */
@@ -213,7 +215,9 @@ struct handshake_frame {
__le32 partner_ver_minor;
__le32 partner_ver_oem;
__le32 partner_ver_build;
-   u32 reserved1[4];
+   __le32 extra_offset;/* NEW */
+   __le32 extra_size;  /* NEW */
+   u32 reserved1[2];
 };
 
 struct req_msg {
@@ -304,6 +308,7 @@ struct st_hba {
void __iomem *mmio_base;/* iomapped PCI memory space */
void *dma_mem;
dma_addr_t dma_handle;
+   size_t dma_size;
 
struct Scsi_Host *host;
struct pci_dev *pdev;
@@ -942,6 +947,11 @@ static int stex_handshake(struct st_hba 
h-status_cnt = cpu_to_le16(MU_STATUS_COUNT);
stex_gettime(h-hosttime);
h-partner_type = HMU_PARTNER_TYPE;
+   if (hba-dma_size  STEX_BUFFER_SIZE) {
+   h-extra_offset = cpu_to_le32(STEX_BUFFER_SIZE);
+   h-extra_size = cpu_to_le32(ST_ADDITIONAL_MEM);
+   } else
+   h-extra_offset = h-extra_size = 0;
 
status_phys = hba-dma_handle + MU_REQ_BUFFER_SIZE;
writel(status_phys, base + IMR0);
@@ -1204,8 +1214,11 @@ stex_probe(struct pci_dev *pdev, const s
goto out_iounmap;
}
 
+   hba-cardtype = (unsigned int) id-driver_data;
+   hba-dma_size = (hba-cardtype == st_vsc1) ?
+   (STEX_BUFFER_SIZE + ST_ADDITIONAL_MEM) : (STEX_BUFFER_SIZE);
hba-dma_mem = dma_alloc_coherent(pdev-dev,
-   STEX_BUFFER_SIZE, hba-dma_handle, GFP_KERNEL);
+   hba-dma_size, hba-dma_handle, GFP_KERNEL);
if (!hba-dma_mem) {
err = -ENOMEM;
printk(KERN_ERR DRV_NAME (%s): dma mem alloc failed\n,
@@ -1218,8 +1231,6 @@ stex_probe(struct pci_dev *pdev, const s
hba-copy_buffer = hba-dma_mem + MU_BUFFER_SIZE;
hba-mu_status = MU_STATE_STARTING;
 
-   hba-cardtype = (unsigned int) id-driver_data;
-
/* firmware uses id/lun pair for a logical drive, but lun would be
   always 0 if CONFIG_SCSI_MULTI_LUN not configured, so we use
   channel to map lun here */
@@ -1267,7 +1278,7 @@ stex_probe(struct pci_dev *pdev, const s
 out_free_irq:
free_irq(pdev-irq, hba);
 out_pci_free:
-   dma_free_coherent(pdev-dev, STEX_BUFFER_SIZE,
+   dma_free_coherent(pdev-dev, hba-dma_size,
  hba-dma_mem, hba-dma_handle);
 out_iounmap:
iounmap(hba-mmio_base);
@@ -1328,7 +1339,7 @@ static void stex_hba_free(struct st_hba 
 
pci_release_regions(hba-pdev);
 
-   dma_free_coherent(hba-pdev-dev, STEX_BUFFER_SIZE,
+   dma_free_coherent(hba-pdev-dev, hba-dma_size,
  hba-dma_mem, hba-dma_handle);
 }
 


-
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/8] stex: fix controller_info command handling

[Ed Lin]

This command needs information from both firmware and driver. First copy
information from firmware to buffer, then fill in driver information.

Signed-off-by: Ed Lin [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 91d484c..ea0d824 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -507,6 +507,7 @@ static void stex_controller_info(struct 
size_t count = sizeof(struct st_frame);
 
p = hba-copy_buffer;
+   stex_internal_copy(ccb-cmd, p, count, ccb-sg_count, ST_FROM_CMD);
memset(p-base, 0, sizeof(u32)*6);
*(unsigned long *)(p-base) = pci_resource_start(hba-pdev, 0);
p-rom_addr = 0;


-
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