Customer has two Emulex hba's with 4 Luns assigned. Luns are designated as follows: 0, 59, 263, and 541. System can see luns 0 and 59, but not 263 and 541. I had customer add the following options to /etc/modprobe.conf and rebuild initrd: options scsi_mod max_luns=1024 max_report_luns=1024 options lpfc lpfc_nodev_tmo=10 lpfc_max_luns=1024 This still does not allow the system to see the luns (reboot was done). This event sent from IssueTracker by jwhiter [Support Engineering Group] issue 113538
This is one thing I noticed in the dmesg output, it comes from scsi_report_lun_scan(), so it does look like the SCSI mid-layer is sending the REPORT_LUNS command to the device. The device returns a list of LUNS that are present. These messages below are generated because these LUN values from the list of LUNS are greater than sdev->host->max_lun. scsi: host 1 channel 0 id 0 lun659 has a LUN larger than allowed by the host adapter scsi: host 1 channel 0 id 0 lun660 has a LUN larger than allowed by the host adapter scsi: host 1 channel 0 id 0 lun661 has a LUN larger than allowed by the host adapter scsi: host 2 channel 0 id 0 lun565 has a LUN larger than allowed by the host adapter scsi: host 2 channel 0 id 0 lun566 has a LUN larger than allowed by the host adapter scsi: host 2 channel 0 id 0 lun567 has a LUN larger than allowed by the host adapter Can they add this option to their current /etc/modprobe.conf along with options scsi_mod scsi_logging_level=0x1c0 options lpfc lpfc_nodev_tmo=10 lpfc_max_luns=1024 Can you double-check and make sure they rebuilt their initrd after modifying /etc/modprobe.conf? I didn't see all the scsi messages I was expecting, plus looking at the lpfc driver it looks like the lpfc_max_luns would be the right parameter to increase host->max_lun. Internal Status set to 'Waiting on Support' This event sent from IssueTracker by jwhiter [Support Engineering Group] issue 113538
dave, I think i've found the problem, lpfc sets the max_luns as a readonly attribute, not an attribute that can be changed. This patch should fix the problem, I'm building a test kernel for the customer to try based off of 42.0.10 so we don't have to worry about the kernel panicing. This event sent from IssueTracker by jwhiter [Support Engineering Group] issue 113538
Created attachment 151164 [details] patch that resolves the problem this patch resolves the problem.
James, Please review and comment on the proposed change. Tom
The LPFC_ATTR_R() vs LPFC_ATTR_RW() change should only affect the sysfs attribute for the shost. The module parameter should have allowed the change without any code change. So, if it didn't take affect, then it likely means the driver was loaded via initrd and the initrd image wasn't rebuilt (my guess is, your code change caused the driver to be rebuilt, which also caused initrd to be updated). From a purely technical viewpoint - yes, extending the max_lun # registered by the driver is the right way to support larger lun #'s. You must be careful though as, if set via the module parameter, it affects all adapters and all targets, and will be used as the upper bound on scan loops in the midlayer, which can result in some longer delays, and on some targets perhaps funny behavior (as they only recognize luns in the 0-255 range). Making the parameter RW isn't sufficient. Ultimately, you need the shost->max_luns value to change, which the default sysfs "store" routine won't do. Even if you create a unique store routine for max_luns, you are now dynamically changing it on the midlayer post the scsi_add_host() call, not always a smart thing to do. Thus, you're starting to see why we allowed it to be changable as a module parameter, but not as a sysfs attribute, with the downside being how global the change is. The other side to this change is - although you can do it, it's not always the smartest to do so based on how it affects qualifications. I hinted at device and scan interactions once the value is changed. To address this part, can we get some insight as to who the customer is, what storage they are using, so we can determine how the "qual" part is to be resolved ?
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Internal Status set to 'Resolved' Status set to: Closed by Client Resolution set to: 'NotABug' This event sent from IssueTracker by jpayne issue 113538
Closing issue, since customer has closed the corresponding Issue Tracker on their side as NOTABUG.