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:
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.
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
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?
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/