Created attachment 366453 [details] Backport of upstream commit provided by Ed Lin. During a manual scan, max_lun is incorrectly used as max actual lun instead of max actual lun plus 1. Upstream commit http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commit;h=367703558825614f70992f424d68fc7408ff562f commit 367703558825614f70992f424d68fc7408ff562f [SCSI] fix inconsistent usage of max_lun max_lun in struct Scsi_Host is used as actual max lun plus 1 in scsi_sequential_lun_scan()(scsi_scan.c). However it is also used as actual max lun in some other cases. According to the comment in the definition of struct Scsi_Host, max_lun should be set to 1 more than the actual max lun, just like max_id. Fix the problem according to this definition. Signed-off-by: Ed Lin <ed.lin> Signed-off-by: James Bottomley <James.Bottomley>
Hi Ed, I have created some test kernel rpms, would you please test and confirm your results? http://people.redhat.com/dmilburn/.bz531488/ Thanks, David
Hi David, I tested the kernel rpm you created for 531488. In the original kernel, I can add non-existent device using command # echo "scsi add-single-device 2 0 0 256" > /proc/scsi/scsi (the Promise controller is scsi host no. 2) In the testing kernel for 531488, the device was not added using the same command. So I think this issue (adding non-existent lun 256) should be fixed in the testing kernel. Thanks, Ed
*** Bug 510732 has been marked as a duplicate of this bug. ***
Thank you Ed, the patch is being reviewed.
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.
@Promise We need to confirm that there is third-party commitment to test for the resolution of this request during the RHEL 5.5 Beta Test Phase before we can approve it for acceptance into the release. RHEL 5.5 Beta Test Phase is expected to begin around February 2010. In order to avoid any unnecessary delays, please post a confirmation as soon as possible, including the contact information for testing engineers. Any additional information about alternative testing variations we could use to reproduce this issue in-house would be appreciated.
Promise will take the commitment to test this patch ([SCSI] fix inconsistent usage of max_lun) during RHEL 5.5 beta test phase. Currently I am the contact for this issue. Promise will provide further test information when RHEL 5.5 beta packages are ready. Thanks!
in kernel-2.6.18-176.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5 Please do NOT transition this bugzilla state to VERIFIED until our QE team has sent specific instructions indicating when to do so. However feel free to provide a comment indicating that this fix has been verified.
Moving back to POST to allow patch to be reverted, due to concerns about it upstream. Next time this bug goes to MODIFIED should be for the actual revert.
in kernel-2.6.18-179.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5 Please update the appropriate value in the Verified field (cf_verified) to indicate this fix has been successfully verified. Include a comment with verification details.
Now moving back to ASSIGNED, as the originally committed patch was reverted...
Hi Ed, The original patch to fix the inconsistent usage of max_lun has been reverted and will not be included in RHEL5.5, please let me know if you plan on making a change to the stex driver to handle this particular case. Thanks, David
Hi David, Yes that is really an unfortunate situation, especially, considering it is not a stex driver bug. I think I have to prepare a patch for the driver and submit to upstream. Then I need to update the RHEL patch to include this patch. I think there is not much time left, and if it's still possible, we need to do it quickly. Thanks, Ed
Thanks Ed, we can still try to have a stex driver change included in RHEL5.5. It would actually need to go on top of the stex driver update patch for BZ 516881 (committed in -178.el5). So once you submit this change upstream, we can backport it to the latest RHEL5 and retest, then re-submit for internal review. http://people.redhat.com/dzickus/el5 Thanks, David
Created attachment 380057 [details] Backport of upstream commit provided by Ed Lin. http://marc.info/?l=linux-scsi&m=126118651528399&w=2
Debbie, Please have customer confirm kernel-2.6.18-183.el5.bz531488_stex.1, thanks. http://people.redhat.com/dmilburn/.bz531488/
Event posted on 01-19-2010 12:22pm JST by mfuruta Kuwano-san, > NEC confirmed that this problem dose not occur with 2.6.18-183.el5.bz531488_stex.1. Thank you for verification! Let me flip back to Waiting on Tech now. Best Regards, Masaki Furuta Internal Status set to 'Waiting on Engineering' This event sent from IssueTracker by mfuruta issue 316468
Event posted on 02-15-2010 05:53pm JST by mfuruta Hi Tatsukawa-san, Thank you for testing! > NEC confirmed that this problem is fixed in kernel-2.6.18-187.el5 kernel. Now let me set status to waiting on Engineering. Best Regards, Masaki Furuta Internal Status set to 'Waiting on Engineering' This event sent from IssueTracker by mfuruta issue 316468
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0178.html