Bug 484836 - DASDFMT not operating like CPFMTXA
DASDFMT not operating like CPFMTXA
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.2
s390x Linux
high Severity urgent
: rc
: ---
Assigned To: Hans-Joachim Picht
Red Hat Kernel QE team
:
Depends On: 474157
Blocks: 483701 5.4/TechnicalNotes
  Show dependency treegraph
 
Reported: 2009-02-10 03:27 EST by Dan Horák
Modified: 2014-07-24 23:38 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
This modifies DASDFMT to operate the same as IBM tools such as CPFMTXA for z/VM and ICKDSF for MVS
Story Points: ---
Clone Of: 474157
: 486431 (view as bug list)
Environment:
Last Closed: 2009-09-02 04:23:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for kernel for BZ 484836 (3.20 KB, patch)
2009-02-11 12:16 EST, John Jarvis
no flags Details | Diff

  None (edit)
Description Dan Horák 2009-02-10 03:27:14 EST
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@redhat.com 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@emc.com on 2008-12-11 16:06:49 EDT ---

Hi Horak,

Any process with this problem?

Thank you,
Tong

--- Additional comment from dhorak@redhat.com 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@emc.com 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@emc.com 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@emc.com 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@emc.com 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@emc.com 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@redhat.com 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@emc.com on 2009-01-12 10:29:49 EDT ---

Hi 

        Anything from IBM Eng yet?

Thanks,

--- Additional comment from bugproxy@us.ibm.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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@us.ibm.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@emc.com on 2009-02-09 16:44:09 EDT ---

The kernel patch will applied to a RHEL 5.2 kernel and tested.
Comment 1 John Jarvis 2009-02-11 12:16:25 EST
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.
Comment 2 John Jarvis 2009-02-12 13:26:38 EST
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.
Comment 3 RHEL Product and Program Management 2009-02-16 10:24:05 EST
Updating PM score.
Comment 4 Hans-Joachim Picht 2009-02-27 10:28:29 EST
The patch has been posted to rhkernel on Feb 28. by Hans-Joachim Picht <hpicht@redhat.com>
Comment 5 Nigel Hislop 2009-02-27 12:08:29 EST
This is rhkernel as per RHEL 5.4?
Comment 6 Don Zickus 2009-03-23 11:53:14 EDT
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.
Comment 8 Tong 2009-03-25 23:44:36 EDT
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,
Comment 9 Andrius Benokraitis 2009-03-26 00:01:21 EDT
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...
Comment 10 Tong 2009-03-26 15:23:19 EDT
Do you have a kernel fix for 5.2 and 5.3 that I need to verify ?
 
Thanks,
Comment 11 Tong 2009-04-08 12:55:33 EDT
Any update with kernel fix for 5.2 and 5.3 

Thanks,
Comment 12 Tong 2009-04-13 11:23:27 EDT
Hi all,

Any update with kernel fix for 5.2 and 5.3? Please let us know 

Thanks,
Comment 14 Evan McNabb 2009-06-17 14:10:31 EDT
EMC, IBM,

Have you been able to test this yet against one of the RHEL5.4 kernels?

http://people.redhat.com/dzickus/el5/
Comment 15 Chris Ward 2009-07-03 14:24:06 EDT
~~ 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.
Comment 16 Shawn Wells 2009-07-08 17:22:45 EDT
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
Comment 17 Chris Ward 2009-07-10 15:10:51 EDT
~~ 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.
Comment 18 Tong 2009-07-10 15:41:47 EDT
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 **
Comment 21 errata-xmlrpc 2009-09-02 04:23:41 EDT
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

Note You need to log in before you can comment on or make changes to this bug.