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

Reply via email to