Bug 463550
|
Description
IBM Bug Proxy
2008-09-23 21:01:42 UTC
Dear RedHat, This involves making the SCSI Hardware Handler functionality available in the kernel by making them available as modules, and making them available in initrd images. IBM, Is this bz for the userspace changes that are needed? I thought we had a 5.4 bugzilla for this? Do we need to make a new one? Or Is this bz for the scsi_dh kernel module changes that will be needed? I also have this bz 471426 from you guys to add some fix to the rdac module. Do you guys have any other related bug fixes or bug fix bzs? Mike, This is for getting the scsi_dh modules available in the kernel. Code is available in mainline since 2.6.27. Enabling the code by including teh config option SCSI_DH_RDAC is needed. ------- Comment From sekharan.com 2009-07-29 22:21 EDT------- Some of the patches had made to mainline after 2.6.29. These patches need to be added to RHEL6. Please consider including these. Created attachment 355626 [details]
[SCSI] scsi dh alua: fix group id masking
------- Comment on attachment From sekharan.com 2009-07-29 22:23 EDT-------
The buf[i] is a byte but we are only asking 4 bits off the
group_id. This patch has us take off a byte.
Created attachment 355627 [details]
[SCSI] scsi_dh_rdac: Retry for Quiescence in Progress in rdac device handler
------- Comment on attachment From sekharan.com 2009-07-29 22:24 EDT-------
During device discovery read capacity fails with 0x068b02 and sets the
device size to 0. As a reason any I/O submitted to this path gets
killed at sd_prep_fn with BLKPREP_KILL. This patch is to retry for
0x068b02
Created attachment 355628 [details]
[SCSI] scsi_dh_rdac: Retry mode select for NO_SENSE, ABORTED_COMMAND, UNIT_ATTENTION, NOT_READY(02/04/01)
------- Comment on attachment From sekharan.com 2009-07-29 22:26 EDT-------
This patch is to add retry for mode select if mode select command is
returned with sense NO_SENSE, UNIT_ATTENTION, ABORTED_COMMAND,
NOT_READY(02/04/01). This patch reorganise the sense keys from if-else
to switch-case format for better maintainability.
Created attachment 355629 [details]
[SCSI] scsi_dh_rdac: Retry for NOT_READY check condition
------- Comment on attachment From sekharan.com 2009-07-29 22:27 EDT-------
This patch adds retry for NOT_READY check condition - Quiesce in
progress (02/A1/02)
Created attachment 355630 [details]
[SCSI] scsi_dh_rdac: Retry for NOT_READY(02/04/01) in rdac device handler
------- Comment on attachment From sekharan.com 2009-07-29 22:27 EDT-------
During device discovery read capacity fails with 0x020401 and sets the
device size to 0. As a reason any I/O submitted to this path gets
killed at sd_prep_fn with BLKPREP_KILL. This patch is to retry for
0x020401. NEED_RETRY in scsi_decide_disposition does not give
sufficient time for the device to become ready.
Created attachment 355631 [details]
dm mpath: call activate fn for each path in pg_init
------- Comment on attachment From sekharan.com 2009-07-29 22:29 EDT-------
Before we moved the hardware handler from dm to SCSI, it performed a pg_init
for a path group and didn't maintain any state about each path in hardware
handler code.
But in SCSI dh, such state is now maintained, as we want to fail I/O early on a
path if it is not the active path.
All the hardware handlers have a state now and set to active or some form of
inactive. They have prep_fn() which uses this state to fail the I/O without
it ever being sent to the device.
So in effect when dm-multipath calls scsi_dh_activate(), activate is
sent to only one path and the "state" of that path is changed appropriately
to "active" while other paths in the same path group are never changed
as they never got an "activate".
In order make sure all the paths in a path group gets their state set
properly when a pg_init happens, we need to call scsi_dh_activate() on
all paths in a path group.
Doing this at the hardware handler layer is not a good option as we
want the multipath layer to define the relationship between path and path
groups and not the hardware handler.
Attached patch sends an "activate" on each path in a path group when a
path group is switched. It also sends an activate when a path is reinstated.
Created attachment 355632 [details] [SCSI] scsi_dh: Reference count scsi_dh_attach ------- Comment on attachment From sekharan.com 2009-07-29 22:31 EDT------- Problem reported: http://marc.info/?l=dm-devel&m=124585978305866&w=2 scsi_dh does not do a refernce count for attach/detach, and this affects the way it is supposed to work with multipath when a device is not in the dev_list of the hardware handler. This patch adds a reference count that counts each attach. ------- Comment From sekharan.com 2009-11-11 20:34 EDT------- installed 10/29/2009 version of Alpha 2 (kernel version 2.6.31-33) and found that the last patch is not applied. (In reply to comment #15) > ------- Comment From sekharan.com 2009-11-11 20:34 EDT------- > installed 10/29/2009 version of Alpha 2 (kernel version 2.6.31-33) and found > that the last patch is not applied. Hi, just wanted to make sure you are talking about [SCSI] scsi_dh: Reference count scsi_dh_attach patch which is upstream in 2.6.32 correct? Thanks, Steve ------- Comment From sekharan.com 2010-01-18 13:17 EDT------- (In reply to comment #17) > (In reply to comment #15) > > installed 10/29/2009 version of Alpha 2 (kernel version 2.6.31-33) and found > > that the last patch is not applied. > > Hi, > > just wanted to make sure you are talking about [SCSI] scsi_dh: Reference count > scsi_dh_attach patch which is upstream in 2.6.32 correct? > > Thanks, > Steve Yes. That is the patch I was referring to. (In reply to comment #17) > ------- Comment From sekharan.com 2010-01-18 13:17 EDT------- > (In reply to comment #17) > > (In reply to comment #15) > > > installed 10/29/2009 version of Alpha 2 (kernel version 2.6.31-33) and found > > > that the last patch is not applied. > > > > Hi, > > > > just wanted to make sure you are talking about [SCSI] scsi_dh: Reference count > > scsi_dh_attach patch which is upstream in 2.6.32 correct? > > > > Thanks, > > Steve > > Yes. That is the patch I was referring to. Ok, thanks. [SCSI] scsi_dh: Reference count scsi_dh_attach patch is in 2.6.32 and we are in the process of moving RHEL 6 to 2.6.32, so I assume there isn't any additional work needed to be done here. The other patches listed in the bz have already been checked and are in RHEL6 correct? Steve ------- Comment From sekharan.com 2010-01-20 12:24 EDT------- > Ok, thanks. [SCSI] scsi_dh: Reference count scsi_dh_attach patch is in 2.6.32 > and we are in the process of moving RHEL 6 to 2.6.32, so I assume there isn't > any additional work needed to be done here. > Which release would have 2.6.32 ? Can you please comment in this bug when that happens. > The other patches listed in the bz have already been checked and are in RHEL6 > correct? Yes. Thanks. > > Steve (In reply to comment #19) > ------- Comment From sekharan.com 2010-01-20 12:24 EDT------- > > Ok, thanks. [SCSI] scsi_dh: Reference count scsi_dh_attach patch is in 2.6.32 > > and we are in the process of moving RHEL 6 to 2.6.32, so I assume there isn't > > any additional work needed to be done here. > > > Which release would have 2.6.32 ? beta > > Can you please comment in this bug when that happens. > > > The other patches listed in the bz have already been checked and are in RHEL6 > > correct? > > Yes. > > Thanks. > > > > Steve I just checked the latest source and it does have this patch. so this bz doesn't have any additional work to be done for it. Steve ------- Comment From sekharan.com 2010-04-28 17:39 EDT------- Verified to be available in Beta1 Red Hat Enterprise Linux 6.0 is now available and should resolve the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you. |