scsi: 64-bit LUN support
Subsystems (23)
cover scsi: 64-bit LUN support
This patchset updates the SCSI midlayer to use 64-bit LUNs internally. It eliminates the need to limit the number of LUNs artificially to avoid aliasing issues; the SCSI midlayer can now accept any LUN presented to it.
The LLDD specific settings for 'max_lun' have been left untouched; it should be raised to '~0' if the HBA supports 64-bit LUNs internally. However, it is up to the driver maintainer to raise that limit.
Hannes Reinecke (4):
scsi_scan: Fixup scsilun_to_int()
scsi: use 64-bit LUNs
scsi: use 64-bit value for 'max_luns'
scsi: Remove CONFIG_SCSI_MULTI_LUN
drivers/ata/libata-scsi.c | 2 +- drivers/ata/libata.h | 2 +- drivers/message/fusion/mptscsih.c | 2 +- drivers/message/i2o/i2o_scsi.c | 6 +- drivers/scsi/Kconfig | 14 ------ drivers/scsi/NCR5380.c | 2 +- drivers/scsi/aacraid/linit.c | 2 +- drivers/scsi/aha152x.c | 6 +- drivers/scsi/aic7xxx/aic79xx.h | 2 +- drivers/scsi/aic7xxx/aic79xx_osm.c | 6 +- drivers/scsi/aic7xxx/aic7xxx_osm.c | 11 +++-- drivers/scsi/aic7xxx_old.c | 21 +++++---- drivers/scsi/aic7xxx_old/aic7xxx_proc.c | 2 +- drivers/scsi/arcmsr/arcmsr_hba.c | 8 ++-- drivers/scsi/csiostor/csio_scsi.c | 24 +++++----- drivers/scsi/cxgbi/libcxgbi.c | 2 +- drivers/scsi/cxgbi/libcxgbi.h | 2 +- drivers/scsi/dc395x.c | 52 ++++++++++------------ drivers/scsi/eata.c | 4 +- drivers/scsi/fnic/fnic_scsi.c | 6 +- drivers/scsi/hpsa.c | 2 +- drivers/scsi/ibmvscsi/ibmvfc.c | 4 +- drivers/scsi/libiscsi.c | 7 ++- drivers/scsi/libsas/sas_scsi_host.c | 11 +++-- drivers/scsi/lpfc/lpfc_attr.c | 10 ++++- drivers/scsi/lpfc/lpfc_scsi.c | 44 +++++++++--------- drivers/scsi/megaraid.c | 8 ++-- drivers/scsi/megaraid/mega_common.h | 2 +- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 4 +- drivers/scsi/ncr53c8xx.h | 4 -- drivers/scsi/pmcraid.c | 2 +- drivers/scsi/qla2xxx/qla_def.h | 4 +- drivers/scsi/qla2xxx/qla_gbl.h | 12 +++--- drivers/scsi/qla2xxx/qla_isr.c | 4 +- drivers/scsi/qla2xxx/qla_mbx.c | 12 +++--- drivers/scsi/qla2xxx/qla_os.c | 41 +++++++++-------- drivers/scsi/qla4xxx/ql4_glbl.h | 4 +- drivers/scsi/qla4xxx/ql4_iocb.c | 2 +- drivers/scsi/qla4xxx/ql4_isr.c | 22 +++++----- drivers/scsi/qla4xxx/ql4_mbx.c | 8 ++-- drivers/scsi/qla4xxx/ql4_os.c | 18 ++++---- drivers/scsi/scsi.c | 8 ++-- drivers/scsi/scsi_debug.c | 15 +++--- drivers/scsi/scsi_priv.h | 2 +- drivers/scsi/scsi_proc.c | 2 +- drivers/scsi/scsi_scan.c | 73 +++++++++++-------------------- drivers/scsi/scsi_sysfs.c | 14 +++--- drivers/scsi/scsi_transport_fc.c | 4 +- drivers/scsi/scsi_transport_iscsi.c | 4 +- drivers/scsi/scsi_transport_sas.c | 2 +- drivers/scsi/sg.c | 4 +- drivers/scsi/sym53c8xx_2/sym_glue.c | 2 +- drivers/scsi/sym53c8xx_2/sym_hipd.h | 2 +- drivers/target/loopback/tcm_loop.c | 4 +- drivers/target/target_core_pscsi.c | 12 +++--- include/linux/moduleparam.h | 5 ++ include/scsi/scsi.h | 2 +- include/scsi/scsi_device.h | 22 +++++----- include/scsi/scsi_host.h | 6 +- include/scsi/scsi_transport.h | 2 +- kernel/params.c | 1 + 61 files changed, 281 insertions(+), 306 deletions(-)
Signature · 1 line
1.7.4.2
PATCH 1/4 scsi_scan: Fixup scsilun_to_int()
scsilun_to_int() has an error which prevents it from generating correct LUN numbers for 64bit values.
Also we should remove the misleading comment about portions of the LUN being ignored; the initiator should treat the LUN as an opaque value.
--- drivers/scsi/scsi_scan.c | 9 +++------ 1 files changed, 3 insertions(+), 6 deletions(-)
drivers/scsi/scsi_scan.c +3 -6
@@ -1228,14 +1228,11 @@ static void scsi_sequential_lun_scan(struct scsi_target *starget,* truncation before using this function. * * Notes: -* The struct scsi_lun is assumed to be four levels, with each level -* effectively containing a SCSI byte-ordered (big endian) short; the -* addressing bits of each level are ignored (the highest two bits). * For a description of the LUN format, post SCSI-3 see the SCSI * Architecture Model, for SCSI-3 see the SCSI Controller Commands. * -* Given a struct scsi_lun of: 0a 04 0b 03 00 00 00 00, this function returns -* the integer: 0x0b030a04 +* Given a struct scsi_lun of: 0a 04 0b 03 00 00 00 00, this function +* returns the integer: 0x0b030a04 **/ int scsilun_to_int (struct scsi_lun *scsilun) {
@@ -1244,7 +1241,7 @@ int scsilun_to_int(struct scsi_lun *scsilun) lun =0 ;for (i =0 ; i <sizeof (lun); i +=2 ) - lun = lun | (((scsilun->scsi_lun[i] <<8 ) | + lun = lun | (((scsilun->scsi_lun[i] << ((i +1 ) *8 )) | scsilun->scsi_lun[i +1 ]) << (i *8 ));return lun; }
Signature · 1 line
1.7.4.2
PATCH 2/4 scsi: use 64-bit LUNs
In reply to Hannes ReineckeThe SCSI standard uses a 64-bit value for LUNs, and large arrays employing large LUN numbers become more and more common. So move the linux SCSI stack to use 64-bit LUN numbers.
--- drivers/ata/libata-scsi.c | 2 +- drivers/ata/libata.h | 2 +- drivers/message/fusion/mptscsih.c | 2 +- drivers/scsi/NCR5380.c | 2 +- drivers/scsi/aacraid/linit.c | 2 +- drivers/scsi/aha152x.c | 6 ++-- drivers/scsi/aic7xxx/aic79xx.h | 2 +- drivers/scsi/aic7xxx/aic79xx_osm.c | 6 ++-- drivers/scsi/aic7xxx/aic7xxx_osm.c | 11 +++--- drivers/scsi/aic7xxx_old.c | 21 ++++++------ drivers/scsi/aic7xxx_old/aic7xxx_proc.c | 2 +- drivers/scsi/arcmsr/arcmsr_hba.c | 8 ++-- drivers/scsi/csiostor/csio_scsi.c | 24 +++++++------- drivers/scsi/dc395x.c | 40 +++++++++++----------- drivers/scsi/eata.c | 2 +- drivers/scsi/fnic/fnic_scsi.c | 6 ++-- drivers/scsi/hpsa.c | 2 +- drivers/scsi/libiscsi.c | 7 ++-- drivers/scsi/libsas/sas_scsi_host.c | 11 +++--- drivers/scsi/lpfc/lpfc_scsi.c | 44 ++++++++++++------------ drivers/scsi/megaraid.c | 6 ++-- drivers/scsi/megaraid/mega_common.h | 2 +- drivers/scsi/pmcraid.c | 2 +- drivers/scsi/qla2xxx/qla_def.h | 4 +- drivers/scsi/qla2xxx/qla_gbl.h | 10 +++--- drivers/scsi/qla2xxx/qla_isr.c | 4 +- drivers/scsi/qla2xxx/qla_mbx.c | 12 +++--- drivers/scsi/qla2xxx/qla_os.c | 35 +++++++++++--------- drivers/scsi/qla4xxx/ql4_glbl.h | 4 +- drivers/scsi/qla4xxx/ql4_iocb.c | 2 +- drivers/scsi/qla4xxx/ql4_isr.c | 22 ++++++------ drivers/scsi/qla4xxx/ql4_mbx.c | 8 ++-- drivers/scsi/qla4xxx/ql4_os.c | 18 +++++----- drivers/scsi/scsi.c | 8 ++-- drivers/scsi/scsi_debug.c | 15 ++++---- drivers/scsi/scsi_priv.h | 2 +- drivers/scsi/scsi_proc.c | 2 +- drivers/scsi/scsi_scan.c | 54 +++++++++++-------------------- drivers/scsi/scsi_sysfs.c | 14 ++++---- drivers/scsi/scsi_transport_fc.c | 4 +- drivers/scsi/scsi_transport_iscsi.c | 4 +- drivers/scsi/scsi_transport_sas.c | 2 +- drivers/scsi/sg.c | 4 +- drivers/scsi/sym53c8xx_2/sym_glue.c | 2 +- drivers/scsi/sym53c8xx_2/sym_hipd.h | 2 +- drivers/target/loopback/tcm_loop.c | 4 +- drivers/target/target_core_pscsi.c | 12 +++--- include/scsi/scsi.h | 2 +- include/scsi/scsi_device.h | 22 ++++++------ include/scsi/scsi_transport.h | 2 +- 50 files changed, 239 insertions(+), 247 deletions(-)
drivers/ata/libata-scsi.c +1 -1
@@ -3886,7 +3886,7 @@ void ata_scsi_hotplug(struct work_struct *work)* Zero. */ int ata_scsi_user_scan (struct Scsi_Host *shost,unsigned int channel, -unsigned int id,unsigned int lun) +unsigned int id,uint64_t lun) {struct ata_port *ap =ata_shost_to_port (shost);unsigned long flags;
drivers/ata/libata.h +1 -1
@@ -147,7 +147,7 @@ extern void ata_schedule_scsi_eh(struct Scsi_Host *shost);extern void ata_scsi_dev_rescan (struct work_struct *work);extern int ata_bus_probe (struct ata_port *ap);extern int ata_scsi_user_scan (struct Scsi_Host *shost,unsigned int channel, -unsigned int id,unsigned int lun); +unsigned int id,uint64_t lun);/* libata-eh.c */
drivers/message/fusion/mptscsih.c +1 -1
@@ -692,7 +692,7 @@ mptscsih_io_done(MPT_ADAPTER *ioc, MPT_FRAME_HDR *mf, MPT_FRAME_HDR *mr)*/ if (scsi_state &MPI_SCSI_STATE_RESPONSE_INFO_VALID && pScsiReply->ResponseInfo) { - printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%d] " + printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%llu] " "FCP_ResponseInfo=%08xh\n", ioc->name, sc->device->host->host_no, sc->device->channel, sc->device->id, sc->device->lun,
drivers/scsi/NCR5380.c +1 -1
@@ -775,7 +775,7 @@ static int __maybe_unused NCR5380_proc_info(struct Scsi_Host *instance,static char *lprint_Scsi_Cmnd (Scsi_Cmnd * cmd,char *pos,char *buffer,int length) { -SPRINTF ("scsi%d : destination target %d, lun %d\n" , cmd->device->host->host_no, cmd->device->id, cmd->device->lun); +SPRINTF ("scsi%d : destination target %d, lun %d\n" , cmd->device->host->host_no, cmd->device->id, (u8 )cmd->device->lun);SPRINTF (" command = " ); pos =lprint_command (cmd->cmnd, pos, buffer, length);return (pos);
drivers/scsi/aacraid/linit.c +1 -1
@@ -551,7 +551,7 @@ static int aac_eh_abort(struct scsi_cmnd* cmd)int count;int ret =FAILED ; -printk (KERN_ERR "%s: Host adapter abort request (%d,%d,%d,%d)\n" , +printk (KERN_ERR "%s: Host adapter abort request (%d,%d,%d,%llu)\n" ,AAC_DRIVERNAME , host->host_no,sdev_channel (dev),sdev_id (dev), dev->lun);switch (cmd->cmnd[0 ]) {
drivers/scsi/aha152x.c +3 -3
@@ -321,7 +321,7 @@ static LIST_HEAD(aha152x_host_list);#define CMDINFO (cmd) \ (cmd) ? ((cmd)->device->host->host_no) : -1, \ (cmd) ? ((cmd)->device->id & 0x0f) : -1, \ - (cmd) ? ((cmd)->device->lun & 0x07) : -1 + (cmd) ? ((u8)(cmd)->device->lun & 0x07) : -1static inline void CMD_INC_RESID (struct scsi_cmnd *cmd,int inc)
@@ -1602,7 +1602,7 @@ static void busfree_run(struct Scsi_Host *shpnt)#if defined(AHA152X_DEBUG )int hostno=DONE_SC ->device->host->host_no;int id=DONE_SC ->device->id &0xf ; -int lun=DONE_SC ->device->lun &0x7 ; +int lun=((u8 )DONE_SC ->device->lun) &0x7 ;#endif Scsi_Cmnd *ptr =DONE_SC ;DONE_SC =NULL ;
@@ -2985,7 +2985,7 @@ static int get_command(char *pos, Scsi_Cmnd * ptr)int i;SPRINTF ("%p: target=%d; lun=%d; cmnd=( " , - ptr, ptr->device->id, ptr->device->lun); + ptr, ptr->device->id, (u8 )ptr->device->lun);for (i =0 ; i <COMMAND_SIZE (ptr->cmnd[0 ]); i++)SPRINTF ("0x%02x " , ptr->cmnd[i]);
drivers/scsi/aic7xxx/aic79xx.h +1 -1
@@ -115,7 +115,7 @@ struct scb_platform_data;#endif #define AHD_BUILD_COL_IDX (target, lun) \ - (((lun) << 4) | target) + ((((u8)lun) << 4) | target)#define AHD_GET_SCB_COL_IDX (ahd, scb) \ ((SCB_GET_LUN(scb) << 4) | SCB_GET_TARGET(ahd, scb))
drivers/scsi/aic7xxx/aic79xx_osm.c +3 -3
@@ -2142,7 +2142,7 @@ ahd_linux_queue_cmd_complete(struct ahd_softc *ahd, struct scsi_cmnd *cmd)if (do_fallback) {printk ("%s: device overrun (status %x) on %d:%d:%d\n" ,ahd_name (ahd), status, cmd->device->channel, - cmd->device->id, cmd->device->lun); + cmd->device->id, (u8 )cmd->device->lun); }ahd_cmd_set_transaction_status (cmd, new_status);
@@ -2258,13 +2258,13 @@ ahd_linux_queue_abort_cmd(struct scsi_cmnd *cmd) disconnected = TRUE;if (ahd_search_qinfifo (ahd, cmd->device->id, cmd->device->channel +'A' , - cmd->device->lun, + cmd->device->lun, pending_scb->hscb->tag,ROLE_INITIATOR ,CAM_REQ_ABORTED ,SEARCH_COMPLETE ) >0 ) {printk ("%s:%d:%d:%d: Cmd aborted from QINFIFO\n" ,ahd_name (ahd), cmd->device->channel, - cmd->device->id, cmd->device->lun); + cmd->device->id, (u8 )cmd->device->lun); retval =SUCCESS ; goto done; }
drivers/scsi/aic7xxx/aic7xxx_osm.c +6 -5
@@ -2125,7 +2125,7 @@ ahc_linux_queue_recovery_cmd(struct scsi_cmnd *cmd, scb_flag flag)*/ printk ("%s:%d:%d:%d: Is not an active device\n" ,ahc_name (ahc), cmd->device->channel, cmd->device->id, - cmd->device->lun); + (u8 )cmd->device->lun); retval =SUCCESS ; goto no_cmd; }
@@ -2133,11 +2133,11 @@ ahc_linux_queue_recovery_cmd(struct scsi_cmnd *cmd, scb_flag flag)if ((dev->flags & (AHC_DEV_Q_BASIC |AHC_DEV_Q_TAGGED )) ==0 &&ahc_search_untagged_queues (ahc, cmd, cmd->device->id, cmd->device->channel +'A' , - cmd->device->lun, + (u8 )cmd->device->lun,CAM_REQ_ABORTED ,SEARCH_COMPLETE ) !=0 ) {printk ("%s:%d:%d:%d: Command found on untagged queue\n" ,ahc_name (ahc), cmd->device->channel, cmd->device->id, - cmd->device->lun); + (u8 )cmd->device->lun); retval =SUCCESS ; goto done; }
@@ -2203,13 +2203,14 @@ ahc_linux_queue_recovery_cmd(struct scsi_cmnd *cmd, scb_flag flag) SEARCH_COMPLETE) > 0) {printk ("%s:%d:%d:%d: Cmd aborted from QINFIFO\n" ,ahc_name (ahc), cmd->device->channel, - cmd->device->id, cmd->device->lun); + cmd->device->id, (u8 )cmd->device->lun); retval =SUCCESS ; goto done; } }else if (ahc_search_qinfifo (ahc, cmd->device->id, cmd->device->channel +'A' , - cmd->device->lun, pending_scb->hscb->tag, + cmd->device->lun, + pending_scb->hscb->tag,ROLE_INITIATOR ,/*status*/ 0 ,SEARCH_COUNT ) >0 ) { disconnected = FALSE;
drivers/scsi/aic7xxx_old.c +11 -10
@@ -1033,8 +1033,8 @@ static struct aic7xxx_syncrate { ((scb->hscb)->target_channel_lun & 0x07)#define CTL_OF_CMD (cmd) ((cmd->device->channel) & 0x01), \ - ((cmd->device->id) & 0x0f), \ - ((cmd->device->lun) & 0x07) + ((cmd->device->id) & 0x0f), \ + (((u8)cmd->device->lun) & 0x07)#define TARGET_INDEX (cmd) ((cmd)->device->id | ((cmd)->device->channel << 3))
@@ -3154,7 +3154,8 @@ aic7xxx_reset_device(struct aic7xxx_host *p, int target, int channel,continue ;if (aic7xxx_verbose & (VERBOSE_ABORT_PROCESS |VERBOSE_RESET_PROCESS ))printk (INFO_LEAD "Cleaning up status information " -"and delayed_scbs.\n" , p->host_no, sd->channel, sd->id, sd->lun); +"and delayed_scbs.\n" , p->host_no, sd->channel, sd->id, + (u8 )sd->lun); aic_dev->flags &= ~BUS_DEVICE_RESET_PENDING ;if ( tag ==SCB_LIST_NULL ) {
@@ -3165,7 +3166,7 @@ aic7xxx_reset_device(struct aic7xxx_host *p, int target, int channel, aic_dev->flags =DEVICE_PRINT_DTR ; aic_dev->temp_q_depth = aic_dev->max_q_depth; } - tcl = (sd->id <<4 ) | (sd->channel <<3 ) | sd->lun; + tcl = (sd->id <<4 ) | (sd->channel <<3 ) | (u8 )sd->lun;if ( (aic7xxx_index_busy_target (p, tcl, FALSE) == tag) || (tag ==SCB_LIST_NULL ) )aic7xxx_index_busy_target (p, tcl,/* unbusy */ TRUE);
@@ -4260,7 +4261,7 @@ aic7xxx_handle_seqint(struct aic7xxx_host *p, unsigned char intstat)memcpy (scb->sense_cmd, &generic_sense[0 ],sizeof (generic_sense)); - scb->sense_cmd[1 ] = (cmd->device->lun <<5 ); + scb->sense_cmd[1 ] = ((u8 )cmd->device->lun <<5 ); scb->sense_cmd[4 ] =SCSI_SENSE_BUFFERSIZE ; scb->sg_list[0].length =
@@ -6284,7 +6285,7 @@ aic7xxx_handle_command_completion_intr(struct aic7xxx_host *p)continue ; }aic7xxx_reset_device (p, scb->cmd->device->id, scb->cmd->device->channel, - scb->cmd->device->lun, scb->hscb->tag); + (u8 )scb->cmd->device->lun, scb->hscb->tag); scb->flags &= ~(SCB_QUEUED_FOR_DONE |SCB_RESET |SCB_ABORT |SCB_QUEUED_ABORT );unpause_sequencer (p, FALSE);
@@ -6644,7 +6645,7 @@ aic7xxx_device_queue_depth(struct aic7xxx_host *p, struct scsi_device *device)if (aic7xxx_verbose &VERBOSE_NEGOTIATION2 )printk (INFO_LEAD "Disconnection disabled, unable to " "enable tagged queueing.\n" , - p->host_no, device->channel, device->id, device->lun); + p->host_no, device->channel, device->id, (u8 )device->lun); tag_enabled = FALSE; }else
@@ -6689,7 +6690,7 @@ aic7xxx_device_queue_depth(struct aic7xxx_host *p, struct scsi_device *device) {printk (INFO_LEAD "Tagged queuing enabled, queue depth %d.\n" , p->host_no, device->channel, device->id, - device->lun, aic_dev->max_q_depth); + (u8 )device->lun, aic_dev->max_q_depth); }scsi_adjust_queue_depth (device,MSG_ORDERED_TAG , aic_dev->max_q_depth); }
@@ -6699,7 +6700,7 @@ aic7xxx_device_queue_depth(struct aic7xxx_host *p, struct scsi_device *device) {printk (INFO_LEAD "Tagged queuing disabled, queue depth %d.\n" , p->host_no, device->channel, device->id, - device->lun, device->host->cmd_per_lun); + (u8 )device->lun, device->host->cmd_per_lun); }scsi_adjust_queue_depth (device,0 , device->host->cmd_per_lun); }
@@ -10164,7 +10165,7 @@ static void aic7xxx_buildscb(struct aic7xxx_host *p, struct scsi_cmnd *cmd, scb->flags |=SCB_DTR_SCB ; } hscb->target_channel_lun = ((cmd->device->id <<4 ) &0xF0 ) | - ((cmd->device->channel &0x01 ) <<3 ) | (cmd->device->lun &0x07 ); + ((cmd->device->channel &0x01 ) <<3 ) | ((u8 )cmd->device->lun &0x07 );/* * The interpretation of request_buffer and request_bufflen
drivers/scsi/aic7xxx_old/aic7xxx_proc.c +1 -1
@@ -262,7 +262,7 @@ aic7xxx_proc_info ( struct Scsi_Host *HBAptr, char *buffer, char **start, off_t sdptr = aic_dev->SDptr; tindex = sdptr->channel <<3 | sdptr->id; size +=sprintf (BLS ,"(scsi%d:%d:%d:%d)\n" , - p->host_no, sdptr->channel, sdptr->id, sdptr->lun); + p->host_no, sdptr->channel, sdptr->id, (u8 )sdptr->lun); size += sprintf(BLS, " Device using %s/%s", (aic_dev->cur.width == MSG_EXT_WDTR_BUS_16_BIT) ? "Wide" : "Narrow",
drivers/scsi/arcmsr/arcmsr_hba.c +4 -4
@@ -2335,7 +2335,7 @@ static int arcmsr_polling_hba_ccbdone(struct AdapterControlBlock *acb," poll command abort successfully \n" , acb->host->host_no , ccb->pcmd->device->id - , ccb->pcmd->device->lun + , (u32 )ccb->pcmd->device->lun , ccb); ccb->pcmd->result =DID_ABORT <<16 ;arcmsr_ccb_complete (ccb);
@@ -2399,7 +2399,7 @@ static int arcmsr_polling_hbb_ccbdone(struct AdapterControlBlock *acb," poll command abort successfully \n" ,acb->host->host_no ,ccb->pcmd->device->id - ,ccb->pcmd->device->lun + ,(u32 )ccb->pcmd->device->lun ,ccb); ccb->pcmd->result =DID_ABORT <<16 ;arcmsr_ccb_complete (ccb);
@@ -2456,7 +2456,7 @@ polling_hbc_ccb_retry:" poll command abort successfully \n" , acb->host->host_no , pCCB->pcmd->device->id - , pCCB->pcmd->device->lun + , (u32 )pCCB->pcmd->device->lun , pCCB); pCCB->pcmd->result =DID_ABORT <<16 ;arcmsr_ccb_complete (pCCB);
@@ -3059,7 +3059,7 @@ static int arcmsr_abort(struct scsi_cmnd *cmd)int rtn =FAILED ;printk (KERN_NOTICE "arcmsr%d: abort device command of scsi id = %d lun = %d \n" , - acb->host->host_no, cmd->device->id, cmd->device->lun); + acb->host->host_no, cmd->device->id, (u32 )cmd->device->lun); acb->acb_flags |=ACB_F_ABORT ; acb->num_aborts++;/*
drivers/scsi/csiostor/csio_scsi.c +12 -12
@@ -1657,7 +1657,7 @@ csio_scsi_err_handler(struct csio_hw *hw, struct csio_ioreq *req)case FW_SCSI_UNDER_FLOW_ERR :csio_warn (hw,"Under-flow error,cmnd:0x%x expected" -" len:0x%x resid:0x%x lun:0x%x ssn:0x%x\n" , +" len:0x%x resid:0x%x lun:0x%llx ssn:0x%x\n" , cmnd->cmnd[0 ],scsi_bufflen (cmnd),scsi_get_resid (cmnd), cmnd->device->lun, rn->flowid);
@@ -1957,7 +1957,7 @@ csio_eh_abort_handler(struct scsi_cmnd *cmnd)csio_dbg (hw,"Request to abort ioreq:%p cmd:%p cdb:%08llx" -" ssni:0x%x lun:%d iq:0x%x\n" , +" ssni:0x%x lun:%llu iq:0x%x\n" , ioreq, cmnd, *((uint64_t *)cmnd->cmnd), rn->flowid, cmnd->device->lun,csio_q_physiqid (hw, ioreq->iq_idx));
@@ -2015,13 +2015,13 @@ inval_scmnd:/* FW successfully aborted the request */ if (host_byte (cmnd->result) ==DID_REQUEUE ) {csio_info (hw, -"Aborted SCSI command to (%d:%d) serial#:0x%lx\n" , +"Aborted SCSI command to (%d:%llu) serial#:0x%lx\n" , cmnd->device->id, cmnd->device->lun, cmnd->serial_number);return SUCCESS ; }else {csio_info (hw, -"Failed to abort SCSI command, (%d:%d) serial#:0x%lx\n" , +"Failed to abort SCSI command, (%d:%llu) serial#:0x%lx\n" , cmnd->device->id, cmnd->device->lun, cmnd->serial_number);return FAILED ;
@@ -2100,13 +2100,13 @@ csio_eh_lun_reset_handler(struct scsi_cmnd *cmnd)if (!rn) goto fail; -csio_dbg (hw,"Request to reset LUN:%d (ssni:0x%x tgtid:%d)\n" , +csio_dbg (hw,"Request to reset LUN:%llu (ssni:0x%x tgtid:%d)\n" , cmnd->device->lun, rn->flowid, rn->scsi_id);if (!csio_is_lnode_ready (ln)) {csio_err (hw,"LUN reset cannot be issued on non-ready" -" local node vnpi:0x%x (LUN:%d)\n" , +" local node vnpi:0x%x (LUN:%llu)\n" , ln->vnp_flowid, cmnd->device->lun); goto fail; }
@@ -2126,7 +2126,7 @@ csio_eh_lun_reset_handler(struct scsi_cmnd *cmnd)if (fc_remote_port_chkready (rn->rport)) {csio_err (hw,"LUN reset cannot be issued on non-ready" -" remote node ssni:0x%x (LUN:%d)\n" , +" remote node ssni:0x%x (LUN:%llu)\n" , rn->flowid, cmnd->device->lun); goto fail; }
@@ -2168,7 +2168,7 @@ csio_eh_lun_reset_handler(struct scsi_cmnd *cmnd) sld.level =CSIO_LEV_LUN ; sld.lnode = ioreq->lnode; sld.rnode = ioreq->rnode; - sld.oslun = (uint64_t )cmnd->device->lun; + sld.oslun = cmnd->device->lun;spin_lock_irqsave (&hw->lock, flags);/* Kick off TM SM on the ioreq */
@@ -2190,7 +2190,7 @@ csio_eh_lun_reset_handler(struct scsi_cmnd *cmnd)/* LUN reset timed-out */ if (((struct scsi_cmnd *)csio_scsi_cmnd (ioreq)) == cmnd) { -csio_err (hw,"LUN reset (%d:%d) timed out\n" , +csio_err (hw,"LUN reset (%d:%llu) timed out\n" , cmnd->device->id, cmnd->device->lun);spin_lock_irq (&hw->lock);
@@ -2203,7 +2203,7 @@ csio_eh_lun_reset_handler(struct scsi_cmnd *cmnd)/* LUN reset returned, check cached status */ if (cmnd->SCp.Status !=FW_SUCCESS ) { -csio_err (hw,"LUN reset failed (%d:%d), status: %d\n" , +csio_err (hw,"LUN reset failed (%d:%llu), status: %d\n" , cmnd->device->id, cmnd->device->lun, cmnd->SCp.Status); goto fail; }
@@ -2223,7 +2223,7 @@ csio_eh_lun_reset_handler(struct scsi_cmnd *cmnd)/* Aborts may have timed out */ if (retval !=0 ) {csio_err (hw, -"Attempt to abort I/Os during LUN reset of %d" +"Attempt to abort I/Os during LUN reset of %llu" " returned %d\n" , cmnd->device->lun, retval);/* Return I/Os back to active_q */ spin_lock_irq (&hw->lock);
@@ -2234,7 +2234,7 @@ csio_eh_lun_reset_handler(struct scsi_cmnd *cmnd)CSIO_INC_STATS (rn, n_lun_rst); -csio_info (hw,"LUN reset occurred (%d:%d)\n" , +csio_info (hw,"LUN reset occurred (%d:%llu)\n" , cmnd->device->id, cmnd->device->lun);return SUCCESS ;
drivers/scsi/dc395x.c +20 -20
@@ -1087,7 +1087,7 @@ static int dc395x_queue_command_lck(struct scsi_cmnd *cmd, void (*done)(struct sstruct AdapterCtlBlk *acb = (struct AdapterCtlBlk *)cmd->device->host->hostdata;dprintkdbg (DBG_0 ,"queue_command: (0x%p) <%02i-%i> cmnd=0x%02x\n" , - cmd, cmd->device->id, cmd->device->lun, cmd->cmnd[0 ]); + cmd, cmd->device->id, (u8 )cmd->device->lun, cmd->cmnd[0 ]);/* Assume BAD_TARGET; will be cleared later */ cmd->result =DID_BAD_TARGET <<16 ;
@@ -1102,7 +1102,7 @@ static int dc395x_queue_command_lck(struct scsi_cmnd *cmd, void (*done)(struct s/* does the specified lun on the specified device exist */ if (!(acb->dcb_map[cmd->device->id] & (1 << cmd->device->lun))) {dprintkl (KERN_INFO ,"queue_command: Ignore target <%02i-%i>\n" , - cmd->device->id, cmd->device->lun); + cmd->device->id, (u8 )cmd->device->lun); goto complete; }
@@ -1111,7 +1111,7 @@ static int dc395x_queue_command_lck(struct scsi_cmnd *cmd, void (*done)(struct sif (!dcb) {/* should never happen */ dprintkl (KERN_ERR ,"queue_command: No such device <%02i-%i>" , - cmd->device->id, cmd->device->lun); + cmd->device->id, (u8 )cmd->device->lun); goto complete; }
@@ -1207,7 +1207,7 @@ static void dump_register_info(struct AdapterCtlBlk *acb,"cmnd=0x%02x <%02i-%i>\n" , srb, srb->cmd, srb->cmd->cmnd[0 ], srb->cmd->device->id, - srb->cmd->device->lun); + (u8)srb->cmd->device->lun);printk (" sglist=%p cnt=%i idx=%i len=%zu\n" , srb->segment_x, srb->sg_count, srb->sg_index, srb->total_xfer_length);
@@ -1302,7 +1302,7 @@ static int __dc395x_eh_bus_reset(struct scsi_cmnd *cmd) (struct AdapterCtlBlk *)cmd->device->host->hostdata;dprintkl (KERN_INFO ,"eh_bus_reset: (0%p) target=<%02i-%i> cmd=%p\n" , - cmd, cmd->device->id, cmd->device->lun, cmd); + cmd, cmd->device->id, (u8 )cmd->device->lun, cmd);if (timer_pending (&acb->waiting_timer))del_timer (&acb->waiting_timer);
@@ -1369,7 +1369,7 @@ static int dc395x_eh_abort(struct scsi_cmnd *cmd)struct DeviceCtlBlk *dcb;struct ScsiReqBlk *srb;dprintkl (KERN_INFO ,"eh_abort: (0x%p) target=<%02i-%i> cmd=%p\n" , - cmd, cmd->device->id, cmd->device->lun, cmd); + cmd, cmd->device->id, (u8 )cmd->device->lun, cmd); dcb =find_dcb (acb, cmd->device->id, cmd->device->lun);if (!dcb) {
@@ -1605,7 +1605,7 @@ static u8 start_scsi(struct AdapterCtlBlk* acb, struct DeviceCtlBlk* dcb,dprintkl (KERN_WARNING ,"start_scsi: (0x%p) " "Out of tags target=<%02i-%i>)\n" , srb->cmd, srb->cmd->device->id, - srb->cmd->device->lun); + (u8 )srb->cmd->device->lun); srb->state =SRB_READY ;DC395x_write16 (acb,TRM_S1040_SCSI_CONTROL ,DO_HWRESELECT );
@@ -1623,7 +1623,7 @@ static u8 start_scsi(struct AdapterCtlBlk* acb, struct DeviceCtlBlk* dcb,/*polling:*/ /* Send CDB ..command block ......... */ dprintkdbg (DBG_KG ,"start_scsi: (0x%p) <%02i-%i> cmnd=0x%02x tag=%i\n" , - srb->cmd, srb->cmd->device->id, srb->cmd->device->lun, + srb->cmd, srb->cmd->device->id, (u8 )srb->cmd->device->lun, srb->cmd->cmnd[0 ], srb->tag_number);if (srb->flag &AUTO_REQSENSE ) {DC395x_write8 (acb,TRM_S1040_SCSI_FIFO ,REQUEST_SENSE );
@@ -2041,7 +2041,7 @@ static void data_out_phase0(struct AdapterCtlBlk *acb, struct ScsiReqBlk *srb,u16 scsi_status = *pscsi_status;u32 d_left_counter =0 ;dprintkdbg (DBG_0 ,"data_out_phase0: (0x%p) <%02i-%i>\n" , - srb->cmd, srb->cmd->device->id, srb->cmd->device->lun); + srb->cmd, srb->cmd->device->id, (u8 )srb->cmd->device->lun);/* * KG: We need to drain the buffers before we draw any conclusions!
@@ -2171,7 +2171,7 @@ static void data_out_phase1(struct AdapterCtlBlk *acb, struct ScsiReqBlk *srb, u16 *pscsi_status) {dprintkdbg (DBG_0 ,"data_out_phase1: (0x%p) <%02i-%i>\n" , - srb->cmd, srb->cmd->device->id, srb->cmd->device->lun); + srb->cmd, srb->cmd->device->id, (u8 )srb->cmd->device->lun);clear_fifo (acb,"data_out_phase1" );/* do prepare before transfer when data out phase */ data_io_transfer (acb, srb,XFERDATAOUT );
@@ -2183,7 +2183,7 @@ static void data_in_phase0(struct AdapterCtlBlk *acb, struct ScsiReqBlk *srb,u16 scsi_status = *pscsi_status;dprintkdbg (DBG_0 ,"data_in_phase0: (0x%p) <%02i-%i>\n" , - srb->cmd, srb->cmd->device->id, srb->cmd->device->lun); + srb->cmd, srb->cmd->device->id, (u8 )srb->cmd->device->lun);/* * KG: DataIn is much more tricky than DataOut. When the device is finished
@@ -2394,7 +2394,7 @@ static void data_in_phase1(struct AdapterCtlBlk *acb, struct ScsiReqBlk *srb, u16 *pscsi_status) {dprintkdbg (DBG_0 ,"data_in_phase1: (0x%p) <%02i-%i>\n" , - srb->cmd, srb->cmd->device->id, srb->cmd->device->lun); + srb->cmd, srb->cmd->device->id, (u8 )srb->cmd->device->lun);data_io_transfer (acb, srb,XFERDATAIN ); }
@@ -2406,7 +2406,7 @@ static void data_io_transfer(struct AdapterCtlBlk *acb,u8 bval;dprintkdbg (DBG_0 ,"data_io_transfer: (0x%p) <%02i-%i> %c len=%i, sg=(%i/%i)\n" , - srb->cmd, srb->cmd->device->id, srb->cmd->device->lun, + srb->cmd, srb->cmd->device->id, (u8 )srb->cmd->device->lun, ((io_dir &DMACMD_DIR ) ?'r' :'w' ), srb->total_xfer_length, srb->sg_index, srb->sg_count);if (srb == acb->tmp_srb)
@@ -2579,7 +2579,7 @@ static void status_phase0(struct AdapterCtlBlk *acb, struct ScsiReqBlk *srb, u16 *pscsi_status) {dprintkdbg (DBG_0 ,"status_phase0: (0x%p) <%02i-%i>\n" , - srb->cmd, srb->cmd->device->id, srb->cmd->device->lun); + srb->cmd, srb->cmd->device->id, (u8 )srb->cmd->device->lun); srb->target_status =DC395x_read8 (acb,TRM_S1040_SCSI_FIFO ); srb->end_message =DC395x_read8 (acb,TRM_S1040_SCSI_FIFO );/* get message */ srb->state =SRB_COMPLETED ;
@@ -2593,7 +2593,7 @@ static void status_phase1(struct AdapterCtlBlk *acb, struct ScsiReqBlk *srb, u16 *pscsi_status) {dprintkdbg (DBG_0 ,"status_phase1: (0x%p) <%02i-%i>\n" , - srb->cmd, srb->cmd->device->id, srb->cmd->device->lun); + srb->cmd, srb->cmd->device->id, (u8 )srb->cmd->device->lun); srb->state =SRB_STATUS ;DC395x_write16 (acb,TRM_S1040_SCSI_CONTROL ,DO_DATALATCH );/* it's important for atn stop */ DC395x_write8 (acb,TRM_S1040_SCSI_COMMAND ,SCMD_COMP );
@@ -3318,7 +3318,7 @@ static void srb_done(struct AdapterCtlBlk *acb, struct DeviceCtlBlk *dcb,int ckc_only =1 ;dprintkdbg (DBG_1 ,"srb_done: (0x%p) <%02i-%i>\n" , srb->cmd, - srb->cmd->device->id, srb->cmd->device->lun); + srb->cmd->device->id, (u8 )srb->cmd->device->lun);dprintkdbg (DBG_SG ,"srb_done: srb=%p sg=%i(%i/%i) buf=%p\n" , srb,scsi_sg_count (cmd), srb->sg_index, srb->sg_count,scsi_sgtalbe (cmd));
@@ -3498,7 +3498,7 @@ static void srb_done(struct AdapterCtlBlk *acb, struct DeviceCtlBlk *dcb,if (srb->total_xfer_length)dprintkdbg (DBG_KG ,"srb_done: (0x%p) <%02i-%i> " "cmnd=0x%02x Missed %i bytes\n" , - cmd, cmd->device->id, cmd->device->lun, + cmd, cmd->device->id, (u8 )cmd->device->lun, cmd->cmnd[0 ], srb->total_xfer_length); }
@@ -3538,7 +3538,7 @@ static void doing_srb_done(struct AdapterCtlBlk *acb, u8 did_flag, dir = p->sc_data_direction; result =MK_RES (0 , did_flag,0 ,0 );printk ("G:%p(%02i-%i) " , p, - p->device->id, p->device->lun); + p->device->id, (u8 )p->device->lun);srb_going_remove (dcb, srb);free_tag (dcb, srb);srb_free_insert (acb, srb);
@@ -3568,7 +3568,7 @@ static void doing_srb_done(struct AdapterCtlBlk *acb, u8 did_flag, result =MK_RES (0 , did_flag,0 ,0 );printk ("W:%p<%02i-%i>" , p, p->device->id, - p->device->lun); + (u8 )p->device->lun);srb_waiting_remove (dcb, srb);srb_free_insert (acb, srb); p->result = result;
@@ -3677,7 +3677,7 @@ static void request_sense(struct AdapterCtlBlk *acb, struct DeviceCtlBlk *dcb, {struct scsi_cmnd *cmd = srb->cmd;dprintkdbg (DBG_1 ,"request_sense: (0x%p) <%02i-%i>\n" , - cmd, cmd->device->id, cmd->device->lun); + cmd, cmd->device->id, (u8 )cmd->device->lun); srb->flag |=AUTO_REQSENSE ; srb->adapter_status =0 ;
drivers/scsi/eata.c +1 -1
@@ -2449,7 +2449,7 @@ static irqreturn_t ihdlr(struct Scsi_Host *shost)"target_status 0x%x, sense key 0x%x.\n" , ha->board_name, SCpnt->device->channel, SCpnt->device->id, - SCpnt->device->lun, + (u8 )SCpnt->device->lun, spp->target_status, SCpnt->sense_buffer[2]); ha->target_to[SCpnt->device->id][SCpnt->device->channel] =0 ;
drivers/scsi/fnic/fnic_scsi.c +3 -3
@@ -843,7 +843,7 @@ static void fnic_fcpio_icmnd_cmpl_handler(struct fnic *fnic, qd = t_sdev->host->cmd_per_lun; shost_printk(KERN_INFO, fnic->lport->host, - "scsi[%d:%d:%d:%d" + "scsi[%d:%d:%d:%llu" "] queue full detected," "new depth = %d\n", t_sdev->host->host_no,
@@ -1584,7 +1584,7 @@ int fnic_abort_cmd(struct scsi_cmnd *sc) tag = sc->request->tag;FNIC_SCSI_DBG (KERN_DEBUG , fnic->lport->host, -"Abort Cmd called FCID 0x%x, LUN 0x%x TAG %x flags %x\n" , +"Abort Cmd called FCID 0x%x, LUN 0x%llx TAG %x flags %x\n" , rport->port_id, sc->device->lun, tag,CMD_FLAGS (sc));CMD_FLAGS (sc) =FNIC_NO_FLAGS ;
@@ -2006,7 +2006,7 @@ int fnic_device_reset(struct scsi_cmnd *sc) rport =starget_to_rport (scsi_target (sc->device));FNIC_SCSI_DBG (KERN_DEBUG , fnic->lport->host, -"Device reset called FCID 0x%x, LUN 0x%x sc 0x%p\n" , +"Device reset called FCID 0x%x, LUN 0x%llx sc 0x%p\n" , rport->port_id, sc->device->lun, sc);if (lp->state !=LPORT_ST_READY || !(lp->link_up))
drivers/scsi/hpsa.c +1 -1
@@ -2584,7 +2584,7 @@ static int hpsa_eh_abort_handler(struct scsi_cmnd *sc)memset (msg,0 ,sizeof (msg)); ml +=sprintf (msg+ml,"ABORT REQUEST on C%d:B%d:T%d:L%d " , h->scsi_host->host_no, sc->device->channel, - sc->device->id, sc->device->lun); + sc->device->id, (u32 )sc->device->lun);/* Find the device of the command to be aborted */ dev = sc->device->hostdata;
drivers/scsi/libiscsi.c +4 -3
@@ -268,7 +268,7 @@ static int iscsi_check_tmf_restrictions(struct iscsi_task *task, int opcode) {struct iscsi_conn *conn = task->conn;struct iscsi_tm *tmf = &conn->tmhdr; -unsigned int hdr_lun; +uint64_t hdr_lun;if (conn->tmf_state ==TMF_INITIAL )return 0 ;
@@ -1813,7 +1813,7 @@ static int iscsi_exec_task_mgmt_fn(struct iscsi_conn *conn,* Fail commands. session lock held and recv side suspended and xmit * thread flushed */ -static void fail_scsi_tasks (struct iscsi_conn *conn,unsigned lun, +static void fail_scsi_tasks (struct iscsi_conn *conn,uint64_t lun,int error) {struct iscsi_task *task;
@@ -2233,7 +2233,8 @@ int iscsi_eh_device_reset(struct scsi_cmnd *sc) cls_session =starget_to_session (scsi_target (sc->device)); session = cls_session->dd_data; -ISCSI_DBG_EH (session,"LU Reset [sc %p lun %u]\n" , sc, sc->device->lun); +ISCSI_DBG_EH (session,"LU Reset [sc %p lun %llu]\n" , sc, + sc->device->lun);mutex_lock (&session->eh_mutex);spin_lock_bh (&session->lock);
drivers/scsi/libsas/sas_scsi_host.c +6 -5
@@ -404,7 +404,7 @@ static int sas_recover_lu(struct domain_device *dev, struct scsi_cmnd *cmd)int_to_scsilun (cmd->device->lun, &lun); -SAS_DPRINTK ("eh: device %llx LUN %x has the task\n" , +SAS_DPRINTK ("eh: device %llx LUN %llx has the task\n" ,SAS_ADDR (dev->sas_addr), cmd->device->lun);
@@ -490,7 +490,8 @@ static void sas_wait_eh(struct domain_device *dev) }EXPORT_SYMBOL (sas_wait_eh); -static int sas_queue_reset (struct domain_device *dev,int reset_type,int lun,int wait) +static int sas_queue_reset (struct domain_device *dev,int reset_type, +uint64_t lun,int wait) {struct sas_ha_struct *ha = dev->port->ha;int scheduled =0 , tries =100 ;
@@ -689,7 +690,7 @@ static void sas_eh_handle_sas_errors(struct Scsi_Host *shost, struct list_head * reset: tmf_resp =sas_recover_lu (task->dev, cmd);if (tmf_resp ==TMF_RESP_FUNC_COMPLETE ) { -SAS_DPRINTK ("dev %016llx LU %x is " +SAS_DPRINTK ("dev %016llx LU %llx is " "recovered\n" ,SAS_ADDR (task->dev), cmd->device->lun);
@@ -742,7 +743,7 @@ static void sas_eh_handle_sas_errors(struct Scsi_Host *shost, struct list_head ** of effort could recover from errors. Quite * possibly the HA just disappeared. */ -SAS_DPRINTK ("error from device %llx, LUN %x " +SAS_DPRINTK ("error from device %llx, LUN %llx " "couldn't be recovered in any way\n" ,SAS_ADDR (task->dev->sas_addr), cmd->device->lun);
@@ -941,7 +942,7 @@ int sas_slave_configure(struct scsi_device *scsi_dev)scsi_set_tag_type (scsi_dev,MSG_SIMPLE_TAG );scsi_activate_tcq (scsi_dev,SAS_DEF_QD ); }else { -SAS_DPRINTK ("device %llx, LUN %x doesn't support " +SAS_DPRINTK ("device %llx, LUN %llx doesn't support " "TCQ\n" ,SAS_ADDR (dev->sas_addr), scsi_dev->lun); scsi_dev->tagged_supported =0 ;
drivers/scsi/lpfc/lpfc_scsi.c +22 -22
170 lines not on this page · raw message
drivers/scsi/megaraid.c +3 -3
@@ -1961,9 +1961,9 @@ megaraid_abort_and_reset(adapter_t *adapter, Scsi_Cmnd *cmd, int aor)scb_t *scb;printk (KERN_WARNING "megaraid: %s cmd=%x <c=%d t=%d l=%d>\n" , - (aor ==SCB_ABORT )?"ABORTING" :"RESET" , - cmd->cmnd[0 ], cmd->device->channel, - cmd->device->id, cmd->device->lun); + (aor ==SCB_ABORT )?"ABORTING" :"RESET" , + cmd->cmnd[0 ], cmd->device->channel, + cmd->device->id, (u32 )cmd->device->lun);if (list_empty (&adapter->pending_list))return FALSE;
drivers/scsi/megaraid/mega_common.h +1 -1
@@ -204,7 +204,7 @@ typedef struct {#define SCP2HOSTDATA (scp) SCP2HOST(scp)->hostdata // to soft state#define SCP2CHANNEL (scp) (scp)->device->channel // to channel#define SCP2TARGET (scp) (scp)->device->id // to target -#define SCP2LUN (scp) (scp)->device->lun // to LUN +#define SCP2LUN (scp) (u32)(scp)->device->lun // to LUN// generic macro to convert scsi command and host to controller's soft state #define SCSIHOST2ADAP (host) (((caddr_t *)(host->hostdata))[0])
drivers/scsi/pmcraid.c +1 -1
@@ -237,7 +237,7 @@ static int pmcraid_slave_configure(struct scsi_device *scsi_dev) scsi_dev->host->unique_id, scsi_dev->channel, scsi_dev->id, - scsi_dev->lun); + (u8)scsi_dev->lun);if (RES_IS_GSCSI (res->cfg_entry)) { scsi_dev->allow_restart =1 ;
drivers/scsi/qla2xxx/qla_def.h +2 -2
@@ -2352,8 +2352,8 @@ struct isp_operations {void (*disable_intrs) (struct qla_hw_data *);int (*abort_command) (srb_t *); -int (*target_reset) (struct fc_port *,unsigned int ,int ); -int (*lun_reset) (struct fc_port *,unsigned int ,int ); +int (*target_reset) (struct fc_port *,uint64_t ,int ); +int (*lun_reset) (struct fc_port *,uint64_t ,int );int (*fabric_login) (struct scsi_qla_host *,uint16_t ,uint8_t ,uint8_t ,uint8_t ,uint16_t *,uint8_t ); int (*fabric_logout) (struct scsi_qla_host *, uint16_t, uint8_t,
drivers/scsi/qla2xxx/qla_gbl.h +5 -5
@@ -250,10 +250,10 @@ extern intqla2x00_abort_command (srb_t *);extern int -qla2x00_abort_target (struct fc_port *,unsigned int ,int ); +qla2x00_abort_target (struct fc_port *,uint64_t ,int );extern int -qla2x00_lun_reset (struct fc_port *,unsigned int ,int ); +qla2x00_lun_reset (struct fc_port *,uint64_t ,int ); extern int qla2x00_get_adapter_id(scsi_qla_host_t *, uint16_t *, uint8_t *, uint8_t *,
@@ -323,12 +323,12 @@ qla24xx_get_isp_stats(scsi_qla_host_t *, struct link_statistics *,extern int qla24xx_abort_command (srb_t *);extern int -qla24xx_abort_target (struct fc_port *,unsigned int ,int ); +qla24xx_abort_target (struct fc_port *,uint64_t ,int );extern int -qla24xx_lun_reset (struct fc_port *,unsigned int ,int ); +qla24xx_lun_reset (struct fc_port *,uint64_t ,int );extern int qla2x00_eh_wait_for_pending_commands (scsi_qla_host_t *,unsigned int , -unsigned int ,enum nexus_wait_type ); +uint64_t ,enum nexus_wait_type );extern int qla2x00_system_error (scsi_qla_host_t *);
drivers/scsi/qla2xxx/qla_isr.c +2 -2
@@ -1581,7 +1581,7 @@ qla2x00_handle_sense(srb_t *sp, uint8_t *sense_data, uint32_t par_sense_len,if (sense_len) {ql_dbg (ql_dbg_io + ql_dbg_buffer, vha,0x301c , -"Check condition Sense data, nexus%ld:%d:%d cmd=%p.\n" , +"Check condition Sense data, nexus%ld:%d:%llu cmd=%p.\n" , sp->fcport->vha->host_no, cp->device->id, cp->device->lun, cp); ql_dump_buffer(ql_dbg_io + ql_dbg_buffer, vha, 0x302b,
@@ -2182,7 +2182,7 @@ out:if (logit) ql_dbg(ql_dbg_io, fcport->vha, 0x3022, "FCP command status: 0x%x-0x%x (0x%x) " - "nexus=%ld:%d:%d portid=%02x%02x%02x oxid=0x%x " + "nexus=%ld:%d:%llu portid=%02x%02x%02x oxid=0x%x " "cdb=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x len=0x%x " "rsp_info=0x%x resid=0x%x fw_resid=0x%x.\n", comp_status, scsi_status, res, vha->host_no,
drivers/scsi/qla2xxx/qla_mbx.c +6 -6
@@ -936,7 +936,7 @@ qla2x00_abort_command(srb_t *sp) }int -qla2x00_abort_target (struct fc_port *fcport,unsigned int l,int tag) +qla2x00_abort_target (struct fc_port *fcport,uint64_t l,int tag) {int rval, rval2;mbx_cmd_t mc;
@@ -989,7 +989,7 @@ qla2x00_abort_target(struct fc_port *fcport, unsigned int l, int tag) }int -qla2x00_lun_reset (struct fc_port *fcport,unsigned int l,int tag) +qla2x00_lun_reset (struct fc_port *fcport,uint64_t l,int tag) {int rval, rval2;mbx_cmd_t mc;
@@ -1011,7 +1011,7 @@ qla2x00_lun_reset(struct fc_port *fcport, unsigned int l, int tag) mcp->mb[1 ] = fcport->loop_id; else mcp->mb[1] = fcport->loop_id << 8; - mcp->mb[2 ] = l; + mcp->mb[2 ] = (u32 )l; mcp->mb[3 ] =0 ; mcp->mb[9 ] = vha->vp_idx;
@@ -2598,7 +2598,7 @@ struct tsk_mgmt_cmd {static int __qla24xx_issue_tmf (char *name,uint32_t type,struct fc_port *fcport, -unsigned int l,int tag) +uint64_t l,int tag) {int rval, rval2;struct tsk_mgmt_cmd *tsk;
@@ -2692,7 +2692,7 @@ __qla24xx_issue_tmf(char *name, uint32_t type, struct fc_port *fcport, }int -qla24xx_abort_target (struct fc_port *fcport,unsigned int l,int tag) +qla24xx_abort_target (struct fc_port *fcport,uint64_t l,int tag) {struct qla_hw_data *ha = fcport->vha->hw;
@@ -2703,7 +2703,7 @@ qla24xx_abort_target(struct fc_port *fcport, unsigned int l, int tag) }int -qla24xx_lun_reset (struct fc_port *fcport,unsigned int l,int tag) +qla24xx_lun_reset (struct fc_port *fcport,uint64_t l,int tag) {struct qla_hw_data *ha = fcport->vha->hw;
drivers/scsi/qla2xxx/qla_os.c +19 -16
@@ -929,7 +929,8 @@ qla2xxx_eh_abort(struct scsi_cmnd *cmd)scsi_qla_host_t *vha =shost_priv (cmd->device->host);srb_t *sp;int ret; -unsigned int id, lun; +unsigned int id; +uint64_t lun;unsigned long flags;int wait =0 ;struct qla_hw_data *ha = vha->hw;
@@ -953,7 +954,7 @@ qla2xxx_eh_abort(struct scsi_cmnd *cmd) }ql_dbg (ql_dbg_taskm, vha,0x8002 , -"Aborting from RISC nexus=%ld:%d:%d sp=%p cmd=%p\n" , +"Aborting from RISC nexus=%ld:%d:%llu sp=%p cmd=%p\n" , vha->host_no, id, lun, sp, cmd);/* Get a reference to the sp and drop the lock.*/
@@ -988,7 +989,7 @@ qla2xxx_eh_abort(struct scsi_cmnd *cmd) }ql_log (ql_log_info, vha,0x801c , -"Abort command issued nexus=%ld:%d:%d -- %d %x.\n" , +"Abort command issued nexus=%ld:%d:%llu -- %d %x.\n" , vha->host_no, id, lun, wait, ret);return ret;
@@ -996,7 +997,7 @@ qla2xxx_eh_abort(struct scsi_cmnd *cmd)int qla2x00_eh_wait_for_pending_commands (scsi_qla_host_t *vha,unsigned int t, -unsigned int l,enum nexus_wait_type type) +uint64_t l,enum nexus_wait_type type) {int cnt, match, status;unsigned long flags;
@@ -1053,7 +1054,7 @@ static char *reset_errors[] = {static int __qla2xxx_eh_generic_reset (char *name,enum nexus_wait_type type, -struct scsi_cmnd *cmd,int (*do_reset)(struct fc_port *,unsigned int ,int )) +struct scsi_cmnd *cmd,int (*do_reset)(struct fc_port *,uint64_t ,int )) {scsi_qla_host_t *vha =shost_priv (cmd->device->host);fc_port_t *fcport = (struct fc_port *) cmd->device->hostdata;
@@ -1068,7 +1069,7 @@ __qla2xxx_eh_generic_reset(char *name, enum nexus_wait_type type,return err;ql_log (ql_log_info, vha,0x8009 , -"%s RESET ISSUED nexus=%ld:%d:%d cmd=%p.\n" , name, vha->host_no, +"%s RESET ISSUED nexus=%ld:%d:%llu cmd=%p.\n" , name, vha->host_no, cmd->device->id, cmd->device->lun, cmd); err =0 ;
@@ -1093,14 +1094,14 @@ __qla2xxx_eh_generic_reset(char *name, enum nexus_wait_type type, }ql_log (ql_log_info, vha,0x800e , -"%s RESET SUCCEEDED nexus:%ld:%d:%d cmd=%p.\n" , name, +"%s RESET SUCCEEDED nexus:%ld:%d:%llu cmd=%p.\n" , name, vha->host_no, cmd->device->id, cmd->device->lun, cmd);return SUCCESS ; eh_reset_failed:ql_log (ql_log_info, vha,0x800f , -"%s RESET FAILED: %s nexus=%ld:%d:%d cmd=%p.\n" , name, +"%s RESET FAILED: %s nexus=%ld:%d:%llu cmd=%p.\n" , name, reset_errors[err], vha->host_no, cmd->device->id, cmd->device->lun, cmd);return FAILED ;
@@ -1147,7 +1148,8 @@ qla2xxx_eh_bus_reset(struct scsi_cmnd *cmd)scsi_qla_host_t *vha =shost_priv (cmd->device->host);fc_port_t *fcport = (struct fc_port *) cmd->device->hostdata;int ret =FAILED ; -unsigned int id, lun; +unsigned int id; +uint64_t lun; id = cmd->device->id; lun = cmd->device->lun;
@@ -1162,7 +1164,7 @@ qla2xxx_eh_bus_reset(struct scsi_cmnd *cmd) ret =FAILED ;ql_log (ql_log_info, vha,0x8012 , -"BUS RESET ISSUED nexus=%ld:%d:%d.\n" , vha->host_no, id, lun); +"BUS RESET ISSUED nexus=%ld:%d:%llu.\n" , vha->host_no, id, lun);if (qla2x00_wait_for_hba_online (vha) !=QLA_SUCCESS ) { ql_log(ql_log_fatal, vha, 0x8013,
@@ -1186,7 +1188,7 @@ qla2xxx_eh_bus_reset(struct scsi_cmnd *cmd) eh_bus_reset_done:ql_log (ql_log_warn, vha,0x802b , -"BUS RESET %s nexus=%ld:%d:%d.\n" , +"BUS RESET %s nexus=%ld:%d:%llu.\n" , (ret ==FAILED ) ?"FAILED" :"SUCCEEDED" , vha->host_no, id, lun);return ret;
@@ -1213,14 +1215,15 @@ qla2xxx_eh_host_reset(struct scsi_cmnd *cmd)scsi_qla_host_t *vha =shost_priv (cmd->device->host);struct qla_hw_data *ha = vha->hw;int ret =FAILED ; -unsigned int id, lun; +unsigned int id; +uint64_t lun;scsi_qla_host_t *base_vha =pci_get_drvdata (ha->pdev); id = cmd->device->id; lun = cmd->device->lun;ql_log (ql_log_info, vha,0x8018 , -"ADAPTER RESET ISSUED nexus=%ld:%d:%d.\n" , vha->host_no, id, lun); +"ADAPTER RESET ISSUED nexus=%ld:%d:%llu.\n" , vha->host_no, id, lun);if (qla2x00_wait_for_reset_ready (vha) !=QLA_SUCCESS ) goto eh_host_reset_lock;
@@ -1262,7 +1265,7 @@ qla2xxx_eh_host_reset(struct scsi_cmnd *cmd) eh_host_reset_lock:ql_log (ql_log_info, vha,0x8017 , -"ADAPTER RESET %s nexus=%ld:%d:%d.\n" , +"ADAPTER RESET %s nexus=%ld:%d:%llu.\n" , (ret ==FAILED ) ?"FAILED" :"SUCCEEDED" , vha->host_no, id, lun);return ret;
@@ -1391,7 +1394,7 @@ static void qla2x00_handle_queue_full(struct scsi_device *sdev, int qdepth)return ;ql_dbg (ql_dbg_io, fcport->vha,0x3029 , -"Queue depth adjusted-down to %d for nexus=%ld:%d:%d.\n" , +"Queue depth adjusted-down to %d for nexus=%ld:%d:%llu.\n" , sdev->queue_depth, fcport->vha->host_no, sdev->id, sdev->lun); }
@@ -1414,7 +1417,7 @@ static void qla2x00_adjust_sdev_qdepth_up(struct scsi_device *sdev, int qdepth)scsi_adjust_queue_depth (sdev,MSG_SIMPLE_TAG , qdepth);ql_dbg (ql_dbg_io, vha,0x302a , -"Queue depth adjusted-up to %d for nexus=%ld:%d:%d.\n" , +"Queue depth adjusted-up to %d for nexus=%ld:%d:%llu.\n" , sdev->queue_depth, fcport->vha->host_no, sdev->id, sdev->lun); }
drivers/scsi/qla4xxx/ql4_glbl.h +2 -2
@@ -23,7 +23,7 @@ void qla4xxx_process_aen(struct scsi_qla_host *ha, uint8_t process_aen);int qla4xxx_get_dhcp_ip_address (struct scsi_qla_host *ha);int qla4xxx_abort_task (struct scsi_qla_host *ha,struct srb *srb);int qla4xxx_reset_lun (struct scsi_qla_host *ha,struct ddb_entry *ddb_entry, -int lun); +uint64_t lun);int qla4xxx_reset_target (struct scsi_qla_host *ha,struct ddb_entry *ddb_entry); int qla4xxx_get_flash(struct scsi_qla_host *ha, dma_addr_t dma_addr,
@@ -76,7 +76,7 @@ int qla4xxx_process_ddb_changed(struct scsi_qla_host *ha, uint32_t fw_ddb_index, uint32_t state, uint32_t conn_error);void qla4xxx_dump_buffer (void *b,uint32_t size);int qla4xxx_send_marker_iocb (struct scsi_qla_host *ha, -struct ddb_entry *ddb_entry,int lun,uint16_t mrkr_mod); +struct ddb_entry *ddb_entry,uint64_t lun,uint16_t mrkr_mod);int qla4xxx_set_flash (struct scsi_qla_host *ha,dma_addr_t dma_addr,uint32_t offset,uint32_t length,uint32_t options); int qla4xxx_mailbox_command(struct scsi_qla_host *ha, uint8_t inCount,
drivers/scsi/qla4xxx/ql4_iocb.c +1 -1
@@ -83,7 +83,7 @@ static int qla4xxx_get_req_pkt(struct scsi_qla_host *ha,* This routine issues a marker IOCB. **/ int qla4xxx_send_marker_iocb (struct scsi_qla_host *ha, -struct ddb_entry *ddb_entry,int lun,uint16_t mrkr_mod) +struct ddb_entry *ddb_entry,uint64_t lun,uint16_t mrkr_mod) {struct qla4_marker_entry *marker_entry;unsigned long flags =0 ;
drivers/scsi/qla4xxx/ql4_isr.c +11 -11
@@ -26,7 +26,7 @@ static void qla4xxx_copy_sense(struct scsi_qla_host *ha,memset (cmd->sense_buffer,0 ,SCSI_SENSE_BUFFERSIZE ); sense_len =le16_to_cpu (sts_entry->senseDataByteCnt);if (sense_len ==0 ) { -DEBUG2 (ql4_printk (KERN_INFO , ha,"scsi%ld:%d:%d:%d: %s:" +DEBUG2 (ql4_printk (KERN_INFO , ha,"scsi%ld:%d:%d:%llu: %s:" " sense len 0\n" , ha->host_no, cmd->device->channel, cmd->device->id, cmd->device->lun, __func__));
@@ -43,7 +43,7 @@ static void qla4xxx_copy_sense(struct scsi_qla_host *ha, sense_len =min_t (uint16_t, sense_len,IOCB_MAX_SENSEDATA_LEN );memcpy (cmd->sense_buffer, sts_entry->senseData, sense_len); - DEBUG2(printk(KERN_INFO "scsi%ld:%d:%d:%d: %s: sense key = %x, " + DEBUG2(printk(KERN_INFO "scsi%ld:%d:%d:%llu: %s: sense key = %x, " "ASL= %02x, ASC/ASCQ = %02x/%02x\n", ha->host_no, cmd->device->channel, cmd->device->id, cmd->device->lun, __func__,
@@ -169,7 +169,7 @@ static void qla4xxx_status_entry(struct scsi_qla_host *ha, cmd->result =DID_ERROR <<16 ; - DEBUG2(printk("scsi%ld:%d:%d:%d: %s: " + DEBUG2(printk("scsi%ld:%d:%d:%llu: %s: " "Mid-layer Data underrun0, " "xferlen = 0x%x, " "residual = 0x%x\n", ha->host_no,
@@ -197,7 +197,7 @@ static void qla4xxx_status_entry(struct scsi_qla_host *ha,break ;case SCS_RESET_OCCURRED : -DEBUG2 (printk ("scsi%ld:%d:%d:%d: %s: Device RESET occurred\n" , +DEBUG2 (printk ("scsi%ld:%d:%d:%llu: %s: Device RESET occurred\n" , ha->host_no, cmd->device->channel, cmd->device->id, cmd->device->lun, __func__));
@@ -205,7 +205,7 @@ static void qla4xxx_status_entry(struct scsi_qla_host *ha,break ;case SCS_ABORTED : -DEBUG2 (printk ("scsi%ld:%d:%d:%d: %s: Abort occurred\n" , +DEBUG2 (printk ("scsi%ld:%d:%d:%llu: %s: Abort occurred\n" , ha->host_no, cmd->device->channel, cmd->device->id, cmd->device->lun, __func__));
@@ -213,7 +213,7 @@ static void qla4xxx_status_entry(struct scsi_qla_host *ha,break ;case SCS_TIMEOUT : -DEBUG2 (printk (KERN_INFO "scsi%ld:%d:%d:%d: Timeout\n" , +DEBUG2 (printk (KERN_INFO "scsi%ld:%d:%d:%llu: Timeout\n" , ha->host_no, cmd->device->channel, cmd->device->id, cmd->device->lun));
@@ -232,7 +232,7 @@ static void qla4xxx_status_entry(struct scsi_qla_host *ha,case SCS_DATA_OVERRUN :if ((sts_entry->iscsiFlags &ISCSI_FLAG_RESIDUAL_OVER ) || (sts_entry->completionStatus ==SCS_DATA_OVERRUN )) { -DEBUG2 (printk ("scsi%ld:%d:%d:%d: %s: " "Data overrun\n" , +DEBUG2 (printk ("scsi%ld:%d:%d:%llu: %s: " "Data overrun\n" , ha->host_no, cmd->device->channel, cmd->device->id, cmd->device->lun, __func__));
@@ -259,7 +259,7 @@ static void qla4xxx_status_entry(struct scsi_qla_host *ha,if (!scsi_status && (scsi_bufflen (cmd) - residual) < cmd->underflow) { DEBUG2(ql4_printk(KERN_INFO, ha, - "scsi%ld:%d:%d:%d: %s: Mid-layer Data underrun, xferlen = 0x%x,residual = 0x%x\n", + "scsi%ld:%d:%d:%llu: %s: Mid-layer Data underrun, xferlen = 0x%x,residual = 0x%x\n", ha->host_no, cmd->device->channel, cmd->device->id,
@@ -291,7 +291,7 @@ static void qla4xxx_status_entry(struct scsi_qla_host *ha,*/ DEBUG2(ql4_printk(KERN_INFO, ha, - "scsi%ld:%d:%d:%d: %s: Dropped frame(s) detected (0x%x of 0x%x bytes).\n", + "scsi%ld:%d:%d:%llu: %s: Dropped frame(s) detected (0x%x of 0x%x bytes).\n", ha->host_no, cmd->device->channel, cmd->device->id,
@@ -313,7 +313,7 @@ check_scsi_status:case SCS_DEVICE_LOGGED_OUT :case SCS_DEVICE_UNAVAILABLE : -DEBUG2 (printk (KERN_INFO "scsi%ld:%d:%d:%d: SCS_DEVICE " +DEBUG2 (printk (KERN_INFO "scsi%ld:%d:%d:%llu: SCS_DEVICE " "state: 0x%x\n" , ha->host_no, cmd->device->channel, cmd->device->id, cmd->device->lun, sts_entry->completionStatus));
@@ -333,7 +333,7 @@ check_scsi_status:* SCSI Mid-Layer handles device queue full */ cmd->result =DID_OK <<16 | sts_entry->scsiStatus; - DEBUG2(printk("scsi%ld:%d:%d: %s: QUEUE FULL detected " + DEBUG2(printk("scsi%ld:%d:%llu: %s: QUEUE FULL detected " "compl=%02x, scsi=%02x, state=%02x, iFlags=%02x," " iResp=%02x\n", ha->host_no, cmd->device->id, cmd->device->lun, __func__,
drivers/scsi/qla4xxx/ql4_mbx.c +4 -4
@@ -1105,7 +1105,7 @@ int qla4xxx_abort_task(struct scsi_qla_host *ha, struct srb *srb)if (mbox_sts[0 ] !=MBOX_STS_COMMAND_COMPLETE ) { status =QLA_ERROR ; -DEBUG2 (printk (KERN_WARNING "scsi%ld:%d:%d: abort task FAILED: " +DEBUG2 (printk (KERN_WARNING "scsi%ld:%d:%llu: abort task FAILED: " "mbx0=%04X, mb1=%04X, mb2=%04X, mb3=%04X, mb4=%04X\n" , ha->host_no, cmd->device->id, cmd->device->lun, mbox_sts[0 ], mbox_sts[1 ], mbox_sts[2 ], mbox_sts[3 ], mbox_sts[4 ]));
@@ -1125,13 +1125,13 @@ int qla4xxx_abort_task(struct scsi_qla_host *ha, struct srb *srb)* are valid before calling this routine. **/ int qla4xxx_reset_lun (struct scsi_qla_host * ha,struct ddb_entry * ddb_entry, -int lun) +uint64_t lun) {uint32_t mbox_cmd[MBOX_REG_COUNT ];uint32_t mbox_sts[MBOX_REG_COUNT ];int status =QLA_SUCCESS ; -DEBUG2 (printk ("scsi%ld:%d:%d: lun reset issued\n" , ha->host_no, +DEBUG2 (printk ("scsi%ld:%d:%llu: lun reset issued\n" , ha->host_no, ddb_entry->fw_ddb_index, lun));/*
@@ -1143,7 +1143,7 @@ int qla4xxx_reset_lun(struct scsi_qla_host * ha, struct ddb_entry * ddb_entry, mbox_cmd[0 ] =MBOX_CMD_LUN_RESET ; mbox_cmd[1 ] = ddb_entry->fw_ddb_index; - mbox_cmd[2 ] = lun <<8 ; + mbox_cmd[2 ] = (lun &0xFFFFFFFF ); mbox_cmd[5 ] =0x01 ;/* Immediate Command Enable */ qla4xxx_mailbox_command (ha,MBOX_REG_COUNT ,1 , &mbox_cmd[0 ], &mbox_sts[0 ]);
drivers/scsi/qla4xxx/ql4_os.c +9 -9
@@ -5783,14 +5783,14 @@ static int qla4xxx_eh_abort(struct scsi_cmnd *cmd) {struct scsi_qla_host *ha =to_qla_host (cmd->device->host);unsigned int id = cmd->device->id; -unsigned int lun = cmd->device->lun; +uint64_t lun = cmd->device->lun;unsigned long flags;struct srb *srb =NULL ;int ret =SUCCESS ;int wait =0 ;ql4_printk (KERN_INFO , ha, -"scsi%ld:%d:%d: Abort command issued cmd=%p\n" , +"scsi%ld:%d:%llu: Abort command issued cmd=%p\n" , ha->host_no, id, lun, cmd);spin_lock_irqsave (&ha->hardware_lock, flags);
@@ -5803,11 +5803,11 @@ static int qla4xxx_eh_abort(struct scsi_cmnd *cmd)spin_unlock_irqrestore (&ha->hardware_lock, flags);if (qla4xxx_abort_task (ha, srb) !=QLA_SUCCESS ) { -DEBUG3 (printk ("scsi%ld:%d:%d: Abort_task mbx failed.\n" , +DEBUG3 (printk ("scsi%ld:%d:%llu: Abort_task mbx failed.\n" , ha->host_no, id, lun)); ret =FAILED ; }else { -DEBUG3 (printk ("scsi%ld:%d:%d: Abort_task mbx success.\n" , +DEBUG3 (printk ("scsi%ld:%d:%llu: Abort_task mbx success.\n" , ha->host_no, id, lun)); wait =1 ; }
@@ -5817,14 +5817,14 @@ static int qla4xxx_eh_abort(struct scsi_cmnd *cmd)/* Wait for command to complete */ if (wait) {if (!qla4xxx_eh_wait_on_command (ha, cmd)) { -DEBUG2 (printk ("scsi%ld:%d:%d: Abort handler timed out\n" , +DEBUG2 (printk ("scsi%ld:%d:%llu: Abort handler timed out\n" , ha->host_no, id, lun)); ret =FAILED ; } }ql4_printk (KERN_INFO , ha, -"scsi%ld:%d:%d: Abort command - %s\n" , +"scsi%ld:%d:%llu: Abort command - %s\n" , ha->host_no, id, lun, (ret ==SUCCESS ) ?"succeeded" :"failed" );return ret;
@@ -5852,7 +5852,7 @@ static int qla4xxx_eh_device_reset(struct scsi_cmnd *cmd) ret =FAILED ;ql4_printk (KERN_INFO , ha, -"scsi%ld:%d:%d:%d: DEVICE RESET ISSUED.\n" , ha->host_no, +"scsi%ld:%d:%d:%llu: DEVICE RESET ISSUED.\n" , ha->host_no, cmd->device->channel, cmd->device->id, cmd->device->lun); DEBUG2(printk(KERN_INFO
@@ -5882,7 +5882,7 @@ static int qla4xxx_eh_device_reset(struct scsi_cmnd *cmd) goto eh_dev_reset_done;ql4_printk (KERN_INFO , ha, -"scsi(%ld:%d:%d:%d): DEVICE RESET SUCCEEDED.\n" , +"scsi(%ld:%d:%d:%llu): DEVICE RESET SUCCEEDED.\n" , ha->host_no, cmd->device->channel, cmd->device->id, cmd->device->lun);
@@ -5999,7 +5999,7 @@ static int qla4xxx_eh_host_reset(struct scsi_cmnd *cmd) }ql4_printk (KERN_INFO , ha, -"scsi(%ld:%d:%d:%d): HOST RESET ISSUED.\n" , ha->host_no, +"scsi(%ld:%d:%d:%llu): HOST RESET ISSUED.\n" , ha->host_no, cmd->device->channel, cmd->device->id, cmd->device->lun);if (qla4xxx_wait_for_hba_online (ha) !=QLA_SUCCESS ) {
drivers/scsi/scsi.c +4 -4
@@ -1243,7 +1243,7 @@ EXPORT_SYMBOL(__starget_for_each_device);* really want to use scsi_device_lookup_by_target instead. **/ struct scsi_device *__scsi_device_lookup_by_target (struct scsi_target *starget, -uint lun) +uint64_t lun) {struct scsi_device *sdev;
@@ -1268,7 +1268,7 @@ EXPORT_SYMBOL(__scsi_device_lookup_by_target);* needs to be released with scsi_device_put once you're done with it. **/ struct scsi_device *scsi_device_lookup_by_target (struct scsi_target *starget, -uint lun) +uint64_t lun) {struct scsi_device *sdev;struct Scsi_Host *shost =dev_to_shost (starget->dev.parent);
@@ -1301,7 +1301,7 @@ EXPORT_SYMBOL(scsi_device_lookup_by_target);* really want to use scsi_device_lookup instead. **/ struct scsi_device *__scsi_device_lookup (struct Scsi_Host *shost, -uint channel,uint id,uint lun) +uint channel,uint id,uint64_t lun) {struct scsi_device *sdev;
@@ -1327,7 +1327,7 @@ EXPORT_SYMBOL(__scsi_device_lookup);* needs to be released with scsi_device_put once you're done with it. **/ struct scsi_device *scsi_device_lookup (struct Scsi_Host *shost, -uint channel,uint id,uint lun) +uint channel,uint id,uint64_t lun) {struct scsi_device *sdev;unsigned long flags;
drivers/scsi/scsi_debug.c +8 -7
@@ -225,9 +225,9 @@ struct sdebug_dev_info {unsigned char sense_buff[SDEBUG_SENSE_LEN ];/* weak nexus */ unsigned int channel;unsigned int target; -unsigned int lun; +uint64_t lun;struct sdebug_host_info *sdbg_host; -unsigned int wlun; +uint64_t wlun;char reset;char stopped;char used;
@@ -2247,7 +2247,8 @@ static int resp_report_luns(struct scsi_cmnd * scp, struct sdebug_dev_info * devip) {unsigned int alloc_len; -int lun_cnt, i, upper, num, n, wlun, lun; +int lun_cnt, i, upper, num, n; +uint64_t wlun, lun;unsigned char *cmd = (unsigned char *)scp->cmnd;int select_report = (int )cmd[2 ];struct scsi_lun *one_lun;
@@ -2430,7 +2431,7 @@ static struct sdebug_dev_info * devInfoReg(struct scsi_device * sdev)static int scsi_debug_slave_alloc (struct scsi_device *sdp) {if (SCSI_DEBUG_OPT_NOISE & scsi_debug_opts) -printk (KERN_INFO "scsi_debug: slave_alloc <%u %u %u %u>\n" , +printk (KERN_INFO "scsi_debug: slave_alloc <%u %u %u %llu>\n" , sdp->host->host_no, sdp->channel, sdp->id, sdp->lun);queue_flag_set_unlocked (QUEUE_FLAG_BIDI , sdp->request_queue);return 0 ;
@@ -2441,7 +2442,7 @@ static int scsi_debug_slave_configure(struct scsi_device *sdp)struct sdebug_dev_info *devip;if (SCSI_DEBUG_OPT_NOISE & scsi_debug_opts) -printk (KERN_INFO "scsi_debug: slave_configure <%u %u %u %u>\n" , +printk (KERN_INFO "scsi_debug: slave_configure <%u %u %u %llu>\n" , sdp->host->host_no, sdp->channel, sdp->id, sdp->lun);if (sdp->host->max_cmd_len !=SCSI_DEBUG_MAX_CMD_LEN ) sdp->host->max_cmd_len =SCSI_DEBUG_MAX_CMD_LEN ;
@@ -2464,7 +2465,7 @@ static void scsi_debug_slave_destroy(struct scsi_device *sdp) (struct sdebug_dev_info *)sdp->hostdata;if (SCSI_DEBUG_OPT_NOISE & scsi_debug_opts) -printk (KERN_INFO "scsi_debug: slave_destroy <%u %u %u %u>\n" , +printk (KERN_INFO "scsi_debug: slave_destroy <%u %u %u %llu>\n" , sdp->host->host_no, sdp->channel, sdp->id, sdp->lun);if (devip) {/* make this slot available for re-use */
@@ -2676,7 +2677,7 @@ static int schedule_resp(struct scsi_cmnd * cmnd,if (scsi_result) {struct scsi_device * sdp = cmnd->device; -printk (KERN_INFO "scsi_debug: <%u %u %u %u> " +printk (KERN_INFO "scsi_debug: <%u %u %u %llu> " "non-zero result=0x%x\n" , sdp->host->host_no, sdp->channel, sdp->id, sdp->lun, scsi_result); }
drivers/scsi/scsi_priv.h +1 -1
@@ -112,7 +112,7 @@ extern void scsi_exit_procfs(void);/* scsi_scan.c */ extern int scsi_complete_async_scans (void );extern int scsi_scan_host_selected (struct Scsi_Host *,unsigned int , -unsigned int ,unsigned int ,int ); +unsigned int ,uint64_t ,int );extern void scsi_forget_host (struct Scsi_Host *);extern void scsi_rescan_device (struct device *);
drivers/scsi/scsi_proc.c +1 -1
@@ -196,7 +196,7 @@ static int proc_print_scsidevice(struct device *dev, void *data) sdev =to_scsi_device (dev);seq_printf (s, -"Host: scsi%d Channel: %02d Id: %02d Lun: %02d\n Vendor: " , +"Host: scsi%d Channel: %02d Id: %02d Lun: %02llu\n Vendor: " , sdev->host->host_no, sdev->channel, sdev->id, sdev->lun);for (i =0 ; i <8 ; i++) {if (sdev->vendor[i] >=0x20 )
drivers/scsi/scsi_scan.c +19 -35
142 lines not on this page · raw message
drivers/scsi/scsi_sysfs.c +7 -7
@@ -80,7 +80,7 @@ const char *scsi_host_state_name(enum scsi_host_state state)return name; } -static int check_set (unsigned int *val,char *src) +static int check_set (unsigned long long *val,char *src) {char *last;
@@ -90,7 +90,7 @@ static int check_set(unsigned int *val, char *src)/* * Doesn't check for int overflow */ - *val =simple_strtoul (src, &last,0 ); + *val =simple_strtoull (src, &last,0 );if (*last !='\0' )return 1 ; }
@@ -99,11 +99,11 @@ static int check_set(unsigned int *val, char *src)static int scsi_scan (struct Scsi_Host *shost,const char *str) { -char s1[15 ], s2[15 ], s3[15 ], junk; -unsigned int channel, id, lun; +char s1[15 ], s2[15 ], s3[17 ], junk; +unsigned long long channel, id, lun;int res; - res =sscanf (str,"%10s %10s %10s %c" , s1, s2, s3, &junk); + res =sscanf (str,"%10s %10s %16s %c" , s1, s2, s3, &junk);if (res !=3 )return -EINVAL ;if (check_set (&channel, s1))
@@ -1110,13 +1110,13 @@ void scsi_sysfs_device_initialize(struct scsi_device *sdev)device_initialize (&sdev->sdev_gendev); sdev->sdev_gendev.bus = &scsi_bus_type; sdev->sdev_gendev.type = &scsi_dev_type; -dev_set_name (&sdev->sdev_gendev,"%d:%d:%d:%d" , +dev_set_name (&sdev->sdev_gendev,"%d:%d:%d:%llu" , sdev->host->host_no, sdev->channel, sdev->id, sdev->lun);device_initialize (&sdev->sdev_dev); sdev->sdev_dev.parent =get_device (&sdev->sdev_gendev); sdev->sdev_dev.class = &sdev_class; -dev_set_name (&sdev->sdev_dev,"%d:%d:%d:%d" , +dev_set_name (&sdev->sdev_dev,"%d:%d:%d:%llu" , sdev->host->host_no, sdev->channel, sdev->id, sdev->lun); sdev->scsi_level = starget->scsi_level;transport_setup_device (&sdev->sdev_gendev);
drivers/scsi/scsi_transport_fc.c +2 -2
@@ -2093,7 +2093,7 @@ fc_timed_out(struct scsi_cmnd *scmd)* on the rport. */ static void -fc_user_scan_tgt (struct Scsi_Host *shost,uint channel,uint id,uint lun) +fc_user_scan_tgt (struct Scsi_Host *shost,uint channel,uint id,uint64_t lun) {struct fc_rport *rport;unsigned long flags;
@@ -2125,7 +2125,7 @@ fc_user_scan_tgt(struct Scsi_Host *shost, uint channel, uint id, uint lun)* object as the parent. */ static int -fc_user_scan (struct Scsi_Host *shost,uint channel,uint id,uint lun) +fc_user_scan (struct Scsi_Host *shost,uint channel,uint id,uint64_t lun) {uint chlo, chhi;uint tgtlo, tgthi;
drivers/scsi/scsi_transport_iscsi.c +2 -2
@@ -773,7 +773,7 @@ EXPORT_SYMBOL_GPL(iscsi_scan_finished);struct iscsi_scan_data {unsigned int channel;unsigned int id; -unsigned int lun; +uint64_t lun; };static int iscsi_user_scan_session (struct device *dev,void *data)
@@ -820,7 +820,7 @@ user_scan_exit: }static int iscsi_user_scan (struct Scsi_Host *shost,uint channel, -uint id,uint lun) +uint id,uint64_t lun) {struct iscsi_scan_data scan_data;
drivers/scsi/scsi_transport_sas.c +1 -1
@@ -1706,7 +1706,7 @@ EXPORT_SYMBOL(scsi_is_sas_rphy);*/ static int sas_user_scan (struct Scsi_Host *shost,uint channel, -uint id,uint lun) +uint id,uint64_t lun) {struct sas_host_attrs *sas_host =to_sas_host_attrs (shost);struct sas_rphy *rphy;
drivers/scsi/sg.c +2 -2
@@ -2492,7 +2492,7 @@ static int sg_proc_seq_show_dev(struct seq_file *s, void *v)read_lock_irqsave (&sg_index_lock, iflags); sdp = it ?sg_lookup_dev (it->index) :NULL ;if (sdp && (scsidp = sdp->device) && (!sdp->detached)) - seq_printf(s, "%d\t%d\t%d\t%d\t%d\t%d\t%d\t%d\t%d\n", + seq_printf(s, "%d\t%d\t%d\t%llu\t%d\t%d\t%d\t%d\t%d\n", scsidp->host->host_no, scsidp->channel, scsidp->id, scsidp->lun, (int) scsidp->type, 1,
@@ -2621,7 +2621,7 @@ static int sg_proc_seq_show_debug(struct seq_file *s, void *v)seq_printf (s,"detached pending close " ); else seq_printf - (s, "scsi%d chan=%d id=%d lun=%d em=%d", + (s, "scsi%d chan=%d id=%d lun=%llu em=%d", scsidp->host->host_no, scsidp->channel, scsidp->id, scsidp->lun,
drivers/scsi/sym53c8xx_2/sym_glue.c +1 -1
@@ -851,7 +851,7 @@ static void sym53c8xx_slave_destroy(struct scsi_device *sdev)* so let's try to stop all on-going I/O. */ starget_printk (KERN_WARNING , tp->starget, -"Removing busy LCB (%d)\n" , sdev->lun); +"Removing busy LCB (%d)\n" , (u8 )sdev->lun);sym_reset_scsi_bus (np,1 ); }
drivers/scsi/sym53c8xx_2/sym_hipd.h +1 -1
@@ -581,7 +581,7 @@ struct sym_pmc {#define sym_lp (tp, lun) (!lun) ? (tp)->lun0p : NULL#else #define sym_lp (tp, lun) \ - (!lun) ? (tp)->lun0p : (tp)->lunmp ? (tp)->lunmp[(lun)] : NULL + (!lun) ? (tp)->lun0p : (tp)->lunmp ? (tp)->lunmp[((u8)lun)] : NULL#endif /*
drivers/target/loopback/tcm_loop.c +2 -2
@@ -220,7 +220,7 @@ static int tcm_loop_queuecommand(struct Scsi_Host *sh, struct scsi_cmnd *sc) {struct tcm_loop_cmd *tl_cmd; -pr_debug ("tcm_loop_queuecommand() %d:%d:%d:%d got CDB: 0x%02x" +pr_debug ("tcm_loop_queuecommand() %d:%d:%d:%llu got CDB: 0x%02x" " scsi_buf_len: %u\n" , sc->device->host->host_no, sc->device->id, sc->device->channel, sc->device->lun, sc->cmnd[0 ],scsi_bufflen (sc));
@@ -301,7 +301,7 @@ static int tcm_loop_device_reset(struct scsi_cmnd *sc)/* * Locate the underlying TCM struct se_lun from sc->device->lun */ -if (transport_lookup_tmr_lun (se_cmd, sc->device->lun) <0 ) +if (transport_lookup_tmr_lun (se_cmd, (u32 )sc->device->lun) <0 ) goto release;/* * Queue the TMR to TCM Core and sleep waiting for tcm_loop_queue_tm_rsp()
drivers/target/target_core_pscsi.c +6 -6
@@ -312,7 +312,7 @@ static int pscsi_add_device_to_list(struct se_device *dev,if (!sd->queue_depth) { sd->queue_depth =PSCSI_DEFAULT_QUEUEDEPTH ; -pr_err ("Set broken SCSI Device %d:%d:%d" +pr_err ("Set broken SCSI Device %d:%d:%llu" " queue_depth to %d\n" , sd->channel, sd->id, sd->lun, sd->queue_depth); }
@@ -375,7 +375,7 @@ static int pscsi_create_type_disk(struct se_device *dev, struct scsi_device *sd)int ret;if (scsi_device_get (sd)) { -pr_err ("scsi_device_get() failed for %d:%d:%d:%d\n" , +pr_err ("scsi_device_get() failed for %d:%d:%d:%llu\n" , sh->host_no, sd->channel, sd->id, sd->lun);spin_unlock_irq (sh->host_lock);return -EIO ;
@@ -401,7 +401,7 @@ static int pscsi_create_type_disk(struct se_device *dev, struct scsi_device *sd)return ret; } -pr_debug ("CORE_PSCSI[%d] - Added TYPE_DISK for %d:%d:%d:%d\n" , +pr_debug ("CORE_PSCSI[%d] - Added TYPE_DISK for %d:%d:%d:%llu\n" , phv->phv_host_id, sh->host_no, sd->channel, sd->id, sd->lun);return 0 ; }
@@ -417,7 +417,7 @@ static int pscsi_create_type_rom(struct se_device *dev, struct scsi_device *sd)int ret;if (scsi_device_get (sd)) { -pr_err ("scsi_device_get() failed for %d:%d:%d:%d\n" , +pr_err ("scsi_device_get() failed for %d:%d:%d:%llu\n" , sh->host_no, sd->channel, sd->id, sd->lun);spin_unlock_irq (sh->host_lock);return -EIO ;
@@ -429,7 +429,7 @@ static int pscsi_create_type_rom(struct se_device *dev, struct scsi_device *sd)scsi_device_put (sd);return ret; } -pr_debug ("CORE_PSCSI[%d] - Added Type: %s for %d:%d:%d:%d\n" , +pr_debug ("CORE_PSCSI[%d] - Added Type: %s for %d:%d:%d:%llu\n" , phv->phv_host_id,scsi_device_type (sd->type), sh->host_no, sd->channel, sd->id, sd->lun);
@@ -452,7 +452,7 @@ static int pscsi_create_type_other(struct se_device *dev,if (ret)return ret; -pr_debug ("CORE_PSCSI[%d] - Added Type: %s for %d:%d:%d:%d\n" , +pr_debug ("CORE_PSCSI[%d] - Added Type: %s for %d:%d:%d:%llu\n" , phv->phv_host_id,scsi_device_type (sd->type), sh->host_no, sd->channel, sd->id, sd->lun);return 0 ;
include/scsi/scsi.h +1 -1
@@ -378,7 +378,7 @@ struct scsi_lun {#define SCSI_W_LUN_ACCESS_CONTROL (SCSI_W_LUN_BASE + 2)#define SCSI_W_LUN_TARGET_LOG_PAGE (SCSI_W_LUN_BASE + 3) -static inline int scsi_is_wlun (unsigned int lun) +static inline int scsi_is_wlun (uint64_t lun) {return (lun &0xff00 ) ==SCSI_W_LUN_BASE ; }
include/scsi/scsi_device.h +11 -11
@@ -91,8 +91,8 @@ struct scsi_device {unsigned long last_queue_ramp_up;/* last queue ramp up time */ -unsigned int id, lun, channel; - +unsigned int id, channel; +uint64_t lun;unsigned int manufacturer;/* Manufacturer of device, for using * vendor-specific cmd's */ unsigned sector_size;/* size in bytes */
@@ -290,9 +290,9 @@ static inline struct scsi_target *scsi_target(struct scsi_device *sdev) dev_printk(prefix, &(starget)->dev, fmt, ##a) extern struct scsi_device *__scsi_add_device(struct Scsi_Host *, - uint, uint, uint, void *hostdata); + uint, uint, uint64_t, void *hostdata);extern int scsi_add_device (struct Scsi_Host *host,uint channel, -uint target,uint lun); +uint target,uint64_t lun);extern int scsi_register_device_handler (struct scsi_device_handler *scsi_dh);extern void scsi_remove_device (struct scsi_device *);extern int scsi_unregister_device_handler (struct scsi_device_handler *scsi_dh);
@@ -300,13 +300,13 @@ extern int scsi_unregister_device_handler(struct scsi_device_handler *scsi_dh);extern int scsi_device_get (struct scsi_device *);extern void scsi_device_put (struct scsi_device *);extern struct scsi_device *scsi_device_lookup (struct Scsi_Host *, -uint ,uint ,uint ); +uint ,uint ,uint64_t );extern struct scsi_device *__scsi_device_lookup (struct Scsi_Host *, -uint ,uint ,uint ); +uint ,uint ,uint64_t );extern struct scsi_device *scsi_device_lookup_by_target (struct scsi_target *, -uint ); +uint64_t );extern struct scsi_device *__scsi_device_lookup_by_target (struct scsi_target *, -uint ); +uint64_t );extern void starget_for_each_device (struct scsi_target *,void *,void (*fn)(struct scsi_device *,void *)); extern void __starget_for_each_device(struct scsi_target *, void *,
@@ -379,13 +379,13 @@ extern void scsi_device_resume(struct scsi_device *sdev);extern void scsi_target_quiesce (struct scsi_target *);extern void scsi_target_resume (struct scsi_target *);extern void scsi_scan_target (struct device *parent,unsigned int channel, -unsigned int id,unsigned int lun,int rescan); +unsigned int id,uint64_t lun,int rescan);extern void scsi_target_reap (struct scsi_target *);extern void scsi_target_block (struct device *);extern void scsi_target_unblock (struct device *,enum scsi_device_state );extern void scsi_remove_target (struct device *); -extern void int_to_scsilun (unsigned int ,struct scsi_lun *); -extern int scsilun_to_int (struct scsi_lun *); +extern void int_to_scsilun (uint64_t ,struct scsi_lun *); +extern uint64_t scsilun_to_int (struct scsi_lun *);extern const char *scsi_device_state_name (enum scsi_device_state );extern int scsi_is_sdev_device (const struct device *);extern int scsi_is_target_device (const struct device *);
include/scsi/scsi_transport.h +1 -1
@@ -35,7 +35,7 @@ struct scsi_transport_template {/* * If set, called from sysfs and legacy procfs rescanning code. */ -int (*user_scan)(struct Scsi_Host *,uint ,uint ,uint ); +int (*user_scan)(struct Scsi_Host *,uint ,uint ,uint64_t );/* The size of the specific transport attribute structure (a * space of this size will be left at the end of the
Signature · 1 line
1.7.4.2
Re: [PATCH 2/4] scsi: use 64-bit LUNs
Hi Hannes,
I like the idea and most of the patch set, so I only have a few questions left and some review comments below.
Just curious: Do you also plan to adapt systemd/udev, especially path_id for fc transport with its open coded copy of int_to_scsilun()?
Since I don't see zfcp touched in this patch set, assuming this set will get merged, I plan to adapt a few spots in zfcp that might not work with 64 bit luns out of the box although most of it already works with 64 bit luns inside.
Speaking of opaque handling of scsi luns: Lately I noticed that some sg3_utils tools decode the lun format and only report parts of the entire 64 bit fcp lun, e.g. sg_scan or "sg_luns -d". I don't have enough historical scsi experience to know why that is, maybe because of some SPI background. By itself this is not a problem, however, rescan-scsi-bus.sh makes use of those scsi lun parts and then fails when matching those with the full scsi lun exposed by the midlayer to user space. E.g. with flat space addresses of IBM DS8000 this does not seem to work:
# sg_luns -v -s2 -d /dev/sg2 | head
report luns cdb: a0 00 02 00 00 00 00 00 20 00 00 00
report luns: requested 8192 bytes but got 4112 bytes
Lun list length = 4104 which imples 513 lun entries
Report luns [select_report=2]:
c101000000000000
REPORT LUNS well known logical unit
4020400000000000
Flat space addressing: lun=32
4020400100000000
Flat space addressing: lun=32
4020400200000000
Flat space addressing: lun=32
^^<=== 0x20 of the lun's 1st shortDid I overlook something or are rescan-scsi-bus.sh and maybe other tools really broken with some "modern" scsi targets?
Quoted 23 lines · Hannes Reinecke
The SCSI standard uses a 64-bit value for LUNs, and large arrays employing large LUN numbers become more and more common. So move the linux SCSI stack to use 64-bit LUN numbers.
Signed-off-by Hannes Reinecke <[email protected]>---
drivers/scsi/scsi_proc.c | 2 +-drivers/scsi/scsi_sysfs.c | 14 ++++---- drivers/scsi/scsi_transport_fc.c | 4 +- drivers/scsi/scsi_transport_iscsi.c | 4 +- drivers/scsi/scsi_transport_sas.c | 2 +- drivers/scsi/sg.c | 4 +-include/scsi/scsi.h | 2 +- include/scsi/scsi_device.h | 22 ++++++------ include/scsi/scsi_transport.h | 2 +- 50 files changed, 239 insertions(+), 247 deletions(-)
drivers/scsi/scsi_proc.c static int proc_print_scsidevice(struct device *dev, void *data) · line 202
Quoted 8 lines
drivers/scsi/scsi_proc.c +1
-1@@ -196,7 +196,7 @@ static int proc_print_scsidevice(struct device *dev, void *data) sdev =to_scsi_device (dev);seq_printf (s, -"Host: scsi%d Channel: %02d Id: %02d Lun: %02d\n Vendor: " , +"Host: scsi%d Channel: %02d Id: %02d Lun: %02llu\n Vendor: " , sdev->host->host_no, sdev->channel, sdev->id, sdev->lun);for (i =0 ; i <8 ; i++) {if (sdev->vendor[i] >=0x20 )
Is it intentional that you did not adapt scsi_add_single_device(), scsi_remove_single_device(), proc_scsi_write() to cope with 64 bit luns? (in the admittedly old and probably somewhat deprecated procfs interface; but then again, proc_print_scsidevice can output 64 bit luns now)
Quoted 23 lines
drivers/scsi/scsi_sysfs.c +2
-2@@ -80,7 +80,7 @@ const char *scsi_host_state_name(enum scsi_host_state state)return name; } -static int check_set (unsigned int *val,char *src) +static int check_set (unsigned long long *val,char *src) {char *last;@@ -90,7 +90,7 @@ static int check_set(unsigned int *val, char *src)/* * Doesn't check for int overflow */ - *val =simple_strtoul (src, &last,0 ); + *val =simple_strtoull (src, &last,0 );if (*last !='\0' )return 1 ; }
drivers/scsi/scsi_sysfs.c static int check_set(unsigned int *val, char *src) · line 102
Quoted 6 lines
drivers/scsi/scsi_sysfs.c +1
-2@@ -99,11 +99,11 @@ static int check_set(unsigned int *val, char *src)static int scsi_scan (struct Scsi_Host *shost,const char *str) { -char s1[15 ], s2[15 ], s3[15 ], junk; -unsigned int channel, id, lun; +char s1[15 ], s2[15 ], s3[17 ], junk;
Since we use automatic base detection with the 3rd argument of simple_strtoull() being 0 in check_set() above, I think the user is free to specify the lun to scan for in decimal/octal/hex base for s3.
With 64 bits, couldn't this need a maximum of 20 decimal digits (plus '\0' termination) which is more than 16? I think this is a legitimate use case as long as the scsi lun is represented in decimal in sysfs so users might just have it from the h:c:t:l device name there. While I don't think anyone would specify the lun in octal, it could even need 22 digits.
[Maximum number of digits is ceil(ln(2**64-1)/ln(base)) if I'm not mistaken.]
drivers/scsi/scsi_sysfs.c static int check_set(unsigned int *val, char *src) · line 106
Quoted 5 lines
drivers/scsi/scsi_sysfs.c +2
-1+unsigned long long channel, id, lun;int res; - res =sscanf (str,"%10s %10s %10s %c" , s1, s2, s3, &junk); + res =sscanf (str,"%10s %10s %16s %c" , s1, s2, s3, &junk);
ditto
Quoted 18 lines
drivers/scsi/scsi_sysfs.c +0
-0if (res !=3 )return -EINVAL ;if (check_set (&channel, s1))drivers/scsi/scsi_transport_fc.c +1
-1@@ -2093,7 +2093,7 @@ fc_timed_out(struct scsi_cmnd *scmd)* on the rport. */ static void -fc_user_scan_tgt (struct Scsi_Host *shost,uint channel,uint id,uint lun) +fc_user_scan_tgt (struct Scsi_Host *shost,uint channel,uint id,uint64_t lun) {struct fc_rport *rport;unsigned long flags;
drivers/scsi/scsi_transport_fc.c fc_user_scan_tgt(struct Scsi_Host *shost, uint channel, uint id, uint lun) · line 2128
Quoted 5 lines
drivers/scsi/scsi_transport_fc.c +1
-1@@ -2125,7 +2125,7 @@ fc_user_scan_tgt(struct Scsi_Host *shost, uint channel, uint id, uint lun)* object as the parent. */ static int -fc_user_scan (struct Scsi_Host *shost,uint channel,uint id,uint lun) +fc_user_scan (struct Scsi_Host *shost,uint channel,uint id,uint64_t lun)
Is it OK, that the maximum lun 2**64-1 overlaps with SCAN_WILD_CARD==~0 from scsi.h?
drivers/scsi/sg.c
Quoted 4 lines
drivers/scsi/sg.c +0
-0
I guess we cannot adapt sg_ioctl SG_GET_SCSI_ID that easily without breaking the user space interface. But how does a user of this interface know that there are 64 bit luns in the kernel but the ioctl cannot handle the new kernel functionality (and may be affected by aliasing)?
Quoted 10 lines
drivers/scsi/sg.c +1
-1@@ -2492,7 +2492,7 @@ static int sg_proc_seq_show_dev(struct seq_file *s, void *v)read_lock_irqsave (&sg_index_lock, iflags); sdp = it ?sg_lookup_dev (it->index) :NULL ;if (sdp && (scsidp = sdp->device) && (!sdp->detached)) - seq_printf(s, "%d\t%d\t%d\t%d\t%d\t%d\t%d\t%d\t%d\n", + seq_printf(s, "%d\t%d\t%d\t%llu\t%d\t%d\t%d\t%d\t%d\n", scsidp->host->host_no, scsidp->channel, scsidp->id, scsidp->lun, (int) scsidp->type, 1,
drivers/scsi/sg.c static int sg_proc_seq_show_debug(struct seq_file *s, void *v) · line 2627
Quoted 8 lines
drivers/scsi/sg.c +1
-1@@ -2621,7 +2621,7 @@ static int sg_proc_seq_show_debug(struct seq_file *s, void *v)seq_printf (s,"detached pending close " ); else seq_printf - (s, "scsi%d chan=%d id=%d lun=%d em=%d", + (s, "scsi%d chan=%d id=%d lun=%llu em=%d", scsidp->host->host_no, scsidp->channel, scsidp->id, scsidp->lun,
Regards,
Steffen
Linux on System z Development
IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
--
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 2/4] scsi: use 64-bit LUNs
Quoted 8 lines · Steffen Maier
Hi Hannes,
I like the idea and most of the patch set, so I only have a few questions left and some review comments below.
Just curious: Do you also plan to adapt systemd/udev, especially
path_idfor fc transport with its open coded copy ofint_to_scsilun()?
Yes.
Quoted 4 lines
Since I don't see zfcp touched in this patch set, assuming this set will get merged, I plan to adapt a few spots in zfcp that might not work with 64 bit luns out of the box although most of it already works with 64 bit luns inside.
Ah. Yes, this might be a good idea. I've already got a patch from QLogic regarding qla4xxx, so maybe we should be adding them as separate patches on top of the original patchset.
Quoted 23 lines
Speaking of opaque handling of scsi luns: Lately I noticed that some
sg3_utilstools decode the lun format and only report parts of the entire 64 bit fcp lun, e.g.sg_scanor "sg_luns-d". I don't have enough historical scsi experience to know why that is, maybe because of some SPI background. By itself this is not a problem, however,rescan-scsi-bus.shmakes use of those scsi lun parts and then fails when matching those with the full scsi lun exposed by the midlayer to user space. E.g. with flat space addresses of IBM DS8000 this does not seem to work:# sg_luns -v -s2 -d /dev/sg2 | head report luns cdb: a0 00 02 00 00 00 00 00 20 00 00 00 report luns: requested 8192 bytes but got 4112 bytes Lun list length = 4104 which imples 513 lun entries Report luns [select_report=2]: c101000000000000 REPORT LUNS well known logical unit 4020400000000000 Flat space addressing: lun=32 4020400100000000 Flat space addressing: lun=32 4020400200000000 Flat space addressing: lun=32 ^^<=== 0x20 of the lun's 1st short
Quoted 3 lines
Did I overlook something or are
rescan-scsi-bus.shand maybe other tools really broken with some "modern" scsi targets?
Should've been fixed by now.
There was a bug in rescan-scsi-bus.sh which indeed tried to decode LUNs, but that has been fixed.
Quoted 25 lines · Hannes Reinecke
Quoted 24 lines
The SCSI standard uses a 64-bit value for LUNs, and large arrays employing large LUN numbers become more and more common. So move the linux SCSI stack to use 64-bit LUN numbers.
Signed-off-by Hannes Reinecke <[email protected]>---
drivers/scsi/scsi_proc.c | 2 +-drivers/scsi/scsi_sysfs.c | 14 ++++---- drivers/scsi/scsi_transport_fc.c | 4 +- drivers/scsi/scsi_transport_iscsi.c | 4 +- drivers/scsi/scsi_transport_sas.c | 2 +- drivers/scsi/sg.c | 4 +-include/scsi/scsi.h | 2 +- include/scsi/scsi_device.h | 22 ++++++------ include/scsi/scsi_transport.h | 2 +- 50 files changed, 239 insertions(+), 247 deletions(-)drivers/scsi/scsi_proc.c +0
-0@@ -196,7 +196,7 @@ static int proc_print_scsidevice(struct device *dev, void *data)
Quoted 13 lines
drivers/scsi/scsi_proc.c static int proc_print_scsidevice(struct device *dev, void *data) · line 202
Quoted 7 lines
drivers/scsi/scsi_proc.c +1
-1sdev =to_scsi_device (dev);seq_printf (s, -"Host: scsi%d Channel: %02d Id: %02d Lun: %02d\n Vendor: " , +"Host: scsi%d Channel: %02d Id: %02d Lun: %02llu\n Vendor: " , sdev->host->host_no, sdev->channel, sdev->id, sdev->lun);for (i =0 ; i <8 ; i++) {if (sdev->vendor[i] >=0x20 )Is it intentional that you did not adapt
scsi_add_single_device(),scsi_remove_single_device(),proc_scsi_write()to cope with 64 bit luns? (in the admittedly old and probably somewhat deprecated procfs interface; but then again,proc_print_scsidevicecan output 64 bit luns now)
I deliberately did _not_ touch procfs (apart from the necessary bits). Precisely because it's being marked as deprecated.
Quoted 24 lines
Quoted 24 lines
drivers/scsi/scsi_sysfs.c +2
-2@@ -80,7 +80,7 @@ const char *scsi_host_state_name(enum scsi_host_state state)return name; } -static int check_set (unsigned int *val,char *src) +static int check_set (unsigned long long *val,char *src) {char *last;@@ -90,7 +90,7 @@ static int check_set(unsigned int *val, char *src)/* * Doesn't check for int overflow */ - *val =simple_strtoul (src, &last,0 ); + *val =simple_strtoull (src, &last,0 );if (*last !='\0' )return 1 ; }@@ -99,11 +99,11 @@ static int check_set(unsigned int *val, char *src)
Quoted 10 lines
drivers/scsi/scsi_sysfs.c static int check_set(unsigned int *val, char *src) · line 102
Quoted 5 lines
drivers/scsi/scsi_sysfs.c +1
-2static int scsi_scan (struct Scsi_Host *shost,const char *str) { -char s1[15 ], s2[15 ], s3[15 ], junk; -unsigned int channel, id, lun; +char s1[15 ], s2[15 ], s3[17 ], junk;Since we use automatic base detection with the 3rd argument of
simple_strtoull()being 0 incheck_set()above, I think the user is free to specify the lun to scan for in decimal/octal/hex base for s3.
Yes, we could (in principle).
However, it's not quite clear to me what the user is supposed to enter here in these cases.
Original output from REPORT LUNS?
Output from scsilun_to_int?
So we would need to come up with a proper naming scheme to identify these kind of things.
However, this should be done with another patch as it's a different story. scsi_debug has a similar issue, and will need to be updated for this, too.
Quoted 6 lines
With 64 bits, couldn't this need a maximum of 20 decimal digits (plus '\0' termination) which is more than 16? I think this is a legitimate use case as long as the scsi lun is represented in decimal in sysfs so users might just have it from the h:c:t:l device name there. While I don't think anyone would specify the lun in octal, it could even need 22 digits. [Maximum number of digits is ceil(ln(2**64-1)/ln(base)) if I'm not mistaken.]
Yeah, you're right. I need to increase this to the correct size.
Quoted 25 lines
drivers/scsi/scsi_sysfs.c static int check_set(unsigned int *val, char *src) · line 106
Quoted 5 lines
drivers/scsi/scsi_sysfs.c +2
-1+unsigned long long channel, id, lun;int res; - res =sscanf (str,"%10s %10s %10s %c" , s1, s2, s3, &junk); + res =sscanf (str,"%10s %10s %16s %c" , s1, s2, s3, &junk);ditto
Quoted 17 lines
drivers/scsi/scsi_sysfs.c +0
-0if (res !=3 )return -EINVAL ;if (check_set (&channel, s1))drivers/scsi/scsi_transport_fc.c +1
-1@@ -2093,7 +2093,7 @@ fc_timed_out(struct scsi_cmnd *scmd)* on the rport. */ static void -fc_user_scan_tgt (struct Scsi_Host *shost,uint channel,uint id,uint lun) +fc_user_scan_tgt (struct Scsi_Host *shost,uint channel,uint id,uint64_t lun) {struct fc_rport *rport;unsigned long flags;
Quoted 9 lines
drivers/scsi/scsi_transport_fc.c fc_user_scan_tgt(struct Scsi_Host *shost, uint channel, uint id, uint lun) · line 2128
Quoted 6 lines
drivers/scsi/scsi_transport_fc.c +1
-1@@ -2125,7 +2125,7 @@ fc_user_scan_tgt(struct Scsi_Host *shost, uint channel, uint id, uint lun)* object as the parent. */ static int -fc_user_scan (struct Scsi_Host *shost,uint channel,uint id,uint lun) +fc_user_scan (struct Scsi_Host *shost,uint channel,uint id,uint64_t lun)Is it OK, that the maximum lun 2**64-1 overlaps with SCAN_WILD_CARD==~0 from
scsi.h?
It's the same as today, isn't it?
Quoted 10 lines
drivers/scsi/sg.c
Quoted 4 lines
drivers/scsi/sg.c +0
-0I guess we cannot adapt
sg_ioctlSG_GET_SCSI_IDthat easily without breaking the user space interface. But how does a user of this interface know that there are 64 bit luns in the kernel but the ioctl cannot handle the new kernel functionality (and may be affected by aliasing)?
Hmm. I thought that SG_GET_SCSI_ID is largely deprecated by now; every user should be converted to use sysfs. But yeah, you're right. I'll be looking into that.
Thanks for your input.
Cheers,
Hannes
Signature · 8 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
Douglas Gilbert
maintainerRe: [PATCH 2/4] scsi: use 64-bit LUNs
In reply to Steffen MaierQuoted 10 lines · Steffen Maier
Hi Hannes,
I like the idea and most of the patch set, so I only have a few questions left and some review comments below.
Just curious: Do you also plan to adapt systemd/udev, especially
path_idfor fc transport with its open coded copy ofint_to_scsilun()?Since I don't see zfcp touched in this patch set, assuming this set will get merged, I plan to adapt a few spots in zfcp that might not work with 64 bit luns out of the box although most of it already works with 64 bit luns inside.
Speaking of opaque handling of scsi luns: Lately I noticed that some
sg3_utilstools decode the lun format and only report parts of the entire 64 bit fcp lun, e.g.sg_scanor "sg_luns-d". I don't have enough historical scsi experience to know why that is, maybe because of some SPI background. By itself this is not a problem, however,rescan-scsi-bus.shmakes use of those scsi lun parts and then fails when matching those with the full scsi lun exposed by the midlayer to user space. E.g. with flat space addresses of IBM DS8000 this does not seem to work:
Quoted 14 lines
# sg_luns -v -s2 -d /dev/sg2 | head
report luns cdb: a0 00 02 00 00 00 00 00 20 00 00 00
report luns: requested 8192 bytes but got 4112 bytes
Lun list length = 4104 which imples 513 lun entries
Report luns [select_report=2]:
c101000000000000
REPORT LUNS well known logical unit
4020400000000000
Flat space addressing: lun=32
4020400100000000
Flat space addressing: lun=32
4020400200000000
Flat space addressing: lun=32
^^<=== 0x20 of the lun's 1st shortAccording to sam5r13.pdf ** section 4.7.7.3 you owe me a beer :-) "Flat space" addressing is only 16 bits long. "Extended Flat space" and "Long Extended Flat space" addressing would have the top bit set in byte 0 (and no part of the actual lun is in byte 0).
# sg_luns --test=4020400200000000 -H Decoded LUN: Flat space addressing: lun=0x0020
A vendor specific LUN or am I misreading SAM-5?
sg_luns --test=d220400200000000 -H
Decoded LUN:
Extended flat space addressing: lun=0x204002
<snip>
Quoted 1 line
I guess we cannot adapt
sg_ioctlSG_GET_SCSI_IDthat easily without breaking the user space interface. But how does a user of this interface know that there are 64 bit luns in the kernel but the ioctl cannot handle the new kernel functionality (and may be affected by aliasing)?
I think that would involve adding a new ioctl (e.g. SG_GET_SCSI_ID64) and last time I proposed that L. Torvalds said something like: over his dead body.
Doug Gilbert
** now we have conglomerate LUNs!
PATCH 3/4 scsi: use 64-bit value for 'max_luns'
In reply to Hannes ReineckeNow that we're using 64-bit LUNs internally we need to increase the size of max_luns to 64 bits, too.
--- drivers/message/i2o/i2o_scsi.c | 6 +++--- drivers/scsi/cxgbi/libcxgbi.c | 2 +- drivers/scsi/cxgbi/libcxgbi.h | 2 +- drivers/scsi/dc395x.c | 3 ++- drivers/scsi/eata.c | 2 +- drivers/scsi/ibmvscsi/ibmvfc.c | 4 ++-- drivers/scsi/lpfc/lpfc_attr.c | 10 +++++++++- drivers/scsi/megaraid.c | 2 +- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 4 ++-- drivers/scsi/qla2xxx/qla_gbl.h | 2 +- drivers/scsi/qla2xxx/qla_os.c | 6 +++--- drivers/scsi/scsi_scan.c | 8 ++++---- include/linux/moduleparam.h | 5 +++++ include/scsi/scsi_host.h | 6 +++--- kernel/params.c | 1 + 15 files changed, 39 insertions(+), 24 deletions(-)
drivers/message/i2o/i2o_scsi.c +3 -3
@@ -73,7 +73,7 @@static struct i2o_driver i2o_scsi_driver;static unsigned int i2o_scsi_max_id =16 ; -static unsigned int i2o_scsi_max_lun =255 ; +static uint64_t i2o_scsi_max_lun =255 ;struct i2o_scsi_host {struct Scsi_Host *scsi_host;/* pointer to the SCSI host */
@@ -287,8 +287,8 @@ static int i2o_scsi_probe(struct device *dev) }if (le64_to_cpu (lun) >= scsi_host->max_lun) { -osm_warn ("SCSI device lun (%lu) >= max_lun of I2O host (%d)" , - (long unsigned int )le64_to_cpu (lun), +osm_warn ("SCSI device lun (%llu) >= max_lun of I2O host (%llu)" , + (long long unsigned int )le64_to_cpu (lun), scsi_host->max_lun);return -EFAULT ; }
drivers/scsi/cxgbi/libcxgbi.c +1 -1
@@ -245,7 +245,7 @@ void cxgbi_hbas_remove(struct cxgbi_device *cdev) }EXPORT_SYMBOL_GPL (cxgbi_hbas_remove); -int cxgbi_hbas_add (struct cxgbi_device *cdev,unsigned int max_lun, +int cxgbi_hbas_add (struct cxgbi_device *cdev,uint64_t max_lun,unsigned int max_id,struct scsi_host_template *sht,struct scsi_transport_template *stt) {
drivers/scsi/cxgbi/libcxgbi.h +1 -1
@@ -692,7 +692,7 @@ struct cxgbi_device *cxgbi_device_register(unsigned int, unsigned int);void cxgbi_device_unregister (struct cxgbi_device *);void cxgbi_device_unregister_all (unsigned int flag);struct cxgbi_device *cxgbi_device_find_by_lldev (void *); -int cxgbi_hbas_add (struct cxgbi_device *,unsigned int ,unsigned int , +int cxgbi_hbas_add (struct cxgbi_device *,uint64_t ,unsigned int ,struct scsi_host_template *,struct scsi_transport_template *);void cxgbi_hbas_remove (struct cxgbi_device *);
drivers/scsi/dc395x.c +2 -1
@@ -4648,7 +4648,8 @@ static int dc395x_proc_info(struct Scsi_Host *host, char *buffer,SPRINTF ("irq_level 0x%04x, " , acb->irq_level);SPRINTF (" SelTimeout %ims\n" , (1638 * acb->sel_timeout) /1000 ); -SPRINTF ("MaxID %i, MaxLUN %i, " , host->max_id, host->max_lun); +SPRINTF ("MaxID %i, MaxLUN %i, " , host->max_id, + (unsigned int )host->max_lun);SPRINTF ("AdapterID %i\n" , host->this_id);SPRINTF ("tag_max_num %i" , acb->tag_max_num);
drivers/scsi/eata.c +1 -1
@@ -1399,7 +1399,7 @@ static int port_detect(unsigned long port_base, unsigned int j,if (shost->max_id >8 || shost->max_lun >8 )printk - ("%s: wide SCSI support enabled, max_id %u, max_lun %u.\n" , + ("%s: wide SCSI support enabled, max_id %u, max_lun %llu.\n" , ha->board_name, shost->max_id, shost->max_lun);for (i =0 ; i <= shost->max_channel; i++)
drivers/scsi/ibmvscsi/ibmvfc.c +2 -2
@@ -46,7 +46,7 @@static unsigned int init_timeout =IBMVFC_INIT_TIMEOUT ;static unsigned int default_timeout =IBMVFC_DEFAULT_TIMEOUT ; -static unsigned int max_lun =IBMVFC_MAX_LUN ; +static uint64_t max_lun =IBMVFC_MAX_LUN ;static unsigned int max_targets =IBMVFC_MAX_TARGETS ;static unsigned int max_requests =IBMVFC_MAX_REQUESTS_DEFAULT ;static unsigned int disc_threads =IBMVFC_MAX_DISC_THREADS ;
@@ -71,7 +71,7 @@ MODULE_PARM_DESC(default_timeout,module_param_named (max_requests, max_requests, uint,S_IRUGO ); MODULE_PARM_DESC(max_requests, "Maximum requests for this adapter. " "[Default=" __stringify(IBMVFC_MAX_REQUESTS_DEFAULT) "]"); -module_param_named (max_lun, max_lun, uint,S_IRUGO ); +module_param_named (max_lun, max_lun, ulong,S_IRUGO ); MODULE_PARM_DESC(max_lun, "Maximum allowed LUN. " "[Default=" __stringify(IBMVFC_MAX_LUN) "]");module_param_named (max_targets, max_targets, uint,S_IRUGO );
drivers/scsi/lpfc/lpfc_attr.c +9 -1
@@ -1967,6 +1967,14 @@ lpfc_vport_param_show(name)\ lpfc_vport_param_init(name, defval, minval, maxval)\ static DEVICE_ATTR(lpfc_##name, S_IRUGO , lpfc_##name##_show, NULL) +#define LPFC_VPORT_ULL_ATTR_R (name, defval, minval, maxval, desc) \ +static uint64_t lpfc_##name = defval;\ +module_param(lpfc_##name, ullong, S_IRUGO);\ +MODULE_PARM_DESC(lpfc_##name, desc);\ +lpfc_vport_param_show(name)\ +lpfc_vport_param_init(name, defval, minval, maxval)\ +static DEVICE_ATTR(lpfc_##name, S_IRUGO , lpfc_##name##_show, NULL) +#define LPFC_VPORT_ATTR_RW (name, defval, minval, maxval, desc) \ static uint lpfc_##name = defval;\ module_param(lpfc_##name, uint, S_IRUGO);\
@@ -3926,7 +3934,7 @@ LPFC_VPORT_ATTR(discovery_threads, 32, 1, 64, "Maximum number of ELS commands "# Value range is [0,65535]. Default value is 255. # NOTE: The SCSI layer might probe all allowed LUN on some old targets. */ -LPFC_VPORT_ATTR_R (max_luns,255 ,0 ,65535 ,"Maximum allowed LUN" ); +LPFC_VPORT_ULL_ATTR_R (max_luns,255 ,0 ,65535 ,"Maximum allowed LUN" );/* # lpfc_poll_tmo: .Milliseconds driver will wait between polling FCP ring.
drivers/scsi/megaraid.c +1 -1
@@ -1881,7 +1881,7 @@ megaraid_info(struct Scsi_Host *host)"LSI Logic MegaRAID %s %d commands %d targs %d chans %d luns" , adapter->fw_version, adapter->product_info.max_commands, adapter->host->max_id, adapter->host->max_channel, - adapter->host->max_lun); + (unsigned int)adapter->host->max_lun);return buffer; }
drivers/scsi/mpt3sas/mpt3sas_scsih.c +2 -2
@@ -112,8 +112,8 @@ MODULE_PARM_DESC(missing_delay, " device missing delay , io missing delay");/* scsi-mid layer global parmeter is max_report_luns, which is 511 */ #define MPT3SAS_MAX_LUN (16895) -static int max_lun =MPT3SAS_MAX_LUN ; -module_param (max_lun, int,0 ); +static uint64_t max_lun =MPT3SAS_MAX_LUN ; +module_param (max_lun, ullong,0 );MODULE_PARM_DESC (max_lun," max lun, default=16895 " );
drivers/scsi/qla2xxx/qla_gbl.h +1 -1
@@ -109,7 +109,7 @@ extern int ql2xenabledif;extern int ql2xenablehba_err_chk;extern int ql2xtargetreset;extern int ql2xdontresethba; -extern unsigned int ql2xmaxlun; +extern uint64_t ql2xmaxlun;extern int ql2xmdcapmask;extern int ql2xmdenable;
drivers/scsi/qla2xxx/qla_os.c +3 -3
@@ -201,8 +201,8 @@ MODULE_PARM_DESC(ql2xdontresethba," 0 (Default) -- Reset on failure.\n" " 1 -- Do not reset on failure.\n"); -uint ql2xmaxlun =MAX_LUNS ; -module_param (ql2xmaxlun, uint,S_IRUGO ); +uint64_t ql2xmaxlun =MAX_LUNS ; +module_param (ql2xmaxlun, ullong,S_IRUGO );MODULE_PARM_DESC (ql2xmaxlun,"Defines the maximum LU number to register with the SCSI " "midlayer. Default is 65535." );
@@ -2449,7 +2449,7 @@ qla2x00_probe_one(struct pci_dev *pdev, const struct pci_device_id *id)ql_dbg (ql_dbg_init, base_vha,0x0033 ,"max_id=%d this_id=%d " "cmd_per_len=%d unique_id=%d max_cmd_len=%d max_channel=%d " -"max_lun=%d transportt=%p, vendor_id=%llu.\n" , host->max_id, +"max_lun=%llu transportt=%p, vendor_id=%llu.\n" , host->max_id, host->this_id, host->cmd_per_lun, host->unique_id, host->max_cmd_len, host->max_channel, host->max_lun, host->transportt, sht->vendor_id);
drivers/scsi/scsi_scan.c +4 -4
@@ -82,14 +82,14 @@ static const char *scsi_null_device_strs = "nullnullnullnull";#define MAX_SCSI_LUNS 512#ifdef CONFIG_SCSI_MULTI_LUN -static unsigned int max_scsi_luns =MAX_SCSI_LUNS ; +static uint64_t max_scsi_luns =MAX_SCSI_LUNS ;#else -static unsigned int max_scsi_luns =1 ; +static uint64_t max_scsi_luns =1 ;#endif -module_param_named (max_luns, max_scsi_luns, uint,S_IRUGO |S_IWUSR ); +module_param_named (max_luns, max_scsi_luns, ullong,S_IRUGO |S_IWUSR );MODULE_PARM_DESC (max_luns, -"last scsi LUN (should be between 1 and 2^32-1)" ); +"last LUN for sequential scan (should be between 1 and 2^64-1)" );#ifdef CONFIG_SCSI_SCAN_ASYNC #define SCSI_SCAN_TYPE_DEFAULT "async"
include/linux/moduleparam.h +5 -0
@@ -372,6 +372,11 @@ extern int param_set_ulong(const char *val, const struct kernel_param *kp);extern int param_get_ulong (char *buffer,const struct kernel_param *kp);#define param_check_ulong (name, p) __param_check(name, p, unsigned long) +extern struct kernel_param_ops param_ops_ullong; +extern int param_set_ullong (const char *val,const struct kernel_param *kp); +extern int param_get_ullong (char *buffer,const struct kernel_param *kp); +#define param_check_ullong (name, p) __param_check(name, p, unsigned long long) +extern struct kernel_param_ops param_ops_charp;extern int param_set_charp (const char *val,const struct kernel_param *kp);extern int param_get_charp (char *buffer,const struct kernel_param *kp);
include/scsi/scsi_host.h +3 -3
@@ -603,11 +603,11 @@ struct Scsi_Host {* These three parameters can be used to allow for wide scsi, * and for host adapters that support multiple busses * The first two should be set to 1 more than the actual max id -* or lun (i.e. 8 for normal systems). +* or lun (e.g. 8 for SCSI parallel systems). */ -unsigned int max_id; -unsigned int max_lun;unsigned int max_channel; +unsigned int max_id; +uint64_t max_lun;/* * This is a unique identifier that must be assigned so that we
kernel/params.c +1 -0
@@ -259,6 +259,7 @@ STANDARD_PARAM_DEF(int, int, "%i", long, strict_strtol); STANDARD_PARAM_DEF(uint, unsigned int, "%u", unsigned long, strict_strtoul);STANDARD_PARAM_DEF (long, long,"%li" , long, strict_strtol); STANDARD_PARAM_DEF(ulong, unsigned long, "%lu", unsigned long, strict_strtoul); +STANDARD_PARAM_DEF(ullong, unsigned long long, "%llu", unsigned long long, strict_strtoull);int param_set_charp (const char *val,const struct kernel_param *kp) {
Signature · 1 line
1.7.4.2
Re: [PATCH 3/4] scsi: use 64-bit value for 'max_luns'
drivers/scsi/dc395x.c
Quoted 28 lines · Hannes Reinecke
drivers/scsi/cxgbi/libcxgbi.c +1
-1@@ -245,7 +245,7 @@ void cxgbi_hbas_remove(struct cxgbi_device *cdev) }EXPORT_SYMBOL_GPL (cxgbi_hbas_remove); -int cxgbi_hbas_add (struct cxgbi_device *cdev,unsigned int max_lun, +int cxgbi_hbas_add (struct cxgbi_device *cdev,uint64_t max_lun,unsigned int max_id,struct scsi_host_template *sht,struct scsi_transport_template *stt) {drivers/scsi/cxgbi/libcxgbi.h +1
-1@@ -692,7 +692,7 @@ struct cxgbi_device *cxgbi_device_register(unsigned int, unsigned int);void cxgbi_device_unregister (struct cxgbi_device *);void cxgbi_device_unregister_all (unsigned int flag);struct cxgbi_device *cxgbi_device_find_by_lldev (void *); -int cxgbi_hbas_add (struct cxgbi_device *,unsigned int ,unsigned int , +int cxgbi_hbas_add (struct cxgbi_device *,uint64_t ,unsigned int ,struct scsi_host_template *,struct scsi_transport_template *);void cxgbi_hbas_remove (struct cxgbi_device *);drivers/scsi/dc395x.c +0
-0
Could it be possible to use u64, so it matches the rest of the driver coding style? The rest of the driver uses the u* definitions instead f the uint*_t ones.
I think it could just be edited when the patch is merged instead of having to send a whole new patchset. We can also just fix it up later of the patches get merged as is.
Re: [PATCH 3/4] scsi: use 64-bit value for 'max_luns'
Quoted 27 lines · Michael Christie
Quoted 25 lines · Hannes Reinecke
drivers/scsi/cxgbi/libcxgbi.c +1
-1@@ -245,7 +245,7 @@ void cxgbi_hbas_remove(struct cxgbi_device *cdev) }EXPORT_SYMBOL_GPL (cxgbi_hbas_remove); -int cxgbi_hbas_add (struct cxgbi_device *cdev,unsigned int max_lun, +int cxgbi_hbas_add (struct cxgbi_device *cdev,uint64_t max_lun,unsigned int max_id,struct scsi_host_template *sht,struct scsi_transport_template *stt) {drivers/scsi/cxgbi/libcxgbi.h +1
-1@@ -692,7 +692,7 @@ struct cxgbi_device *cxgbi_device_register(unsigned int, unsigned int);void cxgbi_device_unregister (struct cxgbi_device *);void cxgbi_device_unregister_all (unsigned int flag);struct cxgbi_device *cxgbi_device_find_by_lldev (void *); -int cxgbi_hbas_add (struct cxgbi_device *,unsigned int ,unsigned int , +int cxgbi_hbas_add (struct cxgbi_device *,uint64_t ,unsigned int ,struct scsi_host_template *,struct scsi_transport_template *);
Quoted 8 lines
drivers/scsi/dc395x.c
Quoted 3 lines
drivers/scsi/cxgbi/libcxgbi.h +0
-0void cxgbi_hbas_remove (struct cxgbi_device *);drivers/scsi/dc395x.c +0
-0Could it be possible to use u64, so it matches the rest of the driver coding style? The rest of the driver uses the u* definitions instead f the uint*_t ones.
In general we should use u64 for kernel internal stuff (which this is). uint64_t is supposed to be reserved for user interfaces.
James
Re: [PATCH 3/4] scsi: use 64-bit value for 'max_luns'
Quoted 37 lines · James Bottomley
Quoted 27 lines · Michael Christie
Quoted 25 lines · Hannes Reinecke
drivers/scsi/cxgbi/libcxgbi.c +1
-1@@ -245,7 +245,7 @@ void cxgbi_hbas_remove(struct cxgbi_device *cdev) }EXPORT_SYMBOL_GPL (cxgbi_hbas_remove); -int cxgbi_hbas_add (struct cxgbi_device *cdev,unsigned int max_lun, +int cxgbi_hbas_add (struct cxgbi_device *cdev,uint64_t max_lun,unsigned int max_id,struct scsi_host_template *sht,struct scsi_transport_template *stt) {drivers/scsi/cxgbi/libcxgbi.h +1
-1@@ -692,7 +692,7 @@ struct cxgbi_device *cxgbi_device_register(unsigned int, unsigned int);void cxgbi_device_unregister (struct cxgbi_device *);void cxgbi_device_unregister_all (unsigned int flag);struct cxgbi_device *cxgbi_device_find_by_lldev (void *); -int cxgbi_hbas_add (struct cxgbi_device *,unsigned int ,unsigned int , +int cxgbi_hbas_add (struct cxgbi_device *,uint64_t ,unsigned int ,struct scsi_host_template *,struct scsi_transport_template *);Quoted 8 lines
drivers/scsi/dc395x.c
Quoted 3 lines
drivers/scsi/cxgbi/libcxgbi.h +0
-0void cxgbi_hbas_remove (struct cxgbi_device *);drivers/scsi/dc395x.c +0
-0Could it be possible to use u64, so it matches the rest of the driver coding style? The rest of the driver uses the u* definitions instead f the uint*_t ones.
Quoted 3 lines
In general we should use u64 for kernel internal stuff (which this is).
uint64_tis supposed to be reserved for user interfaces.
Ok. Will fix it up with the next series.
Cheers,
Hannes
Signature · 8 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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: Remove CONFIG_SCSI_MULTI_LUN
In reply to Hannes ReineckeObsolete now; either use 'max_lun' if the host supports only a limited number of LUNs or BLIST_NOLUN if the target has problems addressing more than one LUN.
--- drivers/scsi/Kconfig | 14 -------------- drivers/scsi/dc395x.c | 9 +-------- drivers/scsi/ncr53c8xx.h | 4 ---- drivers/scsi/scsi_scan.c | 4 ---- 4 files changed, 1 insertions(+), 30 deletions(-)
drivers/scsi/Kconfig +0 -14
@@ -197,20 +197,6 @@ config SCSI_ENCLOSURE it has an enclosure device. Selecting this option will just allow certain enclosure conditions to be reported and is not required. -config SCSI_MULTI_LUN - bool "Probe all LUNs on each SCSI device" - depends on SCSI - help - Some devices support more than one LUN (Logical Unit Number) in order - to allow access to several media, e.g. CD jukebox, USB card reader, - mobile phone in mass storage mode. This option forces the kernel to - probe for all LUNs by default. This setting can be overriden by - max_luns boot/module parameter. Note that this option does not affect - devices conforming to SCSI-3 or higher as they can explicitely report - their number of LUNs. It is safe to say Y here unless you have one of - those rare devices which reacts in an unexpected way when probed for - multiple LUNs. - config SCSI_CONSTANTS bool "Verbose SCSI error reporting (kernel size +=12K)" depends on SCSI
drivers/scsi/dc395x.c +1 -8
@@ -517,9 +517,7 @@ static struct ParameterData cfg_data[] = {CFG_PARAM_UNSET ,0 ,0x2f , -#ifdef CONFIG_SCSI_MULTI_LUN -NAC_SCANLUN | -#endif +NAC_SCANLUN |NAC_GT2DRIVES |NAC_GREATER_1G |NAC_POWERON_SCSI_RESET /*| NAC_ACTIVE_NEG*/ ,NAC_GT2DRIVES |NAC_GREATER_1G |NAC_POWERON_SCSI_RESET |0x08
@@ -4432,15 +4430,10 @@ static void adapter_init_scsi_host(struct Scsi_Host *host)if (host->max_id -1 == eeprom->scsi_id) host->max_id--; -#ifdef CONFIG_SCSI_MULTI_LUN if (eeprom->channel_cfg &NAC_SCANLUN ) host->max_lun =8 ;else host->max_lun =1 ; -#else - host->max_lun =1 ; -#endif - }
drivers/scsi/ncr53c8xx.h +0 -4
@@ -264,11 +264,7 @@#define SCSI_NCR_SG_TABLESIZE (SCSI_NCR_MAX_SCATTER)#define SCSI_NCR_TIMER_INTERVAL (HZ) -#if 1 /* defined CONFIG_SCSI_MULTI_LUN */ #define SCSI_NCR_MAX_LUN (16) -#else -#define SCSI_NCR_MAX_LUN (1) -#endif /* * IO functions definition for big/little endian CPU support.
drivers/scsi/scsi_scan.c +0 -4
@@ -81,11 +81,7 @@ static const char *scsi_null_device_strs = "nullnullnullnull";#define MAX_SCSI_LUNS 512 -#ifdef CONFIG_SCSI_MULTI_LUN static uint64_t max_scsi_luns =MAX_SCSI_LUNS ; -#else -static uint64_t max_scsi_luns =1 ; -#endif module_param_named (max_luns, max_scsi_luns, ullong,S_IRUGO |S_IWUSR ); MODULE_PARM_DESC(max_luns,
Signature · 1 line
1.7.4.2
Regarding changes like this:
- printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%d] "
+ printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%llu] "
"FCP_ResponseInfo=%08xh\n", ioc->name, sc->device->host->host_no, sc->device->channel, sc->device->id, sc->device->lun,
It might be preferable to print the LUN values in hex rather than decimal, particularly if they are large values. SAM-5 includes some guidance for displaying LUNs, shown below.
One important goal is to match the format, if any, that the user must use in a configuration file or command line argument, so cutting-and-pasting the LUN value works. So, the answer might differ for prints from different drivers. If a driver expects decimal input values, then print decimal.
SAM-5 excerpt:
4.7.2 Logical unit representation format
When an application client displays or otherwise makes a 64-bit LUN value visible, the application client should display it in hexadecimal format with byte 0 first (i.e., on the left) and byte 7 last (i.e., on the right), regardless of the internal representation of the LUN value (e.g., a single level LUN with an ADDRESS METHOD field set to 01b (i.e., flat space addressing) and a FLAT SPACE LUN field set to 0001h should be displayed as 40 01 00 00 00 00 00 00h, not 00 00 00 00 00 00 01 40h). A separator (e.g., space, dash, or colon) may be included between each byte, each two bytes (e.g., 4001-0000-0000-0000h), or each four bytes (e.g., 40010000 00000000h).
[The trailing h is just the T10 documentation convention... a 0x prefix is fine too] [The next three paragraph allow stripping off unnecessary trailing zeros:]
When displaying a single level LUN structure using the peripheral device addressing method (see table 11) or a single level LUN structure using the flat space addressing method (see table 12), an application client may display the value as a single 2-byte value representing only the first level LUN (e.g., 40 01h). A separator (e.g., space, dash, or colon) may be included between each byte.
When displaying a single level LUN structure using the extended flat space addressing method (see table 13), an application client may display the value as a single 4-byte value representing only the first level LUN (e.g., D2 00 00 01h). A separator (e.g., space, dash, or colon) may be included between each byte, or between each two bytes (e.g., D200 0001h).
When displaying a single level LUN structure using the long extended flat space addressing method (see table 14), an application client may display the value as a single 6-byte value representing only the first level LUN (e.g., E2 00 00 01 00 01h). A separator (e.g. space, dash, or colon) may be included between each byte, or between each two bytes (e.g., E200 0001 0001h).
When displaying a 16-bit LUN value, an application client should display the value as a single 2-byte value (e.g., 40 01h). A separator (e.g., space, dash, or colon) may be included between each byte.
Quoted 16 lines
-----Original Message-----
From: Hannes Reinecke [mailto:[email protected]]
Sent: Tuesday, 19 February, 2013 2:18 AM
To: [email protected]
Cc: James Bottomley; Jeremy Linton; Elliott, Robert (Server Storage); Bart Van Assche; Hannes Reinecke
Subject: [PATCH 0/4] scsi: 64-bit LUN supportThis patchset updates the SCSI midlayer to use 64-bit LUNs internally. It eliminates the need to limit the number of LUNs artificially to avoid aliasing issues; the SCSI midlayer can now accept any LUN presented to it.
The LLDD specific settings for '
max_lun' have been left untouched; it should be raised to '~0' if the HBA supports 64-bit LUNs internally. However, it is up to the driver maintainer to raise that limit.
Quoted 10 lines · Robert (Server Storage)
Regarding changes like this:
(quoted diff) +1
-1- printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%d] " + printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%llu] " "FCP_ResponseInfo=%08xh\n", ioc->name, sc->device->host->host_no, sc->device->channel, sc->device->id, sc->device->lun,It might be preferable to print the LUN values in hex rather than decimal, particularly if they are large values. SAM-5 includes some guidance for displaying LUNs, shown below.
We can't really change from decimal to hex without causing confusion and possibly breaking ABIs. All the existing SCSI references look like h:c:t:l and all expect l to be a simple decimal. It's not just in the logs, we have active use of this form in all the /sys/class/scsi_*/ directories and some tools may parse this value.
Quoted 8 lines
One important goal is to match the format, if any, that the user must use in a configuration file or command line argument, so cutting-and-pasting the LUN value works. So, the answer might differ for prints from different drivers. If a driver expects decimal input values, then print decimal.
SAM-5 excerpt:
4.7.2 Logical unit representation format
[...]
We're a bit bound by kernel convention here as well. To retain compatibility with SPI and flat addressing schemes, we really need to show the 8 and 16 bit flat addresses as simple decimal numerics. However, we *might* be free to move to a more hierarchical scheme with the multi-level luns, since I don't think there's to many people who've got arrays that output them (yet).
James
Douglas Gilbert
maintainerQuoted 27 lines · James Bottomley
Quoted 10 lines · Robert (Server Storage)
Regarding changes like this:
(quoted diff) +1
-1- printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%d] " + printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%llu] " "FCP_ResponseInfo=%08xh\n", ioc->name, sc->device->host->host_no, sc->device->channel, sc->device->id, sc->device->lun,It might be preferable to print the LUN values in hex rather than decimal, particularly if they are large values. SAM-5 includes some guidance for displaying LUNs, shown below.
We can't really change from decimal to hex without causing confusion and possibly breaking ABIs. All the existing SCSI references look like h:c:t:l and all expect l to be a simple decimal. It's not just in the logs, we have active use of this form in all the
/sys/class/scsi_*/directories and some tools may parse this value.Quoted 8 lines
One important goal is to match the format, if any, that the user must use in a configuration file or command line argument, so cutting-and-pasting the LUN value works. So, the answer might differ for prints from different drivers. If a driver expects decimal input values, then print decimal.
SAM-5 excerpt:
4.7.2 Logical unit representation format
Quoted 8 lines
[...]
We're a bit bound by kernel convention here as well. To retain compatibility with SPI and flat addressing schemes, we really need to show the 8 and 16 bit flat addresses as simple decimal numerics. However, we *might* be free to move to a more hierarchical scheme with the multi-level luns, since I don't think there's to many people who've got arrays that output them (yet).
For those of you that don't remember, back when the Linux OS was born, a SCSI READ(6) command looked like this:
==============================================================================
Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Operation Code (08h) | -----|-----------------------------------------------------------------------| 1 | Logical Unit Number | (MSB) | -----|------------------------------ ---| 2 | Logical Block Address | -----|--- ---| 3 | (LSB) | -----|-----------------------------------------------------------------------| 4 | Transfer Length | -----|-----------------------------------------------------------------------| 5 | Control |
==============================================================================
Notice that 3 bit LUN field tucked into byte 1 of the cdb. There may be still remnants of code in the Linux SCSI subsystem to support that. Since then LUNs have grown to 16, 32 and now 64 bits. Will they keep expanding?
My point is that a T10 sanctioned LUN representation can be a hard act for an OS to follow.
Fixing Linux's broken 32 bit "word-flipped" LUN should be done as a matter of urgency, IMO. Here I am referring to Hannes Reinecke patch:
[PATCH 1/4] scsi_scan: Fixup scsilun_to_int()
Extending Linux's 32 bit word-flipped LUN to a 64 bit word-flipped LUN seems like the least disruptive change for the Linux user space. Existing small LUN formats would continue to yield the same sysfs and bsg file/directory names. And my lsscsi utility would continue to work.
lsscsi will still need some work to support 64 bit word-flipped LUNs. The simple one is to expand the LUN decoding (currently expecting a 32 bit signed integer) to accept uint64_t . Also I would like to add a --lunhex option ('-x' as the more obvious short option letters are already used) to show the LUN in hex along the lines of what Robert Elliott (and SAM-5) propose.
As an example showing the REPORT LUNS well known LUNS as a non-trivial LUN:
# lsscsi [0:0:0:0] disk ATA INTEL SSDSC2CW12 400i /dev/sda [6:0:0:1] disk Linux scsi_debug 0004 /dev/sdb [6:0:0:49409]wlun Linux scsi_debug 0004 -
# lsscsi -x [0:0:0:0x0000] disk ATA INTEL SSDSC2CW12 400i /dev/sda [6:0:0:0x0001] disk Linux scsi_debug 0004 /dev/sdb [6:0:0:0xc101] wlun Linux scsi_debug 0004 -
# lsscsi -xx [0:0:0:0x0000000000000000] disk ATA INTEL SSDSC2CW12 400i /dev/sda [6:0:0:0x0001000000000000] disk Linux scsi_debug 0004 /dev/sdb [6:0:0:0xc101000000000000] wlun Linux scsi_debug 0004 -
Also, given an hierarchical LUN like 02 3a 00 4b 00 00 00 00 the 'lsscsi -x' representation would be something like:
[6:0:0:0x023a_004b]
Doug Gilbert
Quoted 7 lines · Robert (Server Storage)
Regarding changes like this:
(quoted diff) +1
-1- printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%d] " + printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%llu] " "FCP_ResponseInfo=%08xh\n", ioc->name, sc->device->host->host_no, sc->device->channel, sc->device->id, sc->device->lun,
Quoted 9 lines
It might be preferable to print the LUN values in hex rather than decimal, particularly if they are large values. SAM-5 includes some guidance for displaying LUNs, shown below.
One important goal is to match the format, if any, that the user must use in a configuration file or command line argument, so cutting-and-pasting the LUN value works. So, the answer might differ for prints from different drivers. If a driver expects decimal input values, then print decimal.
Yes. And no.
The patchset is meant to be as a drop-in replacement, ie with _no_ user visible changes. So I retained the original output.
Also, the above number is identical to the sysfs representation, where the user will find a device like
/sys/class/scsi_device/X:Y:Z:L
with each X, Y, Z, and L being a decimal number.
_If_ we were to change that we would have to do it consistently for all instances, plus the sysfs layout.
But I guess we need to have a discussion about this, as I think not everybody agrees with that assessment.
Would be a nice topic for LSF, though.
Cheers,
Hannes
Quoted 9 lines · Hannes Reinecke
This patchset updates the SCSI midlayer to use 64-bit LUNs internally. It eliminates the need to limit the number of LUNs artificially to avoid aliasing issues; the SCSI midlayer can now accept any LUN presented to it.
The LLDD specific settings for '
max_lun' have been left untouched; it should be raised to '~0' if the HBA supports 64-bit LUNs internally. However, it is up to the driver maintainer to raise that limit.
Quoted 6 lines
Hannes Reinecke (4):
scsi_scan: Fixupscsilun_to_int()
scsi: use 64-bit LUNs
scsi: use 64-bit value for 'max_luns'
scsi: RemoveCONFIG_SCSI_MULTI_LUN
Hannes,
As we've reviewed these patches internally, the one question that keeps coming up is how do we handle hardware that cannot handle a 64-bit LUN address? For example, some of our older 2G/bps hardware can only handle a 16-bit LUN address. Currently we convert the u32 value to u16. Do we do the same for the 64-bit conversion? Can a way be devised to "opt-out" of receiving a 64-bit address in the first place (IIRC this was an option in the v1 patch set)?
Thanks,
Chad
________________________________
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
Douglas Gilbert
maintainerQuoted 22 lines · Chad Dupuis
Quoted 9 lines · Hannes Reinecke
This patchset updates the SCSI midlayer to use 64-bit LUNs internally. It eliminates the need to limit the number of LUNs artificially to avoid aliasing issues; the SCSI midlayer can now accept any LUN presented to it.
The LLDD specific settings for '
max_lun' have been left untouched; it should be raised to '~0' if the HBA supports 64-bit LUNs internally. However, it is up to the driver maintainer to raise that limit.Quoted 6 lines
Hannes Reinecke (4):
scsi_scan: Fixupscsilun_to_int()
scsi: use 64-bit LUNs
scsi: use 64-bit value for 'max_luns'
scsi: RemoveCONFIG_SCSI_MULTI_LUNHannes,
Quoted 7 lines
As we've reviewed these patches internally, the one question that keeps coming up is how do we handle hardware that cannot handle a 64-bit LUN address? For example, some of our older 2G/bps hardware can only handle a 16-bit LUN address. Currently we convert the u32 value to u16. Do we do the same for the 64-bit conversion? Can a way be devised to "opt-out" of receiving a 64-bit address in the first place (IIRC this was an option in the v1 patch set)?
Chad,
Perhaps I'm missing something. Given a t10_LUN and linux32_LUN and the proposed linux64_LUN then the traditional 16 bit LUN value (flat space addressing ?) would be either:
(t10_LUN[0] << 8) | t10_LUN[1]
or
linux32_LUN & 0xffff
or
linux64_LUN & 0xffffDoug Gilbert
Quoted 25 lines · Chad Dupuis
Quoted 12 lines · Hannes Reinecke
This patchset updates the SCSI midlayer to use 64-bit LUNs internally.
It eliminates the need to limit the number of LUNs artificially to avoid aliasing issues; the SCSI midlayer can now accept any LUN presented
to it.The LLDD specific settings for '
max_lun' have been left untouched; it should be raised to '~0' if the HBA supports 64-bit LUNs internally.
However, it is up to the driver maintainer to raise that limit.Quoted 6 lines
Hannes Reinecke (4):
scsi_scan: Fixupscsilun_to_int()
scsi: use 64-bit LUNs
scsi: use 64-bit value for 'max_luns'
scsi: RemoveCONFIG_SCSI_MULTI_LUNHannes,
Quoted 8 lines
As we've reviewed these patches internally, the one question that keeps coming up is how do we handle hardware that cannot handle a 64-bit LUN address? For example, some of our older 2G/bps hardware can only handle a 16-bit LUN address. Currently we convert the u32 value to u16.
Do we do the same for the 64-bit conversion? Can a way be devised to
"opt-out" of receiving a 64-bit address in the first place (IIRC this was an option in the v1 patch set)?
Yes, you can.
The idea here is to let 'max_luns' control this behaviour; 'max_luns' is the highest LUN number the host can support. So for 16-bit LUN you would set max_luns to '0xFFFF', and for 32-bit
LUN addresses you would be setting max_luns to '0xFFFFFFFF'.
However, since you mention it, maybe I should add a 'scsilun_to_u32' conversion routine, as this is requested in several places.
Cheers,
Hannes
Signature · 8 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
Quoted 42 lines · Hannes Reinecke
Quoted 23 lines · Chad Dupuis
Quoted 12 lines · Hannes Reinecke
This patchset updates the SCSI midlayer to use 64-bit LUNs internally.
It eliminates the need to limit the number of LUNs artificially to avoid aliasing issues; the SCSI midlayer can now accept any LUN presented
to it.The LLDD specific settings for '
max_lun' have been left untouched; it should be raised to '~0' if the HBA supports 64-bit LUNs internally.
However, it is up to the driver maintainer to raise that limit.Quoted 6 lines
Hannes Reinecke (4):
scsi_scan: Fixupscsilun_to_int()
scsi: use 64-bit LUNs
scsi: use 64-bit value for 'max_luns'
scsi: RemoveCONFIG_SCSI_MULTI_LUNQuoted 7 lines
Hannes,
As we've reviewed these patches internally, the one question that keeps coming up is how do we handle hardware that cannot handle a 64-bit LUN address? For example, some of our older 2G/bps hardware can only handle a 16-bit LUN address. Currently we convert the u32 value to u16.
Do we do the same for the 64-bit conversion? Can a way bedevised to
Quoted 3 lines
"opt-out" of receiving a 64-bit address in the first place (IIRC this was an option in the v1 patch set)?
Yes, you can.
The idea here is to let '
max_luns' control this behaviour; 'max_luns' is the highest LUN number the host can support. So for 16-bit LUN you would setmax_lunsto '0xFFFF', and for 32-bit LUN addresses you would be settingmax_lunsto '0xFFFFFFFF'.
Quoted 7 lines
However, since you mention it, maybe I should add a '
scsilun_to_u32' conversion routine, as this is requested in several places.Cheers,
Hannes
Hannes, thanks for the clarification.
________________________________
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
Quoted 35 lines · Hannes Reinecke
Quoted 23 lines · Chad Dupuis
Quoted 12 lines · Hannes Reinecke
This patchset updates the SCSI midlayer to use 64-bit LUNs internally.
It eliminates the need to limit the number of LUNs artificially to avoid aliasing issues; the SCSI midlayer can now accept any LUN presented
to it.The LLDD specific settings for '
max_lun' have been left untouched; it should be raised to '~0' if the HBA supports 64-bit LUNs internally.
However, it is up to the driver maintainer to raise that limit.Quoted 6 lines
Hannes Reinecke (4):
scsi_scan: Fixupscsilun_to_int()
scsi: use 64-bit LUNs
scsi: use 64-bit value for 'max_luns'
scsi: RemoveCONFIG_SCSI_MULTI_LUNQuoted 7 lines
Hannes,
As we've reviewed these patches internally, the one question that keeps coming up is how do we handle hardware that cannot handle a 64-bit LUN address? For example, some of our older 2G/bps hardware can only handle a 16-bit LUN address. Currently we convert the u32 value to u16.
Do we do the same for the 64-bit conversion? Can a way bedevised to
Quoted 3 lines
"opt-out" of receiving a 64-bit address in the first place (IIRC this was an option in the v1 patch set)?
Quoted 6 lines
Yes, you can.
The idea here is to let '
max_luns' control this behaviour; 'max_luns' is the highest LUN number the host can support. So for 16-bit LUN you would setmax_lunsto '0xFFFF', and for 32-bit LUN addresses you would be settingmax_lunsto '0xFFFFFFFF'.
Hi all,
in scsi_report_lun_scan is max_lun compared with the result of scsilun_to_int, but in that value is also stored the address method. This means, that we compare the max_lun to a LUN 'handle' which doesn't seem to make much sense. This makes that test dependent on which address method is used and not only to the LUN number which is I think expected.
The solution is to have a new function 'scsilun_to_num', (I can send a patch) or let the individual drivers set the max_lun to -1 and test for the allowed LUNs in the driver.
Thanks,
Tomas
Quoted 7 lines
However, since you mention it, maybe I should add a '
scsilun_to_u32' conversion routine, as this is requested in several places.Cheers,
Hannes
Quoted 45 lines · Tomas Henzl
Quoted 35 lines · Hannes Reinecke
Quoted 23 lines · Chad Dupuis
Quoted 12 lines · Hannes Reinecke
This patchset updates the SCSI midlayer to use 64-bit LUNs internally.
It eliminates the need to limit the number of LUNs artificially to avoid aliasing issues; the SCSI midlayer can now accept any LUN presented
to it.The LLDD specific settings for '
max_lun' have been left untouched; it should be raised to '~0' if the HBA supports 64-bit LUNs internally.
However, it is up to the driver maintainer to raise that limit.Quoted 6 lines
Hannes Reinecke (4):
scsi_scan: Fixupscsilun_to_int()
scsi: use 64-bit LUNs
scsi: use 64-bit value for 'max_luns'
scsi: RemoveCONFIG_SCSI_MULTI_LUNQuoted 7 lines
Hannes,
As we've reviewed these patches internally, the one question that keeps coming up is how do we handle hardware that cannot handle a 64-bit LUN address? For example, some of our older 2G/bps hardware can only handle a 16-bit LUN address. Currently we convert the u32 value to u16.
Do we do the same for the 64-bit conversion? Can a way bedevised to
Quoted 3 lines
"opt-out" of receiving a 64-bit address in the first place (IIRC this was an option in the v1 patch set)?
Quoted 6 lines
Yes, you can.
The idea here is to let '
max_luns' control this behaviour; 'max_luns' is the highest LUN number the host can support. So for 16-bit LUN you would setmax_lunsto '0xFFFF', and for 32-bit LUN addresses you would be settingmax_lunsto '0xFFFFFFFF'.Hi all,
Quoted 9 lines
in
scsi_report_lun_scanismax_luncompared with the result ofscsilun_to_int, but in that value is also stored the address method. This means, that we compare themax_lunto a LUN 'handle' which doesn't seem to make much sense. This makes that test dependent on which address method is used and not only to the LUN number which is I think expected.
The solution is to have a new function 'scsilun_to_num', (I can send a patch) or let the individual drivers set themax_lunto -1 and test for the allowed LUNs in the driver.
You sure this is necessary?
I would like to avoid having to parse the LUN number for validity as we cannot guarantee this check has any meaning for the target. The only authoritative check can be made by the target.
In the 64-bit context the max_luns should rather be interpreted as a
'max bits' setting, ie the number of _bits_ per LUN number the HBA is able to transport.
But renaming 'max_luns' to 'max_bits' is a bit pointless, as it would break backwards compability for no real gain.
So with my patchset we have a two-step LUN validation:
- max_luns controls the max LUN number
(read: max number of bits per LUN) which can be transported to the target
- The target validates the transported LUN number.
Hence I don't think we would need an additional function here.
But yes, we need to update scsi_debug as this should validate the incoming LUN number. As should the target mode drivers.
But this can be left for later once the 64-bit changes are in.
Cheers,
Hannes
Quoted 51 lines · Hannes Reinecke
Quoted 41 lines · Tomas Henzl
Quoted 30 lines · Hannes Reinecke
Quoted 21 lines · Chad Dupuis
Quoted 12 lines · Hannes Reinecke
This patchset updates the SCSI midlayer to use 64-bit LUNs internally.
It eliminates the need to limit the number of LUNs artificially to avoid aliasing issues; the SCSI midlayer can now accept any LUN presented
to it.The LLDD specific settings for '
max_lun' have been left untouched; it should be raised to '~0' if the HBA supports 64-bit LUNs internally.
However, it is up to the driver maintainer to raise that limit.Quoted 6 lines
Hannes Reinecke (4):
scsi_scan: Fixupscsilun_to_int()
scsi: use 64-bit LUNs
scsi: use 64-bit value for 'max_luns'
scsi: RemoveCONFIG_SCSI_MULTI_LUNQuoted 7 lines
Hannes,
As we've reviewed these patches internally, the one question that keeps coming up is how do we handle hardware that cannot handle a 64-bit LUN address? For example, some of our older 2G/bps hardware can only handle a 16-bit LUN address. Currently we convert the u32 value to u16.
Do we do the same for the 64-bit conversion? Can a way bedevised to
Quoted 8 lines
Quoted 2 lines
"opt-out" of receiving a 64-bit address in the first place (IIRC this was an option in the v1 patch set)?
Yes, you can.
The idea here is to let '
max_luns' control this behaviour; 'max_luns' is the highest LUN number the host can support. So for 16-bit LUN you would setmax_lunsto '0xFFFF', and for 32-bit LUN addresses you would be settingmax_lunsto '0xFFFFFFFF'.Hi all,
Quoted 9 lines
in
scsi_report_lun_scanismax_luncompared with the result ofscsilun_to_int, but in that value is also stored the address method. This means, that we compare themax_lunto a LUN 'handle' which doesn't seem to make much sense. This makes that test dependent on which address method is used and not only to the LUN number which is I think expected.
The solution is to have a new function 'scsilun_to_num', (I can send a patch) or let the individual drivers set themax_lunto -1 and test for the allowed LUNs in the driver.
Quoted 1 line
You sure this is necessary?
This is not directly related to your 64bit patch, I just 'used' this thread to discuss another issue - sorry.
Quoted 4 lines
I would like to avoid having to parse the LUN number for validity as we cannot guarantee this check has any meaning for the target. The only authoritative check can be made by the target.
What we can do is to decode the LUN and compare it to max_lun provided by the driver, I think that sg_luns is able to do that, so what is needed is just to follow the SAM.
I have seen reports of problem on three different drivers connected to various external storage, all of them having the same basic reason - the driver sets a max_lun and then LUN comes encoded with a newer addressing method and something like this is shown 'kernel: scsi: host 2 channel 0 id 2 lun16643 has a LUN larger than allowed by the host adapter'
Decoding the real LUN value would fix this problem, by decoding is only meant the use in scsi_report_lun_scan. The LUN would be stored exactly the same way as it is now. I know we can patch the certain drivers too, but when max_lun were what the name says
- max LU number, it would fix my problem very easy.
Quoted 11 lines
In the 64-bit context the
max_lunsshould rather be interpreted as a 'max bits' setting, ie the number of _bits_ per LUN number the HBA is able to transport.
But renaming 'max_luns' to 'max_bits' is a bit pointless, as it would break backwards compability for no real gain.So with my patchset we have a two-step LUN validation:
-max_lunscontrols the max LUN number
(read: max number of bits per LUN) which can be transported to the target
This means in fact only 32 or 64 bit - so a single bit flag is enough?
Quoted 17 lines
- The target validates the transported LUN number.
Hence I don't think we would need an additional function here. But yes, we need to update
scsi_debugas this should validate the incoming LUN number.
As should the target mode drivers.But this can be left for later once the 64-bit changes are in.
Cheers,
Hannes
--
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
Quoted 2 lines · Tomas Henzl
Quoted 1 line · Hannes Reinecke
On 03/29/2013 05:32 PM, Tomas Henzl wrote:
[ .. ]
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
in
scsi_report_lun_scanismax_luncompared with the result ofscsilun_to_int, but in that value is also stored the address method. This means, that we compare themax_lunto a LUN 'handle' which doesn't seem to make much sense. This makes that test dependent on which address method is used and not only to the LUN number which is I think expected.
The solution is to have a new function 'scsilun_to_num', (I can send a patch) or let the individual drivers set themax_lunto -1 and test for the allowed LUNs in the driver.
Quoted 5 lines
Quoted 1 line
You sure this is necessary?
This is not directly related to your 64bit patch, I just 'used' this thread to discuss another issue - sorry.
Yeah, and thereby decreasing the chance of getting my patchset in :-(
Quoted 13 lines
Quoted 4 lines
I would like to avoid having to parse the LUN number for validity as we cannot guarantee this check has any meaning for the target. The only authoritative check can be made by the target.
What we can do is to decode the LUN and compare it to
max_lunprovided by the driver, I think thatsg_lunsis able to do that, so what is needed is just to follow the SAM.I have seen reports of problem on three different drivers connected to various external storage, all of them having the same basic reason - the driver sets a
max_lunand then LUN comes encoded with a newer addressing method and something like this is shown 'kernel: scsi: host 2 channel 0 id 2 lun16643 has a LUN larger than allowed by the host adapter'
Quoted 5 lines
Decoding the real LUN value would fix this problem, by decoding is only meant the use in
scsi_report_lun_scan. The LUN would be stored exactly the same way as it is now. I know we can patch the certain drivers too, but whenmax_lunwere what the name says
- max LU number, it would fix my problem very easy.
Errm.
No. Decoding LUNs is _evil_. It has only a relevance on the target, and even then it might choose to ignore it.
So we cannot try to out-guess the target here.
The error you're reporting is that lpfc is setting max_luns to '255', which of course is less than 16643. Increasing max_luns on lpfc to '0xFFFF' will fix your problem; nothing to do with 64-bit LUNs ...
Quoted 7 lines
Quoted 7 lines
In the 64-bit context the
max_lunsshould rather be interpreted as a 'max bits' setting, ie the number of _bits_ per LUN number the HBA is able to transport.
But renaming 'max_luns' to 'max_bits' is a bit pointless, as it would break backwards compability for no real gain.
Quoted 7 lines
Quoted 4 lines
So with my patchset we have a two-step LUN validation:
-max_lunscontrols the max LUN number
(read: max number of bits per LUN) which can be transported to the targetThis means in fact only 32 or 64 bit - so a single bit flag is enough?
No, it is not.
We have SPI narrow with max_luns = 8, SPI wide with max_luns = 16, some (older) FC HBAs supporting only 8 or 16 bits LUNs, some RAID arrays supporting 32-bit LUNs etc.
Cheers,
Hannes
Signature · 8 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
Quoted 16 lines · Hannes Reinecke
Quoted 8 lines · Tomas Henzl
What we can do is to decode the LUN and compare it to
max_lunprovided by the driver, I think thatsg_lunsis able to do that, so what is needed is just to follow the SAM.I have seen reports of problem on three different drivers connected to various external storage, all of them having the same basic reason - the driver sets a
max_lunand then LUN comes encoded with a newer addressing method and something like this is shown 'kernel: scsi: host 2 channel 0 id 2 lun16643 has a LUN larger than allowed by the host adapter'Quoted 5 lines
Decoding the real LUN value would fix this problem, by decoding is only meant the use in
scsi_report_lun_scan. The LUN would be stored exactly the same way as it is now. I know we can patch the certain drivers too, but whenmax_lunwere what the name says
- max LU number, it would fix my problem very easy.Errm.
Quoted 9 lines
No. Decoding LUNs is _evil_. It has only a relevance on the target, and even then it might choose to ignore it.
So we cannot try to out-guess the target here.The error you're reporting is that lpfc is setting
max_lunsto '255', which of course is less than 16643. Increasingmax_lunson lpfc to '0xFFFF' will fix your problem; nothing to do with 64-bit LUNs ...
The reason lpfc set max_luns to 255 is due to the midlayer using max_luns as a (SCSI-2 device) max sequential scan loop top value, not necessarily as a max lun # as what's now in the report luns scan loop. When we were attached to jbods (loop, etc) - we saw 2 problems: our scan time dramatically increased (several minutes based on a 16k max_lun value); and as the jbod only decoded 8 bits - it happened to respond successfully to any lun value where the lower 8-bits were 0, meaning lots of midlayer "ghost" devices were created when in reality there was only 1 lun present. Changing the max_luns value is fine as long as you know what's attached.
-- james s
Quoted 37 lines · James Smart
Quoted 25 lines · Hannes Reinecke
Quoted 14 lines · Tomas Henzl
What we can do is to decode the LUN and compare it to
max_lunprovided by the driver,
I think thatsg_lunsis able to do that, so what is needed is just to follow the SAM.I have seen reports of problem on three different drivers connected to various
external storage, all of them having the same basic reason - the driver sets amax_lun
and then LUN comes encoded with a newer addressing method and something like this is shown
'kernel: scsi: host 2 channel 0 id 2 lun16643 has a LUN larger than allowed by the host adapter'Quoted 8 lines
Decoding the real LUN value would fix this problem, by decoding is only meant the use in
scsi_report_lun_scan. The LUN would be stored exactly the same way as it is now.
I know we can patch the certain drivers too, but whenmax_lunwere what the name says
- max LU number, it would fix my problem very easy.Errm.
Quoted 9 lines
No. Decoding LUNs is _evil_. It has only a relevance on the target, and even then it might choose to ignore it.
So we cannot try to out-guess the target here.The error you're reporting is that lpfc is setting
max_lunsto '255', which of course is less than 16643. Increasingmax_lunson lpfc to '0xFFFF' will fix your problem; nothing to do with 64-bit LUNs ...
Quoted 11 lines
The reason lpfc set
max_lunsto 255 is due to the midlayer usingmax_lunsas a (SCSI-2 device) max sequential scan loop top value, not necessarily as a max lun # as what's now in the report luns scan loop. When we were attached to jbods (loop, etc) - we saw 2
problems: our scan time dramatically increased (several minutes based on a 16kmax_lunvalue); and as the jbod only decoded 8 bits - it happened to respond successfully to any lun value where the lower 8-bits were 0, meaning lots of midlayer "ghost" devices were created
when in reality there was only 1 lun present. Changing themax_lunsvalue is fine as long as you know what's attached.
Well, these are actually _two_ issues; the one is for sequential scan scaling with max_luns, the other is for a JBOD behaving badly when addressing LUNs with more than 8 bits set.
Yes, it is true that sequential scan scales linearly with max_luns, so scanning 16k LUNs _does_ take some time.
We had the same issue when using older EMC Clariion or Symmetrix which announced themselves as SCSI-2 devices.
This is why we introduced the BLIST_REPORTLUN2 flag ...
However, this will only be an issue if you have 'sparse_lun' set.
The first I would declare a non-issue, as sequential scanning should stop after the first invalid device.
Unless 'sparse_lun' is set, but this must be set explicitly via blacklist flags.
And using 'sparse_lun' is _always_ asking for trouble, especially on a known broken device ...
Do you happen to know which make the JBOD was?
I would rather advocate for adding another BLIST flag here instead of degrading the entire scsi host ...
Thanks.
Cheers,
Hannes
Signature · 8 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
Quoted 16 lines · James Smart
Quoted 14 lines · Hannes Reinecke
Quoted 13 lines · Tomas Henzl
What we can do is to decode the LUN and compare it to
max_lunprovided by the driver, I think thatsg_lunsis able to do that, so what is needed is just to follow the SAM.I have seen reports of problem on three different drivers connected to various external storage, all of them having the same basic reason - the driver sets a
max_lunand then LUN comes encoded with a newer addressing method and something like this is shown 'kernel: scsi: host 2 channel 0 id 2 lun16643 has a LUN larger than allowed by the host adapter'Decoding the real LUN value would fix this problem, by decoding is only meant the use in
scsi_report_lun_scan. The LUN would be stored exactly the same way as it is now. I know we can patch the certain drivers too, but whenmax_lunwere what the name says
- max LU number, it would fix my problem very easy.
Quoted 5 lines
Quoted 5 lines
Errm.
No. Decoding LUNs is _evil_. It has only a relevance on the target, and even then it might choose to ignore it.
So we cannot try to out-guess the target here.
OK, I can see the problems with decoding the LUN one of them is the need to again encode the LUN to address format + number. I'm not sure if the hw would work if another address mode were used.
When we understand the LUN as a complex structure then it makes no sense
to compare to max_lun as a number - http://lxr.linux.no/#linux+v3.8.6/drivers/scsi/scsi_scan.c#L1471
Quoted 4 lines
Quoted 4 lines
The error you're reporting is that lpfc is setting
max_lunsto '255', which of course is less than 16643. Increasingmax_lunson lpfc to '0xFFFF' will fix your problem; nothing to do with 64-bit LUNs ...
I think I haven't mentioned lpfc, but it doesn't matter.
Fixing this in individual drivers by increasing the max_lun is not easy, because the firmware could have some reasons for the max lun (some tables, ..., fact is I have no idea how this is implemented in the hw).
If the fix for this were just to set max_lun to 0xFFFF in every driver it means that we could remove the max_lun and the test completely.
A kernel option like 'ignore_max_lun' would help, but I somehow dislike it, what do you think?
Quoted 17 lines
The reason lpfc set
max_lunsto 255 is due to the midlayer usingmax_lunsas a (SCSI-2 device) max sequential scan loop top value, not necessarily as a max lun # as what's now in the report luns scan loop. When we were attached to jbods (loop, etc) - we saw 2 problems: our scan time dramatically increased (several minutes based on a 16kmax_lunvalue); and as the jbod only decoded 8 bits - it happened to respond successfully to any lun value where the lower 8-bits were 0, meaning lots of midlayer "ghost" devices were created when in reality there was
only 1 lun present. Changing themax_lunsvalue is fine as long as
you know what's attached.-- james 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
Quoted 22 lines · Tomas Henzl
Quoted 16 lines · James Smart
Quoted 14 lines · Hannes Reinecke
Quoted 13 lines · Tomas Henzl
What we can do is to decode the LUN and compare it to
max_lunprovided by the driver, I think thatsg_lunsis able to do that, so what is needed is just to follow the SAM.I have seen reports of problem on three different drivers connected to various external storage, all of them having the same basic reason - the driver sets a
max_lunand then LUN comes encoded with a newer addressing method and something like this is shown 'kernel: scsi: host 2 channel 0 id 2 lun16643 has a LUN larger than allowed by the host adapter'Decoding the real LUN value would fix this problem, by decoding is only meant the use in
scsi_report_lun_scan. The LUN would be stored exactly the same way as it is now. I know we can patch the certain drivers too, but whenmax_lunwere what the name says
- max LU number, it would fix my problem very easy.Quoted 5 lines
Quoted 5 lines
Errm.
No. Decoding LUNs is _evil_. It has only a relevance on the target, and even then it might choose to ignore it.
So we cannot try to out-guess the target here.
Quoted 7 lines
OK, I can see the problems with decoding the LUN one of them is the need to again encode the LUN to address format + number. I'm not sure if the hw would work if another address mode were used.
When we understand the LUN as a complex structure then it makes no sense
to compare tomax_lunas a number - http://lxr.linux.no/#linux+v3.8.6/drivers/scsi/scsi_scan.c#L1471
Oh, but it does. See below.
Quoted 11 lines
Quoted 4 lines
Quoted 4 lines
The error you're reporting is that lpfc is setting
max_lunsto '255', which of course is less than 16643. Increasingmax_lunson lpfc to '0xFFFF' will fix your problem; nothing to do with 64-bit LUNs ...I think I haven't mentioned lpfc, but it doesn't matter.
Fixing this in individual drivers by increasing themax_lunis not easy, because the firmware could have some reasons for the max lun (some tables, ..., fact is I have no idea how this is implemented in the hw).
If the fix for this were just to setmax_lunto0xFFFFin every driver it means that we could remove themax_lunand the test completely.
Quoted 3 lines
A kernel option like '
ignore_max_lun' would help, but I somehow dislike it, what do you think?
Well, I've thought about this, too.
You are right in the sense that 'max_lun' actually has a double meaning.
First it's being used as the upper limit for sequential scan, where is has a strictly sequential meaning. So any internal LUN structure doesn't come into play here are we're just 'counting'.
Secondly it's being used as a simple validation for any LUN numbers reported via REPORT LUNS.
Here it the max_lun value actually refers to the amount of _bits_ in a LUN number the HBA can transfer. Again, the internal LUN structure doesn't come into play here; this is purely a hardware limitation on the HBA. Whether a LUN is valid or not is none of our concern; if the target accepts the LUN is has to be valid. If it doesn't then we don't care whether the LUN structure is valid or not; there is no device to be had anyway.
However, after consulting SAM it is true that a plain 'max_lun' is incorrect for any LUN value higher than 255.
LUN values higher than 255 should be represented with the 'flat space addressing' model, ie bit 6 should be set.
Sadly, the various SAM revisions differ on how LUNs lower than 255 should be treated; they might or might not have set the flat space addressing model.
So yeah, I guess we should be handling the HBA restriction different from the max_lun setting.
I see to cook up a patch.
Cheers,
Hannes
Signature · 8 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
Quoted 32 lines
-----Original Message-----
From: Hannes Reinecke [mailto:[email protected]]
Sent: Tuesday, 09 April, 2013 2:38 AM
To: Tomas Henzl
Cc: [email protected]; Chad Dupuis; [email protected]; James Bottomley; Jeremy Linton; Elliott, Robert (Server Storage); Bart Van Assche; Bud Brown
Subject: Re: [PATCH 0/4] scsi: 64-bit LUN supportQuoted 5 lines · Tomas Henzl
Quoted 3 lines · James Smart
Quoted 1 line · Hannes Reinecke
On 03/31/2013 07:44 PM, Tomas Henzl wrote:
You are right in the sense that '
max_lun' actually has a double meaning.First it's being used as the upper limit for sequential scan, where is has a strictly sequential meaning. So any internal LUN structure doesn't come into play here are we're just 'counting'.
Secondly it's being used as a simple validation for any LUN numbers reported via REPORT LUNS.
Here it themax_lunvalue actually refers to the amount of _bits_ in a LUN number the HBA can transfer. Again, the internal LUN structure doesn't come into play here; this is purely a hardware limitation on the HBA. Whether a LUN is valid or not is none of our concern; if the target accepts the LUN is has to be valid. If it doesn't then we don't care whether the LUN structure is valid or not; there is no device to be had anyway.
Quoted 7 lines
However, after consulting SAM it is true that a plain '
max_lun' is incorrect for any LUN value higher than 255.
LUN values higher than 255 should be represented with the 'flat space addressing' model, ie bit 6 should be set.
Sadly, the various SAM revisions differ on how LUNs lower than 255 should be treated; they might or might not have set the flat space addressing model.
If you treat the LUN as an 8-byte single big-endian value, then every LUN using an address method other than the peripheral device addressing method (00b) is greater than 255; in fact, they're all greater than 4,611,686,018,427,387,904 (0x4000_0000_0000_0000).
One "LUN value" is not represented by different addressing models. For example, these are four different LUNs, not multiple ways to express the same "LUN 0":
a) LUN 0x0000_0000_0000_0000
address method 00b target or lun = 0000_0000b b) LUN 0x4000_0000_0000_0000 address method 01b flat space lun = 00_0000_0000_0000b c) LUN 0xD200_0000_0000_0000 address method 11b length 01b extended address method 0x2 extended flat space lun = 0x00_0000 d) LUN 0xE200_0000_0000_0000 address method 11b length 10b extended address method 0x2 long extended flat space lun = 0x00_00000000
Sequential scanning should be an exception for very old devices that don't support REPORT LUNS; a small maximum scan value would be safer than scanning to max_luns, which could be huge.
Three plausible lower scan limits:
a) address method 00b with TARGET OR LUN set to 0..7: the number of LUNs supported by SCSI-1, which had a 3-bit LUN field in the CDBs themselves (long since obsolete)
b) address method 00b with TARGET OR LUN set to 0..255: the number of LUNs supported by devices that only support address method 00b; the 8-bit TARGET OR LUN field portion of the first two bytes of the LUN.
c) first two bytes set to 0..65535: the possible LUNs supported by devices with protocols with 2-byte LUN fields. I think scanning this many would take too long, though, and might trigger bugs in devices that don't decode the LUN correctly.
Quoted 40 lines · Robert (Server Storage)
Quoted 32 lines
-----Original Message-----
From: Hannes Reinecke [mailto:[email protected]]
Sent: Tuesday, 09 April, 2013 2:38 AM
To: Tomas Henzl
Cc: [email protected]; Chad Dupuis; [email protected]; James Bottomley; Jeremy Linton; Elliott, Robert (Server Storage); Bart Van Assche; Bud Brown
Subject: Re: [PATCH 0/4] scsi: 64-bit LUN supportQuoted 5 lines · Tomas Henzl
Quoted 3 lines · James Smart
Quoted 1 line · Hannes Reinecke
On 03/31/2013 07:44 PM, Tomas Henzl wrote:
You are right in the sense that '
max_lun' actually has a double meaning.First it's being used as the upper limit for sequential scan, where is has a strictly sequential meaning. So any internal LUN structure doesn't come into play here are we're just 'counting'.
Secondly it's being used as a simple validation for any LUN numbers reported via REPORT LUNS.
Here it themax_lunvalue actually refers to the amount of _bits_ in a LUN number the HBA can transfer. Again, the internal LUN structure doesn't come into play here; this is purely a hardware limitation on the HBA. Whether a LUN is valid or not is none of our concern; if the target accepts the LUN is has to be valid. If it doesn't then we don't care whether the LUN structure is valid or not; there is no device to be had anyway.Quoted 7 lines
However, after consulting SAM it is true that a plain '
max_lun' is incorrect for any LUN value higher than 255.
LUN values higher than 255 should be represented with the 'flat space addressing' model, ie bit 6 should be set.
Sadly, the various SAM revisions differ on how LUNs lower than 255 should be treated; they might or might not have set the flat space addressing model.
Quoted 6 lines
If you treat the LUN as an 8-byte single big-endian value, then every LUN using an address method other than the peripheral device addressing method (00b) is greater than 255; in fact, they're all greater than 4,611,686,018,427,387,904 (0x4000_0000_0000_0000).
Yes. I know.
Quoted 4 lines
One "LUN value" is not represented by different addressing models. For example, these are four different LUNs, not multiple ways to express the same "LUN 0":
a) LUN 0x0000_0000_0000_0000
Quoted 16 lines
address method 00b target or lun = 0000_0000b b) LUN 0x4000_0000_0000_0000 address method 01b flat space lun = 00_0000_0000_0000b c) LUN 0xD200_0000_0000_0000 address method 11b length 01b extended address method 0x2 extended flat space lun = 0x00_0000 d) LUN 0xE200_0000_0000_0000 address method 11b length 10b extended address method 0x2 long extended flat space lun = 0x00_00000000
Yes.
Quoted 4 lines
Sequential scanning should be an exception for very old devices that don't support REPORT LUNS; a small maximum scan value would be safer than scanning to
max_luns, which could be huge.
Or, to be more precise, for modern devices claiming SCSI-2 or SCSI-3 conformance.
Some storage arrays have the habit of doing so.
Quoted 10 lines
Three plausible lower scan limits:
a) address method 00b with TARGET OR LUN set to 0..7: the number of LUNs supported by SCSI-1, which had a 3-bit LUN field in the CDBs themselves (long since obsolete)b) address method 00b with TARGET OR LUN set to 0..255: the number of LUNs supported by devices that only support address method 00b; the 8-bit TARGET OR LUN field portion of the first two bytes of the LUN.
Quoted 6 lines
c) first two bytes set to 0..65535: the possible LUNs supported by devices with protocols with 2-byte LUN fields. I think scanning this many would take too long, though, and might trigger bugs in devices that don't decode the LUN correctly.
My current thinking is to restrict sequential LUN scan to 255 LUNs (ie address method 00b) and adding a BLIST flag if someone wants/needs to scan more than that.
I thought of decoding the address method for LUNs higher than 255, but then we might run into the differences between the various SAM versions:
- SAM / SPC (ie SCSI-3) does _not_ define an internal LUN structure, so in theory any LUN is valid
- SAM-2 / SPC-3 states that peripheral addressing should be used for LUNs less than 255, and flat space addressing for LUNs between 256 and 16383
- SAM-3 / SPC-4 and beyound states that peripheral _or_ flat space addressing can be used for LUNs less then 255, and flat space addressing should be used for LUNs between 256 and 16383
So any decoding we do would fail for SCSI-3 devices. And the amount of devices supporting more than 255 LUNs and _NOT_ supporting REPORT_LUN should be relatively small. Hence I think decoding LUNs is not worth the trouble and the BLIST approach should work just nicely here.
Cheers,
Hannes
Signature · 8 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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