Bug 474157 - DASDFMT not operating like CPFMTXA
DASDFMT not operating like CPFMTXA
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: s390utils (Show other bugs)
5.2
s390x Linux
low Severity urgent
: rc
: 5.4
Assigned To: Dan Horák
BaseOS QE
:
Depends On:
Blocks: 459808 484836 5.4/TechnicalNotes
  Show dependency treegraph
 
Reported: 2008-12-02 10:23 EST by Tong
Modified: 2010-03-14 17:32 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
It is now possible to format ECKD DASD devices that do not contain a default record 0.
Story Points: ---
Clone Of:
: 484836 (view as bug list)
Environment:
Last Closed: 2009-09-02 05:58:49 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)
RHEl 5.4, grants per default subsystems the permission to write the R0 (3.20 KB, text/plain)
2009-02-09 11:21 EST, IBM Bug Proxy
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 50422 None None None Never

  None (edit)
Description Tong 2008-12-02 10:23:00 EST
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
Comment 1 Dan Horák 2008-12-02 10:41:38 EST
Adding Hans to CC as he is our development contact to IBM.
Comment 2 Tong 2008-12-11 16:06:49 EST
Hi Horak,

Any process with this problem?

Thank you,
Tong
Comment 3 Dan Horák 2008-12-12 10:40:27 EST
Hi Tong,
this issue was transfered to the IBM engineers.

Regards, Dan
Comment 4 Tong 2008-12-13 14:44:24 EST
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
Comment 5 Tong 2008-12-15 10:03:38 EST
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.
Comment 6 Tong 2008-12-22 10:03:19 EST
Hi Dan,

Do you have any update from IBM engineers yet?

Thanks, Tong
Comment 7 Tong 2008-12-30 13:57:44 EST
Hi All,

    Is there any update from IBM Eng yet ?

Thanks 
Tong
Comment 8 Tong 2009-01-02 14:11:37 EST
Hi All,

    Is there any update from IBM Eng yet ?

Thank in advance
Tong
Comment 9 Dan Horák 2009-01-05 06:13:31 EST
Hi,
I am back from the holidays, but the answer is that I have no update from IBM yet.
Comment 10 Tong 2009-01-12 10:29:49 EST
Hi 

        Anything from IBM Eng yet?

Thanks,
Comment 11 IBM Bug Proxy 2009-01-19 11:41:07 EST
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
Comment 18 IBM Bug Proxy 2009-02-09 11:21:52 EST
Created attachment 331328 [details]
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.
Comment 19 Nigel Hislop 2009-02-09 16:44:09 EST
The kernel patch will applied to a RHEL 5.2 kernel and tested.
Comment 21 IBM Bug Proxy 2009-02-12 04:51:28 EST
Just for the record
the patch has been tested at IBM site
Comment 25 IBM Bug Proxy 2009-02-12 13:00:41 EST
The patch will be posted upstream soon.
Comment 26 Nigel Hislop 2009-02-12 13:07:24 EST
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 27 John Jarvis 2009-02-12 13:27:05 EST
Please note that https://bugzilla.redhat.com/show_bug.cgi?id=484836 is tracking the kernel portion of this fix.
Comment 28 John Jarvis 2009-04-13 11:52:53 EDT
Will this fix be part of the s390utils rebase we are doing in 5.4 and tracking in https://bugzilla.redhat.com/show_bug.cgi?id=477189 ?
Comment 29 IBM Bug Proxy 2009-04-14 05:31:15 EDT
------- Comment From michael.holzheu@de.ibm.com 2009-04-14 05:27 EDT-------
Yes, it is part of the s390-tools 1.8.1 base code for the s390utils rebase for 5.4.
Comment 30 IBM Bug Proxy 2009-04-20 08:20:55 EDT
------- Comment From mgrf@de.ibm.com 2009-04-20 08:17 EDT-------
Just for the record:
The kernel patch has been posted upstream 2009-03-26
Comment 32 IBM Bug Proxy 2009-06-30 07:40:46 EDT
------- Comment From gmuelas@de.ibm.com 2009-06-30 07:35 EDT-------
This fix was successfully verified by IBM STG Development, Linux on System z
and resolves the present  issue.

Closing bugzilla
Comment 33 Chris Ward 2009-07-03 14:14:42 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 34 Shawn Wells 2009-07-08 18:03:21 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 mirror the behaviour of IBMs' CPFMTXA utility.
Comment 35 IBM Bug Proxy 2009-07-09 12:01:20 EDT
------- Comment From wein@de.ibm.com 2009-07-09 11:52 EDT-------
I think a claim that we "mirror the behavior of IBMs' CPFMTXA utility" is too generic and not correct. We have just implemented one ability that CPFMTXA had and we did not, but otherwise the tools are completely different.

I suggest to point out the new feature instead, e.g. like this:
"It is now possible to format ECKD DASD devices that do not contain a default record 0."
Comment 36 Shawn Wells 2009-07-09 12:35:43 EDT
Agreed - I took the text from various comments in the BZ.  Updated the release notes.
Comment 37 Shawn Wells 2009-07-09 12:35:43 EDT
Release note updated. 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.

Diffed Contents:
@@ -1 +1,2 @@
-This modifies DASDFMT to mirror the behaviour of IBMs' CPFMTXA utility.+It is now possible to format ECKD DASD devices that do not contain a default
+record 0.
Comment 38 Chris Ward 2009-07-10 15:06:55 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 39 Tong 2009-07-10 15:40:21 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 42 errata-xmlrpc 2009-09-02 05:58:49 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/RHBA-2009-1311.html

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