Bug 474157

Adding Hans to CC as he is our development contact to IBM.

Hi Horak,

Any process with this problem?

Thank you,
Tong

Hi Tong,
this issue was transfered to the IBM engineers.

Regards, Dan

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

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.

Hi Dan,

Do you have any update from IBM engineers yet?

Thanks, Tong

Hi All,

    Is there any update from IBM Eng yet ?

Thanks 
Tong

Hi All,

    Is there any update from IBM Eng yet ?

Thank in advance
Tong

Hi,
I am back from the holidays, but the answer is that I have no update from IBM yet.

Hi 

        Anything from IBM Eng yet?

Thanks,

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

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.

The kernel patch will applied to a RHEL 5.2 kernel and tested.

Just for the record
the patch has been tested at IBM site

The patch will be posted upstream soon.

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.

Please note that https://bugzilla.redhat.com/show_bug.cgi?id=484836 is tracking the kernel portion of this fix.

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 From michael.holzheu.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 From mgrf.com 2009-04-20 08:17 EDT-------
Just for the record:
The kernel patch has been posted upstream 2009-03-26

------- Comment From gmuelas.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

~~ 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 mirror the behaviour of IBMs' CPFMTXA utility.

------- Comment From wein.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."

Agreed - I took the text from various comments in the BZ.  Updated the release notes.

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.

~~ 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/RHBA-2009-1311.html