Creating new bug to track the kernel side of the original report. +++ This bug was initially created as a clone of Bug #474157 +++ Hi Horak, We Running zLinux RHEL5u2 64 bits s390x/SLES10-SP2 64 bits s390x as guest under zVM5.3/zVM5.4 running CKD DASD devices and attached to EMC DMX array. We encounters some performing differ between the DASDFMT vs. CPFMTXA not operating the same: Please see the descriptions below: The s390-tools 1.6.3 DASDFMT is not operating the same as other IBM tools such as CPFMTXA for zVM and ICKDSF for MVS. The later two programs all have byte 7 bit 5 set in the Define Extent CCW when formatting the device. These are new devices and may not contain Record 0. We are wondering why this is not set consistently with this program as most channel programs were from this program. The byte 7 bit 5 = 0 No permission is granted to modify R0 unless the channel program has changed it. The bit 5 = 1 Permission granted to the subsystem to format write R0 with: an ID CCHHR, where CC = Physical cyl number, HH = physical head number# and R = 0 a key length of 0 a data length of 8 a data field containing all zeros. If you not the one working on this problem, would you please point to the right contact. Thank you Tong --- Additional comment from dhorak on 2008-12-02 10:41:38 EDT --- Adding Hans to CC as he is our development contact to IBM. --- Additional comment from huynh_tong on 2008-12-11 16:06:49 EDT --- Hi Horak, Any process with this problem? Thank you, Tong --- Additional comment from dhorak on 2008-12-12 10:40:27 EDT --- Hi Tong, this issue was transfered to the IBM engineers. Regards, Dan --- Additional comment from huynh_tong on 2008-12-13 14:44:24 EDT --- Additional info adding to the BZ: Please see below The Linux kernel's BIODASDFMT routine dasd_eckd_format_device() in the kernel supports an "intensity" flag byte. Bit 0 of the intensity flag byte is described as "Bit 0: write record zero" To determine the effect of enabling that flag bit, EMC modified dasdfmt.c in s390-tools-1.6.3 In dasdfmt_format(), this line of code format_params->intensity |= DASD_FMT_INT_FMT_R0; /*enable Bit 0 */ was inserted immediately after #566 format_step.blksize = format_params->blksize; Some observations: Chain A: will work fine on full volume, but will require a fix in VM to leave the "Regular Record Zero" bit on in define extent parameter byte 7 bit 5 when translated for a minidisk. CHAIN B works fine with full volumes or minidisk minidisk without any other fix to VM. So I would go for chain B. Chain A -> CCW(1) = 63440010 1BEE3FD0, CCW ADDRESS = 1F595178 ** IDA ** -> IDAW(1) = 00000000_0C7A17D4 DATA = C0CC0000 00000004 00000000 00000000 *................* 'Regular R0' bit on, VM leaves it on -> CCW(2) = 47400010 1F5951C0, CCW ADDRESS = 1F595180 for Full Volume DATA = 0380000C 00000000 00000000 00001008 *................* -> CCW(3) = 1D640008 1BEE3EE0, CCW ADDRESS = 1F595188 ** IDA ** -> IDAW(1) = 00000000_124E5719 DATA = 00000000 01001000 *........* -> CCW(4) = 1D640008 1BEE3F08, CCW ADDRESS = 1F595190 ** IDA ** -> IDAW(1) = 00000000_0EF49721 DATA = 00000000 02001000 *........* -> CCW(5) = 1D640008 1BEE3940, CCW ADDRESS = 1F595198 ** IDA ** -> IDAW(1) = 00000000_039FC729 DATA = 00000000 03001000 *........* ETC... Chain B TRACE TYPE IO, CPU 0001 TIME 19:53:01.067801 TRACEID = EMCTRACE, TRACESET = EMC, IODATA = 32 USER = ETFG, I/O OLD PSW = 07064000 80000000 00000000 00000000 DEVICE = 1064, SCSW = 00E440C9 1098FCD0 00000000 ESW = 00000000 I/O PRIORITIES: CHANNEL = 0, CURRENT = 0, ORIGINAL = 0 OUT-PRIORITIZED COUNT = 0 -> CCW(1) = 63400010 1C0A7AC0, CCW ADDRESS = 1098FCC8 DATA = C0CC0000 00000000 0BBD0001 0BBD0001 *................* -> CCW(2) = 47400010 1098FDF8, CCW ADDRESS = 1098FCD0 DATA = 0B80000D 0BBD0001 0BBD0001 00001008 *................* Real Track Address Cyl 0BBD head 1 -> CCW(3) = 05440008 1098FDF0, CCW ADDRESS = 1098FCD8 ** IDA ** Update R0 data. -> IDAW(1) = 00000000_10121711 DATA = 00000000 00000000 *........* Record 0 data -> CCW(4) = 1D640008 1098FDD0, CCW ADDRESS = 1098FCE0 ** IDA ** CMD 1D Format write -> IDAW(1) = 00000000_10121719 DATA = 00040001 01001000 *........* Record 1 Virtual Count area Cyl 4 Head 1 -> CCW(5) = 1D640008 1098FDC8, CCW ADDRESS = 1098FCE8 ** IDA ** -> IDAW(1) = 00000000_0FE4F721 DATA = 00040001 02001000 *........* -> CCW(6) = 1D640008 1098FDA8, CCW ADDRESS = 1098FCF0 ** IDA ** -> IDAW(1) = 00000000_118AD729 DATA = 00040001 03001000 *........* -> CCW(7) = 1D640008 1098FD88, CCW ADDRESS = 1098FCF8 ** IDA ** -> IDAW(1) = 00000000_19B56731 DATA = 00040001 04001000 *........* -> CCW(8) = 1D640008 1098FD68, CCW ADDRESS = 1098FD00 ** IDA ** -> IDAW(1) = 00000000_10973739 DATA = 00040001 05001000 *........* -> CCW(9) = 1D640008 1098FD48, CCW ADDRESS = 1098FD08 ** IDA ** -> IDAW(1) = 00000000_109FE741 DATA = 00040001 06001000 *........* -> CCW(10) = 1D640008 1098FFC0, CCW ADDRESS = 1098FD10 ** IDA ** -> IDAW(1) = 00000000_10185749 DATA = 00040001 07001000 *........* -> CCW(11) = 1D640008 1098FFA0, CCW ADDRESS = 1098FD18 ** IDA ** -> IDAW(1) = 00000000_0FD47751 DATA = 00040001 08001000 *........* -> CCW(12) = 1D640008 1098FF80, CCW ADDRESS = 1098FD20 ** IDA ** -> IDAW(1) = 00000000_1197F759 DATA = 00040001 09001000 *........* -> CCW(13) = 1D640008 1098FF60, CCW ADDRESS = 1098FD28 ** IDA ** -> IDAW(1) = 00000000_1C20C761 DATA = 00040001 0A001000 *........* -> CCW(14) = 1D640008 1098FF40, CCW ADDRESS = 1098FD30 ** IDA ** -> IDAW(1) = 00000000_10C04769 DATA = 00040001 0B001000 *........* -> CCW(15) = 1D240008 1098FF20, CCW ADDRESS = 1098FD38 ** IDA ** -> IDAW(1) = 00000000_108EE771 DATA = 00040001 0C001000 *........* Record 12 --- Additional comment from huynh_tong on 2008-12-15 10:03:38 EDT --- Please used the comments #5 the comments #4 is not accurate. Sorry for the wrong info: The Linux kernel's BIODASDFMT routine dasd_eckd_format_device() in the kernel supports an "intensity" flag byte. Bit 0 of the intensity flag byte is described as "Bit 0: write record zero" To determine the effect of enabling that flag bit, EMC modified dasdfmt.c in s390-tools-1.6.3 In dasdfmt_format(), this line of code format_params->intensity |= DASD_FMT_INT_FMT_R0; /*enable Bit 0 */ was inserted immediately after #566 format_step.blksize = format_params->blksize; Some observations: 1. Before the change, the formatting CCWs looked like this: -> CCW(1) = 63400010 7E9AF91C, CCW ADDRESS = 46063C08 DATA = 00C40000 00000000 00000001 00000001 *.D..............* -> CCW(2) = 47400010 46063CA8, CCW ADDRESS = 46063C10 DATA = 0380000C 00000001 00000001 00001000 *................* -> CCW(3) = 1D600008 22989FA0, CCW ADDRESS = 46063C18 DATA = 00000001 012C0060 *.......-* Note: Define Extent byte 7 bit 5 is off After the change, the formatting CCWs were: -> CCW(1) = 63400010 22989F68, CCW ADDRESS = 7D111A68 DATA = C2C40000 00000000 0599000A 0599000A *BD.......r...r..* -> CCW(2) = 47400010 7D111AB0, CCW ADDRESS = 7D111A70 DATA = 4300000E 0599000A 0599000A 00000000 *.....r...r......* -> CCW(3) = 15600008 22989F98, CCW ADDRESS = 7D111A78 DATA = 0599000A 00000008 *.r......* -> CCW(4) = 1D600008 22989FA0, CCW ADDRESS = 7D111A80 DATA = 0599000A 01001000 *.r......* -> CCW(5) = 1D600008 22989FA8, CCW ADDRESS = 7D111A88 DATA = 0599000A 02001000 *.r......* Define Extent byte 7 bit 5 is still off An additional CCW is generated for Write R0 The locate intent is incorrectly set to 0x0E - instead of 0x0D While this CCW chain is supported for dasd attached as UNSUP, VM translation causes cmd 15 to be rejected for minidisks. 2. An additional minidisk problem. Even if dasd_eckd_format_device() was changed to support the setting of the Define Extent byte 7 bit 5, z/VM translation for minidisks still turns off the Define Extent byte 7 bit 5. --- Additional comment from huynh_tong on 2008-12-22 10:03:19 EDT --- Hi Dan, Do you have any update from IBM engineers yet? Thanks, Tong --- Additional comment from huynh_tong on 2008-12-30 13:57:44 EDT --- Hi All, Is there any update from IBM Eng yet ? Thanks Tong --- Additional comment from huynh_tong on 2009-01-02 14:11:37 EDT --- Hi All, Is there any update from IBM Eng yet ? Thank in advance Tong --- Additional comment from dhorak on 2009-01-05 06:13:31 EDT --- Hi, I am back from the holidays, but the answer is that I have no update from IBM yet. --- Additional comment from huynh_tong on 2009-01-12 10:29:49 EDT --- Hi Anything from IBM Eng yet? Thanks, --- Additional comment from bugproxy.com on 2009-01-19 11:41:07 EDT --- A solution for this issue is provided in the scope of IBM Bugzilla 49993. https://bugzilla.linux.ibm.com/show_bug.cgi?id=49993 Please obtain resolution information from this bugzilla and mirror back to Red Hat. Regards Holger --- Additional comment from dkovalsk on 2009-02-09 04:52:46 EDT --- Hi Dan, I'm reviewing this bug for ACKing, but I'm a bit unsure if we're able to test this (and have the equipment). Can we reproduce this in house or are we going to need EMC to sign up for testing? Cheers, /David --- Additional comment from dhorak on 2009-02-09 07:04:52 EDT --- I got this response from my contact in IBM and I have requested more information about the kernel part: Regarding https://bugzilla.redhat.com/show_bug.cgi?id=474157: I talked to our responsible developers. They told me that the problem will be solved with a kernel patch. But probably there will be also a s390-tools patch for dasdfmt. The dasdfmt part will be in the final 1.8.1 tarball, but not in the one we will send you next week. IMO we should ask EMC to test the fix, because it requires detailed level of knowledge of z/VM or z/OS. --- Additional comment from dkovalsk on 2009-02-09 07:35:30 EDT --- Thanks for the info Dan! I'll ACK this once we have EMC signed up to do the testing. I've already contacted Chris Ward to start the conversation. Back to the bug - you might want to open another bug for the kernel part, blocking this bug, to track the progress. --- Additional comment from cward on 2009-02-09 09:30:37 EDT --- Andrius, bug 474157 was submitted by EMC. Looks like we're going to need them to test. Could you please get their confirmation that they'll be able to commit resources to testing this for 5.4? --- Additional comment from andriusb on 2009-02-09 10:25:49 EDT --- Chris - I am unaware of this person from EMC - not one of my contacts... esp. it being S/390. I'll do what I can, but right now I can't commit that EMC will do this... --- Additional comment from cward on 2009-02-09 10:37:52 EDT --- Thanks. Glad we asked. David, this is a perfect example of why it's so important that we don't just tag and ack bugs OtherQA on the whim that they'll test. Thanks for escalating! --- Additional comment from bugproxy.com on 2009-02-09 11:21:52 EDT --- Created an attachment (id=331328) RHEl 5.4, grants per default subsystems the permission to write the R0 Attached is the kernel side patch for RHEL 5.4. It grants per default subsystems the permission to write the record 0. A second patch will be part of the s390-tools/dasdfmt and will consist of an option to disable the feature. --- Additional comment from hislop_nigel on 2009-02-09 16:44:09 EDT --- The kernel patch will applied to a RHEL 5.2 kernel and tested.
Created attachment 331593 [details] patch for kernel for BZ 484836 Adding the kernel patch to this BZ which is tracking the kernel side of the fix.
Copying the comments posted to https://bugzilla.redhat.com/show_bug.cgi?id=474157 which is tracking the userspace portion of this fix: =========================== The kernel patch was tested on a RHEL 5.2 guest running under z/VM 5.3.0 with APAR VM64603 applied The patch works as expected. Thank you very much.
Updating PM score.
The patch has been posted to rhkernel on Feb 28. by Hans-Joachim Picht <hpicht>
This is rhkernel as per RHEL 5.4?
in kernel-2.6.18-136.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.
Hi Don, Is this kernel version kernel-2.6.18-136.el5 for RHEL 5.2 or RHEL 5.3 ? I try apply this fix to RHEL 5.2 and get the following errors [root@lx53cr01r5u2 HOTFIX]# rpm -U *.rpm error: Failed dependencies: ecryptfs-utils < 44 conflicts with kernel-2.6.18-136.el5.s390x ecryptfs-utils < 44 conflicts with kernel-debug-2.6.18-136.el5.s390x ecryptfs-utils < 44 conflicts with kernel-kdump-2.6.18-136.el5.s390x Thanks,
Tong - it is a post RHEL 5.3 kernel (-128 was RHEL 5.3 GA, therefore anything after that is a RHEL 5.4 build). I would recommend that you install RHEL 5.3 GA, and then just rpm -ivh the -136 kernels. That's just my guess...
Do you have a kernel fix for 5.2 and 5.3 that I need to verify ? Thanks,
Any update with kernel fix for 5.2 and 5.3 Thanks,
Hi all, Any update with kernel fix for 5.2 and 5.3? Please let us know Thanks,
EMC, IBM, Have you been able to test this yet against one of the RHEL5.4 kernels? http://people.redhat.com/dzickus/el5/
~~ Attention - RHEL 5.4 Beta Released! ~~ RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner! If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity. Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value. Questions can be posted to this bug or your customer or partner representative.
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: This modifies DASDFMT to operate the same as IBM tools such as CPFMTXA for z/VM and ICKDSF for MVS
~~ Attention Partners - RHEL 5.4 Snapshot 1 Released! ~~ RHEL 5.4 Snapshot 1 has been released on partners.redhat.com. If you have already reported your test results, you can safely ignore this request. Otherwise, please notice that there should be a fix available now that addresses this particular request. Please test and report back your results here, at your earliest convenience. The RHEL 5.4 exception freeze is quickly approaching. If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity. Do not flip the bug status to VERIFIED. Instead, please set your Partner ID in the Verified field above if you have successfully verified the resolution of this issue. Further questions can be directed to your Red Hat Partner Manager or other appropriate customer representative.
Hi, I just finish verify the the Kernel fix for the following linux Beta release: RHEL5.4 beta1 (2.6.18-155.el5). The beta release have the Kernel fix for DASDFMT the bit stay on when I'm performed the DASDFMT. Please see Result below: I have verify both on Minidisk and Real DASD and both are working fine: Regards, Tong RHEL5.4 Beta1 DASDFMT on MINI DISK -------------------------- 07/08/09 14:10:25.126495 -------------------------- RACE TYPE IO, CPU 0002 TIME 14:10:25.126495 TRACEID = EMCTRACE, TRACESET = EMC, IODATA = 32 USER = LX53CR01, I/O OLD PSW = 07064000 80000000 00000000 00000000 DEVICE = F809, SCSW = 00C04007 7F6E9210 0C000000 ESW = 00400006 I/O PRIORITIES: CHANNEL = 0, CURRENT = 0, ORIGINAL = 0 OUT-PRIORITIZED COUNT = 0 -> CCW(1) = 63400010 7FDB1AC0, CCW ADDRESS = 7F6E91A0 DATA = 00C40000 00000004 16CD000D 16CD000D *.D..............* -> CCW(2) = 47400010 7F6E92D0, CCW ADDRESS = 7F6E91A8 DATA = 0380000C 16CD000D 16CD000D 00001000 *................* -> CCW(3) = 1D640008 7F6E92C8, CCW ADDRESS = 7F6E91B0 ** IDA ** DASDFMT on REAL DASD -------------------------- 07/08/09 14:21:20.631104 -------------------------- RACE TYPE IO, CPU 0001 TIME 14:21:20.631104 TRACEID = EMCTRACE, TRACESET = EMC, IODATA = 32 USER = LX53CR01, I/O OLD PSW = 07064000 80000000 00000000 00000000 DEVICE = F874, SCSW = 00C04007 7F7B6ED0 0C000000 ESW = 00800006 I/O PRIORITIES: CHANNEL = 0, CURRENT = 0, ORIGINAL = 0 OUT-PRIORITIZED COUNT = 0 -> CCW(1) = 63400010 7FDB1878, CCW ADDRESS = 7F7B6E60 DATA = 00C40000 00000004 26660007 26660007 *.D..............* -> CCW(2) = 47400010 7F7B6F90, CCW ADDRESS = 7F7B6E68 DATA = 0380000C 26660007 26660007 00001000 *................* -> CCW(3) = 1D640008 7F7B6F88, CCW ADDRESS = 7F7B6E70 ** IDA **
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-2009-1243.html