Bug 147671 - aic79xx driver doesn't detect LUNs
aic79xx driver doesn't detect LUNs
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Coughlan
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-10 08:12 EST by Richard Freeman
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-01 03:57:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Richard Freeman 2005-02-10 08:12:13 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

Description of problem:
For some reason, I was unable to get my Quantum Superloader working on my Sunfire v65x. The tape (LUN 0) was detected fine on the internal Adaptec 7902 controller, but the jukebox itself on the same id, but LUN 1 was not found.

scsidev@0.10.0:QUANTUM SDLT320         4848|Tape, /dev/nst0
                                           S/N: RBD31Y0125  
                                           ATNN:QUANTUM SDLT320         RBD31Y0125  
                                           IENN:00E09E6000114DDA
                                           WWNN:500E09E000114DDA
scsidev@1.0.0:SEAGATE ST336607LSUN36G 0307|Disk, /dev/sg1
                                           S/N: 3JA2HTRG000073515VC1
scsidev@1.1.0:SEAGATE ST336607LSUN36G 0307|Disk, /dev/sg2
                                           S/N: 3JA2D67Q000074032J24
scsidev@1.2.0:SEAGATE ST336607LSUN36G 0207|Disk, /dev/sg3
                                           S/N: 3JA0HTZY000073233LGF
scsidev@1.3.0:SEAGATE ST336607LSUN36G 0207|Disk, /dev/sg4
                                           S/N: 3JA1AYX900007338W4PB
scsidev@1.4.0:SEAGATE ST336607LSUN36G 0207|Disk, /dev/sg5
                                           S/N: 3JA0KVLQ000073248GTM
scsidev@1.5.0:SEAGATE ST336607LSUN36G 0207|Disk, /dev/sg6
                                           S/N: 3JA0J0P1000073233ESX
scsidev@1.6.0:ESG-SHV SCA HSBP M16    0.05|Processor, /dev/sg7

I was unable to use the jukebox properly. I tried various kernel options, but I eventually got it working by compiling a custom kernel with these options added:

CONFIG_SCSI_DEBUG_QUEUES=y
CONFIG_SCSI_MULTI_LUN=y

At this point, this appeared:


scsidev@0.10.0:QUANTUM SDLT320         4848|Tape, /dev/nst0
                                           S/N: RBD31Y0125  
                                           ATNN:QUANTUM SDLT320         RBD31Y0125  
                                           IENN:00E09E6000114DDA
                                           WWNN:500E09E000114DDA
scsidev@0.10.1:QUANTUM UHDL            0028|Autochanger (Jukebox), /dev/sg1
                                           S/N: RB0335AAD05075
                                           ATNN:QUANTUM UHDL            RB0335AAD05075
                                           IENN:00E09EFFFF064ABA
                                           WWNN:100000E09E064ABA
scsidev@1.0.0:SEAGATE ST336607LSUN36G 0307|Disk, /dev/sg2
                                           S/N: 3JA2HTRG000073515VC1
scsidev@1.1.0:SEAGATE ST336607LSUN36G 0307|Disk, /dev/sg3
                                           S/N: 3JA2D67Q000074032J24
scsidev@1.2.0:SEAGATE ST336607LSUN36G 0207|Disk, /dev/sg4
                                           S/N: 3JA0HTZY000073233LGF
scsidev@1.3.0:SEAGATE ST336607LSUN36G 0207|Disk, /dev/sg5
                                           S/N: 3JA1AYX900007338W4PB
scsidev@1.4.0:SEAGATE ST336607LSUN36G 0207|Disk, /dev/sg6
                                           S/N: 3JA0KVLQ000073248GTM
scsidev@1.5.0:SEAGATE ST336607LSUN36G 0207|Disk, /dev/sg7
                                           S/N: 3JA0J0P1000073233ESX
scsidev@1.6.0:ESG-SHV SCA HSBP M16    0.05|Processor, /dev/sg8

Why did I have to compile a kernel to fix this issue? 

I did try just the LUN option by itself, but it didn't seem to fix it. Only with both enabled did it work (although I did use make oldconfig; make menuconfig to enable them which could have altered some other variables), although to add LUN support I just altered .config.

Version-Release number of selected component (if applicable):
 2.4.21-27

How reproducible:
Always

Steps to Reproduce:
1. Reboot box.
2. Check SCSI devices
3.
  

Actual Results:  No jukebox was found.

Expected Results:  A jukebox should have been found on with the same LUN.

Additional info:

Nothing special. Jukebox is the only device on the external SCSI bus on my v65x.
Comment 1 Tom Coughlan 2005-02-28 11:56:17 EST
The following is from the RHEL 3 U1 Release Notes:

http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/release-notes/as-x86/RELEASE-NOTES-U1-x86-en.html

================

The SCSI standard requires that all SCSI devices respond to Logical Unit Number
(LUN) zero. Some SCSI devices fail when they are scanned for Logical Unit
Numbers (LUNs) greater than zero. Other devices require that LUNs must be
numbered sequentially.

The Red Hat Enterprise Linux 3 Update 1 kernel contains a list of devices that
have been tested and shown to work correctly when scanned for non-zero LUNs, and
non-sequential LUNs. Only devices on this list are scanned by default. This
default behavior can be overridden on a system-wide basis by adding the
following entry to the /etc/modules.conf file:

options scsi_mod max_scsi_luns=255

After modifying modules.conf, it is necessary to rebuild the initial ramdisk
file using the mkinitrd script. Refer to mkinitrd man page (using the command
man mkinitrd) for more information about creating the initial ramdisk image.

When this option is used, the LUN numbers on the device must be assigned
sequentially, starting with zero.

===============

Please try this option with the stock RHEL 3 kernel (not re-compiled). Update
the BZ with your results.

Tom
Comment 2 Richard Freeman 2005-03-01 03:57:22 EST
Spot on, thanks that has fixed it.

I was aware of the mod to the modules.conf, which I tried. I was not aware of
the re-build of mkinitrd. I tried this of course, and it must have been present
when I re-built the custom kernel. As I thought it was the kernel that was the
fix, I then removed it so later kernels didn't pick up the option.

Cheers,

Rich

Note You need to log in before you can comment on or make changes to this bug.