[Bug 1683808] Re: fail to activate the second DS8K fcp device permanently

[Andy Whitcroft]

Hello bugproxy, or anyone else affected,

Accepted s390-tools into zesty-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/s390-tools/1.37.0-0ubuntu3.1 in a
few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-zesty to verification-done-zesty. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-zesty. In either case, details of your testing
will help us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: s390-tools (Ubuntu Zesty)
       Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-zesty

** Changed in: s390-tools (Ubuntu Yakkety)
       Status: In Progress => Fix Committed

** Tags added: verification-needed-yakkety

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to s390-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1683808

Title:
  fail to activate the second DS8K fcp device permanently

Status in Ubuntu on IBM z Systems:
  In Progress
Status in s390-tools package in Ubuntu:
  Fix Released
Status in s390-tools source package in Xenial:
  Fix Committed
Status in s390-tools source package in Yakkety:
  Fix Committed
Status in s390-tools source package in Zesty:
  Fix Committed
Status in s390-tools source package in Artful:
  Fix Released

Bug description:
  [Impact]

   * out of order devices fail to activate

  [Test Case]

   * See steps to reproduce below

  [Regression Potential]

   * s390-tools rebuild, includes rebuilding the bootloader, thus
  failure to boot should be tested in case of a no-change rebuild
  regression. The fix for the issue in question is a pure ordering
  issue, thus ordering the ids should resolve the issue at hand without
  any other negative side-effects

  [Other Info]
   
   * Original report:

  ---Problem Description---
  Fail to active the second DS8K fcp lun permanently

  Machine Type = z13 lpar

  ---Debugger---
  A debugger is not configured

  ---Steps to Reproduce---
   1. Map tow fcp luns from DS8880:
     root at ilz62u:~# lsluns
     Scanning for LUNs on adapter 0.0.1800
   at port 0x50050763070057f9:
    0x4000402800000000
    0x4001401000000000
     Scanning for LUNs on adapter 0.0.1900
   at port 0x50050763070b17f9:
    0x4000402800000000
    0x4001401000000000
  2. active the two fcp temporarily
  echo 0x4001401000000000 > /sys/bus/ccw/drivers/zfcp/0.0.1800/0x50050763070057f9/unit_add
    echo 0x4001401000000000 > /sys/bus/ccw/drivers/zfcp/0.0.1900/0x50050763070b17f9/unit_add

  3. active them via tool "chzdev" permanently
     root at ilz62u:~# lszdev | grep 57f9
  zfcp-lun     0.0.1800:0x50050763070057f9:0x4000402800000000  yes  yes   sdas sg44
  zfcp-lun     0.0.1800:0x50050763070057f9:0x4001401000000000  yes  yes   sdau sg46

  4. multipath show
  root at ilz62u:~# multipath -ll | grep 2107s
  d2ilsd2107s (36005076307ffd7f90000000000000110) dm-15 IBM,2107900
  d1ilsd2107s (36005076307ffd7f90000000000000028) dm-14 IBM,2107900

  5. reboot

  6. the secod fcp lun "0x4001401000000000" fail to keep active any more
  root at ilz62u:/sys/bus/ccw/drivers/zfcp/0.0.1800# ls 0x50050763070057f9
  0x4000402800000000  access_denied  failed  in_recovery  power  status  uevent  unit_add  unit_remove
  root at ilz62u:/sys/bus/ccw/drivers/zfcp/0.0.1900# ls 0x50050763070b17f9
  0x4000402800000000  access_denied  failed  in_recovery  power  status  uevent  unit_add  unit_remove

  root at ilz62u:/sys/bus/ccw/drivers/zfcp/0.0.1900# multipath -ll | grep 2107s
  d1ilsd2107s (36005076307ffd7f90000000000000028) dm-14 IBM,2107900

  Stack trace output:
   no

  Oops output:
   no

  System Dump Info:
    The system is not configured to capture a system dump.

  == Comment: #1 - Heinz-Werner Seeck <heinz-werner_seeck at de.ibm.com> -
  2017-04-18 03:08:54 ==

  First problem evaluation:
  Could be a chzdev problem. Seeing two jump-labels in the udev rule for port 0x50050763070b17f9 on fcp device 0x1800 and 0x1900. The first label enables the LUN that is working, while the second one with the LUN number that is not working is likely ignored.

  Confirmed as a bug in chzdev!

  Workaround:
  Use chzdev to configure and immediately deconfigure a non-existent FCP LUN for the FCP devices that displays the problem.

  Example (ignore any warnings that might show up):

  For FCP device 0x1800:

  chzdev -e -p zfcp-lun 0x1800:0x0000000000000000:0x0000000000000000
  chzdev -d -p zfcp-lun 0x1800:0x0000000000000000:0x0000000000000000

  and for FCP device 0x1900:

  chzdev -e -p zfcp-lun 0x1900:0x0000000000000000:0x0000000000000000
  chzdev -d -p zfcp-lun 0x1900:0x0000000000000000:0x0000000000000000

  Solution available : Patch applied:
  Upstream patch, also applies to s390-tools v1.37.0 and v1.37.1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1683808/+subscriptions