[Group.of.nepali.translators] [Bug 1690225] Re: nvidia-docker on ppc64le-ubuntu16.04 issue due to cross-thread naming if !PR_DUMPABLE

[Manoj Iyer]

** Changed in: linux (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1690225

Title:
  nvidia-docker on ppc64le-ubuntu16.04  issue due to cross-thread naming
  if !PR_DUMPABLE

Status in The Ubuntu-power-systems project:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Released

Bug description:
  == Comment: #0 - Breno Henrique Leitao  - 2017-05-11 
15:30:52 ==
  The PR_DUMPABLE flag causes the pid related paths of the proc file system to 
be owned by ROOT.
  
  The implementation of pthread_set/getname_np however needs access to  
/proc//task//comm.  If PR_DUMPABLE is false this implementation is 
locked out.
  
  This patch installs a special permission function for the file "comm"  
that grants read and write access to all threads of the same group  regardless 
of the ownership of the inode.  For all other threads the  function falls back 
to the generic inode permission check.

  Nvidia-docker issue on ppc64le:

  1b3044e39a89cb1d4d5313da477e8dfea2b5232d

  This is fixed by commit 1b3044e39a89cb1d4d5313da477e8dfea2b5232d

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1764628] Re: incorrect hypervisor and virtualization type reported in compat mode guest

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: In Progress => Fix Released

** Changed in: ubuntu-power-systems
   Status: Fix Released => Fix Committed

** Also affects: util-linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: util-linux (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: util-linux (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: util-linux (Ubuntu Xenial)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1764628

Title:
  incorrect hypervisor and virtualization type reported in compat mode
  guest

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  Fix Committed

Bug description:
  [IMPACT]

  In xenial lscpu prints the wrong "Hypervisor vendor" and
  "Virtualization type" on PowerVM or KVM systems. Incorrect hypervisor
  and virtualization type reported in ubuntu 16.04.04 guest running in
  P8compat mode on P9 boston-LC.

  [TEST]

  Curent output:

  ubuntu@P8lpar3:~$ dpkg -l "*util-linux*"
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name   Version  Architecture Description
  +++-==---=
  ii  util-linux 2.31.1-0.4ub ppc64el  miscellaneous system utilities
  un  util-linux-loc   (no description available)

  ubuntu@P8lpar3:~$ lscpu
  Architecture:ppc64le
  Byte Order:  Little Endian
  CPU(s):  128
  On-line CPU(s) list: 0-127
  Thread(s) per core:  8
  Core(s) per socket:  1
  Socket(s):   16
  NUMA node(s):2
  Model:   2.1 (pvr 004b 0201)
  Model name:  POWER8 (architected), altivec supported
  Hypervisor vendor:   pHyp
  Virtualization type: para
  L1d cache:   64K
  L1i cache:   32K
  NUMA node0 CPU(s):   
  NUMA node4 CPU(s):   0-127
  ubuntu@P8lpar3:~$ 

  Expected Output:

  $ lscpu 
  Architecture:  ppc64le
  Byte Order:Little Endian
  CPU(s):128
  On-line CPU(s) list:   0-127
  Thread(s) per core:8
  Core(s) per socket:1
  Socket(s): 16
  NUMA node(s):  2
  Model: 2.1 (pvr 004b 0201)
  Model name:POWER8 (architected), altivec supported
  Hypervisor vendor: pHyp
  Virtualization type:   para
  L1d cache: 64K
  L1i cache: 32K
  NUMA node0 CPU(s): 
  NUMA node4 CPU(s): 0-127

  [Potential Regression]
  The fix changes the logic to how lscpu-dmi returns from read_hypervisor_dmi() 
this could introduce potential regression in platforms  that has incorrect DMI 
information.

  [Other Info]
  ---uname output---
  Linux guest 4.15.0-13-generic #14~16.04.1-Ubuntu SMP Sat Mar 17 03:03:53 UTC 
2018 ppc64le ppc64le ppc64le GNU/Linux

  Machine Type = boston-LC

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

  ---Steps to Reproduce---
   Incorrect hypervisor and virtualization type reported in ubuntu 16.04.04 
guest running in P8compat mode on P9 boston-LC:

  root@guest:/tmp# lscpu
  Architecture:  ppc64le
  Byte Order:Little Endian
  CPU(s):2
  On-line CPU(s) list:   0,1
  Thread(s) per core:2
  Core(s) per socket:1
  Socket(s): 1
  NUMA node(s):  1
  Model: 2.2 (pvr 004e 1202)
  Model name:POWER8 (architected), altivec supported
  >> Hypervisor vendor: horizontal
  >> Virtualization type:   full
  L1d cache: 32K
  L1i cache: 32K
  NUMA node0 CPU(s): 0,1

  Stack trace output:
   no

  Oops output:
   no

  We test what is coming along with distro. If you are not able to see
  issue with : https://launchpad.net/ubuntu/+source/util-
  linux/2.27.1-6ubuntu3.5 .. can we get this included in 16.04.x train ?

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1765364] Re: Backport spectre/meltdown fixes on qemu for ppc64 into 16.04 and possibly 14.04 LTS releases

[Manoj Iyer]

This bug covers patches to qemu, marking the kernel track as invalid.

** Changed in: ubuntu-power-systems/ubuntu-16.04
   Status: In Progress => Invalid

** Changed in: ubuntu-power-systems/ubuntu-14.04
   Status: New => Invalid

** Changed in: ubuntu-power-systems
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1765364

Title:
  Backport spectre/meltdown fixes on qemu for ppc64 into 16.04 and
  possibly 14.04 LTS releases

Status in The Ubuntu-power-systems project:
  Fix Released
Status in The Ubuntu-power-systems project ubuntu-14.04 series:
  Invalid
Status in The Ubuntu-power-systems project ubuntu-16.04 series:
  Invalid
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Fix Released

Bug description:
  == Comment: #0 - Satheesh Rajendran  - 2018-04-19 
04:26:51 ==
  ---Problem Description---
  Backport spectre/meltdown fixes on qemu for ppc64 into all LTS releases
   
  Contact Information = sathe...@in.ibm.com 
   
  ---uname output---
  -
   
  Machine Type = power8,power9 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   For pseries guests there are 3 tri-state -machine options/capabilities 
relating to Spectre/Meltdown mitigation: cap-cfpc, cap-sbbc, cap-ibs, which 
each correspond to a set of host machine capabilities advertised by the KVM 
kernel module in new/patched host kernels that can be used to mitigate various 
aspects of Spectre/Meltdown:

  cap-cfpc: Cache Flush on Privilege Change
  cap-sbbc: Speculation Barrier Bounds Checking
  cap-ibs: Indirect Branch Serialisation

  Details can be found here https://www.qemu.org/2018/02/14/qemu-2-11-1
  -and-spectre-update/

  Needed qemu commits:

  cb931c2108 target/ppc: Check mask when setting cap_ppc_safe_indirect_branch
  4f5b039d2b ppc/spapr-caps: Disallow setting workaround for spapr-cap-ibs
  8c5909c419 ppc/spapr-caps: Change migration macro to take full spapr-cap name
  c59704b254 target/ppc/spapr: Add H-Call H_GET_CPU_CHARACTERISTICS
  4be8d4e7d9 target/ppc/spapr_caps: Add new tristate cap safe_indirect_branch
  09114fd817 target/ppc/spapr_caps: Add new tristate cap safe_bounds_check
  8f38eaf8f9 target/ppc/spapr_caps: Add new tristate cap safe_cache
  6898aed77f target/ppc/spapr_caps: Add support for tristate spapr_capabilities
  8acc2ae5e9 target/ppc/kvm: Add 
cap_ppc_safe_[cache/bounds_check/indirect_branch]


  Optional commits to introduce a machine type variant pseries--sxxm, 
when used would set/enable the three machine capabilities explained above 
automatically, if host is capable(host kernel is supported). Bug 166426
  813f3cf655 ppc/spapr-caps: Define the pseries-2.12-sxxm machine type
  c76c0d3090 ppc/spapr-caps: Convert cap-ibs to custom spapr-cap
  aaf265ffde ppc/spapr-caps: Convert cap-sbbc to custom spapr-cap
  f27aa81e72 ppc/spapr-caps: Convert cap-cfpc to custom spapr-cap
  87175d1bc5 ppc/spapr-caps: Add support for custom spapr_capabilities

  
   
  Userspace tool common name: qemu-kvm 
   
  The userspace tool has the following bit modes: both 

  Userspace rpm: qemu-kvm

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for sathe...@in.ibm.com:
  -Attach ltrace and strace of userspace application.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1783252] Re: gcc on ppc64le has bogus r30 register handling, as exposed by greenlet 0.4.14 will not build on ppc64le

[Manoj Iyer]

Doko confirmed that this is fix released. So marking this track fix
released.

** Changed in: gcc-6 (Ubuntu Cosmic)
   Status: Fix Committed => Fix Released

** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1783252

Title:
  gcc on ppc64le has bogus r30 register handling, as exposed by greenlet
  0.4.14 will not build on ppc64le

Status in The Ubuntu-power-systems project:
  Fix Released
Status in gcc-5 package in Ubuntu:
  Fix Released
Status in gcc-6 package in Ubuntu:
  Fix Released
Status in python-greenlet package in Ubuntu:
  Fix Released
Status in gcc-5 source package in Xenial:
  Fix Released
Status in gcc-5 source package in Bionic:
  Won't Fix
Status in gcc-6 source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

   * GCC has a minor bug w.r.t. clobber r30 register in PIC binaries.
   * A patch to fix this has been upstream in 6+
   * But it is not in gcc-5.4 as used on xenial
   * This prevents compiling future-proof and correct greenlet code, on Ubuntu 
16.04 LTS as used by current and supported Openstack Queens release on ppc64el
   * Whilst backported greenlet is available via the cloud archive for binary 
usage, the toolchain is still technically incorrect, and thus hinders using 
Ubuntu 16.04 LTS as workers in upstream Openstack CI
   * As a wishlist it would be nice to backport this one small gcc patch as an 
SRU

  [Test Case]

   * git clone https://github.com/python-greenlet/greenlet
   * cd greenlet
   * ./setup.py build
  Expect success

  Current result failure:

  creating build/temp.linux-ppc64le-2.7
  powerpc64le-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall 
-Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC 
-I/usr/include/python2.7 -c greenlet.c -o 
build/temp.linux-ppc64le-2.7/greenlet.o -fno-tree-dominator-opts
  In file included from slp_platformselect.h:16:0,
   from greenlet.c:343:
  platform/switch_ppc64_linux.h: In function 'slp_switch':
  platform/switch_ppc64_linux.h:80:5: error: PIC register clobbered by 'r30' in 
'asm'
   __asm__ volatile ("" : : : REGS_TO_SAVE);
   ^
  platform/switch_ppc64_linux.h:95:5: error: PIC register clobbered by 'r30' in 
'asm'
   __asm__ volatile ("" : : : REGS_TO_SAVE);
   ^
  error: command 'powerpc64le-linux-gnu-gcc' failed with exit status 1

  
  [Regression Potential] 

   * Upstream cherrypick present in later releases including bionic
  
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9213244550335bcb2b8590a0d7d58ac74c932361

  
  [Other Info]
   
   * Original bug report

  
  == Comment: #0 - William M. Edmonds  - 2018-07-23 
16:21:41 ==
  ---Problem Description---
  greenlet 0.4.14 will not build on ppc64le

  Opened https://github.com/python-greenlet/greenlet/issues/136 because
  attempting to build bdist_wheel for greenlet 0.4.14 on ppc64le Ubuntu
  16.04 LTS yields the following error:

  running build
  running build_ext
  building 'greenlet' extension
  creating build
  creating build/temp.linux-ppc64le-2.7
  powerpc64le-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall 
-Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC 
-I/usr/include/python2.7 -c greenlet.c -o 
build/temp.linux-ppc64le-2.7/greenlet.o -fno-tree-dominator-opts
  In file included from slp_platformselect.h:16:0,
  from greenlet.c:343:
     platform/switch_ppc64_linux.h: In function 'slp_switch':
     platform/switch_ppc64_linux.h:80:5: error: PIC register clobbered by 'r30' 
in 'asm'
  __asm__ volatile ("" : : : REGS_TO_SAVE);
  ^
     platform/switch_ppc64_linux.h:95:5: error: PIC register clobbered by 'r30' 
in 'asm'
  __asm__ volatile ("" : : : REGS_TO_SAVE);
  ^
     error: command 'powerpc64le-linux-gnu-gcc' failed with exit status 1```

  But the greenlet community is saying this is a gcc bug and it would
  not be safe to revert the greenlet change that exposed this issue. I
  have no idea whether that is true or not. Supposedly this should be
  fixed by
  
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9213244550335bcb2b8590a0d7d58ac74c932361
  but that fix is not present in the latest version of gcc (5.4.0)
  available for Ubuntu 16.04 LTS.

  ---uname output---
  unavailable due to lab outage

  Machine Type = unavailable due to lab outage

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

  ---Steps to Reproduce---
  This should be reproducible with `git clone 
git://github.com/python-greenlet/greenlet; cd greenlet; python setup.py 
bdist_wheel`, though it was originally found using pypi rather than github and 
with a more 

[Group.of.nepali.translators] [Bug 1655280] Re: ISST-LTE:pVM:roselp4:ubuntu 16.04: cp: error reading '/proc/vmcore': Bad address when trying to dump vmcore

[Manoj Iyer]

Since the required fix is in makedumpfile, marking the linux track as
invalid.

** Changed in: linux (Ubuntu Xenial)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1655280

Title:
  ISST-LTE:pVM:roselp4:ubuntu 16.04: cp: error reading '/proc/vmcore':
  Bad address when trying to dump vmcore

Status in The Ubuntu-power-systems project:
  In Progress
Status in linux package in Ubuntu:
  Invalid
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Invalid
Status in makedumpfile source package in Xenial:
  New
Status in linux source package in Bionic:
  Invalid
Status in makedumpfile source package in Bionic:
  New
Status in linux source package in Cosmic:
  Invalid
Status in makedumpfile source package in Cosmic:
  In Progress
Status in linux source package in Disco:
  Invalid
Status in makedumpfile source package in Disco:
  Fix Released

Bug description:
  == Comment: #0 - Ping Tian Han  - 2017-01-09 02:51:00 ==
  ---Problem Description---
  Vmcore cannot be saved when triggering bug 150353 on roselp4:

  Copying data   : [  2.0 %] \/usr/sbin/kdump-config: line 
591:  5502 Bus error   makedumpfile $MAKEDUMP_ARGS $vmcore_file 
$KDUMP_CORETEMP
  [  512.833872] kdump-tools[5450]:  * kdump-tools: makedumpfile failed, 
falling back to 'cp'
  [  573.595449] kdump-tools[5450]: cp: error reading '/proc/vmcore': Bad 
address
  [  573.605717] kdump-tools[5450]:  * kdump-tools: failed to save vmcore in 
/var/crash/201701090223
  [  573.765417] kdump-tools[5450]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/201701090223/dmesg.201701090223
  [  574.285506] kdump-tools[5450]: The kernel version is not supported.
  [  574.285672] kdump-tools[5450]: The makedumpfile operation may be 
incomplete.
  [  574.285767] kdump-tools[5450]: The dmesg log is saved to 
/var/crash/201701090223/dmesg.201701090223.
  [  574.305422] kdump-tools[5450]: makedumpfile Completed.
  [  574.315363] kdump-tools[5450]:  * kdump-tools: saved dmesg content in 
/var/crash/201701090223
  [  574.615688] kdump-tools[5450]: Mon, 09 Jan 2017 02:24:26 -0600
  [  574.705384] kdump-tools[5450]: Rebooting.
   Stopping ifup for ib0...
  [  OK  ] Stopped ifup for ib0.
  [ 1008.579897] reboot: Restarting system
   
  Contact Information = Ping Tian Han/pt...@cn.ibm.com Carrie 
Mitsuyoshi/carri...@us.ibm.com 
   
  ---uname output---
  Linux roselp4 4.8.0-34-generic #36~16.04.1-Ubuntu SMP Wed Dec 21 18:53:20 UTC 
2016 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = lpar 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. config kdump on roselp4
  2. try to trigger bug 150353

   
  *Additional Instructions for Ping Tian Han/pt...@cn.ibm.com Carrie 
Mitsuyoshi/carri...@us.ibm.com: 
  -Post a private note with access information to the machine that the bug is 
occuring on.

  == Comment: #3 - Brahadambal Srinivasan  -
  2017-01-10 02:42:25 ==

  root@roselp4:~# cat /proc/cmdline
  BOOT_IMAGE=/boot/vmlinux-4.8.0-34-generic 
root=UUID=0bcf3431-df8b-499c-9a13-33070f242e0c ro splash quiet 
crashkernel=384M-:512M

  root@roselp4:~# dmesg | grep Reser
  [0.00] Reserving 512MB of memory at 128MB for crashkernel (System 
RAM: 21760MB)

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1655280] Re: ISST-LTE:pVM:roselp4:ubuntu 16.04: cp: error reading '/proc/vmcore': Bad address when trying to dump vmcore

[Manoj Iyer]

Required fix is to makedumpfile package therefore marking the linux
track as invalid.

** Changed in: linux (Ubuntu Bionic)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1655280

Title:
  ISST-LTE:pVM:roselp4:ubuntu 16.04: cp: error reading '/proc/vmcore':
  Bad address when trying to dump vmcore

Status in The Ubuntu-power-systems project:
  In Progress
Status in linux package in Ubuntu:
  Invalid
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Invalid
Status in makedumpfile source package in Xenial:
  New
Status in linux source package in Bionic:
  Invalid
Status in makedumpfile source package in Bionic:
  New
Status in linux source package in Cosmic:
  Invalid
Status in makedumpfile source package in Cosmic:
  In Progress
Status in linux source package in Disco:
  Invalid
Status in makedumpfile source package in Disco:
  Fix Released

Bug description:
  == Comment: #0 - Ping Tian Han  - 2017-01-09 02:51:00 ==
  ---Problem Description---
  Vmcore cannot be saved when triggering bug 150353 on roselp4:

  Copying data   : [  2.0 %] \/usr/sbin/kdump-config: line 
591:  5502 Bus error   makedumpfile $MAKEDUMP_ARGS $vmcore_file 
$KDUMP_CORETEMP
  [  512.833872] kdump-tools[5450]:  * kdump-tools: makedumpfile failed, 
falling back to 'cp'
  [  573.595449] kdump-tools[5450]: cp: error reading '/proc/vmcore': Bad 
address
  [  573.605717] kdump-tools[5450]:  * kdump-tools: failed to save vmcore in 
/var/crash/201701090223
  [  573.765417] kdump-tools[5450]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/201701090223/dmesg.201701090223
  [  574.285506] kdump-tools[5450]: The kernel version is not supported.
  [  574.285672] kdump-tools[5450]: The makedumpfile operation may be 
incomplete.
  [  574.285767] kdump-tools[5450]: The dmesg log is saved to 
/var/crash/201701090223/dmesg.201701090223.
  [  574.305422] kdump-tools[5450]: makedumpfile Completed.
  [  574.315363] kdump-tools[5450]:  * kdump-tools: saved dmesg content in 
/var/crash/201701090223
  [  574.615688] kdump-tools[5450]: Mon, 09 Jan 2017 02:24:26 -0600
  [  574.705384] kdump-tools[5450]: Rebooting.
   Stopping ifup for ib0...
  [  OK  ] Stopped ifup for ib0.
  [ 1008.579897] reboot: Restarting system
   
  Contact Information = Ping Tian Han/pt...@cn.ibm.com Carrie 
Mitsuyoshi/carri...@us.ibm.com 
   
  ---uname output---
  Linux roselp4 4.8.0-34-generic #36~16.04.1-Ubuntu SMP Wed Dec 21 18:53:20 UTC 
2016 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = lpar 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. config kdump on roselp4
  2. try to trigger bug 150353

   
  *Additional Instructions for Ping Tian Han/pt...@cn.ibm.com Carrie 
Mitsuyoshi/carri...@us.ibm.com: 
  -Post a private note with access information to the machine that the bug is 
occuring on.

  == Comment: #3 - Brahadambal Srinivasan  -
  2017-01-10 02:42:25 ==

  root@roselp4:~# cat /proc/cmdline
  BOOT_IMAGE=/boot/vmlinux-4.8.0-34-generic 
root=UUID=0bcf3431-df8b-499c-9a13-33070f242e0c ro splash quiet 
crashkernel=384M-:512M

  root@roselp4:~# dmesg | grep Reser
  [0.00] Reserving 512MB of memory at 128MB for crashkernel (System 
RAM: 21760MB)

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1788549] Re: powerpc/powernv/pci: Work around races in PCI bridge enabling

[Manoj Iyer]

*** This bug is a duplicate of bug 1805245 ***
https://bugs.launchpad.net/bugs/1805245

** This bug has been marked a duplicate of bug 1805245
   powerpc/powernv/pci: Work around races in PCI bridge enabling

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1788549

Title:
  powerpc/powernv/pci: Work around races in PCI bridge enabling

Status in The Ubuntu-power-systems project:
  Incomplete
Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Bionic:
  In Progress
Status in linux source package in Cosmic:
  Fix Released

Bug description:
  == Comment: #0 - Michael Ranweiler  - 2018-08-21 
13:52:03 ==
  +++ This bug was initially created as a clone of Bug #170766 +++

  Please apply the following kernel patch:

  
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=next=db2173198b9513f7add8009f225afa1f1c79bcc6

  powerpc/powernv/pci: Work around races in PCI bridge enabling

  The generic code is racy when multiple children of a PCI bridge try to
  enable it simultaneously.

  This leads to drivers trying to access a device through a
  not-yet-enabled bridge, and this EEH errors under various
  circumstances when using parallel driver probing.

  There is work going on to fix that properly in the PCI core but it
  will take some time.

  x86 gets away with it because (outside of hotplug), the BIOS enables
  all the bridges at boot time.

  This patch does the same thing on powernv by enabling all bridges that
  have child devices at boot time, thus avoiding subsequent races. It's
  suitable for backporting to stable and distros, while the proper PCI
  fix will probably be significantly more invasive.

  Signed-off-by: Benjamin Herrenschmidt 
  Cc: sta...@vger.kernel.org
  Signed-off-by: Michael Ellerman 

  == Comment: #2 - Michael Ranweiler  - 2018-08-21 
18:23:35 ==
  This has some fuzz and also move it back from the pci macro to dev_err so 
we'll attach the backported patch.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1783252] Re: gcc on ppc64le has bogus r30 register handling, as exposed by greenlet 0.4.14 will not build on ppc64le

[Manoj Iyer]

Based on comment #40 (doko) marking this series as won't fix.

** Changed in: gcc-5 (Ubuntu Bionic)
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1783252

Title:
  gcc on ppc64le has bogus r30 register handling, as exposed by greenlet
  0.4.14 will not build on ppc64le

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in gcc-5 package in Ubuntu:
  Fix Released
Status in gcc-6 package in Ubuntu:
  Fix Released
Status in python-greenlet package in Ubuntu:
  Fix Released
Status in gcc-5 source package in Xenial:
  Fix Released
Status in gcc-5 source package in Bionic:
  Won't Fix
Status in gcc-6 source package in Cosmic:
  Fix Committed

Bug description:
  [Impact]

   * GCC has a minor bug w.r.t. clobber r30 register in PIC binaries.
   * A patch to fix this has been upstream in 6+
   * But it is not in gcc-5.4 as used on xenial
   * This prevents compiling future-proof and correct greenlet code, on Ubuntu 
16.04 LTS as used by current and supported Openstack Queens release on ppc64el
   * Whilst backported greenlet is available via the cloud archive for binary 
usage, the toolchain is still technically incorrect, and thus hinders using 
Ubuntu 16.04 LTS as workers in upstream Openstack CI
   * As a wishlist it would be nice to backport this one small gcc patch as an 
SRU

  [Test Case]

   * git clone https://github.com/python-greenlet/greenlet
   * cd greenlet
   * ./setup.py build
  Expect success

  Current result failure:

  creating build/temp.linux-ppc64le-2.7
  powerpc64le-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall 
-Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC 
-I/usr/include/python2.7 -c greenlet.c -o 
build/temp.linux-ppc64le-2.7/greenlet.o -fno-tree-dominator-opts
  In file included from slp_platformselect.h:16:0,
   from greenlet.c:343:
  platform/switch_ppc64_linux.h: In function 'slp_switch':
  platform/switch_ppc64_linux.h:80:5: error: PIC register clobbered by 'r30' in 
'asm'
   __asm__ volatile ("" : : : REGS_TO_SAVE);
   ^
  platform/switch_ppc64_linux.h:95:5: error: PIC register clobbered by 'r30' in 
'asm'
   __asm__ volatile ("" : : : REGS_TO_SAVE);
   ^
  error: command 'powerpc64le-linux-gnu-gcc' failed with exit status 1

  
  [Regression Potential] 

   * Upstream cherrypick present in later releases including bionic
  
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9213244550335bcb2b8590a0d7d58ac74c932361

  
  [Other Info]
   
   * Original bug report

  
  == Comment: #0 - William M. Edmonds  - 2018-07-23 
16:21:41 ==
  ---Problem Description---
  greenlet 0.4.14 will not build on ppc64le

  Opened https://github.com/python-greenlet/greenlet/issues/136 because
  attempting to build bdist_wheel for greenlet 0.4.14 on ppc64le Ubuntu
  16.04 LTS yields the following error:

  running build
  running build_ext
  building 'greenlet' extension
  creating build
  creating build/temp.linux-ppc64le-2.7
  powerpc64le-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall 
-Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC 
-I/usr/include/python2.7 -c greenlet.c -o 
build/temp.linux-ppc64le-2.7/greenlet.o -fno-tree-dominator-opts
  In file included from slp_platformselect.h:16:0,
  from greenlet.c:343:
     platform/switch_ppc64_linux.h: In function 'slp_switch':
     platform/switch_ppc64_linux.h:80:5: error: PIC register clobbered by 'r30' 
in 'asm'
  __asm__ volatile ("" : : : REGS_TO_SAVE);
  ^
     platform/switch_ppc64_linux.h:95:5: error: PIC register clobbered by 'r30' 
in 'asm'
  __asm__ volatile ("" : : : REGS_TO_SAVE);
  ^
     error: command 'powerpc64le-linux-gnu-gcc' failed with exit status 1```

  But the greenlet community is saying this is a gcc bug and it would
  not be safe to revert the greenlet change that exposed this issue. I
  have no idea whether that is true or not. Supposedly this should be
  fixed by
  
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9213244550335bcb2b8590a0d7d58ac74c932361
  but that fix is not present in the latest version of gcc (5.4.0)
  available for Ubuntu 16.04 LTS.

  ---uname output---
  unavailable due to lab outage

  Machine Type = unavailable due to lab outage

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

  ---Steps to Reproduce---
  This should be reproducible with `git clone 
git://github.com/python-greenlet/greenlet; cd greenlet; python setup.py 
bdist_wheel`, though it was originally found using pypi rather than github and 
with a more complicated (scripted) command as detailed in the greenlet bug 
description.

  Contact Information = 

[Group.of.nepali.translators] [Bug 1760099] Re: Additional spectre and meltdown patches

[Manoj Iyer]

** Changed in: linux (Ubuntu Trusty)
   Status: Triaged => Won't Fix

** Changed in: ubuntu-power-systems
   Status: Incomplete => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1760099

Title:
  Additional spectre and meltdown patches

Status in The Ubuntu-power-systems project:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  Won't Fix
Status in linux source package in Xenial:
  Fix Released
Status in linux source package in Artful:
  Won't Fix
Status in linux source package in Bionic:
  Fix Released

Bug description:
  == Comment: #0 - Breno Leitao  - 2018-03-29 08:53:56 ==
  Hi Canonical,

  There are some additional patches for Spectre and Meltdown that is
  required on ppc64el. We would need to have them included on all Ubuntu
  kernels.

  This is the patch series:

  [v2,10/10] powerpc/64s: Wire up cpu_show_spectre_v2()   [v2,01/10] powerpc: 
Add security feature flags for Spectre/Meltdown 
   
  [v2,09/10] powerpc/64s: Wire up cpu_show_spectre_v1()   [v2,01/10] powerpc: 
Add security feature flags for Spectre/Meltdown
  [v2,08/10] powerpc/pseries: Use the security flags in 
pseries_setup_rfi_flush() [v2,01/10] powerpc: Add security feature 
flags for Spectre/Meltdown
  [v2,07/10] powerpc/powernv: Use the security flags in pnv_setup_rfi_flush()   
  [v2,01/10] powerpc: Add security feature flags for Spectre/Meltdown
  [v2,06/10] powerpc/64s: Enhance the information in cpu_show_meltdown()  
[v2,01/10] powerpc: Add security feature flags for Spectre/Meltdown
  [v2,05/10] powerpc/64s: Move cpu_show_meltdown()[v2,01/10] powerpc: 
Add security feature flags for Spectre/Meltdown
  [v2,04/10] powerpc/powernv: Set or clear security feature flags 
[v2,01/10] powerpc: Add security feature flags for Spectre/Meltdown
  [v2,03/10] powerpc/pseries: Set or clear security feature flags 
[v2,01/10] powerpc: Add security feature flags for Spectre/Meltdown
  [v2,02/10] powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags 
[v2,01/10] powerpc: Add security feature flags for Spectre/Meltdown 
  [v2,01/10] powerpc: Add security feature flags for Spectre/Meltdown 
[v2,01/10] powerpc: Add security feature flags for Spectre/Meltdown 

  http://patchwork.ozlabs.org/project/linuxppc-
  dev/list/?series=36012=*

  == Comment: #1 - Breno Leitao  - 2018-03-29 08:55:48 ==
  This is a better formatted patch series list:

  [v2,10/10] powerpc/64s: Wire up cpu_show_spectre_v2() 

 
  [v2,09/10] powerpc/64s: Wire up cpu_show_spectre_v1()   
  [v2,08/10] powerpc/pseries: Use the security flags in 
pseries_setup_rfi_flush() 
  [v2,07/10] powerpc/powernv: Use the security flags in pnv_setup_rfi_flus()
  
  [v2,06/10] powerpc/64s: Enhance the information in cpu_show_meltdown()  
  [v2,05/10] powerpc/64s: Move cpu_show_meltdown()
  [v2,04/10] powerpc/powernv: Set or clear security feature flags 
  [v2,03/10] powerpc/pseries: Set or clear security feature flags 
  [v2,02/10] powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags 
  [v2,01/10] powerpc: Add security feature flags for Spectre/Meltdown

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1783140] Re: KVM live migration fails

[Manoj Iyer]

** Changed in: linux (Ubuntu)
   Status: Triaged => Invalid

** Changed in: ubuntu-power-systems
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1783140

Title:
  KVM live migration fails

Status in The Ubuntu-power-systems project:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * Backport fix from the 2.6.2 stable branch to the qemu 2.5 in Xenial

   * Newer guests might use virtio attributes that are clobbered on 
 migration with the old qemu code.

  [Test Case]

   * Setup two Xenial hosts on ppc64el

   * Create a guest that has a rather new kernel (>=4.14) I'd recommend 
 Bionic

   * Migrate that guest from Host1 to Host2

  [Regression Potential]

   * The modification could affect virtio handling in other cases in a non 
 expected way, but mostly related to migrations. So the expected 
 regression would be issues to migrate properly.
 I verified plenty of migrations in regression testing and we had
 this very code in the Yakkety release as we picked 2.6.1 stable release 
 back then. Due to that it is actually pretty well tested and should not 
 really regress anything out in the wild.

  [Other Info]
   
   * So far this only triggers on the confused endian marshalling on 
 ppc64el, but in theory a different case could trigger it on x86 just as 
 much.

  ---

  Environment:
  2 POWER8 with Ubuntu 16.04.4 LTS as KVM hypervisor.
  1 KVM guest with Ubuntu 18.04 LTS. Virtual disk for the guest is a qcow2 file 
on an NFS share, accessible from both hypervisors, so live migration is 
possible and works for all other guests (SLES, RHEL, Ubunutu 16.04),
  Live migratino of Ubuntu 18.04 guest fails on ppc, while the same test on an 
x86_64 environment suceeds.

  root@pkvm2:~# virsh migrate --persistent --live p8lnxtst4 
qemu+ssh://pkvm1/system
  error: internal error: early end of file from monitor, possible problem: 
2018-07-23T11:12:25.586385Z qemu-system-ppc64: VQ 0 size 0x100 Guest index 
0x38aa inconsistent with Host index 0xa980: delta 0x8f2a
  2018-07-23T11:12:25.586434Z qemu-system-ppc64: error while loading state for 
instance 0x0 of device 'pci@8002000:01.0/virtio-net'
  2018-07-23T11:12:25.587246Z qemu-system-ppc64: load of migration failed: 
Operation not permitted

  root@pkvm2:~# uname -a
  Linux pkvm2 4.4.0-130-generic #156-Ubuntu SMP Thu Jun 14 08:51:21 UTC 2018 
ppc64le ppc64le ppc64le GNU/Linux

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1783252] Re: gcc on ppc64le has bogus r30 register handling, as exposed by greenlet 0.4.14 will not build on ppc64le

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: Won't Fix => In Progress

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1783252

Title:
  gcc on ppc64le has bogus r30 register handling, as exposed by greenlet
  0.4.14 will not build on ppc64le

Status in The Ubuntu-power-systems project:
  In Progress
Status in gcc-5 package in Ubuntu:
  Won't Fix
Status in python-greenlet package in Ubuntu:
  Fix Released
Status in gcc-5 source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * GCC has a minor bug w.r.t. clobber r30 register in PIC binaries.
   * A patch to fix this has been upstream in 6+
   * But it is not in gcc-5.4 as used on xenial
   * This prevents compiling future-proof and correct greenlet code, on Ubuntu 
16.04 LTS as used by current and supported Openstack Queens release on ppc64el
   * Whilst backported greenlet is available via the cloud archive for binary 
usage, the toolchain is still technically incorrect, and thus hinders using 
Ubuntu 16.04 LTS as workers in upstream Openstack CI
   * As a wishlist it would be nice to backport this one small gcc patch as an 
SRU

  [Test Case]

   * git clone https://github.com/python-greenlet/greenlet
   * cd greenlet
   * ./setup.py build
  Expect success

  Current result failure:

  creating build/temp.linux-ppc64le-2.7
  powerpc64le-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall 
-Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC 
-I/usr/include/python2.7 -c greenlet.c -o 
build/temp.linux-ppc64le-2.7/greenlet.o -fno-tree-dominator-opts
  In file included from slp_platformselect.h:16:0,
   from greenlet.c:343:
  platform/switch_ppc64_linux.h: In function 'slp_switch':
  platform/switch_ppc64_linux.h:80:5: error: PIC register clobbered by 'r30' in 
'asm'
   __asm__ volatile ("" : : : REGS_TO_SAVE);
   ^
  platform/switch_ppc64_linux.h:95:5: error: PIC register clobbered by 'r30' in 
'asm'
   __asm__ volatile ("" : : : REGS_TO_SAVE);
   ^
  error: command 'powerpc64le-linux-gnu-gcc' failed with exit status 1

  
  [Regression Potential] 

   * Upstream cherrypick present in later releases including bionic
  
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9213244550335bcb2b8590a0d7d58ac74c932361

  
  [Other Info]
   
   * Original bug report

  
  == Comment: #0 - William M. Edmonds  - 2018-07-23 
16:21:41 ==
  ---Problem Description---
  greenlet 0.4.14 will not build on ppc64le

  Opened https://github.com/python-greenlet/greenlet/issues/136 because
  attempting to build bdist_wheel for greenlet 0.4.14 on ppc64le Ubuntu
  16.04 LTS yields the following error:

  running build
  running build_ext
  building 'greenlet' extension
  creating build
  creating build/temp.linux-ppc64le-2.7
  powerpc64le-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall 
-Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC 
-I/usr/include/python2.7 -c greenlet.c -o 
build/temp.linux-ppc64le-2.7/greenlet.o -fno-tree-dominator-opts
  In file included from slp_platformselect.h:16:0,
  from greenlet.c:343:
     platform/switch_ppc64_linux.h: In function 'slp_switch':
     platform/switch_ppc64_linux.h:80:5: error: PIC register clobbered by 'r30' 
in 'asm'
  __asm__ volatile ("" : : : REGS_TO_SAVE);
  ^
     platform/switch_ppc64_linux.h:95:5: error: PIC register clobbered by 'r30' 
in 'asm'
  __asm__ volatile ("" : : : REGS_TO_SAVE);
  ^
     error: command 'powerpc64le-linux-gnu-gcc' failed with exit status 1```

  But the greenlet community is saying this is a gcc bug and it would
  not be safe to revert the greenlet change that exposed this issue. I
  have no idea whether that is true or not. Supposedly this should be
  fixed by
  
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9213244550335bcb2b8590a0d7d58ac74c932361
  but that fix is not present in the latest version of gcc (5.4.0)
  available for Ubuntu 16.04 LTS.

  ---uname output---
  unavailable due to lab outage

  Machine Type = unavailable due to lab outage

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

  ---Steps to Reproduce---
  This should be reproducible with `git clone 
git://github.com/python-greenlet/greenlet; cd greenlet; python setup.py 
bdist_wheel`, though it was originally found using pypi rather than github and 
with a more complicated (scripted) command as detailed in the greenlet bug 
description.

  Contact Information = Matthew Edmonds / edmon...@us.ibm.com

  Userspace tool common name: greenlet

  The userspace tool has the following bit modes: no idea

  Userspace rpm: N/A

  Userspace tool obtained from project website:  0.4.14

  *Additional 

[Group.of.nepali.translators] [Bug 1765660] Re: Ubuntu 18.04 [ briggs ]: "ipcs" command fails with error "invalid structure member offset" in crash prompt.

[Manoj Iyer]

Sorry for all the confusion I might have created. cascardo, thanks for
fixing my errors.

** Changed in: ubuntu-power-systems
   Status: Fix Released => In Progress

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1765660

Title:
  Ubuntu 18.04 [ briggs ]: "ipcs" command fails with error "invalid
  structure member offset" in crash prompt.

Status in The Ubuntu-power-systems project:
  In Progress
Status in crash package in Ubuntu:
  Fix Released
Status in crash source package in Xenial:
  Won't Fix
Status in crash source package in Artful:
  Won't Fix
Status in crash source package in Bionic:
  In Progress
Status in crash source package in Cosmic:
  Fix Released

Bug description:
  [Impact]
  Some analysis won't be possible on new kernels (hwe-edge on xenial, for 
example; or the standard bionic kernel).

  [Test Case]
  The ipcs command has been run after the fix was applied to crash, on a live 
amd64 system, with success.

  [Regression Potential]
  Analysis of crashed kernels will require that the crash file be moved to a 
system where crash doesn't have the regression. The patch, however, should 
touch only the broken command, and has been tested.

  -

  
  == Comment: #0 - PAVITHRA R. PRAKASH <> - 2018-03-29 01:14:47 ==
  ---Problem Description---

  Ubuntu 18.04: "ipcs" command fails with error "invalid structure
  member offset" in crash prompt.

  ---Environment--

  System Name :  ltc-briggs2
  Model/Type  :  P8
  Platform:  BML

  ---Uname output---

  root@ltc-briggs2:~# uname -a
  Linux ltc-briggs2 4.15.0-13-generic #14-Ubuntu SMP Sat Mar 17 13:43:15 UTC 
2018 ppc64le ppc64le ppc64le GNU/Linux

  ---Steps to reproduce--

  1. Configure kdump.
  2. Trigger crash
  3. run crash on captured dump

  ---Logs

  root@ltc-briggs2:~# dpkg -l|grep makedumpfile
  ii  makedumpfile   1:1.6.3-1  
  ppc64el  VMcore extraction tool
  root@ltc-briggs2:~# dpkg -l|grep crash
  ii  apport 2.20.9-0ubuntu1
  all  automatically generate crash reports for debugging
  ii  crash  7.2.1-1
  ppc64el  kernel debugging utility, allowing gdb like syntax
  ii  kdump-tools1:1.6.3-1  
  ppc64el  scripts and tools for automating kdump (Linux crash dumps)
  ii  python3-apport 2.20.9-0ubuntu1
  all  Python 3 library for Apport crash report handling
  root@ltc-briggs2:~# dpkg -l|grep kexec
  ii  kexec-tools1:2.0.16-1ubuntu1  
  ppc64el  tools to support fast kexec reboots
  root@ltc-briggs2:~#

  .0-13-generic dump.201803272257 03272257# crash
  /usr/lib/debug/boot/vmlinux-4.15.

  crash 7.2.1
  Copyright (C) 2002-2017  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.

  GNU gdb (GDB) 7.6
  Copyright (C) 2013 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "powerpc64le-unknown-linux-gnu"...

    KERNEL: /usr/lib/debug/boot/vmlinux-4.15.0-13-generic
  DUMPFILE: dump.201803272257  [PARTIAL DUMP]
  CPUS: 160
  DATE: Tue Mar 27 22:56:58 2018
    UPTIME: 00:04:07
  LOAD AVERAGE: 1.06, 0.53, 0.20
     TASKS: 1734
  NODENAME: ltc-briggs2
   RELEASE: 4.15.0-13-generic
   VERSION: #14-Ubuntu SMP Sat Mar 17 13:43:15 UTC 2018
   MACHINE: ppc64le  (2926 Mhz)
    MEMORY: 512 GB
     PANIC: "sysrq: SysRq : Trigger a crash"
   PID: 7420
   COMMAND: "bash"
  TASK: c03e56c7c600  [THREAD_INFO: c03e56cb]
   CPU: 41
     STATE: TASK_RUNNING (SYSRQ)

  crash> ?

  *  files  mach   repeat timer
  alias  foreachmodrunq   tree
  ascii  fuser  mount 

[Group.of.nepali.translators] [Bug 1779815] Re: [Ubuntu 18.04.01][BostonLC][mpt3sas] installer does not detect any LSI based SAS/md raid device

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1779815

Title:
  [Ubuntu 18.04.01][BostonLC][mpt3sas] installer does not detect any LSI
  based SAS/md raid device

Status in The Ubuntu-power-systems project:
  Fix Released
Status in debian-installer package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Committed
Status in debian-installer source package in Xenial:
  Fix Released
Status in systemd source package in Xenial:
  Fix Released
Status in debian-installer source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released

Bug description:
  == Comment: #0 - ABDUL HALEEM  - 2018-07-02 03:55:33 ==
  ---Problem Description---
  Ubuntu 18.04.01 ppc64el installer does not detect LSI3008  base SAS disks / 
MD RAID devices 

  Used 20101020ubuntu543 version to install
  
http://ports.ubuntu.com/ubuntu-ports/dists/bionic/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/

  Contact Information = abdha...@in.ibm.com 
   
  ---uname output---
  Linux ltc-boston21 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 
2018 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = BostonLC
   
  ---boot type---
  Network boot
   

  Installer fails to detect the LSI SAS disks / RAID MD device

  ===console error log===

?? [!!] Partition disks ???
? ?
? Note that all data on the disk you select will be erased, but not   ?
? before you have confirmed that you really want to make the changes. ?
? ?
? Select disk to partition:   ?
? ?
? /dev/nvme0n1 - 491.5 GB NVMe Device ?
? /dev/nvme1n1 - 98.3 GB NVMe Device  ?
? ?
??
? ?
???



   moves;  selects;  activates buttons

  
  To make sure it detects the disks I had to 
  
  
  Detect disks-->Guided partitioning--> Guided - use entire disk 

  
?? [!!] Partition disks ???
? ?
? Note that all data on the disk you select will be erased, but not   ?
? before you have confirmed that you really want to make the changes. ?
? ?
? Select disk to partition:   ?
? ?
?  /dev/nvme0n1 - 491.5 GB NVMe Device?
?  /dev/nvme1n1 - 98.3 GB NVMe Device ?
?  SCSI3 (0,0,0) (sda) - 4.0 TB SEAGATE ST4000NM0075  ?
?  SCSI3 (1,0,0) (sdb) - 199.9 GB LSI Logical Volume  ?
?  SCSI3 (0,2,0) (sdc) - 2.0 TB ATA ST2000NM0125-1YZ  ?
? ?
??
? ?
???

  IPR had similar issue reported  #164932 and fixed with 4.15.0-20,
  looks installer need a fix for LSI (mpt3sas) devices too

  == Comment: #2 - SEETEENA THOUFEEK  - 2018-07-03 
02:01:47 ==
  164932 - refers LP1751813

  == Comment: #3 - SEETEENA THOUFEEK  - 2018-07-03 
02:02:51 ==
  Jul  2 08:49:52 anna-install: Installing mdadm-udeb
  Jul  2 08:49:52 disk-detect: No Intel/DDF RAID disks detected.
  Jul  2 08:49:52 anna-install: Installing dmraid-udeb
  Jul  2 08:49:52 disk-detect: No Serial ATA RAID disks detected
  Jul  2 08:49:53 check-missing-firmware: looking at dmesg again, restarting 
from \[  330.659712\]
  Jul  2 08:49:53 check-missing-firmware: timestamp found, truncating dmesg 
accordingly
  Jul  2 08:49:53 check-missing-firmware: saving timestamp for a later use: 
  Jul  2 08:49:53 check-missing-firmware: /dev/.udev/firmware-missing does not 
exist, skipping
  Jul  2 08:49:53 check-missing-firmware: /run/udev/firmware-missing does not 

[Group.of.nepali.translators] [Bug 1779815] Re: [Ubuntu 18.04.01][BostonLC][mpt3sas] installer does not detect any LSI based SAS/md raid device

[Manoj Iyer]

abdhalee, Looks like you have successfully verified, could you please
change the tag to verification-done-bionic ?

** No longer affects: linux (Ubuntu)

** No longer affects: linux (Ubuntu Xenial)

** No longer affects: linux (Ubuntu Bionic)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1779815

Title:
  [Ubuntu 18.04.01][BostonLC][mpt3sas] installer does not detect any LSI
  based SAS/md raid device

Status in The Ubuntu-power-systems project:
  In Progress
Status in debian-installer package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Committed
Status in debian-installer source package in Xenial:
  New
Status in systemd source package in Xenial:
  New
Status in debian-installer source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Fix Committed

Bug description:
  == Comment: #0 - ABDUL HALEEM  - 2018-07-02 03:55:33 ==
  ---Problem Description---
  Ubuntu 18.04.01 ppc64el installer does not detect LSI3008  base SAS disks / 
MD RAID devices 

  Used 20101020ubuntu543 version to install
  
http://ports.ubuntu.com/ubuntu-ports/dists/bionic/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/

  Contact Information = abdha...@in.ibm.com 
   
  ---uname output---
  Linux ltc-boston21 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 
2018 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = BostonLC
   
  ---boot type---
  Network boot
   

  Installer fails to detect the LSI SAS disks / RAID MD device

  ===console error log===

?? [!!] Partition disks ???
? ?
? Note that all data on the disk you select will be erased, but not   ?
? before you have confirmed that you really want to make the changes. ?
? ?
? Select disk to partition:   ?
? ?
? /dev/nvme0n1 - 491.5 GB NVMe Device ?
? /dev/nvme1n1 - 98.3 GB NVMe Device  ?
? ?
??
? ?
???



   moves;  selects;  activates buttons

  
  To make sure it detects the disks I had to 
  
  
  Detect disks-->Guided partitioning--> Guided - use entire disk 

  
?? [!!] Partition disks ???
? ?
? Note that all data on the disk you select will be erased, but not   ?
? before you have confirmed that you really want to make the changes. ?
? ?
? Select disk to partition:   ?
? ?
?  /dev/nvme0n1 - 491.5 GB NVMe Device?
?  /dev/nvme1n1 - 98.3 GB NVMe Device ?
?  SCSI3 (0,0,0) (sda) - 4.0 TB SEAGATE ST4000NM0075  ?
?  SCSI3 (1,0,0) (sdb) - 199.9 GB LSI Logical Volume  ?
?  SCSI3 (0,2,0) (sdc) - 2.0 TB ATA ST2000NM0125-1YZ  ?
? ?
??
? ?
???

  IPR had similar issue reported  #164932 and fixed with 4.15.0-20,
  looks installer need a fix for LSI (mpt3sas) devices too

  == Comment: #2 - SEETEENA THOUFEEK  - 2018-07-03 
02:01:47 ==
  164932 - refers LP1751813

  == Comment: #3 - SEETEENA THOUFEEK  - 2018-07-03 
02:02:51 ==
  Jul  2 08:49:52 anna-install: Installing mdadm-udeb
  Jul  2 08:49:52 disk-detect: No Intel/DDF RAID disks detected.
  Jul  2 08:49:52 anna-install: Installing dmraid-udeb
  Jul  2 08:49:52 disk-detect: No Serial ATA RAID disks detected
  Jul  2 08:49:53 check-missing-firmware: looking at dmesg again, restarting 
from \[  330.659712\]
  Jul  2 08:49:53 check-missing-firmware: timestamp found, truncating dmesg 
accordingly
  Jul  2 08:49:53 check-missing-firmware: saving timestamp for a later use: 
  Jul  2 08:49:53 

[Group.of.nepali.translators] [Bug 1746088] Re: [Ubuntu 16.04.4] Unable to analyze the vmcore generated by kdump on 4.13.0-26-generic kernel

[Manoj Iyer]

** Changed in: crash (Ubuntu Artful)
   Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1746088

Title:
  [Ubuntu 16.04.4] Unable to analyze the vmcore generated by kdump on
  4.13.0-26-generic kernel

Status in The Ubuntu-power-systems project:
  In Progress
Status in crash package in Ubuntu:
  Fix Released
Status in crash source package in Xenial:
  New
Status in crash source package in Artful:
  Won't Fix
Status in crash source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  It won't be possible to analyze dumps produced by newer kernels (hwe on 
xenial, for example).

  [Test Case]
  Tested that this version of crash can analyze both GA (4.4) and hwe (4.15) 
kernels.

  [Regression Potential]
  New crash versions may have bugs and some commands not work with older 
kernels. The smoke test helps a little, but more testing may be desirable.


  ---Problem Description---
  Unable to analyze the vmcore generated by kdump on 4.13.0-26-generic kernel 
(Ubuntu 16.04.4)

  ---uname output---
  Linux ltc-briggs1 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 21:40:36 
UTC 2018 ppc64le ppc64le ppc64le GNU/Linux

  Machine Type = 8001-22C

  ---Steps to Reproduce---
   This bug follow up bug of 
https://bugzilla.linux.ibm.com/show_bug.cgi?id=163565
  The steps to create dump is as follows

  Once you generate the kdump
  use crash to analyze the vmcore and we get this error

  console logs ==

  root@ltc-briggs1:/var/crash/201801150227# ls
  dmesg.201801150227  vmcore.201801150227
  .0-26-generic vmcore.2018011502271150227# crash 
/usr/lib/debug/boot/vmlinux-4.13.

  crash 7.1.4
  Copyright (C) 2002-2015  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.

  GNU gdb (GDB) 7.6
  Copyright (C) 2013 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "powerpc64le-unknown-linux-gnu"...

  please wait... (gathering module symbol data)
  WARNING: cannot access vmalloc'd module memory

  crash: invalid structure member offset: thread_info_task
     FILE: task.c  LINE: 598  FUNCTION: irqstacks_init()

  [/usr/bin/crash] error trace: 1008ade0 => 1011552c => 1017d220 =>
  100833e0

    100833e0: (undetermined)
    1017d220: OFFSET_verify+80
    1011552c: task_init+5084
    1008ade0: main_loop+336

  == Comment from Hari Krishna Bathini ==

  There are quite a few commits (all available upstream) that are needed for
  crash tool to work fine. I think the right thing to do here would be to use
  the latest crash tool version 7.2.0 to go with the kernel update. Also, the
  below commit would be needed on top of 7.2.0 crash utility:

    commit c8178eca9c74f81a7f803a58d339635cc152e8d9
    Author: Dave Anderson 
    Date:   Thu Nov 9 11:39:05 2017 -0500

  Update for support of Linux 4.14 and later PPC64 kernels where the
  hash page table geometry accomodates a larger virtual address range.
  Without the patch, the virtual-to-physical translation of user space
  virtual addresses by "vm -p", "vtop", and "rd -u" may generate an
  invalid translation or otherwise fail.
  (hbath...@linux.vnet.ibm.com)

  Similar thing holds true for makedumpfile tool..

  Thanks
  Hari

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1765660] Re: Ubuntu 18.04 [ briggs ]: "ipcs" command fails with error "invalid structure member offset" in crash prompt.

[Manoj Iyer]

Looks like the patch mentioned in this bug is already present in bionic

0a835c4f090a Reimplement IDR and IDA using the radix tree

Closing out the bionic track as fix released.

** Changed in: crash (Ubuntu Bionic)
   Status: In Progress => Fix Released

** Changed in: ubuntu-power-systems
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1765660

Title:
  Ubuntu 18.04 [ briggs ]: "ipcs" command fails with error "invalid
  structure member offset" in crash prompt.

Status in The Ubuntu-power-systems project:
  Fix Released
Status in crash package in Ubuntu:
  Fix Released
Status in crash source package in Xenial:
  Won't Fix
Status in crash source package in Artful:
  Won't Fix
Status in crash source package in Bionic:
  Fix Released
Status in crash source package in Cosmic:
  Fix Released

Bug description:
  [Impact]
  Some analysis won't be possible on new kernels (hwe-edge on xenial, for 
example; or the standard bionic kernel).

  [Test Case]
  The ipcs command has been run after the fix was applied to crash, on a live 
amd64 system, with success.

  [Regression Potential]
  Analysis of crashed kernels will require that the crash file be moved to a 
system where crash doesn't have the regression. The patch, however, should 
touch only the broken command, and has been tested.

  -

  
  == Comment: #0 - PAVITHRA R. PRAKASH <> - 2018-03-29 01:14:47 ==
  ---Problem Description---

  Ubuntu 18.04: "ipcs" command fails with error "invalid structure
  member offset" in crash prompt.

  ---Environment--

  System Name :  ltc-briggs2
  Model/Type  :  P8
  Platform:  BML

  ---Uname output---

  root@ltc-briggs2:~# uname -a
  Linux ltc-briggs2 4.15.0-13-generic #14-Ubuntu SMP Sat Mar 17 13:43:15 UTC 
2018 ppc64le ppc64le ppc64le GNU/Linux

  ---Steps to reproduce--

  1. Configure kdump.
  2. Trigger crash
  3. run crash on captured dump

  ---Logs

  root@ltc-briggs2:~# dpkg -l|grep makedumpfile
  ii  makedumpfile   1:1.6.3-1  
  ppc64el  VMcore extraction tool
  root@ltc-briggs2:~# dpkg -l|grep crash
  ii  apport 2.20.9-0ubuntu1
  all  automatically generate crash reports for debugging
  ii  crash  7.2.1-1
  ppc64el  kernel debugging utility, allowing gdb like syntax
  ii  kdump-tools1:1.6.3-1  
  ppc64el  scripts and tools for automating kdump (Linux crash dumps)
  ii  python3-apport 2.20.9-0ubuntu1
  all  Python 3 library for Apport crash report handling
  root@ltc-briggs2:~# dpkg -l|grep kexec
  ii  kexec-tools1:2.0.16-1ubuntu1  
  ppc64el  tools to support fast kexec reboots
  root@ltc-briggs2:~#

  .0-13-generic dump.201803272257 03272257# crash
  /usr/lib/debug/boot/vmlinux-4.15.

  crash 7.2.1
  Copyright (C) 2002-2017  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.

  GNU gdb (GDB) 7.6
  Copyright (C) 2013 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "powerpc64le-unknown-linux-gnu"...

    KERNEL: /usr/lib/debug/boot/vmlinux-4.15.0-13-generic
  DUMPFILE: dump.201803272257  [PARTIAL DUMP]
  CPUS: 160
  DATE: Tue Mar 27 22:56:58 2018
    UPTIME: 00:04:07
  LOAD AVERAGE: 1.06, 0.53, 0.20
     TASKS: 1734
  NODENAME: ltc-briggs2
   RELEASE: 4.15.0-13-generic
   VERSION: #14-Ubuntu SMP Sat Mar 17 13:43:15 UTC 2018
   MACHINE: ppc64le  (2926 Mhz)
    MEMORY: 512 GB
     PANIC: "sysrq: SysRq : Trigger a crash"
   PID: 7420
   COMMAND: "bash"
  TASK: c03e56c7c600  [THREAD_INFO: c03e56cb]
   CPU: 41
     STATE: TASK_RUNNING (SYSRQ)

  crash> ?

 

[Group.of.nepali.translators] [Bug 1771439] Re: [LTC Test] Ubuntu 18.04: tm_sigreturn failed on P8 compat mode 16.04.04 guest

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1771439

Title:
  [LTC Test] Ubuntu 18.04:  tm_sigreturn failed on P8 compat mode
  16.04.04 guest

Status in The Ubuntu-power-systems project:
  Fix Released
Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  Fix Released

Bug description:
  
  == SRU Justification ==
  IBM is seeing tm_sigreturn test failures on P8 and P9 hosts.  The bad thing
  exception is being raised when executing the following line:

  c004fcfc: b0 04 03 e8 ld r0,1200(r3)
  -> c004fd00: a6 23 02 7c mtspr 130,r0

  Which is basically restoring TEXASR in the thread.

  ISA says "These registers can be written only when in Non-transactional
  state" and the MSR is set to be transactional (suspended):

  MSR: 800300201033 [ME][RI][IR][DR][LE][SF][HTM][TSU]

  That explains why they are getting the "bad thing exception". A mtspr is
  being called with a transaction suspended.

  This test failure is fixed by upstream commit 78a3e8889b4b.
  Upstream commit 78a3e8889b4b is in mainline as of 4.8-rc5.

  == Fix ==
  78a3e8889b4b ("powerpc: signals: Discard transaction state from signal 
frames")

  == Regression Potential ==
  Low.  Specific to powerpc.

  == Test Case ==
  A test kernel was built with this patch and tested by the original bug 
reporter.
  The bug reporter states the test kernel resolved the bug.


  
  This test fails in the same way on a P8 host, so it is nothing to do with P9.

  There have been many TM bugs fixed upstream since 4.4. I would suggest
  starting with commit 044215d145a7 ("powerpc/tm: Fix illegal TM state
  in signal handler", 2017-08-22) and see if that helps.

  The bad thing exception is being raised when executing the following
  line:

   c004fcfc:   b0 04 03 e8 ld  r0,1200(r3)
    ->   c004fd00:   a6 23 02 7c mtspr   130,r0

  Which is basically restoring TEXASR in the thread.

  ISA says "These registers can be written only when in Non-
  transactional state" and the MSR is set to be transactional
  (suspended):

  MSR: 800300201033 [ME][RI][IR][DR][LE][SF][HTM][TSU]

  That explains why we are getting the "bad thing exception". A mtspr is
  being called with a transaction suspended.

  I think we need the following commit to have this fixed:

  commit 78a3e8889b4b6b99775ed954696ff3e017f5d19b
  Author: Cyril Bur 
  Date:   Tue Aug 23 10:46:17 2016 +1000

  powerpc: signals: Discard transaction state from signal frames

  Userspace can begin and suspend a transaction within the signal
  handler which means they might enter sys_rt_sigreturn() with the
  processor in suspended state.

  sys_rt_sigreturn() wants to restore process context (which may have
  been in a transaction before signal delivery). To do this it must
  restore TM SPRS. To achieve this, any transaction initiated within the
  signal frame must be discarded in order to be able to restore TM SPRs
  as TM SPRs can only be manipulated non-transactionally..
  >From the PowerPC ISA:
    TM Bad Thing Exception [Category: Transactional Memory]
     An attempt is made to execute a mtspr targeting a TM register in
     other than Non-transactional state.

  Not doing so results in a TM Bad Thing:
  [12045.221359] Kernel BUG at c0050a40 [verbose debug info 
unavailable]
  [12045.221470] Unexpected TM Bad Thing exception at c0050a40 (msr 
0x201033)
  [12045.221540] Oops: Unrecoverable exception, sig: 6 [#1]
  [12045.221586] SMP NR_CPUS=2048 NUMA PowerNV
  [12045.221634] Modules linked in: xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE
   nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 
nf_defrag_ipv4
   xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp 
llc ebtable_filter
   ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables 
kvm_hv kvm
   uio_pdrv_genirq ipmi_powernv uio powernv_rng ipmi_msghandler autofs4 ses 
enclosure
   scsi_transport_sas bnx2x ipr mdio libcrc32c
  [12045.222167] CPU: 68 PID: 6178 Comm: sigreturnpanic Not tainted 4.7.0 
#34
  [12045.24] task: c000fce38600 ti: c000fceb4000 task.ti: 
c000fceb4000
  [12045.93] NIP: c0050a40 LR: c00163bc CTR: 

  [12045.222361] REGS: c000fceb7ac0 TRAP: 0700   Not tainted (4.7.0)
  [12045.222418] MSR: 900300201033  CR: 
28444280  XER: 2000
  [12045.222625] CFAR: c00163b8 SOFTE: 0 PACATMSCRATCH: 
90014280f033
  GPR00: 0110b801 c000fceb7d40 c139c100 c000fce390d0
  GPR04: 90034280f033  

[Group.of.nepali.translators] [Bug 1761442] Re: sosreport: AttributeError: 'str' object has no attribute 'decode'

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1761442

Title:
  sosreport: AttributeError: 'str' object has no attribute 'decode'

Status in sosreport:
  New
Status in The Ubuntu-power-systems project:
  Fix Released
Status in sosreport package in Ubuntu:
  Fix Released
Status in sosreport source package in Trusty:
  Fix Released
Status in sosreport source package in Xenial:
  Fix Released
Status in sosreport source package in Artful:
  Fix Released
Status in sosreport source package in Bionic:
  Fix Released
Status in sosreport source package in Cosmic:
  Fix Released

Bug description:
  [impact]

  sosreport plugin(s) fail

  [test case]

  run sosreport, then extract the captured report and check the sos_logs
  /logs-plugin-errors.txt file for output like:

  Traceback (most recent call last):
    File "/usr/share/sosreport/sos/sosreport.py", line 1300, in collect
  plug.collect()
    File "/usr/share/sosreport/sos/plugins/__init__.py", line 877, in collect
  self._collect_strings()
    File "/usr/share/sosreport/sos/plugins/__init__.py", line 860, in 
_collect_strings
  (content.splitlines()[0]).decode('utf8', 'ignore'))
  AttributeError: 'str' object has no attribute 'decode'

  
  one of the ways to trigger this is for sosreport to gather a file that is 
larger than its max size to gather, for example log files over its --log-size 
limit.  To reproduce this way, first make sure one or more of the 
sosreport-gathered log files are over 1m, e.g. on a newly-installed system 
(where log files are small) you could do this just to generate logs:

  # udevadm control -l 7
  # for n in $( seq 1 50 ) ; do udevadm trigger ; done

  after that, /var/log/syslog should be larger than 1m.  Then run
  sosreport and limit its log file size to 1m:

  # sosreport --log-size 1

  The resulting sosreport will contain the error while trying to gather
  the syslog.

  
  [regression potential]

  the currently failing plugins fail to gather any of their data, so
  there is not much regression for them, but this change has the
  potential to affect any plugin and prevent data gathering.

  [other info]

  original description below.
  ---

  ---Problem Description---
  sosreport: ubuntu 16.04.04: AttributeError: 'str' object has no attribute 
'decode'

  ---uname output---
  Linux guest 4.15.0-13-generic #14~16.04.1-Ubuntu SMP Sat Mar 17 03:03:53 UTC 
2018 ppc64le ppc64le ppc64le GNU/Linux

  Machine Type = boston-LC

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

  ---Steps to Reproduce---
   running sosreport throws below error. report collection succeeds. this bug 
is to fix below:

  root@guest:~/sosreport-guest-20180405020015/sos_logs# cat 
logs-plugin-errors.txt
  Traceback (most recent call last):
    File "/usr/share/sosreport/sos/sosreport.py", line 1300, in collect
  plug.collect()
    File "/usr/share/sosreport/sos/plugins/__init__.py", line 877, in collect
  self._collect_strings()
    File "/usr/share/sosreport/sos/plugins/__init__.py", line 860, in 
_collect_strings
  (content.splitlines()[0]).decode('utf8', 'ignore'))
  AttributeError: 'str' object has no attribute 'decode'

  root@guest:~/sosreport-guest-20180405020015/sos_logs# lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 16.04.4 LTS
  Release:  16.04
  Codename: xenial
  root@guest:~/sosreport-guest-20180405020015/sos_logs# dpkg -l | grep -i sos
  ii  sosreport3.5-1~ubuntu16.04.2  
  ppc64el  Set of tools to gather troubleshooting data from a system

  == Comment: #5 - SEETEENA THOUFEEK  - 2018-04-05 
04:53:10 ==
  identified this commit will fix the issue.

  
https://github.com/sosreport/sos/commit/1fd12690870e85e8ac83b0e99bb272ce4489dc60

To manage notifications about this bug go to:
https://bugs.launchpad.net/sosreport/+bug/1761442/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1763685] Re: Fix for flushing TM on coredump only if CPU has TM feature

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1763685

Title:
  Fix for flushing TM on coredump only if CPU has TM feature

Status in The Ubuntu-power-systems project:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Invalid
Status in linux source package in Artful:
  Fix Released

Bug description:
  Problem description
  ==
  Fix for flushing TM on coredump only if CPU has TM feature

  ---Additional Hardware Info---
  POWER9/POWER8/compat mode 
   
  Machine Type = P9 baremetal + VM (POWER9, POWER8, Compat mode) 
   
  ---Steps to Reproduce---
   On POWER9 machines it's possible that TM is disabled for use by the VMs and 
if a coredump is generated in the VM it will crash since it will execute TM 
instructions when coredumping if a check is not present on the VM's kernel. 
Since POWER9 can run VM on P8 compatibility mode, it's necessary to patch all 
kernels that run on compat mode as well.
   
  Stack trace output:
   na
   
  Oops output:
   PID: 16438  TASK: c00272f515e0  CPU: 3   COMMAND: "vma05_vdso"
   #0 [c002711f7050] crash_kexec at c01a07e4
   #1 [c002711f7080] die at c0025278
   #2 [c002711f7120] _exception at c0025594
   #3 [c002711f72b0] program_check_exception at c0a0e1b8
   #4 [c002711f7330] program_check_common at c0006308
   Program Check [700] exception frame:
   R0:  R1:  c002711f7620R2:  c1274700
   R3:  c00272f51af0R4:  80010280b033R5:  
   R6:  0100R7:  R8:  
   R9:  0002R10: R11: 
   R12: c0010720R13: c7b81b00R14: 
   R15: R16: c002711f7db0R17: 00040006
   R18: c0002ab95800R19: 0100R20: 0001
   R21: 0002R22: c0bfc1c8R23: c002711f79b8
   R24: c0a30480R25: c0a30478R26: 0018
   R27: R28: c0002ab95800R29: 
   R30: 0100R31: c00272f515e0
   NIP: c005b10cMSR: 80010288b033OR3: c00108e0
   CTR: c0010720LR:  c00108e4XER: 2000
   CCR: 28002448MQ:  0001DAR: c00275599748
   DSISR: c00274092988 Syscall Result: 
   #5 [c002711f7620] tm_save_sprs at c005b10c
   [Link Register] [c002711f7620] vsr_get at c00108e4
   #6 [c002711f7770] fill_thread_core_info at c03d8b44
   #7 [c002711f7820] fill_note_info at c03d8e94
   #8 [c002711f78b0] elf_core_dump at c03d94d4
   #9 [c002711f7a90] do_coredump at c03dfcf4
  #10 [c002711f7c20] get_signal_to_deliver at c01061d4
  #11 [c002711f7d10] do_signal at c001beac
  #12 [c002711f7e00] do_notify_resume at c001c2cc
  #13 [c002711f7e30] ret_from_except_lite at c000a7b0
   System Call [c00] exception frame:
   R0:  00faR1:  3fffd0470f00R2:  3fffa8af7f00
   R3:  R4:  4036R5:  000b
   R6:  3fffd0471428R7:  1770R8:  4036
   R9:  R10: R11: 
   R12: R13: 3fffa8babb80R14: 
   R15: R16: R17: 
   R18: R19: R20: 
   R21: R22: R23: 
   R24: R25: R26: 
   R27: 3fffa8b9fbb8R28: 3fffa8baR29: 3fffa8b9f550
   R30: R31: 
   NIP: 3fffa8ad54c8MSR: 8000d033OR3: 4036
   CTR: LR:  155cXER: 
   CCR: 42000442MQ:  0001DAR: 3fffa89b2100
   DSISR: 4000 Syscall Result: 

  == Comment: #1 - Gustavo Bueno Romero  - 2018-04-12 
17:24:21 ==
  Dear maintainer, please cherry-pick the fix alreayd available upstream 
containing the additional check to avoid the issue here described. It must 
apply cleanly on stable kernels:

  "powerpc/tm: Flush TM only if CPU has TM feature":
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c1fa0768a8713b135848f78fd43ffc208d8ded70

  Please cherry-pick the pointed out fix and apply 

[Group.of.nepali.translators] [Bug 1765660] Re: Ubuntu 18.04 [ briggs ]: "ipcs" command fails with error "invalid structure member offset" in crash prompt.

[Manoj Iyer]

** Changed in: crash (Ubuntu Artful)
   Status: New => Won't Fix

** Changed in: crash (Ubuntu Xenial)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1765660

Title:
  Ubuntu 18.04 [ briggs ]: "ipcs" command fails with error "invalid
  structure member offset" in crash prompt.

Status in The Ubuntu-power-systems project:
  In Progress
Status in crash package in Ubuntu:
  Fix Released
Status in crash source package in Xenial:
  Won't Fix
Status in crash source package in Artful:
  Won't Fix
Status in crash source package in Bionic:
  In Progress
Status in crash source package in Cosmic:
  Fix Released

Bug description:
  [Impact]
  Some analysis won't be possible on new kernels (hwe-edge on xenial, for 
example; or the standard bionic kernel).

  [Test Case]
  The ipcs command has been run after the fix was applied to crash, on a live 
amd64 system, with success.

  [Regression Potential]
  Analysis of crashed kernels will require that the crash file be moved to a 
system where crash doesn't have the regression. The patch, however, should 
touch only the broken command, and has been tested.

  -

  
  == Comment: #0 - PAVITHRA R. PRAKASH <> - 2018-03-29 01:14:47 ==
  ---Problem Description---

  Ubuntu 18.04: "ipcs" command fails with error "invalid structure
  member offset" in crash prompt.

  ---Environment--

  System Name :  ltc-briggs2
  Model/Type  :  P8
  Platform:  BML

  ---Uname output---

  root@ltc-briggs2:~# uname -a
  Linux ltc-briggs2 4.15.0-13-generic #14-Ubuntu SMP Sat Mar 17 13:43:15 UTC 
2018 ppc64le ppc64le ppc64le GNU/Linux

  ---Steps to reproduce--

  1. Configure kdump.
  2. Trigger crash
  3. run crash on captured dump

  ---Logs

  root@ltc-briggs2:~# dpkg -l|grep makedumpfile
  ii  makedumpfile   1:1.6.3-1  
  ppc64el  VMcore extraction tool
  root@ltc-briggs2:~# dpkg -l|grep crash
  ii  apport 2.20.9-0ubuntu1
  all  automatically generate crash reports for debugging
  ii  crash  7.2.1-1
  ppc64el  kernel debugging utility, allowing gdb like syntax
  ii  kdump-tools1:1.6.3-1  
  ppc64el  scripts and tools for automating kdump (Linux crash dumps)
  ii  python3-apport 2.20.9-0ubuntu1
  all  Python 3 library for Apport crash report handling
  root@ltc-briggs2:~# dpkg -l|grep kexec
  ii  kexec-tools1:2.0.16-1ubuntu1  
  ppc64el  tools to support fast kexec reboots
  root@ltc-briggs2:~#

  .0-13-generic dump.201803272257 03272257# crash
  /usr/lib/debug/boot/vmlinux-4.15.

  crash 7.2.1
  Copyright (C) 2002-2017  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.

  GNU gdb (GDB) 7.6
  Copyright (C) 2013 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "powerpc64le-unknown-linux-gnu"...

    KERNEL: /usr/lib/debug/boot/vmlinux-4.15.0-13-generic
  DUMPFILE: dump.201803272257  [PARTIAL DUMP]
  CPUS: 160
  DATE: Tue Mar 27 22:56:58 2018
    UPTIME: 00:04:07
  LOAD AVERAGE: 1.06, 0.53, 0.20
     TASKS: 1734
  NODENAME: ltc-briggs2
   RELEASE: 4.15.0-13-generic
   VERSION: #14-Ubuntu SMP Sat Mar 17 13:43:15 UTC 2018
   MACHINE: ppc64le  (2926 Mhz)
    MEMORY: 512 GB
     PANIC: "sysrq: SysRq : Trigger a crash"
   PID: 7420
   COMMAND: "bash"
  TASK: c03e56c7c600  [THREAD_INFO: c03e56cb]
   CPU: 41
     STATE: TASK_RUNNING (SYSRQ)

  crash> ?

  *  files  mach   repeat timer
  alias  foreachmodrunq   tree
  ascii  fuser  mount  search union

[Group.of.nepali.translators] [Bug 1746299] Re: update makedumpfile tool version to v1.6.3

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1746299

Title:
  update makedumpfile tool version to v1.6.3

Status in The Ubuntu-power-systems project:
  Fix Released
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Xenial:
  Fix Released
Status in makedumpfile source package in Artful:
  Fix Released
Status in makedumpfile source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  New upstream kernel versions, as those in linux-hwe package, require a newer 
makedumpfile to be supported. Otherwise, all copies fallback to copying the 
entire memory.

  [Test case]
  kdump-tools has been installed, system rebooted, then crash trigerred and 
verified that a small dump file was present on /var/crash/. Tested on amd64 and 
ppc64le.

  [Regression potential]
  Many other bug fixes have been included in the latest version of the package. 
The changes are supposed to fix these bugs, and have been tested as well. 
However, as the total of changes is not trivial, there is impact of regression 
that has been minimized by the tests done. Regression potential of not 
supporting older kernels has been tested with the kernels shipped on xenial and 
artful as well.


  
  

  == Comment: #0 - Hari Krishna Bathini  - 2018-01-30 
10:46:53 ==
  ---Problem Description---
  update makedumpfile to latest version v1.6.3 that officially supports
  up to kernel version 4.14.8. Since makedumpfile is inherently backward 
compatible,
  this would not break existing functionality..

  Contact Information = hbath...@in.ibm.com

  ---uname output---
  na

  Machine Type = na

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

  ---Steps to Reproduce---
   makedumpfile reports ""The kernel version is not supported" while generating 
vmcore
  Also, there is a possibility of bogus address translations in makedumpfile 
tool with
  missing upstream patches. Can't be so sure without an exhaustive testing. 
Instead,
  it would be a good idea to go with the version which officially supports the 
kernel
  version in question.

  Userspace tool common name: makedumpfile

  The userspace tool has the following bit modes: 64-bit

  Userspace rpm: makedumpfile

  Userspace tool obtained from project website:  na

  *Additional Instructions for hbath...@in.ibm.com:
  -Attach ltrace and strace of userspace application.

  == Comment: #1 - Hari Krishna Bathini  - 2018-01-30 
10:49:13 ==
  With kernel version updated to 4.13.0, please update makedumpfile tool
  version to 1.6.3 which officially supports up to kernel version 4.14.8 [1].

  Thanks
  Hari

  [1]
  http://lists.infradead.org/pipermail/kexec/2018-January/019853.html

  This needs to be tagged for both 16.04.4 & 18.04 releases

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1743529] Re: Merge kexec-tools 2.0.16-1 from Debian: System hung with Kernel panic -not syncing: Out of memory message when crash is triggered.

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1743529

Title:
  Merge kexec-tools 2.0.16-1 from Debian: System hung with Kernel panic
  -not syncing: Out of memory message when crash is triggered.

Status in The Ubuntu-power-systems project:
  Fix Released
Status in kexec-tools package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Fix Released
Status in kexec-tools source package in Artful:
  Fix Released
Status in kexec-tools source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  Latest kexec-tools is needed to load/kexec recent kernels. For older 
releases, like xenial, it's needed to support linux-hwe kernels.

  [Regression Potential]
  It might fail to load the GA kernels, like a 4.4 kernel on xenial.

  [Test case]
  Different kernels on different architectures have been tested.

  
  == Comment: #0 - INDIRA P. JOGA
  Problem Description:
  ===
  System hung with kernel panic Kernel panic - not syncing: Out of memory 
message when crash is triggered

  Steps to re-create:
  ==
  > Installed ubuntu1804 daily build on Witherspoon test system
  root@whip:~# uname -a
  Linux whip 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:03:08 UTC 2017 
ppc64le ppc64le ppc64le GNU/Linux
  root@whip:~# uname -r
  4.13.0-17-generic

  > root@whip:~# free -h
    totalusedfree  shared  buff/cache   
available
  Mem:   507G2.0G504G 19M728M
503G
  Swap:  2.0G  0B2.0G

  > Edited the grub /etc/default/grub.d/kexec-tools.cfg file and set the
  crash kernel parameter=4096M

  > Updated grub using update-grub command and reboot system.

  cat root@whip:~# cat /proc/cmdline
  root=UUID=46c6aa02-8215-44cc-b3fc-0bc79c3c8815 ro splash quiet 
crashkernel=4096M

  > kdump status before triggering crash

  root@whip:~# kdump-config show
  DUMP_MODE:kdump
  USE_KDUMP:1
  KDUMP_SYSCTL: kernel.panic_on_oops=1
  KDUMP_COREDIR:/var/crash
  crashkernel addr:
     /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.13.0-17-generic
  kdump initrd:
     /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.13.0-17-generic
  current state:ready to kdump

  kexec command:
    /sbin/kexec -p 
--command-line="root=UUID=46c6aa02-8215-44cc-b3fc-0bc79c3c8815 ro splash quiet 
irqpoll noirqdistrib nr_cpus=1 nousb systemd.unit=kdump-tools.service 
ata_piix.prefer_ms_hyperv=0" --initrd=/var/lib/kdump/initrd.img 
/var/lib/kdump/vmlinuz

  root@whip:~# kdump-config status
  current state   : ready to kdump

  >  Enabled sysrq
  root@whip:~# sysctl -w kernel.sysrq=1
  kernel.sysrq = 1

  > Triggered crash and it hangs with kernel panic- OOM message as below

  root@whip:~# echo c > /proc/sysrq-trigger
  [   85.731415] sysrq: SysRq : Trigger a crash
  [   85.731472] Unable to handle kernel paging request for data at address 
0x
  [   85.731584] Faulting instruction address: 0xc078f588
  [   85.731670] Oops: Kernel access of bad area, sig: 11 [#1]
  [   85.731744] SMP NR_CPUS=2048
  [   85.731745] NUMA
  [   85.731790] PowerNV
  [   85.731853] Modules linked in: rpcsec_gss_krb5 nfsv4 nfs fscache sctp_diag 
sctp dccp_diag dccp tcp_diag udp_diag raw_diag inet_diag unix_diag 
af_packet_diag netlink_diag binfmt_misc vmx_crypto crct10dif_vpmsum ofpart 
cmdlinepart idt_89hpesx powernv_flash ipmi_powernv opal_prd ibmpowernv mtd 
ipmi_devintf ipmi_msghandler at24 uio_pdrv_genirq uio dm_multipath scsi_dh_rdac 
scsi_dh_emc scsi_dh_alua nfsd auth_rpcgss sch_fq_codel nfs_acl lockd grace 
sunrpc ip_tables x_tables autofs4 btrfs xor raid6_pq nouveau bnx2x ast 
i2c_algo_bit ttm drm_kms_helper mdio libcrc32c crc32c_vpmsum mlx5_core 
syscopyarea sysfillrect sysimgblt fb_sys_fops tg3 drm ahci mlxfw libahci nvme 
devlink nvme_core
  [   85.732704] CPU: 10 PID: 4316 Comm: bash Not tainted 4.13.0-17-generic 
#20-Ubuntu
  [   85.732764] task: c03fcb141700 task.stack: c03fc2374000
  [   85.732858] NIP: c078f588 LR: c07904b8 CTR: 
c078f560
  [   85.732977] REGS: c03fc23779f0 TRAP: 0300   Not tainted  
(4.13.0-17-generic)
  [   85.733066] MSR: 90009033 
  [   85.733075]   CR: 2842  XER: 2004
  [   85.733201] CFAR: c07904b4 DAR:  DSISR: 4200 
SOFTE: 1
  [   85.733201] GPR00: c07904b8 c03fc2377c70 c15f6000 
0063
  [   85.733201] GPR04: c03feedfade8 c03feee12068 90009033 
000a
  [   85.733201] GPR08: 0007 0001  
90001003
  [   85.733201] GPR12: c078f560 c7a66900 10180df8 
10189e30
  [   

[Group.of.nepali.translators] [Bug 1771283] Re: iperf2 long time run on 40Gb/s NIC crashes

[Manoj Iyer]

** Bug watch added: Debian Bug tracker #900793
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900793

** Also affects: iperf (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900793
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1771283

Title:
  iperf2 long time run on 40Gb/s NIC crashes

Status in iperf package in Ubuntu:
  New
Status in iperf source package in Xenial:
  New
Status in iperf source package in Artful:
  New
Status in iperf source package in Bionic:
  New
Status in iperf source package in Cosmic:
  New
Status in iperf package in Debian:
  Unknown

Bug description:
  ubuntu@recht:~$ iperf -c 192.168.121.2 -P10 -w 130k -t 3600
  
  Client connecting to 192.168.121.2, TCP port 5001
  TCP window size:  254 KByte (WARNING: requested  127 KByte)
  
  [ 10] local 192.168.121.3 port 40756 connected with 192.168.121.2 port 5001
  [ 12] local 192.168.121.3 port 40760 connected with 192.168.121.2 port 5001
  [ 11] local 192.168.121.3 port 40758 connected with 192.168.121.2 port 5001
  [  8] local 192.168.121.3 port 40754 connected with 192.168.121.2 port 5001
  [  9] local 192.168.121.3 port 40752 connected with 192.168.121.2 port 5001
  [  7] local 192.168.121.3 port 40750 connected with 192.168.121.2 port 5001
  [  6] local 192.168.121.3 port 40746 connected with 192.168.121.2 port 5001
  [  5] local 192.168.121.3 port 40748 connected with 192.168.121.2 port 5001
  [  3] local 192.168.121.3 port 40744 connected with 192.168.121.2 port 5001
  [  4] local 192.168.121.3 port 40742 connected with 192.168.121.2 port 5001
  Segmentation fault (core dumped)

  Will report more information with gdb attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iperf/+bug/1771283/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1635597] Re: Ubuntu:talclp1: Kdump failed with multipath disk

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1635597

Title:
  Ubuntu:talclp1: Kdump failed with multipath disk

Status in The Ubuntu-power-systems project:
  Fix Released
Status in linux package in Ubuntu:
  New
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  Won't Fix
Status in makedumpfile source package in Trusty:
  Won't Fix
Status in linux source package in Xenial:
  New
Status in makedumpfile source package in Xenial:
  Fix Released
Status in linux source package in Zesty:
  Won't Fix
Status in makedumpfile source package in Zesty:
  Won't Fix

Bug description:
  [Impact]
  When the target device where to dump the kernel is under a multipath 
configuration, dumping will fail, possibly leaving the system stuck in the 
kdump kernel.
  The fix is to include some scsi device handlers needed for the multipath 
setup inside the initramfs image that is used by kdump.
  All modules currently loaded in the system are included.

  [Test Case]
  Setting up kdump to target a multipath device using an appropriate storage 
that requires such scsi_dh modules and triggering a crash will demonstrate that 
kdump fails.
  After the fix, it works fine.

  [Regression Potential]
  If a bug is introduced, loading kdump might fail, and a crash will not be 
generated. A worse regression that might be considered is the system is stuck 
in such a kdump kernel and needs to be rebooted locally (and the crash file is 
not generated either). But since this is what we are trying to fix, we don't 
expect other systems to break. This didn't happen on a small (less than 1GiB of 
RAM) x86 VM, though.

  Problem  Description
  ==
  On talclp1, I enabled kdump. But kdump failed and it drop to BusyBox.

  root@talclp1:~# echo c> /proc/sysrq-trigger
  [  132.643690] sysrq: SysRq : Trigger a crash
  [  132.643739] Unable to handle kernel paging request for data at address 
0x
  [  132.643745] Faulting instruction address: 0xc05c28f4
  [  132.643749] Oops: Kernel access of bad area, sig: 11 [#1]
  [  132.643753] SMP NR_CPUS=2048 NUMA pSeries
  [  132.643758] Modules linked in: fuse ufs qnx4 hfsplus hfs minix ntfs msdos 
jfs rpadlpar_io rpaphp rpcsec_gss_krb5 nfsv4 dccp_diag cifs nfs dns_resolver 
dccp tcp_diag fscache udp_diag inet_diag unix_diag af_packet_diag netlink_diag 
binfmt_misc xfs libcrc32c pseries_rng rng_core ghash_generic gf128mul 
vmx_crypto sg nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables 
autofs4 ext4 crc16 jbd2 fscrypto mbcache crc32c_generic btrfs xor raid6_pq 
dm_round_robin sr_mod sd_mod cdrom ses enclosure scsi_transport_sas ibmveth 
crc32c_vpmsum ipr scsi_dh_emc scsi_dh_rdac scsi_dh_alua dm_multipath dm_mod
  [  132.643819] CPU: 49 PID: 10174 Comm: bash Not tainted 4.8.0-15-generic 
#16-Ubuntu
  [  132.643824] task: c00111767080 task.stack: c000d82e
  [  132.643828] NIP: c05c28f4 LR: c05c39d8 CTR: 
c05c28c0
  [  132.643832] REGS: c000d82e3990 TRAP: 0300   Not tainted  
(4.8.0-15-generic)
  [  132.643836] MSR: 80009033   CR: 28242422  
XER: 0001
  [  132.643848] CFAR: c00087d0 DAR:  DSISR: 4200 
SOFTE: 1
  GPR00: c05c39d8 c000d82e3c10 c0f67b00 0063
  GPR04: c0011d04a9b8 c0011d05f7e0 c0047fb0 00015998
  GPR08: 0007 0001  0001
  GPR12: c05c28c0 c7b4b900  2200
  GPR16: 10170dc8 01002b566368 10140f58 100c7570
  GPR20:  1017dd58 10153618 1017b608
  GPR24: 3e87a294 0001 c0ebff60 0004
  GPR28: c0ec0320 0063 c0e72a90 
  [  132.643906] NIP [c05c28f4] sysrq_handle_crash+0x34/0x50
  [  132.643911] LR [c05c39d8] __handle_sysrq+0xe8/0x280
  [  132.643914] Call Trace:
  [  132.643917] [c000d82e3c10] [c0a245e8] 0xc0a245e8 
(unreliable)
  [  132.643923] [c000d82e3c30] [c05c39d8] __handle_sysrq+0xe8/0x280
  [  132.643928] [c000d82e3cd0] [c05c4188] 
write_sysrq_trigger+0x78/0xa0
  [  132.643935] [c000d82e3d00] [c03ad770] proc_reg_write+0xb0/0x110
  [  132.643941] [c000d82e3d50] [c030fc3c] __vfs_write+0x6c/0xe0
  [  132.643946] [c000d82e3d90] [c0311144] vfs_write+0xd4/0x240
  [  132.643950] [c000d82e3de0] [c0312e5c] SyS_write+0x6c/0x110
  [  132.643957] [c000d82e3e30] [c00095e0] system_call+0x38/0x108
  [  132.643961] Instruction dump:
  [  132.643963] 38425240 7c0802a6 

[Group.of.nepali.translators] [Bug 1635597] Re: Ubuntu:talclp1: Kdump failed with multipath disk

[Manoj Iyer]

** Changed in: makedumpfile (Ubuntu Trusty)
   Status: Confirmed => Won't Fix

** Changed in: linux (Ubuntu Trusty)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1635597

Title:
  Ubuntu:talclp1: Kdump failed with multipath disk

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in linux package in Ubuntu:
  New
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  Won't Fix
Status in makedumpfile source package in Trusty:
  Won't Fix
Status in linux source package in Xenial:
  New
Status in makedumpfile source package in Xenial:
  Fix Released
Status in linux source package in Zesty:
  Won't Fix
Status in makedumpfile source package in Zesty:
  Won't Fix

Bug description:
  [Impact]
  When the target device where to dump the kernel is under a multipath 
configuration, dumping will fail, possibly leaving the system stuck in the 
kdump kernel.
  The fix is to include some scsi device handlers needed for the multipath 
setup inside the initramfs image that is used by kdump.
  All modules currently loaded in the system are included.

  [Test Case]
  Setting up kdump to target a multipath device using an appropriate storage 
that requires such scsi_dh modules and triggering a crash will demonstrate that 
kdump fails.
  After the fix, it works fine.

  [Regression Potential]
  If a bug is introduced, loading kdump might fail, and a crash will not be 
generated. A worse regression that might be considered is the system is stuck 
in such a kdump kernel and needs to be rebooted locally (and the crash file is 
not generated either). But since this is what we are trying to fix, we don't 
expect other systems to break. This didn't happen on a small (less than 1GiB of 
RAM) x86 VM, though.

  Problem  Description
  ==
  On talclp1, I enabled kdump. But kdump failed and it drop to BusyBox.

  root@talclp1:~# echo c> /proc/sysrq-trigger
  [  132.643690] sysrq: SysRq : Trigger a crash
  [  132.643739] Unable to handle kernel paging request for data at address 
0x
  [  132.643745] Faulting instruction address: 0xc05c28f4
  [  132.643749] Oops: Kernel access of bad area, sig: 11 [#1]
  [  132.643753] SMP NR_CPUS=2048 NUMA pSeries
  [  132.643758] Modules linked in: fuse ufs qnx4 hfsplus hfs minix ntfs msdos 
jfs rpadlpar_io rpaphp rpcsec_gss_krb5 nfsv4 dccp_diag cifs nfs dns_resolver 
dccp tcp_diag fscache udp_diag inet_diag unix_diag af_packet_diag netlink_diag 
binfmt_misc xfs libcrc32c pseries_rng rng_core ghash_generic gf128mul 
vmx_crypto sg nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables 
autofs4 ext4 crc16 jbd2 fscrypto mbcache crc32c_generic btrfs xor raid6_pq 
dm_round_robin sr_mod sd_mod cdrom ses enclosure scsi_transport_sas ibmveth 
crc32c_vpmsum ipr scsi_dh_emc scsi_dh_rdac scsi_dh_alua dm_multipath dm_mod
  [  132.643819] CPU: 49 PID: 10174 Comm: bash Not tainted 4.8.0-15-generic 
#16-Ubuntu
  [  132.643824] task: c00111767080 task.stack: c000d82e
  [  132.643828] NIP: c05c28f4 LR: c05c39d8 CTR: 
c05c28c0
  [  132.643832] REGS: c000d82e3990 TRAP: 0300   Not tainted  
(4.8.0-15-generic)
  [  132.643836] MSR: 80009033   CR: 28242422  
XER: 0001
  [  132.643848] CFAR: c00087d0 DAR:  DSISR: 4200 
SOFTE: 1
  GPR00: c05c39d8 c000d82e3c10 c0f67b00 0063
  GPR04: c0011d04a9b8 c0011d05f7e0 c0047fb0 00015998
  GPR08: 0007 0001  0001
  GPR12: c05c28c0 c7b4b900  2200
  GPR16: 10170dc8 01002b566368 10140f58 100c7570
  GPR20:  1017dd58 10153618 1017b608
  GPR24: 3e87a294 0001 c0ebff60 0004
  GPR28: c0ec0320 0063 c0e72a90 
  [  132.643906] NIP [c05c28f4] sysrq_handle_crash+0x34/0x50
  [  132.643911] LR [c05c39d8] __handle_sysrq+0xe8/0x280
  [  132.643914] Call Trace:
  [  132.643917] [c000d82e3c10] [c0a245e8] 0xc0a245e8 
(unreliable)
  [  132.643923] [c000d82e3c30] [c05c39d8] __handle_sysrq+0xe8/0x280
  [  132.643928] [c000d82e3cd0] [c05c4188] 
write_sysrq_trigger+0x78/0xa0
  [  132.643935] [c000d82e3d00] [c03ad770] proc_reg_write+0xb0/0x110
  [  132.643941] [c000d82e3d50] [c030fc3c] __vfs_write+0x6c/0xe0
  [  132.643946] [c000d82e3d90] [c0311144] vfs_write+0xd4/0x240
  [  132.643950] [c000d82e3de0] [c0312e5c] SyS_write+0x6c/0x110
  [  132.643957] [c000d82e3e30] [c00095e0] system_call+0x38/0x108
  [  

[Group.of.nepali.translators] [Bug 1724152] Re: ISST-LTE: pVM: aureport couldn't get the right auid from the audit log on ubuntu16.04

[Manoj Iyer]

** Changed in: audit (Ubuntu Zesty)
   Status: Fix Committed => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1724152

Title:
  ISST-LTE: pVM: aureport couldn't get the right auid from the audit log
  on ubuntu16.04

Status in The Ubuntu-power-systems project:
  Fix Released
Status in audit package in Ubuntu:
  Invalid
Status in audit source package in Xenial:
  Fix Released
Status in audit source package in Zesty:
  Won't Fix

Bug description:
  [Impact]

  The aureport command, part of the audit userspace utilities,
  incorrectly reports the user id of successful logins. "-1" is printed
  instead of the expected user id.

  [Test Case]

  As root, run `login`. Proceed as follows:

  1. Login with a blank username and any password
  2. Login with an invalid username and any password
  3. Login with a valid username and an invalid password
  4. Login with a valid username and a valid password
  5. Exit from the login shell
  6. Run `aureport -l` and examine the last for login records

  An unpatched aureport will print the following:

  
  # date time auid host term exe success event
  
  ...
  2. 10/17/2017 23:45:32 UNKNOWN ? /dev/pts/8 /bin/login no 97
  3. 10/17/2017 23:45:39 UNKNOWN ? /dev/pts/8 /bin/login no 99
  4. 10/17/2017 23:45:45 tyhicks ? /dev/pts/8 /bin/login no 101
  5. 10/17/2017 23:45:49 -1 ? /dev/pts/8 /bin/login yes 107

  A patch aureport will print the correct output:

  Login Report
  
  # date time auid host term exe success event
  
  ...
  2. 10/17/2017 23:52:44 UNKNOWN ? /dev/pts/8 /bin/login no 165
  3. 10/17/2017 23:52:52 UNKNOWN ? /dev/pts/8 /bin/login no 167
  4. 10/17/2017 23:52:58 tyhicks ? /dev/pts/8 /bin/login no 169
  5. 10/17/2017 23:53:02 1000 ? /dev/pts/8 /bin/login yes 175

  Note the "1000" in the auid column on the #5 row. It should *not* be
  "-1".

  [Regression Potential]

  The regression potential is limited due to the change only affecting a
  single line of code, the fix comes from upstream, and that the
  aureport utility is not critical.

  [Original Report]

  == Comment: #0 - Miao Tao Feng  - 2016-11-23 02:46:25 ==
  When we develop new testcase for audit, we found that command "aureport -l" 
print out wrong auid "-1"  on ubuntu16.04  and it should be 1000 according to 
the audit.log.

  The following are details:

  root@roselp2:~# aureport -l

  Login Report
  
  # date time auid host term exe success event
  
  1. 11/23/2016 02:20:12 -1 10.33.24.118 /dev/pts/0 /usr/sbin/sshd yes 18

  The auid "-1" on the above line should be "1000? according to the
  audit.log.

  root@roselp2:~# grep ":18" /var/log/audit/audit.log
  type=USER_LOGIN msg=audit(1479889212.292:18): pid=4177 uid=0 auid=1000 ses=4 
msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=10.33.24.118 
addr=10.33.24.118 terminal=/dev/pts/0 res=success'

  root@roselp2:~# dpkg -s auditd
  Package: auditd
  Status: install ok installed
  Priority: extra
  Section: admin
  Installed-Size: 1051
  Maintainer: Ubuntu Developers 
  Architecture: ppc64el
  Source: audit
  Version: 1:2.4.5-1ubuntu2
  Depends: lsb-base (>= 3.0-6), mawk | gawk, init-system-helpers (>= 1.18~), 
libaudit1 (>= 1:2.4.2), libauparse0 (>= 1:2.3.1), libc6 (>= 2.17)
  Suggests: audispd-plugins

  root@roselp2:~# uname -a
  Linux roselp2 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:38:24 UTC 2016 
ppc64le ppc64le ppc64le GNU/Linux

  root@roselp2:~# service auditd status
  ? auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: e
     Active: active (running) since Wed 2016-11-23 02:19:21 CST; 19s ago
   Main PID: 4085 (auditd)
     CGroup: /system.slice/auditd.service
     ??4085 /sbin/auditd -n

  Nov 23 02:19:21 roselp2 auditctl[4086]: enabled 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: failure 1
  Nov 23 02:19:21 roselp2 auditctl[4086]: pid 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: rate_limit 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_limit 320
  Nov 23 02:19:21 roselp2 auditctl[4086]: lost 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_wait_time 15000
  Nov 23 02:19:21 roselp2 systemd[1]: Started Security Auditing Service.
  Nov 23 02:19:21 roselp2 auditd[4085]: Init complete, auditd 2.4.5 listening 
for

  Please cherry pick https://github.com/linux-audit/audit-
  userspace/commit/25097d64344828a80acf681da5c1dacc4ea3c069

To manage notifications about this bug go to:

[Group.of.nepali.translators] [Bug 1635597] Re: Ubuntu:talclp1: Kdump failed with multipath disk

[Manoj Iyer]

** Changed in: makedumpfile (Ubuntu Zesty)
   Status: Confirmed => Won't Fix

** Changed in: linux (Ubuntu Zesty)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1635597

Title:
  Ubuntu:talclp1: Kdump failed with multipath disk

Status in The Ubuntu-power-systems project:
  Incomplete
Status in linux package in Ubuntu:
  New
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  New
Status in makedumpfile source package in Trusty:
  Confirmed
Status in linux source package in Xenial:
  New
Status in makedumpfile source package in Xenial:
  Fix Committed
Status in linux source package in Zesty:
  Won't Fix
Status in makedumpfile source package in Zesty:
  Won't Fix

Bug description:
  [Impact]
  When the target device where to dump the kernel is under a multipath 
configuration, dumping will fail, possibly leaving the system stuck in the 
kdump kernel.
  The fix is to include some scsi device handlers needed for the multipath 
setup inside the initramfs image that is used by kdump.
  All modules currently loaded in the system are included.

  [Test Case]
  Setting up kdump to target a multipath device using an appropriate storage 
that requires such scsi_dh modules and triggering a crash will demonstrate that 
kdump fails.
  After the fix, it works fine.

  [Regression Potential]
  If a bug is introduced, loading kdump might fail, and a crash will not be 
generated. A worse regression that might be considered is the system is stuck 
in such a kdump kernel and needs to be rebooted locally (and the crash file is 
not generated either). But since this is what we are trying to fix, we don't 
expect other systems to break. This didn't happen on a small (less than 1GiB of 
RAM) x86 VM, though.

  Problem  Description
  ==
  On talclp1, I enabled kdump. But kdump failed and it drop to BusyBox.

  root@talclp1:~# echo c> /proc/sysrq-trigger
  [  132.643690] sysrq: SysRq : Trigger a crash
  [  132.643739] Unable to handle kernel paging request for data at address 
0x
  [  132.643745] Faulting instruction address: 0xc05c28f4
  [  132.643749] Oops: Kernel access of bad area, sig: 11 [#1]
  [  132.643753] SMP NR_CPUS=2048 NUMA pSeries
  [  132.643758] Modules linked in: fuse ufs qnx4 hfsplus hfs minix ntfs msdos 
jfs rpadlpar_io rpaphp rpcsec_gss_krb5 nfsv4 dccp_diag cifs nfs dns_resolver 
dccp tcp_diag fscache udp_diag inet_diag unix_diag af_packet_diag netlink_diag 
binfmt_misc xfs libcrc32c pseries_rng rng_core ghash_generic gf128mul 
vmx_crypto sg nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables 
autofs4 ext4 crc16 jbd2 fscrypto mbcache crc32c_generic btrfs xor raid6_pq 
dm_round_robin sr_mod sd_mod cdrom ses enclosure scsi_transport_sas ibmveth 
crc32c_vpmsum ipr scsi_dh_emc scsi_dh_rdac scsi_dh_alua dm_multipath dm_mod
  [  132.643819] CPU: 49 PID: 10174 Comm: bash Not tainted 4.8.0-15-generic 
#16-Ubuntu
  [  132.643824] task: c00111767080 task.stack: c000d82e
  [  132.643828] NIP: c05c28f4 LR: c05c39d8 CTR: 
c05c28c0
  [  132.643832] REGS: c000d82e3990 TRAP: 0300   Not tainted  
(4.8.0-15-generic)
  [  132.643836] MSR: 80009033   CR: 28242422  
XER: 0001
  [  132.643848] CFAR: c00087d0 DAR:  DSISR: 4200 
SOFTE: 1
  GPR00: c05c39d8 c000d82e3c10 c0f67b00 0063
  GPR04: c0011d04a9b8 c0011d05f7e0 c0047fb0 00015998
  GPR08: 0007 0001  0001
  GPR12: c05c28c0 c7b4b900  2200
  GPR16: 10170dc8 01002b566368 10140f58 100c7570
  GPR20:  1017dd58 10153618 1017b608
  GPR24: 3e87a294 0001 c0ebff60 0004
  GPR28: c0ec0320 0063 c0e72a90 
  [  132.643906] NIP [c05c28f4] sysrq_handle_crash+0x34/0x50
  [  132.643911] LR [c05c39d8] __handle_sysrq+0xe8/0x280
  [  132.643914] Call Trace:
  [  132.643917] [c000d82e3c10] [c0a245e8] 0xc0a245e8 
(unreliable)
  [  132.643923] [c000d82e3c30] [c05c39d8] __handle_sysrq+0xe8/0x280
  [  132.643928] [c000d82e3cd0] [c05c4188] 
write_sysrq_trigger+0x78/0xa0
  [  132.643935] [c000d82e3d00] [c03ad770] proc_reg_write+0xb0/0x110
  [  132.643941] [c000d82e3d50] [c030fc3c] __vfs_write+0x6c/0xe0
  [  132.643946] [c000d82e3d90] [c0311144] vfs_write+0xd4/0x240
  [  132.643950] [c000d82e3de0] [c0312e5c] SyS_write+0x6c/0x110
  [  132.643957] [c000d82e3e30] [c00095e0] system_call+0x38/0x108
  [  

[Group.of.nepali.translators] [Bug 1714485] Re: Ubuntu 16.04.03: kdump fails with error "kdump-tools[1532]: /etc/init.d/kdump-tools: 26: [: -ne: unexpected operator" when / file system is xfs.

[Manoj Iyer]

Cascardo, did you get chance to make those changes you mentioned in
comment #8 ? Please update this bug if this fix was already applied to
x/a/z releases.

** Changed in: makedumpfile (Ubuntu Zesty)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1714485

Title:
  Ubuntu 16.04.03: kdump fails with error "kdump-tools[1532]:
  /etc/init.d/kdump-tools: 26: [: -ne: unexpected operator" when / file
  system is xfs.

Status in The Ubuntu-power-systems project:
  Triaged
Status in makedumpfile package in Ubuntu:
  In Progress
Status in makedumpfile source package in Xenial:
  New
Status in makedumpfile source package in Zesty:
  Won't Fix
Status in makedumpfile source package in Artful:
  New
Status in makedumpfile source package in Bionic:
  In Progress

Bug description:
  == Comment: #0 - PAVITHRA R. PRAKASH <> - 2017-08-31 00:33:37 ==
  ---Problem Description---

  Ubuntu 16.04.03: kdump fails with error "kdump-tools[1532]:
  /etc/init.d/kdump-tools: 26: [: -ne: unexpected operator" when / file
  system is xfs.

  ---Steps to Reproduce---

  1. Install Ubuntu 16.04.03 with / as xfs.
  2. Configure kdump.
  3. trigger crash.

  Machine hangs after below log. Attaching console log.

  [  OK  ] Reached target Network is Online.
   Starting Kernel crash dump capture service...
   Starting iSCSI initiator daemon (iscsid)...
  [   12.263089] kdump-tools[1205]: /etc/init.d/kdump-tools: 26: [: -ne: 
unexpected operator
  [  OK  ] Started Kernel crash dump capture service.
  [  OK  ] Started iSCSI initiator daemon (iscsid).
   Starting Login to default iSCSI targets...
  [  OK  ] Started Login to default iSCSI targets.
  [  OK  ] Reached target Remote File Systems (Pre).

  
  4. After manual reboot  /etc/default/kdump-tools is empty.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1692538] Re: Ubuntu 16.04.02: ibmveth: Support to enable LSO/CSO for Trunk VEA

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1692538

Title:
  Ubuntu 16.04.02: ibmveth: Support to enable LSO/CSO for Trunk VEA

Status in The Ubuntu-power-systems project:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Zesty:
  Fix Released
Status in linux source package in Artful:
  Fix Released

Bug description:
  
  == SRU Justification ==
  Commit 66aa0678ef is request to fix four issues with the ibmveth driver.
  The issues are as follows:
  - Issue 1: ibmveth doesn't support largesend and checksum offload features 
when configured as "Trunk".
  - Issue 2: SYN packet drops seen at destination VM. When the packet
  originates, it has CHECKSUM_PARTIAL flag set and as it gets delivered to IO
  server's inbound Trunk ibmveth, on validating "checksum good" bits in ibmveth
  receive routine, SKB's ip_summed field is set with CHECKSUM_UNNECESSARY flag.
  - Issue 3: First packet of a TCP connection will be dropped, if there is
  no OVS flow cached in datapath.
  - Issue 4: ibmveth driver doesn't have support for SKB's with frag_list.

  The details for the fixes to these issues are described in the commits
  git log.



  == Comment: #0 - BRYANT G. LY  - 2017-05-22 08:40:16 ==
  ---Problem Description---

   - Issue 1: ibmveth doesn't support largesend and checksum offload features
     when configured as "Trunk". Driver has explicit checks to prevent
     enabling these offloads.

   - Issue 2: SYN packet drops seen at destination VM. When the packet
     originates, it has CHECKSUM_PARTIAL flag set and as it gets delivered to
     IO server's inbound Trunk ibmveth, on validating "checksum good" bits
     in ibmveth receive routine, SKB's ip_summed field is set with
     CHECKSUM_UNNECESSARY flag. This packet is then bridged by OVS (or Linux
     Bridge) and delivered to outbound Trunk ibmveth. At this point the
     outbound ibmveth transmit routine will not set "no checksum" and
     "checksum good" bits in transmit buffer descriptor, as it does so only
     when the ip_summed field is CHECKSUM_PARTIAL. When this packet gets
     delivered to destination VM, TCP layer receives the packet with checksum
     value of 0 and with no checksum related flags in ip_summed field. This
     leads to packet drops. So, TCP connections never goes through fine.

   - Issue 3: First packet of a TCP connection will be dropped, if there is
     no OVS flow cached in datapath. OVS while trying to identify the flow,
     computes the checksum. The computed checksum will be invalid at the
     receiving end, as ibmveth transmit routine zeroes out the pseudo
     checksum value in the packet. This leads to packet drop.

   - Issue 4: ibmveth driver doesn't have support for SKB's with frag_list.
     When Physical NIC has GRO enabled and when OVS bridges these packets,
     OVS vport send code will end up calling dev_queue_xmit, which in turn
     calls validate_xmit_skb.
     In validate_xmit_skb routine, the larger packets will get segmented into
     MSS sized segments, if SKB has a frag_list and if the driver to which
     they are delivered to doesn't support NETIF_F_FRAGLIST feature.

  Contact Information = Bryant G. Ly/b...@us.ibm.com

  ---uname output---
  4.8.0-51.54

  Machine Type = p8

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

  ---Steps to Reproduce---
   Increases performance greatly

  The patch has been accepted upstream:
  https://patchwork.ozlabs.org/patch/764533/

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1741978] Re: Add support for ARM events

[Manoj Iyer]

debdiff for Xenial (0.5.6)

** Patch added: "rasdaemon-0.5.6 debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/rasdaemon/+bug/1741978/+attachment/5039750/+files/rasdaemon-0.5.6.debdiff

** Changed in: rasdaemon (Ubuntu Zesty)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1741978

Title:
  Add support for ARM events

Status in rasdaemon package in Ubuntu:
  Fix Released
Status in rasdaemon source package in Xenial:
  New
Status in rasdaemon source package in Zesty:
  Won't Fix
Status in rasdaemon source package in Artful:
  New
Status in rasdaemon package in Debian:
  Fix Released

Bug description:
  [IMPACT]
  The UEFI 2.6 spec added support for ARM processor errors and errors
  that have unrecognized CPER section types. rasdaemon needs to support ARM 
kernel trace events.

  [FIX]
  The following patches add support for ARM events to rasdaemon:

  rasdaemon: add support for non standard CPER section events
  rasdaemon: add support for ARM events

  ARM support was added to rasdaemon in version 0.6.0 release.

  [TESTING]
  The patches were applied to rasdaemon 0.5.8 and 0.5.6 versions and tested on 
Artful and Xenial. Test results are attached to comments below.

  [REGRESSION POTENTIAL]
  None.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rasdaemon/+bug/1741978/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1734856] Re: Can't boot VM with more than 16 disks (slof buffer issue)

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: Incomplete => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1734856

Title:
  Can't boot VM with more than 16 disks (slof buffer issue)

Status in SLOF - Slimline Open Firmware:
  New
Status in The Ubuntu-power-systems project:
  Fix Released
Status in slof package in Ubuntu:
  Fix Released
Status in slof source package in Xenial:
  Fix Released
Status in slof source package in Zesty:
  Fix Released
Status in slof source package in Artful:
  Fix Released
Status in slof source package in Bionic:
  Fix Released

Bug description:
  [Impact]

   * Booting a KVM guest with many disks considered as potential boot device 
 fails on ppc64le

   * In detail this was an overflow, so now the processing of devices is 
 changed to use dynamic allocation which works with higher numbers of 
 devices.

  [Test Case]

   * Comment #12 has the full final testcase, not writing all that up 
 here again.

  [Regression Potential]

   * It is a change of disk processing in the slof loader for ppc64el
 - that means on one hand only ppc64el will be affected by an issue
 - OTOH there might be a disk combination not part of my or upstreams or 
   IBMs testing that might now fail with the new code (unlikely)
 - Given that the change is upstream and was provided by IBM which I 
   consider the authority on that code I think it is safe to be 
   considered.

  [Other Info]
   
   * n/a

  
  


  == Comment: #0 - RAHUL CHANDRAKAR  - 2017-11-28 03:40:37 
==
  ---Problem Description---
  Can't boot VM with more than 16 disks.
  It is an issue with qemu/SLOF (Bug: https://github.com/qemu/SLOF/issues/3) 
and it was fixed by Nikunj Amritlal Dadhnia.  He has made a patch available and 
it has been tested by PowerVC team.

  We need this fix in Ubuntu 16.04 and later releases.

  Machine Type = 8348-21C (P8 Habanero)

  ---Steps to Reproduce---
   Steps to recreate:
  1. Create a VM
  2. Attach 50 disks
  3. Shutdown from OS
  4. Start again and let it boot

  ---uname output---
  Linux neo160.blr.stglabs.ibm.com 4.4.0-101-generic #124-Ubuntu SMP Fri Nov 10 
18:29:11 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux

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

  Patch posted and awaiting response...

  http://patchwork.ozlabs.org/patch/842011/

To manage notifications about this bug go to:
https://bugs.launchpad.net/slof/+bug/1734856/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1693369] Re: 5U84 - ses driver isn't binding right - cannot blink lights on 1 of the 2 5u84

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1693369

Title:
  5U84 - ses driver isn't binding right - cannot blink lights on 1 of
  the 2 5u84

Status in The Ubuntu-power-systems project:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Released
Status in linux source package in Zesty:
  Fix Released
Status in linux source package in Artful:
  Fix Released

Bug description:
  
  == SRU Justification ==
  This bug is resolved by commit 62e62ffd95539b9220894a7900a619e0f3ef4756.

  Without this patch, the symlink in sysfs which binds a SAS device to an 
enclosure 
  slot does not get created. This makes disk hotplug near impossible on large 
  JBOD disk drawers.

  Commit 62e62ffd95 is also needed in Xenial.  However, Xenial also needed some 
  prereq commits, so it's SRU will be sent separately.

  Commit 62e62ffd95 is in mainline as of 4.13-rc1.

  
  == Fix ==
  commit 62e62ffd95539b9220894a7900a619e0f3ef4756
  Author: Maurizio Lombardi 
  Date:   Tue Jun 27 11:53:27 2017 +0200

  scsi: ses: do not add a device to an enclosure if
  enclosure_add_links() fails.

  == Regression Potential ==
  This patch was also cc'd and applied to upstream stable, so there is 
  upstream confidence in it.

  == Test Case ==
  A test kernel was built with this patch and tested by the original bug 
reporter.
  The bug reporter states the test kernel resolved the bug.


  
  This is a request to add the following upstream commit to both Ubuntu 16.04.1 
and 16.04.2:

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/scsi/ses.c?id=9373eba6cfae48911b977d14323032cd5d161aae

  Without this patch, the symlink in sysfs which binds a SAS device to
  an enclosure slot does not get created. This makes disk hotplug near
  impossible on large JBOD disk drawers.

  You should be able to do:

  ls /sys/block/sdb/device/ | grep enclosure

  and see something like:

  enclosure_device:1

  If you cd to this directory, you can then access the SES controls for
  that slot to flash the LED to assist in locating the disk to replace a
  failed disk.

  Currently with 16.04.1 and 16.04.2, these symlinks are not getting
  created.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1715101] Re: Xenial : installer fails on POWER9

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1715101

Title:
  Xenial : installer fails on POWER9

Status in The Ubuntu-power-systems project:
  Fix Released
Status in debian-installer package in Ubuntu:
  Invalid
Status in debian-installer source package in Xenial:
  Fix Released

Bug description:
  Hi,

  could you please update the installer to use linux-hwe version >=
  4.10.0-29 for POWER9 on Xenial.

  At the moment the kernel/vmlinux in 
http://ports.ubuntu.com/ubuntu-ports/dists/xenial-proposed/main/installer-ppc64el/current/images/hwe-netboot/ubuntu-installer/ppc64el/
 is based on
  linux 4.10.0-28 which doesn't include this ERAT related patch 
(https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1700521 and other P9 
fixes also) which cause the installer to fail on POWER9.

  A move to hwe kernels with version greater than 4.10.0-29 should work.
  Thanks a lot.

  F.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1709877] Re: CPU hotplug fails in the system with empty numa nodes, "Invalid value '0-1, 16-17' for 'cpuset.mems': Invalid argument"

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1709877

Title:
  CPU hotplug fails in the system with empty numa nodes, "Invalid value
  '0-1,16-17' for 'cpuset.mems': Invalid argument"

Status in The Ubuntu-power-systems project:
  Fix Released
Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Incomplete

Bug description:
  == Comment: #0 - Satheesh Rajendran  - 2017-07-19 
04:13:18 ==
  CPU hotplug operation fails in the host with empty numa nodes(with no memory) 
even though VM placement is static and with/without numad is running.
  ..
   32
  ...

  
  # virsh setvcpus virt-tests-vm1 6 --live
  error: Invalid value '0-1,16-17' for 'cpuset.mems': Invalid argument

  
  # numactl --hardware
  available: 4 nodes (0-1,16-17)
  node 0 cpus: 0 8 16 24 32 40
  node 0 size: 16188 MB
  node 0 free: 1119 MB
  node 1 cpus: 48 56 64 72 80 88
  node 1 size: 32630 MB
  node 1 free: 13233 MB
  node 16 cpus: 96 104 112 120 128 136
  node 16 size: 0 MB
  node 16 free: 0 MB
  node 17 cpus: 144 152 160 168 176 184
  node 17 size: 0 MB
  node 17 free: 0 MB
  node distances:
  node   0   1  16  17 
0:  10  20  40  40 
1:  20  10  40  40 
   16:  40  40  10  20 
   17:  40  40  20  10 

  # cat /sys/fs/cgroup/cpuset/cpuset.mems 
  0-1

  Host:
  #uname -a
  Linux powerkvm4-lp1 4.10.0-27-generic #30~16.04.2-Ubuntu SMP Thu Jun 29 
16:06:52 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux

  ii  libvirt-bin1.3.1-1ubuntu10.11 
  ii  numad  0.5+20150602-4 
  qemu-kvm   1:2.5+dfsg-5ubuntu10.14

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1696434] Re: drmgr command fails during the scale-up test on Novalink System (Brazos)

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1696434

Title:
  drmgr command fails during the scale-up test on Novalink System
  (Brazos)

Status in The Ubuntu-power-systems project:
  Fix Released
Status in powerpc-utils package in Ubuntu:
  Fix Released
Status in powerpc-utils source package in Xenial:
  Fix Released
Status in powerpc-utils source package in Yakkety:
  Fix Committed
Status in powerpc-utils source package in Zesty:
  Fix Released

Bug description:
  [SRU Justification]
  drmgr fails intermittently when adding devices to the system.

  [Test case]
  To be completed by IBM, who have access to the hardware.
  1. Run a scale test of launching 1000 VMs on a Novalink system.
  2. Observe that some of the deployments fail with the following error:
  kernel I/O op failed, rc = 26 len = 26.
  3. Install powerpc-utils from -proposed
  4. Run the scale test again.
  5. Observe that all the deployments succeed.

  [Regression potential]
  This change cherry-picked from upstream corrects faulty handling of a 0 
return code from syscalls. Regression potential appears to be minimal.

  
  Problem:

  During the scale-up test to 1000 VMs I could see 20 deploys failed due
  to following command failure..

  Command /usr/sbin/pvmdrmgr drmgr -c slot -s 'U9119.MHE.1085B07-V1-C1030' -a 
-w 3 returned 19. Additional messages: /usr/sbin/pvmdrmgr drmgr -c slot -s 
'U9119.MHE.1085B07-V1-C1030' -a -w 3
  Validating I/O DLPAR capability...yes.
  kernel I/O op failed, rc = 26 len = 26.

  I have been looking through the logs on this system to piece together
  what is happening when the dlpar add failures occur. From what I am
  seeing we are trying to dlpar add a virtual network device and getting
  a error when trying to add the device to the system.

  > ## May 17 05:18:00 2017 ##
  > drmgr: -c slot -s U9119.MHE.1085B07-V1-C1030 -a -w 3
  > Validating I/O DLPAR capability...yes.
  > Getting node types 0x0003
  > Could not find DRC property group in path: /proc/device-tree/ibm,serial.
  > Acquiring drc index 0x3406
  > get-sensor for 3406: 0, 2
  > Setting allocation state to 'alloc usable'
  > Setting indicator state to 'unisolate'
  > Configuring connector for drc index 3406
  > Adding device-tree node /proc/device-tree/vdevice/l-lan@3406
  > ofdt update: add_node /vdevice/l-lan@3406 ibm,loc-code 30 
U9119.MHE.1085B07-V1-C1030-T1
  > Getting node types 0x0003
  > performing kernel op for U9119.MHE.1085B07-V1-C1030, file is 
/sys/bus/pci/slots/control/add_slot
  > kernel I/O op failed, rc = 26 len = 26.
  > No such device
  > Releasing drc index 0x3406
  > get-sensor for 3406: 0, 1
  > Setting isolation state to 'isolate'
  > Setting allocation state to 'alloc unusable'
  > get-sensor for 3406: 0, 2
  > drc_index 3406 sensor-state: 2
  > Resource is not available to the partition.
  > Removing device-tree node /proc/device-tree/vdevice/l-lan@3406
  > ## May 17 05:20:11 2017 ##

  From the drmgr log, you can see that we get a ENODEV return code when
  performing the kernel operation to add the device to the system.

  > performing kernel op for U9119.MHE.1085B07-V1-C1030, file is 
/sys/bus/pci/slots/control/add_slot
  > kernel I/O op failed, rc = 26 len = 26.
  > No such device

  This indicates that the rpadlpar_io kernel modules was unable to find
  the device in the device tree. This doesn not seem right because
  earlier in the drmgr logs we add the device to the device tree.
  Additionally, the drmgr code validates that the add succeeds by
  retrieveing the newly added device node from the device tree as a
  sanity check. There are no failures reported for this.

  > Adding device-tree node /proc/device-tree/vdevice/l-lan@3406
  > ofdt update: add_node /vdevice/l-lan@3406 ibm,loc-code 30 
U9119.MHE.1085B07-V1-C1030-T1
  > Getting node types 0x0003

  I started scale-up testing and I could see deploys are going fine.
  Will post a comment here if I see further drmgr failures.

  Patches have been submitted upstream.

  https://groups.google.com/forum/#!topic/powerpc-utils-
  devel/GNEi65WBwkQ

  and

  https://groups.google.com/forum/#!topic/powerpc-utils-
  devel/hJfUb5wYPsE

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1696102] Re: xfs/073 test fails with Metadata corruption detected on xfs file system (xfsprogs)

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: Confirmed => Fix Released

** Changed in: ubuntu-power-systems
 Assignee: (unassigned) => Canonical Foundations Team 
(canonical-foundations)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1696102

Title:
  xfs/073 test fails with Metadata corruption detected on xfs file
  system (xfsprogs)

Status in The Ubuntu-power-systems project:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in xfsprogs package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Invalid
Status in xfsprogs source package in Xenial:
  Triaged
Status in linux source package in Zesty:
  Invalid
Status in xfsprogs source package in Zesty:
  Triaged

Bug description:
  Problem Description
  
  xfs/073 test fails with Metadata corruption detected on xfs file system. Test 
fails with _check_xfs_filesystem: filesystem on /mnt/test/84004.image2 is 
inconsistent.

  # diff -u tests/xfs/073.out /root/xfstests-dev/results//xfs/073.out.bad
  --- tests/xfs/073.out 2017-03-23 12:13:05.288877197 +0530
  +++ /root/xfstests-dev/results//xfs/073.out.bad   2017-03-27 
11:11:43.023059702 +0530
  @@ -59,8 +59,7 @@
   comparing new image geometry to old
   unmounting and removing new image
   checking new image
  -mounting new image on loopback
  -comparing new image files to old
  -comparing new image directories to old
  -comparing new image geometry to old
  -unmounting and removing new image
  +_check_xfs_filesystem: filesystem on /mnt/test/15413.image2 is inconsistent 
(c)
  +(see /root/xfstests-dev/results//xfs/073.full for details)
  +_check_xfs_filesystem: filesystem on /mnt/test/15413.image2 is inconsistent 
(r)
  +(see /root/xfstests-dev/results//xfs/073.full for details)

  Metadata corruption detected at xfs_agf block 0x1/0x200

  # uname -a
  Linux ltc-tuleta12 4.10.0-21-generic #23~16.04.1-Ubuntu SMP Tue May 2 
12:54:57 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux

  Steps to reproduce:
  
  1. Create a loop device with xfs filesystem
  2. git clone git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git; cd 
xfstests-dev
  3. make
  4. Create a local.conf for running with created loop device
  5.. Run xfstests-dev test  : ./check tests/xfs/073

  Full log is attached.

  == Comment: #2 - Harish Sriram  - 2017-05-31 01:22:11 ==
  (In reply to comment #1)
  > Hi Harish,
  > Can you share the steps used in creating the loop device with xfs filesystem
  > ?
  > 
  > Thank you.

  Create loop device:
  # mkdir /mnt/loop-device /mnt/test /mnt/scratch

  # for i in $(seq 0 1); do fallocate -o 0 -l 5GiB 
/mnt/loop-device/file-$i.img; done
  # for i in $(seq 0 1); do losetup /dev/loop$i /mnt/loop-device/file-$i.img; 
done

  Create File system:
  # for i in $(seq 0 1); do mkfs.ext4 -F /dev/loop$i; done

  # cat local.config
  export TEST_DEV=/dev/loop0
  export TEST_DIR=/mnt/test
  export SCRATCH_DEV=/dev/loop1
  export SCRATCH_MNT=/mnt/scratch

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1705763] Re: PPC64: "mbind: Invalid argument" still seen after 8175813

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1705763

Title:
  PPC64: "mbind: Invalid argument" still seen after 8175813

Status in The Ubuntu-power-systems project:
  Fix Released
Status in openjdk-8 package in Ubuntu:
  Fix Released
Status in openjdk-8 source package in Xenial:
  Fix Released
Status in openjdk-8 source package in Zesty:
  Fix Released

Bug description:
  ---Problem Description---
  PPC64: "mbind: Invalid argument" still seen after 8175813
   
  ---Steps to Reproduce---
   see https://bugs.openjdk.java.net/browse/JDK-8181055
   
  Dear maintainer, please consider applying the following fix to that issue 
already pushed uptream to jdk8u: 
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/d3cc20285653 Thank you.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1655625] Re: ISST-LTE:pVM:roselp4:ubuntu 16.04.2: vmcore cannot be analysed by crash

[Manoj Iyer]

** Tags removed: triage-r
** Tags added: triage-g

** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1655625

Title:
  ISST-LTE:pVM:roselp4:ubuntu 16.04.2: vmcore cannot be analysed by
  crash

Status in The Ubuntu-power-systems project:
  Fix Released
Status in crash package in Ubuntu:
  Fix Released
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in crash source package in Xenial:
  Fix Released
Status in makedumpfile source package in Xenial:
  Fix Released

Bug description:
  [SRU justification]
  This fix is required to make the crash tool usable. It does also improve 
makedumpfile filtering of pages.

  [Impact]
  Kernel crashes cannot be analysed with the crash tool.
  makedumpfile incorrectly filter pages.

  [Fix]
  Cherry-pick upstream commits fixing those issues.

  [Test Case]
  Running crash tool on a kernel crash file will display something like :

  # crash -s usr/lib/debug/boot/vmlinux-4.8.0-34-generic
  crash: read error: kernel virtual address: 81e29ff0  type: 
"pv_init_ops"
  crash: this kernel may be configured with CONFIG_STRICT_DEVMEM, which
     renders /dev/mem unusable as a live memory source.
  crash: trying /proc/kcore as an alternative to /dev/mem

  crash: seek error: kernel virtual address: 81e29ff0  type: 
"pv_init_ops"
  crash: seek error: kernel virtual address: 82166130  type: 
"shadow_timekeeper xtime_sec"
  crash: seek error: kernel virtual address: 81e0d304  type: 
"init_uts_ns"
  crash: usr/lib/debug/boot/vmlinux-4.8.0-34-generic and 
/var/crash/201701191308/dump.201701191308 do not match!

  With the fix, the crash command will work as expected

  Running the crash tool on a vmcore file produced by makedumpfile may
  return :

  crash: page excluded: kernel virtual address: <> type:
  "fill_task_struct"

  [Regression]
  None expected as those modifications are part of the Zesty and upstream 
version.

  The makedumpfile patches are in Yakkety and Zesty 1.6.0 & after

  [Original description of the problem]
  vmcore captured by kdump cannot be opened with crash:

  % sudo crash -d1 /usr/lib/debug/boot/vmlinux-4.8.0-34-generic 
/var/crash/201612282137/dump.201612282137
  ... ...
  base kernel version: 0.8.0
  linux_banner:
  
  crash: /usr/lib/debug/boot/vmlinux-4 and 
/var/crash/201612282137/dump.201612282137 do not match!

  Usage:

    crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (dumpfile form)
    crash [OPTION]... [NAMELIST]  (live system form)

  Enter "crash -h" for details.

  Looks like the 'linux_banner' cannot be understood by crash.

  And when the vmcore was dumping, this message being showed:

  [  729.609196] kdump-tools[5192]: The kernel version is not supported.
  [  729.609447] kdump-tools[5192]: The makedumpfile operation may be 
incomplete.
  ---uname output---
  Linux roselp4 4.8.0-34-generic #36~16.04.1-Ubuntu SMP Wed Dec 21 18:53:20 UTC 
2016 ppc64le ppc64le ppc64le GNU/Linux

  Machine Type = lpar

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

  ---Steps to Reproduce---
   1. config kdump
  2. trigger kdump
  3. analyse vmcore with crash

  Userspace tool common name: crash/makedumpfile

  The userspace tool has the following bit modes: 64-bit

  Userspace rpm: makedumpfile 1.5.9-5ubuntu0.3/crash 7.1.4-1ubuntu4

  Userspace tool obtained from project website:  na

  *Additional Instructions for Ping Tian Han/pt...@cn.ibm.com:
  -Post a private note with access information to the machine that the bug is 
occuring on.
  -Attach ltrace and strace of userspace application.

  xtime timespec.tv_sec: 586481e8: Wed Dec 28 21:24:24 2016
  utsname:
   sysname: Linux
  nodename: boblp1
   release: 4.8.0-32-generic
   version: #34~16.04.1-Ubuntu SMP Tue Dec 13 17:01:57 UTC 2016
   machine: ppc64le
    domainname: (none)
  base kernel version: 4.8.0
  verify_namelist:
  dumpfile /proc/version:
  Linux version 4.8.0-32-generic (buildd@bos01-ppc64el-001) (gcc version 5.4.0 
20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4) ) #34~16.04.1-Ubuntu SMP Tue Dec 
13 17:01:57 UTC 2016 (Ubuntu 4.8.0-32.34~16.04.1-generic 4.8.11)
  /usr/lib/debug/boot/vmlinux-4.8.0-32-generic:
  Linux version 4.8.0-32-generic (buildd@bos01-ppc64el-001) (gcc version 5.4.0 
20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4) ) #34~16.04.1-Ubuntu SMP Tue Dec 
13 17:01:57 UTC 2016 (Ubuntu 4.8.0-32.34~16.04.1-generic 4.8.11)

  hypervisor: (undetermined)
  crash: per_cpu_symbol_search(per_cpu__tvec_bases): NULL
  ppc64_vmemmap_init: vmemmap base: f000

  crash: PPC64: cannot find 'cpu_possible_map', 'cpu_present_map',
  'cpu_online_map' or 'cpu_active_map' symbols

  root@boblp1:/usr/lib/debug/boot# uname -a
  Linux boblp1 4.8.0-32-generic 

[Group.of.nepali.translators] [Bug 1654068] Re: Ubuntu 16.04.02: Error message "kernel version is not supported" is logged during fadump, dump capture will be successful.

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: In Progress => Won't Fix

** Tags added: triage-g

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1654068

Title:
  Ubuntu 16.04.02: Error message "kernel version is not supported" is
  logged during fadump, dump capture will be successful.

Status in The Ubuntu-power-systems project:
  Won't Fix
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Yakkety:
  Won't Fix

Bug description:
  == Comment: #0 - PAVITHRA R. PRAKASH - 2016-12-25 23:00:37 ==
  ---Problem Description---

  Ubuntu 16.04.02: Error message "kernel version is not supported" is
  logged during fadump, dump capture will be successful.

  
  ---Steps to Reproduce---

  1. Configure fadump.
  2. Trigger crash.

  Logs
  =

  root@alp9:/home/ubuntu#  service kdump status
  ? kdump.service
 Loaded: not-found (Reason: No such file or directory)
 Active: inactive (dead)
  root@alp9:/home/ubuntu# kdump-config show
  DUMP_MODE:fadump
  USE_KDUMP:1
  KDUMP_SYSCTL: kernel.panic_on_oops=1
  KDUMP_COREDIR:/var/crash
 /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.8.0-32-generic
  kdump initrd: 
 /var/lib/kdump/initrd.img: symbolic link to 
/var/lib/kdump/initrd.img-4.8.0-32-generic
  current state:ready to fadump


  [-1;-1f[3.187917] 
kdump-tools[1049]: Starting kdump-tools:  * running makedumpfile -c -d 31 
/proc/vmcore /var/crash/201612220208/dump-incomplete
  Copying data   : [100.0 %] |
  [5.711820] kdump-tools[1049]: The kernel version is not supported.
  [5.712201] kdump-tools[1049]: The makedumpfile operation may be 
incomplete.
  [5.712515] kdump-tools[1049]: The dumpfile is saved to 
/var/crash/201612220208/dump-incomplete.
  [5.712849] kdump-tools[1049]: makedumpfile Completed.
  [5.720901] kdump-tools[1049]:  * kdump-tools: saved vmcore in 
/var/crash/201612220208
  [5.916826] kdump-tools[1049]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/201612220208/dmesg.201612220208
  [5.941113] kdump-tools[1049]: The kernel version is not supported.
  [5.941612] kdump-tools[1049]: The makedumpfile operation may be 
incomplete.
  [5.941969] kdump-tools[1049]: The dmesg log is saved to 
/var/crash/201612220208/dmesg.201612220208.
  [5.942340] kdump-tools[1049]: makedumpfile Completed.
  [5.942648] kdump-tools[1049]:  * kdump-tools: saved dmesg content in 
/var/crash/201612220208
  [5.994508] kdump-tools[1049]: Thu, 22 Dec 2016 02:08:35 -0500
  [6.018241] kdump-tools[1049]: Rebooting.
  [6.025884] reboot: Restarting system

  == Comment: #3 - Hari Krishna Bathini  - 2017-01-04 07:14:19 ==

  Canonical,

  Please pick the latest version of makedumpfile (v1.6.1) which
  officially supports 4.8 kernels.

  Thanks
  Hari

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1696710] Re: Ubuntu 16.04.02: depmod: WARNING: needs unknown symbol .TOC.

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1696710

Title:
  Ubuntu 16.04.02: depmod: WARNING:  needs unknown symbol
  .TOC.

Status in The Ubuntu-power-systems project:
  Fix Released
Status in kmod package in Ubuntu:
  Fix Released
Status in kmod source package in Xenial:
  Fix Committed

Bug description:
  == Comment: #0 - Douglas Miller  - 2017-01-24 07:59:54 ==
  ---Problem Description---
  depmod does not handle .TOC symbol on powerpc platforms
   
  Contact Information = Douglas Miller  
   
  ---uname output---
  Linux p8le03 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:40:06 UTC 2016 
ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = other 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   Compile kernel, during modules_install target the messages appear. PPC64 
modules have a .TOC symbol which is required. It may be the only symbol with a 
period in the name, and so tools that restrict symbols based on a pattern may 
neglect to include .TOC.
   
  Userspace tool common name: depmod 
   
  The userspace tool has the following bit modes: 64 

  Userspace rpm: libkmod2:ppc64el

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for Douglas Miller :
  -Attach ltrace and strace of userspace application.

  == Comment: #3 - Douglas Miller  - 2017-01-24 08:12:58 ==
  kmod package:

  # dpkg --list |grep kmod
  ii  kmod   22-1ubuntu4
 ppc64el  tools for managing Linux kernel modules
  ii  libkmod2:ppc64el   22-1ubuntu4
 ppc64el  libkmod shared library

  == Comment: #7 - Douglas Miller  - 2017-06-07 16:20:38 ==
   I was doing a build of upstream origin/master on Ubuntu 16.04.2 fresh 
install and still getting these messages. In the "make modules_install" output 
I see:

  ...
DEPMOD  4.12.0-rc4
  depmod: WARNING: 
/lib/modules/4.12.0-rc4/kernel/arch/powerpc/kernel/rtas_flash.ko needs unknown 
symb
  ol .TOC.
  ...

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1701698] Re: update skiboot to 5.4.3 in xenial

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: New => Fix Released

** Tags added: triage-g

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1701698

Title:
  update skiboot to 5.4.3 in xenial

Status in The Ubuntu-power-systems project:
  Fix Released
Status in skiboot package in Ubuntu:
  Fix Released
Status in skiboot source package in Xenial:
  Fix Committed

Bug description:
  [Impact]

  skiboot is a hardware enablement component used by certain POWER systems and 
should be kept up-to-date on LTS releases. The new upstream version of skiboot 
is required for xenial to support the new POWER9 systems.
  The new upstream version update was requested by upstream and includes only 
hardware enablement changes and bugfixes, making it an ideal case for a new 
microrelease backport.

  [Test Case]

  On a supported system, upgrade opal-prd and opal-utils. Reboot and
  verify that system works as expected. Verify that the opal-prd service
  is running with `systemctl status opal-prd`, make sure there are no
  worrying error messages in the logs.

  [Regression Potential]

  Any new upstream release can introduce potential regressions. The opal-prd 
service is used for diagnostics and runtime maintenance of POWER systems, 
meaning a critical regression can cause the system being unusable.
  The requested release is in zesty since the end of May 2017 and no critical 
issues have been reported so far. Also, seeing that the package is still in 
universe and only targets specific ppc64el hardware, in the case of a 
regression the number of affected users should be relatively low.

  [Original Description]

  Dear Canonical,

  Current skiboot version on Xenial is not enough to full support POWER9
  machines, and the backport is not trivial, since it involves a lot of
  commit,

  We would like to migrate skiboot version 5.4.3, from Zesty into
  xenial-updates, if possible.

  Thank you,

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1557751] Re: makedumpfile generates kernel version error

[Manoj Iyer]

** Changed in: ubuntu-power-systems
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1557751

Title:
  makedumpfile generates kernel version error

Status in The Ubuntu-power-systems project:
  Fix Released
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Trusty:
  Confirmed
Status in makedumpfile source package in Xenial:
  Fix Released
Status in makedumpfile source package in Yakkety:
  Confirmed

Bug description:
  == Comment: #7 - Vaishnavi Bhat  - 2016-03-15 06:16:53 ==
  The following warning is generated by makedumpfile 
  * running makedumpfile --dump-dmesg /proc/vmcore 
/mnt/201602030129/dmesg.201602030129
  The kernel version is not supported.
  The created dumpfile may be incomplete.

  The makedumpfile version on your machine is 
  # makedumpfile -v
  makedumpfile: version 1.5.5 (released on 18 Dec 2013)

  I did a #sudo apt-get source makedumpfile and checked for the sources. 
  In the makedumpfile.h ,  the LATEST_VERSION is set to
  #define OLDEST_VERSION  KERNEL_VERSION(2, 6, 15)/* linux-2.6.15 */
  #define LATEST_VERSION  KERNEL_VERSION(4, 1, 0)/* linux-4.1.0 */
  where as kernel version on the machine is 
  # uname -r
  4.2.0-27-generic

  Hence we see this mismatch and message as "The kernel version is not
  supported."

  We need canonical to change the value of LATEST_VERSION  so that we do
  not see this message.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1655625] Re: ISST-LTE:pVM:roselp4:ubuntu 16.04.2: vmcore cannot be analysed by crash

[Manoj Iyer]

** Changed in: makedumpfile (Ubuntu)
 Assignee: Louis Bouchard (louis) => Nish Aravamudan (nacc)

** Also affects: ubuntu-power-systems
   Importance: Undecided
   Status: New

** Changed in: crash (Ubuntu)
 Assignee: (unassigned) => Nish Aravamudan (nacc)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1655625

Title:
  ISST-LTE:pVM:roselp4:ubuntu 16.04.2: vmcore cannot be analysed by
  crash

Status in The Ubuntu-power-systems project:
  New
Status in crash package in Ubuntu:
  Confirmed
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in crash source package in Xenial:
  Fix Released
Status in makedumpfile source package in Xenial:
  Fix Released

Bug description:
  [SRU justification]
  This fix is required to make the crash tool usable. It does also improve 
makedumpfile filtering of pages.

  [Impact]
  Kernel crashes cannot be analysed with the crash tool.
  makedumpfile incorrectly filter pages.

  [Fix]
  Cherry-pick upstream commits fixing those issues.

  [Test Case]
  Running crash tool on a kernel crash file will display something like :

  # crash -s usr/lib/debug/boot/vmlinux-4.8.0-34-generic
  crash: read error: kernel virtual address: 81e29ff0  type: 
"pv_init_ops"
  crash: this kernel may be configured with CONFIG_STRICT_DEVMEM, which
     renders /dev/mem unusable as a live memory source.
  crash: trying /proc/kcore as an alternative to /dev/mem

  crash: seek error: kernel virtual address: 81e29ff0  type: 
"pv_init_ops"
  crash: seek error: kernel virtual address: 82166130  type: 
"shadow_timekeeper xtime_sec"
  crash: seek error: kernel virtual address: 81e0d304  type: 
"init_uts_ns"
  crash: usr/lib/debug/boot/vmlinux-4.8.0-34-generic and 
/var/crash/201701191308/dump.201701191308 do not match!

  With the fix, the crash command will work as expected

  Running the crash tool on a vmcore file produced by makedumpfile may
  return :

  crash: page excluded: kernel virtual address: <> type:
  "fill_task_struct"

  [Regression]
  None expected as those modifications are part of the Zesty and upstream 
version.

  The makedumpfile patches are in Yakkety and Zesty 1.6.0 & after

  [Original description of the problem]
  vmcore captured by kdump cannot be opened with crash:

  % sudo crash -d1 /usr/lib/debug/boot/vmlinux-4.8.0-34-generic 
/var/crash/201612282137/dump.201612282137
  ... ...
  base kernel version: 0.8.0
  linux_banner:
  
  crash: /usr/lib/debug/boot/vmlinux-4 and 
/var/crash/201612282137/dump.201612282137 do not match!

  Usage:

    crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (dumpfile form)
    crash [OPTION]... [NAMELIST]  (live system form)

  Enter "crash -h" for details.

  Looks like the 'linux_banner' cannot be understood by crash.

  And when the vmcore was dumping, this message being showed:

  [  729.609196] kdump-tools[5192]: The kernel version is not supported.
  [  729.609447] kdump-tools[5192]: The makedumpfile operation may be 
incomplete.
  ---uname output---
  Linux roselp4 4.8.0-34-generic #36~16.04.1-Ubuntu SMP Wed Dec 21 18:53:20 UTC 
2016 ppc64le ppc64le ppc64le GNU/Linux

  Machine Type = lpar

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

  ---Steps to Reproduce---
   1. config kdump
  2. trigger kdump
  3. analyse vmcore with crash

  Userspace tool common name: crash/makedumpfile

  The userspace tool has the following bit modes: 64-bit

  Userspace rpm: makedumpfile 1.5.9-5ubuntu0.3/crash 7.1.4-1ubuntu4

  Userspace tool obtained from project website:  na

  *Additional Instructions for Ping Tian Han/pt...@cn.ibm.com:
  -Post a private note with access information to the machine that the bug is 
occuring on.
  -Attach ltrace and strace of userspace application.

  xtime timespec.tv_sec: 586481e8: Wed Dec 28 21:24:24 2016
  utsname:
   sysname: Linux
  nodename: boblp1
   release: 4.8.0-32-generic
   version: #34~16.04.1-Ubuntu SMP Tue Dec 13 17:01:57 UTC 2016
   machine: ppc64le
    domainname: (none)
  base kernel version: 4.8.0
  verify_namelist:
  dumpfile /proc/version:
  Linux version 4.8.0-32-generic (buildd@bos01-ppc64el-001) (gcc version 5.4.0 
20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4) ) #34~16.04.1-Ubuntu SMP Tue Dec 
13 17:01:57 UTC 2016 (Ubuntu 4.8.0-32.34~16.04.1-generic 4.8.11)
  /usr/lib/debug/boot/vmlinux-4.8.0-32-generic:
  Linux version 4.8.0-32-generic (buildd@bos01-ppc64el-001) (gcc version 5.4.0 
20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4) ) #34~16.04.1-Ubuntu SMP Tue Dec 
13 17:01:57 UTC 2016 (Ubuntu 4.8.0-32.34~16.04.1-generic 4.8.11)

  hypervisor: (undetermined)
  crash: per_cpu_symbol_search(per_cpu__tvec_bases): NULL
  ppc64_vmemmap_init: vmemmap base: f000

  crash: PPC64: cannot find 'cpu_possible_map', 'cpu_present_map',
  

[Group.of.nepali.translators] [Bug 1651518] Re: systemd/logind parsing problem: HTX exercisers stopped on error: rc 11, errno 11 from main(): pthread_create

[Manoj Iyer]

** Also affects: ubuntu-power-systems
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1651518

Title:
  systemd/logind parsing problem: HTX exercisers stopped on error: rc
  11, errno 11 from main(): pthread_create

Status in The Ubuntu-power-systems project:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  New
Status in systemd source package in Yakkety:
  Fix Released

Bug description:
  [SRU justification]
  Before systemd 232, UserTasksMax=infinity is not respected in logind.conf, 
despite the documentation referring to systemd.resource-control(5) for the 
definition of this field. This limits the use of Ubuntu 16.04 and later in 
contexts where a user session should be permitted to allocate large numbers of 
processes.

  [Test case]
  1. Set UserTasksMax=infinity in /etc/systemd/logind.conf.
  2. Create a new login session.
  3. Check the ulimit for user processes with 'ulimit -u'.
  4. Verify that the limit has a numeric value.
  5. Upgrade to systemd from -proposed.
  6. Create a new login session.
  7. Check the ulimit for user processes with 'ulimit -u'.
  8. Verify that the limit is now set to 'unlimited'.

  [Regression potential]
  This is an upstream patch which is part of 232 and later without issues and 
clearly addresses the bug in question.  While the upstream commit includes code 
changes that are not strictly required in order to fix this bug, these are 
mostly cosmetic and should not carry significant additional risk.


  == Comment: #1 - Application Cdeadmin  -
  2016-12-19 04:15:10 ==

  Configuration: IBM 8001-22C (S822LC), LSI SAS adapters, SMC 4U90 disk
  drawers, HDD (180) 7.3TB

  Problem: HTX exercisers stopped on error, with HTX log showing "rc 11,
  errno 11 from main(): pthread_create"

  htxubuntu-425

  lpar: busybee.aus.stglabs.ibm.com (root/ lab passwd)

  root@busybee:~# uname -a
  Linux busybee 4.4.0-51-generic #72-Ubuntu SMP Thu Nov 24 18:27:59 UTC 2016 
ppc64le ppc64le ppc64le GNU/Linux

  root@busybee:~# cat /tmp/htxerr

  /dev/sdh  Dec 12 23:52:42 2016 err=000b sev=1 hxestorage
  rc 11, errno 11 from main(): pthread_create

  /dev/sdh  Dec 12 23:52:42 2016 err=000b sev=1 hxestorage
  Hardware Exerciser stopped on an error

  /dev/sdao Dec 12 23:52:42 2016 err=000b sev=1 hxestorage
  rc 11, errno 11 from main(): pthread_create

  /dev/sdao Dec 12 23:52:42 2016 err=000b sev=1 hxestorage
  Hardware Exerciser stopped on an error

  /dev/sddx Dec 12 23:52:42 2016 err=000b sev=1 hxestorage
  rc 11, errno 11 from main(): pthread_create

  /dev/sddx Dec 12 23:52:42 2016 err=000b sev=1 hxestorage
  Hardware Exerciser stopped on an error

  /dev/sdcz Dec 12 23:52:42 2016 err=000b sev=1 hxestorage
  rc 11, errno 11 from main(): pthread_create

  /dev/sdcz Dec 12 23:52:42 2016 err=000b sev=1 hxestorage
  Hardware Exerciser stopped on an error

  /dev/sddp Dec 12 23:52:42 2016 err=000b sev=1 hxestorage
  rc 11, errno 11 from main(): pthread_create

  /dev/sddp Dec 12 23:52:42 2016 err=000b sev=1 hxestorage
  Hardware Exerciser stopped on an error

  No errors logged in syslog after starting HTX:

   State: Open by: asperez on 16 December 2016 10:28:02 
  This error recreated on the smaller 1U Open Power system with the same 
smaller 1-adapter/1-4U90 drawer/90 HDD. There are 2 cables connected to the 
drawer (one to each ESM) that requires multipath enabled.

  lpar: yellowbee

  root@yellowbee:~# cat /tmp/htxerr

  /dev/sdao Dec 16 01:14:44 2016 err=000b sev=1 hxestorage
  rc 11, errno 11 from main(): pthread_create

  /dev/sdak Dec 16 01:14:44 2016 err=000b sev=1 hxestorage
  rc 11, errno 11 from main(): pthread_create

  /dev/sdt  Dec 16 01:14:44 2016 err=000b sev=1 hxestorage
  rc 11, errno 11 from main(): pthread_create

  /dev/sdaz Dec 16 01:14:44 2016 err=000b sev=1 hxestorage
  rc 11, errno 11 from main(): pthread_create

  /dev/sdn  Dec 16 01:14:44 2016 err=000b sev=1 hxestorage
  rc 11, errno 11 from main(): pthread_create

  /dev/sdv  Dec 16 01:14:44 2016 err=000b sev=1 hxestorage
  rc 11, errno 11 from main(): pthread_create

  /dev/sdaj Dec 16 01:14:44 2016 err=000b sev=1 hxestorage
  rc 11, errno 11 from main(): pthread_create

  /dev/sdal Dec 16 01:14:44 2016 err=000b sev=1 hxestorage
  rc 11, errno 11 from main(): pthread_create

   State: Open by: cde00 on 19 December 2016 02:48:46 

  This defect will go to Linux as even after making the below 2 changes
  in systemd resource limit, errors are seen:

  root@yellowbee:/etc/systemd/logind.conf.d# cat 

[Group.of.nepali.translators] [Bug 1663400] Re: kexec: arm64: Increase the upper limit for RAM segments

[Manoj Iyer]

** Summary changed:

- [SRU] kexec: arm64: Increase the upper limit for RAM segments
+ kexec: arm64: Increase the upper limit for RAM segments

** Bug watch added: Debian Bug tracker #854826
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854826

** Also affects: kexec-tools (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854826
   Importance: Unknown
   Status: Unknown

** Changed in: kexec-tools (Ubuntu Xenial)
 Assignee: (unassigned) => Manoj Iyer (manjo)

** Changed in: kexec-tools (Ubuntu Yakkety)
 Assignee: (unassigned) => Manoj Iyer (manjo)

** Changed in: kexec-tools (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: kexec-tools (Ubuntu Yakkety)
   Status: New => In Progress

** Changed in: kexec-tools (Ubuntu)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1663400

Title:
  kexec: arm64: Increase the upper limit for RAM segments

Status in kexec-tools package in Ubuntu:
  In Progress
Status in kexec-tools source package in Xenial:
  In Progress
Status in kexec-tools source package in Yakkety:
  In Progress
Status in kexec-tools package in Debian:
  Unknown

Bug description:
  [Impact]
  Currently kexec is unable to see all the "System RAM" recorded in /proc/iomem.

  On a newer UEFI based Qualcomm target the number of system ram regions
  retrieved from /proc/iomem  are ~40. Currently KEXEC_SEGMENT_MAX is
  set to 16, which represents the kexec segments passed to kexec_load
  syscall, like kernel image, initrd image etc. The patch increases the
  value to 64. This enables kexec to see all the "System RAM" as
  recorded in /proc/iomem.

  [Test Case]
  == System RAM reported by /proc/iomem ==
  ubuntu@ubuntu:~$ sudo cat /proc/iomem | grep "System RAM"
  0020-0020 : System RAM
  0082-0307 : System RAM
  0308-0308 : System RAM
  0309-031f : System RAM
  0320-033f : System RAM
  0341-0589 : System RAM
  058a-058a : System RAM
  058b-058b : System RAM
  058c-0597 : System RAM
  0598-05987fff : System RAM
  05988000-0598bfff : System RAM
  0598c000-05a0 : System RAM
  05a1-05aa : System RAM
  05ab-05ca0fff : System RAM
  05ca1000-08ca : System RAM
  08cb-08cf : System RAM
  08d0-08ed : System RAM
  08ee-08ee0fff : System RAM
  08ee1000-08ee3fff : System RAM
  08ee4000-08ee : System RAM
  08ef-092a : System RAM
  092b-092d : System RAM
  092e-09422fff : System RAM
  09423000-0949 : System RAM
  094a-0957 : System RAM
  0958-0958cfff : System RAM
  0958d000-098c : System RAM
  098d-098d0fff : System RAM
  098d1000-098dbfff : System RAM
  098dc000-0e8b : System RAM
  0e8c-0e8e : System RAM
  0e8f-0fff : System RAM
  1080-17fe : System RAM
  1c02-1c7f : System RAM
  1c80-1c80 : System RAM
  1c81-7efb : System RAM
  7efc-7efd : System RAM
  7efe-7efe : System RAM
  7eff-7eff : System RAM
  7f00-17 : System RAM
  ubuntu@ubuntu:~$

  == BEFORE PATCH: System RAM reported by kexec ==
  ubuntu@ubuntu:~$ sudo kexec -d -l /boot/vmlinuz-4.7.0-2-generic --reuse-cmd 
--initrd=/boot/initrd.img-4.7.0-2-generic | grep "System RAM"
  get_memory_ranges_iomem_cb: 0020 - 0020 : System RAM
  get_memory_ranges_iomem_cb: 0082 - 0307 : System RAM
  get_memory_ranges_iomem_cb: 0308 - 0308 : System RAM
  get_memory_ranges_iomem_cb: 0309 - 031f : System RAM
  get_memory_ranges_iomem_cb: 0320 - 033f : System RAM
  get_memory_ranges_iomem_cb: 0341 - 0589 : System RAM
  get_memory_ranges_iomem_cb: 058a - 058a : System RAM
  get_memory_ranges_iomem_cb: 058b - 058b : System RAM
  get_memory_ranges_iomem_cb: 058c - 0597 : System RAM
  get_memory_ranges_iomem_cb: 0598 - 05987fff : System RAM
  get_memory_ranges_iomem_cb: 05988000 - 0598bfff : System RAM
  get_memory_ranges_iomem_cb: 0598c000 - 05a0 : System RAM
  get_memory_ranges_iomem_cb: 05a1 - 05aa : System RAM
  get_memory_ranges_iomem_cb: 05ab - 05ca0fff : System RAM
  get_memory_ranges_iomem_cb: 05ca1000 - 08ca : System RAM
  get_memory_ranges_iomem_cb: 08cb - 08cf : System RAM

  ==AFTER PATCH: System RAM reported by kexec ==
  ubuntu@ubuntu:~$ sudo kexec -d -l /boot/vmlinuz-4.7.0-2-generic --reuse-cmd 
--initrd=/boot/initrd.img-4.7.0-2-generic | grep "System RAM"
  get_memory_