Problems seeing multiple LUNs

[Peter J. Holzer]

On 2004-06-24 16:20:56 -0500, David Cross wrote:
> Hello,
> 
> Previously running RH9 on a system with dual Intel Xeon 3.0 processors
> and an Adaptec SCSI Card 39320D, connecting to an external raid which is
> divided into two LUNs. The first LUN is 2 TBytes and the other
> 1.3TBytes.  Prior to our system disk dying, this worked fine.  The first
> LUN is at about 90% usage, and the smaller device is about 60%
> populated.
> 
> We replaced the system disk and decided this might be a good time to try
> to jump to Fedora Core 2.  Everything seems to be fine, with the
> exception of the fact that we can no longer see the second LUN.  We were
> instructed by our vendor contact to custom rebuild the kernel and to add
> Multiple LUN support.  That did not seem to make a difference with only
> change to the kernel config being the addition of multiple LUN Support. 
> That suggestion included the addition of "options scsi_mod.o
> scsi_max_luns=255" to the /etc/modules.conf file.  We still do not see
> the second LUN.  I have included below the dmesg from the custom build
> of kernel-2.6.6-i686-smp.config for the kernel version
> 2.6.6-1.435custom.
>   
> You might note the section of the dmesg where it says the SCSI "has a
> LUN larger than currently supported."  Note also that the larger of the
> two LUNs mounts just fine.

A bit of nitpicking: "LUN" means "Logical Unit Number", and it is
usually a small integer. You have two logical units, one with LUN 0 and
2 TBytes, and one with an unknown LUN (probably 1) and 1.3 TB.

> scsi1 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 1.3.11
>         <Adaptec AIC7902 Ultra320 SCSI adapter>
>         aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz,
> 512 SCBs
> 
> scsi1:A:0:0: DV failed to configure device.  Please file a bug report
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	       This looks suspicious.
> against this driver.
> (scsi1:A:0): 160.000MB/s transfers (80.000MHz DT, 16bit)
>   Vendor: Tornado-  Model: F4 V2.0           Rev: 0001
>   Type:   Direct-Access                      ANSI SCSI revision: 03
> scsi1:A:0:0: Tagged Queuing enabled.  Depth 4
> SCSI device sdc: 4194304000 512-byte hdwr sectors (2147484 MB)
> SCSI device sdc: drive cache: write back
>  sdc: sdc1
> Attached scsi disk sdc at scsi1, channel 0, id 0, lun 0
                                                    ^^^^^
Here is your first Logical Unit.

> scsi: host 1 channel 0 id 0 lun 0x00000200080c0400 has a LUN larger than
> currently supported.
> scsi: host 1 channel 0 id 0 lun 0xff010000ffffffff has a LUN larger than
> currently supported.
> scsi: host 1 channel 0 id 0 lun 0x0002202020202020 has a LUN larger than
> currently supported.
> scsi: host 1 channel 0 id 0 lun808529923 has a LUN larger than allowed
> by the host adapter
> scsi: host 1 channel 0 id 0 lun3078 has a LUN larger than allowed by the
> host adapter

64 bit LUNs? I didn't know that LUNs could be that large even
theoretically. Anyway, the numbers look strange.  Maybe the driver is
misinterpreting some other data as LUNs. 

	hp

-- 
   _  | Peter J. Holzer      | Shooting the users in the foot is bad. 
|_|_) | Sysadmin WSR / LUGA  | Giving them a gun isn't.
| |   | hjp at wsr.ac.at        |	-- Gordon Schumacher,
__/   | http://www.hjp.at/   |     mozilla bug #84128
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 388 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/aic7xxx/attachments/20040625/6b87867e/attachment.bin