Environment
Novell SUSE Linux Enterprise Server 10
Novell SUSE Linux Enterprise Server 9
Novell SUSE Linux Enterprise Server 8
Novell Open Enterprise Server (Linux based)
SCSI storage or SAN (e.g. Fibre Channel based)
Novell SUSE Linux Enterprise Server 9
Novell SUSE Linux Enterprise Server 8
Novell Open Enterprise Server (Linux based)
SCSI storage or SAN (e.g. Fibre Channel based)
Situation
Sample symptoms:
- Cannot see more than 7 SCSI Devices
- Cannot see more than 7 LUNs
- Some LUNs are not detected
Resolution
Use kernel parameters to change the way SCSI devices are scanned for.
Additional Information
Introduction
On a Linux system SCSI devices are usually detected automatically upon boot or once the respective driver module for the SCSI controller is loaded. Under certain circumstances this detection might fail or not be completely correct.
Sanity check
A SCSI controller or Fibre Channel HBA typically offers the possibility of scanning for storage/LUNs from its BIOS. In particular for Fibre Channel SANs, where factors like complex cabling, LUN masking and zoning can come into play, it's a good sanity check to first use this facility to check that the storage is seen at this level. If storage is not visible through the controller's BIOS, it will not be seen by the operating system either and the problem lies outside the operating system's control.
SCSI scanning flags example
Boot with
SCSI scanning flags (not for SLES8)
The parameters that influence the SCSI scanning behaviour are combined in a single parameter, scsi_mod.default_dev_flags. This parameter can be passed to the kernel through the kernel command line, or it can be built into the initial RAM disk (initrd) through a line
The value for scsi_mod.default_dev_flags is the sum of the applicable individual flag values (as detailed below).
SCSI scanning flags (SLES8 only)
SLES8 uses an older kernel and has individual parameters for the various flags which can be passed on the kernel command line or which can be added to /etc/modules.conf to be built into the initrd.
Flag: Handle sparse LUN numbering
Flag value: 0x040
(SLES8: scsi_sparselun=1)
By default, LUNs are scanned sequentially and scanning stops when a LUN has been reported not to exist. (or when max_luns is reached). This flag should be used when the LUN numbering is sparse, i.e. non-consecutive. With it, scanning continues until max_luns is reached, which may increase the scan time but makes sure all LUNs of a target are scanned for.
Flag: Use REPORT_LUNS command
Flag value: 0x20000
(SLES8: scsi_reportlun2=1)
Instruct the kernel to try the REPORT_LUNS command even for SCSI-2 devices in case the SCSI host controller (HBA) does support more than 8 LUNs (the maximum for SCSI-2 devices according to the SCSI standards). This option is safe to use as the broken USB devices that lock up on REPORT_LUNS are on the USB controller which does not support more than 8 LUNs.
Flag: Scan for large LUNs
Flag value: 0x200
(SLES8: scsi_largelun=1)
Theoretically, only SCSI-3 devices should have LUNs larger than 7, but in practice there are some devices which report themselves as supporting SCSI version 2 but which have LUNs larger than 7. This parameter forces scanning for LUNs larger than 7 on non-SCSI-3 devices.
Flag: switch off the use of REPORT_LUN
Flag value: 0x40000
(SLES8: scsi_noreportlun=1)
For SCSI-3 devices the REPORT_LUN command is used to avoid the need for a serial scan and thus to avoid problems with non-consecutive LUNs. This can be switched off with this parameter, which is needed in case the LUN mapping of the host adapter and the Linux are different. For the zfcp adapter, REPORT_LUN is not used.
More specific targetting of devices
scsi_mod.default_dev_flags sets the scanning options for all devices. When this causes undesired side effects with other devices, a variant can be applied to a specific device only.
The syntax for it on 2.6 kernels is
For the SLES8 kernel, the syntax is
It sets BLIST_LARGELUN | BLIST_SPARSELUN for the devices on controller number C, bus number B (normally 0) and for target ID T. Up to 8 devices can be modified this way.
Other scsi_mod parameters
scsi_mod has some other parameters that are useful when troubleshooting or configuring special setups :
On a Linux system SCSI devices are usually detected automatically upon boot or once the respective driver module for the SCSI controller is loaded. Under certain circumstances this detection might fail or not be completely correct.
Sanity check
A SCSI controller or Fibre Channel HBA typically offers the possibility of scanning for storage/LUNs from its BIOS. In particular for Fibre Channel SANs, where factors like complex cabling, LUN masking and zoning can come into play, it's a good sanity check to first use this facility to check that the storage is seen at this level. If storage is not visible through the controller's BIOS, it will not be seen by the operating system either and the problem lies outside the operating system's control.
SCSI scanning flags example
Boot with
scsi_mod.default_dev_flags=0x240 (SLES9 and newer)
orscsi_largelun=1 scsi_sparselun=1 (SLES8)
to scan for LUNs larger than 7 on a SCSI-2 device and to scan without assuming LUNs are consecutive.SCSI scanning flags (not for SLES8)
The parameters that influence the SCSI scanning behaviour are combined in a single parameter, scsi_mod.default_dev_flags. This parameter can be passed to the kernel through the kernel command line, or it can be built into the initial RAM disk (initrd) through a line
options scsi_mod default_dev_flags=value
in /etc/modprobe.conf.localThe value for scsi_mod.default_dev_flags is the sum of the applicable individual flag values (as detailed below).
SCSI scanning flags (SLES8 only)
SLES8 uses an older kernel and has individual parameters for the various flags which can be passed on the kernel command line or which can be added to /etc/modules.conf to be built into the initrd.
Flag: Handle sparse LUN numbering
Flag value: 0x040
(SLES8: scsi_sparselun=1)
By default, LUNs are scanned sequentially and scanning stops when a LUN has been reported not to exist. (or when max_luns is reached). This flag should be used when the LUN numbering is sparse, i.e. non-consecutive. With it, scanning continues until max_luns is reached, which may increase the scan time but makes sure all LUNs of a target are scanned for.
Flag: Use REPORT_LUNS command
Flag value: 0x20000
(SLES8: scsi_reportlun2=1)
Instruct the kernel to try the REPORT_LUNS command even for SCSI-2 devices in case the SCSI host controller (HBA) does support more than 8 LUNs (the maximum for SCSI-2 devices according to the SCSI standards). This option is safe to use as the broken USB devices that lock up on REPORT_LUNS are on the USB controller which does not support more than 8 LUNs.
Flag: Scan for large LUNs
Flag value: 0x200
(SLES8: scsi_largelun=1)
Theoretically, only SCSI-3 devices should have LUNs larger than 7, but in practice there are some devices which report themselves as supporting SCSI version 2 but which have LUNs larger than 7. This parameter forces scanning for LUNs larger than 7 on non-SCSI-3 devices.
Flag: switch off the use of REPORT_LUN
Flag value: 0x40000
(SLES8: scsi_noreportlun=1)
For SCSI-3 devices the REPORT_LUN command is used to avoid the need for a serial scan and thus to avoid problems with non-consecutive LUNs. This can be switched off with this parameter, which is needed in case the LUN mapping of the host adapter and the Linux are different. For the zfcp adapter, REPORT_LUN is not used.
More specific targetting of devices
scsi_mod.default_dev_flags sets the scanning options for all devices. When this causes undesired side effects with other devices, a variant can be applied to a specific device only.
The syntax for it on 2.6 kernels is
dev_flags=VENDOR:MODEL:FLAGS[,VENDOR2:MODEL2:FLAGS2[,..]]
Here, VENDOR and MODEL are strings as reported by the SCSI hardware (typically they can be found in the system's boot messages) and the FLAGS are the same as described above; they need to be prefixed with scsi_mod. when passed on the kernel command line.For the SLES8 kernel, the syntax is
llun_blklst=C,B,T[,C,B,T[,..]]
It sets BLIST_LARGELUN | BLIST_SPARSELUN for the devices on controller number C, bus number B (normally 0) and for target ID T. Up to 8 devices can be modified this way.
Other scsi_mod parameters
scsi_mod has some other parameters that are useful when troubleshooting or configuring special setups :
- scsi_mod.scsi_logging: a bitmask that can be used to get verbose output during SCSI scanning. Recommended values for troubleshooting are 448 (very verbose) or 128 (slightly less verbose). For definitions of the bits, refer to /usr/src/linux/drivers/scsi/scsi_scanning.h
- scsi_mod.max_luns: the highest LUN number to scan for.
- scsi_mod.inq_timeout: the SCSI timeout, in seconds. Some broken hardware needs larger values than the default of 6. There's one SCSI to IDE converter known to need 25. The default on the ppc64 architecture is 25.
scsi_allow_ghost_devices (SLES8 specific)
On SLES8, there is an additional parameter:
scsi_allow_ghost_devices=N
This allows to access LUNs with a unit number smaller than N to be accessed despite it reporting as offline. This is needed for some EMC storage devices.
TID history
Formerly known as TID# 10098290. Based primarily on Daniel Rahn's SDB article Options for SCSI device scanning and Kurt Garloff's page on Linux SCSI scanning troubleshooting.
