Bug 90935 - LUN scanning in 2.4.18-27.7.x vs kernel-2.4.20-13.7
LUN scanning in 2.4.18-27.7.x vs kernel-2.4.20-13.7
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-15 11:35 EDT by Brent H.
Modified: 2007-04-18 12:53 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:40:56 EDT
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 Brent H. 2003-05-15 11:35:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Description of problem:
We are using Qlogic qla2100f cards to connect through our vixel switches to our 
raidtec san.  Up until a while ago we were using a custom kernel of 2.4.18-5 
with CONFIG_SCSI_MULTI_LUN turned on inorder to see the san partitions.  We 
then upgraded to 2.4.18-27.7.x and where happy to find that we could see the 
san with the default kernel, no modifications neccessary.  This morning we were 
testing kernel-2.4.20-13.7 and found that once again we cannot see the san with 
the default kernel.  Is there a sysconfig or module flag we can set somewhere, 
or do we have to build a custom kernel again inorder to get the new security 
patches?  What is redhat's stance on having the default kernel do LUN scanning? 
Was this feature compiled on in 2.4.18-27.7.x or did it work for another reason?

Thanks,

Brent

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


How reproducible:
Always

Steps to Reproduce:
1.fdisk -l , see san
2.upgrade from 2.4.18-27.7.x  to kernel-2.4.20-13.7
3.reboot
4. fdisk-l , cant see the san
    

Additional info:
Comment 1 Arjan van de Ven 2003-05-16 10:42:24 EDT
	
From our online docs:
When using RAID storage configured with Logical Unit Numbers (LUNs) greater than
zero, it is necessary to enable LUN support 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
using 'mkinitrd'. Refer to The Official Red Hat Linux Customization Guide for
more information about creating the ramdisk image with mkinitrd.
---

In addition if we get the /proc/scsi/scsi file information we can add your raid
controller to the list of devices this needs to be done automatic on.
Comment 2 Brent H. 2003-05-19 09:32:34 EDT
Fibre Card is :

01:02.0 SCSI storage controller: QLogic Corp. QLA2100 64-bit Fibre Channel 
Adapter (rev 04)

SAN:
cat /proc/scsi/scsi

Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: Raidtec  Model: FCR - AA RAID5   Rev: 8.32
  Type:   Direct-Access                    ANSI SCSI revision: 02
Comment 3 Tom Coughlan 2003-05-30 09:42:35 EDT
The following line needs to be added to the device list in scsi_scan.c:

	{"Raidtec", "FCR", "*", BLIST_SPARSELUN | BLIST_LARGELUN},

This will cause the kernel to 

1) always scan for LUNs > 0, 
2) continue scanning if there are gaps in the LUN numbering
3) scan for LUNs > 7 even though the device identifies itself as SCSI-2

This will apply to any Raidtec model that begins with "FCR". 

Would you be able to test this, and post the results here?
Comment 4 Bugzilla owner 2004-09-30 11:40:56 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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