Bug 531488

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